[e2e] Open the floodgate

[Cannara]

What about Sony, Jon -- Playstations are already being amassed to build
supercomputers because of their graphics power/$?  Isn't Sony nicer than
uSoft?  :]

Alex

Jon Crowcroft wrote:
> 
> 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