[e2e] It's all my fault

[Jon Crowcroft]

which reminds me, BGP is totally backwards if you want to control
qos, and yet MPLS which has the right model for path engineering has the wrong
model for interdomain

how do we reconcile needs (complexity) of interdomain relationships in terms of
controling transit traffic etc , and needs for engineering paths for sources -
ones a sink and the other a source based activity - i know there;'s lots of BGP
workaround hacks (esp since various VOIP things make demands) but are there any
architecturally pleasant  ideas around?

In missive <20070516.001750.784.350796 at webmail24.lax.untd.com>, "Fergie" typed:

 >>Wait, wait.

 >>Let's take a bit better effort to define what we're talking
 >>about here.
 >>
 >>Traffic Engineering these days takes one of two forms; one
 >>being the ability to multi-home and propagate a particular
 >>preference in the [forwarding|reverse] path (given certain
 >>parameters), and secondly the ability to establish paths via
 >>some MPLS VPN magic (primarily).
 >>
 >>I think we need to be a little more specific when talk about TE,
 >>given the architectural implications.
 >>
 >>- ferg
 >>
 >>
 >>-- Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk> wrote:
 >>
 >>so your point about TE in previous message was on the money
 >>in one sense - customers (oops, sorry end users) bypassing the routes
 >>chosen by ISPs who are doin TE may undermine its effectiveness
 >>
 >>but TE typically operates to optimise for 1 objective function (e.g.
 >>loss or
 >>throughput) and much measurement shows that even within an ISP and
 >>certainly
 >>interdomain, the customer can (and some want to) optimise for a
 >>different goal
 >>which IP and BGP doesnt give ISPs tools  to do - e.g. delay or reliabili=
 >>ty
 >>
 >>I might agree (loose/lose) source routing might not be the tool for
 >>this. how
 >>about loose destination routing? I am not just making a joke here- two
 >>runaway
 >>successes in the intenret, mobile IP and multicast (home agents and PIM
 >>RPs), =
 >>
 >>both allow the user to
 >>control how traffic _reaches_ them - i think this is a more useful
 >>feature than
 >>controlling how I can send traffic to someone via someone, neither of
 >>whom might
 >>want my traffic anywhere near them - one could imagine a number of DoS
 >>mitagating
 >>tricks if some technique for loose destiantion routeing were devised -
 >>and one
 >>could use it for the debugging mentioned by someone (just as one uses
 >>traceroute
 >>and route view servers to gain multiple viewpoints on the net over
 >>time...only
 >>more directly part of the IP routing "service")
 >>
 >>LSR:
 >>loneliniess of the long distance runner
 >>or
 >>goalkeepers fear of the penalty?
 >>
 >>-----aside:
 >>oh routing on end systems - Xorp and Quagga work really quite well, and
 >>at least
 >>in our experience, xorp might end up being quite comercially viable in
 >>terms of
 >>robust code and interworking...
 >>
 >>----
 >>
 >>In missive
 >><Pine.LNX.4.44.0705151217100.10404-100000 at gato.kotovnik.com>, Vadim
 >>Antonov typ
 >>ed:
 >>
 >> >>On Tue, 15 May 2007, Jon Crowcroft wrote:
 >> >>
 >> >>> if we took ALL routing out of routers, life _would_ be simpler - =
 >>
 >> >>
 >> >>That's cute, but does not address the reason why SR is nearly useless=
 >> in
 >> >>the real life - namely that endpoints lack the up-to-date network
 >>topology
 >> >>information.  To specify a path for a packet one has to know what pat=
 >>hs
 >> >>are available and feasible.
 >> >>
 >> >>> running path computation on boxed _designed_ to do computation
 >> >>> and forwarding on boxeds designed to switch packets fast
 >> >>> just sounds like a perfectly reasonable idea to me
 >> >>
 >> >>Yep. It sounds good until you actually try to put together a working
 >> >>network based on that idea.  Which immediately uncovers the =
 >>
 >> >>aforementioned problem.
 >> >>
 >> >>> ISPs and router vendors, which is why they complain so much about
 >>every time
 >> >>> it when its  discussed...
 >> >>
 >> >>It could be because they do have extensive real-life experience with =
 >>=
 >>
 >> >>backbone networking and large-scale routing, couldn't it?
 >> >> =
 >>
 >> >>> given we havnt actually tried this approach (at the level where end=
 >>
 >> >>> users have access to it)
 >> =
 >>
 >> >>You're mistaken. It was tried, and was rightfully rejected because it=
 >>
 >> >>sucked.  (BTW, one of the most popular little toys I made was a thing=
 >>ie
 >> >>which did domain name-based e-mail routing over UUCP - not by trackin=
 >>g
 >> >>global topology maps a la pathalias, but by insertion of the next hop=
 >>
 >> >>lookup step at every transit point.  No more stuck e-mail trying to g=
 >>et
 >> >>along a precomputed path which has one hop down. That thingie was a
 >>smash
 >> >>hit in the place where phone lines used to be so notoriously flaky th=
 >>at
 >> >>every rain caused a singificant portion of them to get so bad that
 >>modems
 >> >>couldn't connect.)
 >>
 >>um, yes, well it sucked because of the fast v. slow path router
 >>hardware (it was
 >>an early deployment optioon for IP multicast but reversion to other
 >>tunneling
 >>technqiuues quickly happned when the impact on unicast of having the mai=
 >>n
 >>processor deal with all the audio/video streaming traffic that Van et
 >>al were
 >>doing back in 1988 was felt...) - but thats not a network architectural
 >>objection
 >>its a router hardware design limitation...(and not common to all router
 >>hardware
 >>designs and not therefore inevitable
 >> =
 >>
 >> >>> since the old token/proteon ring and IBM stuff, I think claims
 >>about its
 >> >>> legitimacy or otherwise are moot
 >> =
 >>
 >> >>See many token rings around nowadays?
 >>
 >>ah, well no - but nor do we see slotted rings which were cheap as
 >>ethernet and
 >>gave resource guarantees- the best doesnt always win:)
 >>
 >> >>> as you say, for debugging, it has been quite useful in the past to
 >>some people =
 >>
 >> >>> within the service...
 >> =
 >>
 >> >>Ah, debugging.  It makes zero engineering sense to put a feature used=
 >> =
 >>
 >> >>primarily in debugging into the expensive and highly optimized fast
 >>packet =
 >>
 >> >>path. So what real routers typically do (with rare exceptions) is =
 >>
 >> >>bouncing all packets with IP options to the slow path (i.e. software)=
 >>.
 >>
 >>v. good point -
 >>
 >> >>And, of course, the fast path and slow path components use different
 >> >>forwarding tables, physically residing in different memories.  Which
 >> >>sometimes get desynchronized. Or simply broken.  When you have couple=
 >> of
 >> >>thousand routers in your network this kind of things tend to happen
 >>to you
 >> >>now and then.
 >> >>
 >> >>When you use diagnostic tools relying on the same kind of packets as
 >>the =
 >>
 >> >>payload traffic, you have much higher confidence that they show you
 >>what =
 >>
 >> >>happens to the real payload. The very first encounter with a fried
 >>silicon =
 >>
 >> >>switching engine tends to teach network engineers to use straightforw=
 >>ard
 >> >>packet probes like ping and traceroute and avoid using fancy stuff in=
 >> =
 >>
 >> >>their day-to-day work.
 >> =
 >>
 >> >>> you know without those pesker users asking for IP adresses =
 >>
 >> >>> and routes and the ability to send data to each other
 >> >>> the internet would be a whole lot Gooder
 >> >>> and google would clearly do no Evil provably.
 >>
 >> >>It is useless to portrait network operator guys as control freaks. IS=
 >>Ps =
 >>
 >> >>own their backbones, so it is *their* business decision to select
 >>routing =
 >>
 >> >>policies which make economic sense to them.  They have to make
 >>profit, or =
 >>
 >> >>they are dead meat. Capitalism 101.
 >>
 >>sure - but if we do build an internet that offers choice (like the
 >>phone net
 >>does) e.g. because of regulation (oops - sorry, government: bad word in =
 >>the
 >>US:)...
 >>
 >> >>The pesky customers pay them to get packets delivered, and the ISPs a=
 >>re =
 >>
 >> >>keenly aware of that fact. If there were any significant number of =
 >>
 >> >>customers absolutely positively wanting to control the paths their
 >>packets =
 >>
 >> >>take, and willing to pay for that, ISPs would build networks supporti=
 >>ng =
 >>
 >> >>this functionality.
 >>
 >>see above on TE objectives versus customer SLA needs
 >>
 >> >>The reality is, of course, that customers do not care about paths. Th=
 >>ey
 >> >>care about loss, end-to-end bandwidth and latency. So they actually p=
 >>ay
 >> >>money to ISPs to make routing decisions for them. This is called
 >>"division =
 >>
 >> >>of labour".
 >> =
 >>
 >> yes - i am not trying to disturb that completely
 >>
 >> cheers
 >>
 >>   jon
 >>
 >>
 >>
 >>--
 >>"Fergie", a.k.a. Paul Ferguson
 >> Engineering Architecture for the Internet
 >> fergdawg(at)netzero.net
 >> ferg's tech blog: http://fergdawg.blogspot.com/
 >>

 cheers

   jon