[e2e] Open the floodgate

[Jon Crowcroft]

so the one thing you could "add" in the network is somethign that we discussed on this list before
(i think it was JMS who put it that the real purist end2end thing would be to take routing decisions out of the net
and put them in the end systems too along with error recovery) - 

if you want to do mechanism design to align incentives for provider and subscriber, then you need to allow
subscriber to choose provider (c.f. kelly's dual formulation of congestion control too) - this means you need (at
least loose) source routing 

if you do this one thing, then users can avoid bad providers. proiders still have to do some sort of route
computation, route advertisement, and  congestion feedback (could be loss or ECN or whatever), but then there is a
level playing field between the users and the network, which there isnt today

going back to the model of TCP and path wonderfulness or other design-mischoices, this puts incentives on providers
to make sure their choice of kit (and redunddncey in routes) is good enough (not perfect, but just good enough)...

so basically, something like NIMROD instead of BGP would be a very fine thing at this point in time...

but of course, e2e doest do routing:-)

so in the absence of the right solution, someone would argue for some sort of path characteristic feedback
protocol (like the combination of ECN and MTU discovery and anything else like link capacity feedback) - but 
i feel that without (session timescale) route choice, its futile adding this and doesnt stop the network provider
gaming the field ANYHOW...

I wonder if microsoft could be pursuaded to get into the router market - hey, the xbox might make quite a good
router (use the graphics card to do the packet processing stuff on IP headers and prefix match, 
and the main processor to run incremental fast dijkstra (fibinacci heaps etc) and it ought to do quite well- of
course there's I/O and line cards,but maybe with a fore/marconi switch along side (PACE, ipsilon) and 
a whole new mpls/nimrod/ipv6 net could emerge, and then TCP (and bittorrent) would all work beautifully (even over
wireless networks)

just call me Dr Pangloss:-)


In missive <20040423011240.2A52986AE1 at mercury.lcs.mit.edu>, Noel Chiappa typed:

 >>    > From: "Christian Huitema" <huitema at windows.microsoft.com>
 >>
 >>    > The problem with a strict transport-layer approach is that transport
 >>    > actors may well have an incentive to cheat and maximize their immediate
 >>    > satisfaction ...
 >>    > If you want an approach that resists gaming, you probably need to
 >>    > involve the network.
 >>
 >>I'm not a priori against adding such function, but neither am I a priori for
 >>it. I've heard this reasoning before, and it has a certain amount of
 >>plausibility. Then again, the argument about voice needing to bound delay
 >>jitter sounds plausible too, but people seem to be deploying packet voice
 >>without ubiquitous deployment of IntServ.
 >>
 >>Part of the reason I'm a bit dubious is that it seems to me that in the
 >>contemporary network, at least, congestion is most likely to happen at the
 >>ends, most likely on the drop to the individual host. If so, you'd only be
 >>protecting people against themselves. The network core is not congested,
 >>nor congestable through anything but a massive DDoS attack.
 >>
 >>Still, maybe it's the right thing, but that's really a separate point from
 >>confusing error and congestion drops.
 >>
 >>
 >>    > you would want to implement a response function in the network where
 >>    > abuse of a congested link would lead to a lesser goodput than playing
 >>    > by the rules.
 >>
 >>Yes, but you don't have to get the end-end involved to make that kind of
 >>thing happen. People have devised drop functions for routers that do this,
 >>without any explicit interaction with the transport layer, IIRC.
 >>
 >>	Noel

 cheers

   jon