[e2e] It's all my fault

[Jon Crowcroft]

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 reliability

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 paths
 >>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 thingie
 >>which did domain name-based e-mail routing over UUCP - not by tracking
 >>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 get
 >>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 that
 >>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 main
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 straightforward
 >>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. ISPs 
 >>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 are 
 >>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 supporting 
 >>this functionality.

see above on TE objectives versus customer SLA needs

 >>The reality is, of course, that customers do not care about paths. They
 >>care about loss, end-to-end bandwidth and latency. So they actually pay
 >>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