[e2e] What happen "after slow start"

[Black_David@emc.com]

Jon,

> 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?

a) Because nothing out there is perfect, and TCP is very good
at dealing with little things that go awry when you least
expect them.

b) Because TCP provides an end-to-end check on whether the link
is still behaving as provisioned, although this entails endpoint
cluefulness in knowing what to look for and how to make
sense of it.

> 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

IMHO, what this overlooks is that there is a range of situations
between 1 and 2.  What's needed is a way for flows that can use
high bandwidth to use it when it's available without stomping
on "ordinary" flows.  There's been no lack of research in this
area, to the point that an IRTF RG was announced at IETF in Paris
for the express purpose of sorting through all the research ideas
and figuring out which one(s) to get serious about.  I don't see
that group on the IRTF's list of RGs on their web site yet ...

> 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.

Also see draft-ietf-tsvwg-quickstart-01.txt (-02 should be
coming out shortly, but it won't change the basic idea of using
an IP option to shadow TTL) for a somewhat less random, but
similar router-centric approach.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------