[e2e] Reacting to corruption based loss

[Jon Crowcroft]

well, it wasnt an entirely serious proposal - more a gedanken experiment 
but yes, if you want to think of it this way - the idea is that the mesh of TCP connections
is an overlay (like RON, but 100% instead of partial), and provides direct information about the capacity pairwise
between all edge points in the net, irrespective of the topology in the interdomain routes.

but if the first (or last) hope is congested  -e.g. its a wireles hop like GPRS or UMTS and shared,
then you would want to run TCP to the first router - this is no new idea either - TCP slice 
or TCP splice approaches have been around a while (not sure which came first - i think the berkeley folks probably
did the first wide area wireless things with two tcp connection 's glommed together at the impedance mimatched
border between the  host/edge, and edge/core router... of course fndamentally such a thing has been around for a
long time since we had dial up with compressed TCP/IP headers and state restoration, but the de-coupling of the
reliabilty, rate and congestion management at this point was a further step in the evolution of end-to-end

if one had edge-to-edge implemeted as a mesh of TCP (and remember it aint going really to scale that well), you
could probably do some _very_ simple DOS and flash crowd mitigation trivially too

so thinking about the scaling, is a million or even 10^9 connections actually mad? there are probbly some nice data
structure tricks one could do to reduce the memory cost, and share redundent connection state, and maybe keep a lot
of it in the same structure if its "similar" enough , - basically, using 
shared memory like shared library for the TCPCBs while they have the same values, and with copy-on-write
when you change more than some delta...

hmmm - quite a fun research project for someone....what is the standard deviation of the values in fields
in the TCPCB data structure distrubtion, over space and time?


In missive <42B0724E.1010906 at cs.uni-goettingen.de>, Xiaoming Fu typed:

 >>Jon,
 >>
 >>Jon Crowcroft wrote:
 >>>  >>>and will lead to  far less memory wastage in hosts runnign all
 >>>  >>>that complicated TCP protcol - they can just send web pages and video
 >>>  >>>and audio and so on as a sequence of IP packets
 >>>  >>>[...]
 >>>  >>>IP over TCP: way to go.
 >>> 
 >>>  >>Yeah right.  What happens if one if the nodes on the path is
 >>>  >>unavailable?  The data just gets dropped. That's completely unacceptable.
 >>> 
 >>> um - sorry - you have lost me - there's a TCP connection from each node to every other node - i can stripe the data
 >>> how i like...
 >>
 >>Your vision of "creating a TCP mesh among (all) first/last hops" sounds 
 >>interesting. Yeah TCP may run well in face of packet loss and path 
 >>dynamics. A question is whether (and if yes, how) an endhost should 
 >>react to congestions indicated by TCP in its first hop? Can this avoid 
 >>re-introducing flow/rate control and fragmentation functions in the 
 >>endhost?
 >>Xiaoming

 cheers

   jon