[e2e] Open the floodgate
cannara at attglobal.net
Fri Apr 23 00:03:38 PDT 2004
What about Sony, Jon -- Playstations are already being amassed to build
supercomputers because of their graphics power/$? Isn't Sony nicer than
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
More information about the end2end-interest