[e2e] What happen "after slow start"

[Jon Crowcroft]

There's a big fast link we want to get reasonable utilisation on.
The reaso nthere's a big fast link is either
1/ its there for a special reason - it goes between two uber-physics labs
and we dont really care what people do with it - why run tcp?
2/ its there as part of the internet and was provisioned for some reason - probably, if it is a public part of the
internet, then if it has a lot of capacity, but is a hop on any reasonable set of possible end-to-end routes,
it is expected to carry a lot of flows. The distribution of access link speeds in the world is not clear, but
assuming its drawn from some sort of obvious statistical distribution, with lots of 56kbps->1Mbps DSL, and slightly
less 1-nMbps VDSL/Cable, and less 10Mbps->Gbps ethernet and so on and that for any given backbone link they are
equally likely to have connections sourced from any and all of these, then it is not reasonable to 
_in the absence of other special knowledge_
modify the behaviour of a distributed resource allocation algorithm

what type of special knowledge could we have (aside from pre-cognition and telepathy)?
(note that case 1/ above is also a type of special knowledge - topological restriction on access to the
bottleneck).

well, we might know about time-of-day traffic variation and take advantage of that. we might have some sort of
_oracle_ that we can consult about the distribution of mice/elephant TCP connections currently on the link, which
might allow us to set TCP slow start parameters slightly more cleverly. We might do something radical - what could
that be?

well, if everyone modifies slow start, in the absence of special knowledge, bad things may happen - but if a few 
modify it, then they may get an unfair advantage. But since people keep asking, when we do not have a magic oracle,
is there somethign we could do that would be a way to get high utilsiation when the bottleneck link is in fact
under-utilisaed, and to avoid the awfully long bogus adventure that TCP has to engage upon to eventually fulfll the
pipe-dream?

here's a strawman proposal:-  apply the good old fashioned ethernet randomness+contention back/off strategy 
to the slow start itself:

step 1  - host looks in a cache of destinations (in the host routing table)
to find a last logged magic number (corresponds to last estimate of
number of other folks using the bottleneck on that route)

step 2 - throw a dice with that many sides - 

step 3 - if this host's number comes up, we get to blast away with a big initial send window and a go-faster increase
function..., otherwise behave normally

Then there's two possible extreme outcomes:

a) the net was in use - we cause quite a bit of loss in the first RTT, but of course, (especialy if the net is
runnign virtual queues and small buffers, as per damon wischik/nick mckeown et al work)
this will settle down to normal behaviour real soon
b) the net was idle, and we will fill it ok and not haev to wait ages.

over some large number of connection attempts like this, I reckon this is also fair

what is needed in the routers in terms of state to improve this hack? well if the router logged in the IGP and EGP
the number of connections current on each hop, then this could be a simple value delivered at the edge of any net
as a service (or we could have a TCP option to record "someone-elses-point-of-view"
(for those who have seen the hitchikers guide to the galazy, you know what i mean)
in general, if you see someone elses point of view, when everyone is in the same boat, then you have basically got
a good handle on how to behave sociably.

anyhow, this is not seriously a proposition, but i think there might be two possible directions to go from here.

j.
p.s.
index I get from vladivostok telephone directory.