[e2e] TCP 'fast start'

[Jon Crowcroft]

two more ideas

1/ in rcp (or xcp) you have 1 rtt before you knwow what values to use for the rate on the conenction.

most applications go through a whole huge pre-amble of lookups of various kinds (ARPs, DNS, route etc etc) - and
various people have proposed nonce/capability too, to prevent DoS - if the routers _advertise_ links with the
number of connections or N_hat in RCP terms) then this could be cached near the edges of the net, and used for
initial rate selection - if we are already considfering cranking the route update frequency up to many times per
second, so that we can do resilience and fast failober fast enough to mask link outages from VOIP, then it would be
easy to add this to OSPF (and to some state stuff per route's bottleneck per AS for BGP) and then we could have
zero RTT convergence on an initial rate

2/ alternative, if every hos embarking on a new TCP connection, as well as slow statre and congestion avoidance,
has a small applet alongside which looks up the route (either by speaking to a nearest OSPF and/or BGP  speaker, or
else by traceroute), then it has a unique mapping from route to _multicast_ address, then hosts
could multicast their TCPCB - this would be done
i) once per RTT 
and
ii) only if the other seen TCPCB parameters (e.g. cwnd and rtt or computed rate) differed a lot
actually, you'd use a trick very much like RTCP timer reconsiderations to set when you send an update...

so then, insteads o having to deploy router modifications to do XCP or RCP or similar ideas, you could just
have a daemon (right now) on any end system, and as long as you had multicast, at relatively low cost, you would
get to see the set of other TCPCBs - this would let you chose rates when routes changed or whan lots of flows
stopped and started, much more quickly...

of course, someone would have to emable multicast, but it seems to me that this is potentially more likely than
someone deploying XCP capable routrrs jsut a tad:)

(3/  I had thought about using PGM for unicast, but thats probably really barking mad)

my 3 eurocents...
In missive <BAYC1-PASMTP017B1DFE8E60B7AD3210BAC08D0 at CEZ.ICE> <BF60659B.1820C%keshav at uwaterloo.ca>, "S. Keshav" typed:

 >>Hi,
 >>    The idea of using environmental variables to optimize TCP start goes
 >>back a while. It is particularly useful for short transfers that complete
 >>before they reach the 'steady-state'. My students and I worked on this in
 >>1999. We used Shared Passive Network Discovery, proposed by Seshan, Stemm,
 >>and Katz to discover connection parameters from a cluster of users to a
 >>popular destination, say, Yahoo, and used this information to choose initial
 >>TCP parameters. Though we only did simulations, our results looked pretty
 >>decent, so maybe Joe, you can actually implement our work :-)
 >>
 >>For more details, please see:
 >>
 >> Y. Zhang, L. Qiu, and S. Keshav, "Speeding Up Short Data Transfers: Theory,
 >>Architecture Support, and Simulation Results," Proc. NOSSDAV 2000, Chapel
 >>Hill, NC, June 2000.
 >>
 >>http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/00/tcpspand_nossdav0
 >>0.pdf
 >>
 >>regards
 >>
 >>keshav
 >>
 >>

 cheers

   jon