[e2e] It's all my fault

[Vadim Antonov]

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.)

> 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?

> 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).

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.

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.

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".

--vadim