[e2e] What happen "after slow start"

[Joe Touch]

Jon Crowcroft wrote:
...
> 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 

FYI, we have a small DARPA project here at ISI looking at that, called
"Adaptive Learning Networks", which is a kind of "smart RFC2140", i.e., it:

    Assumes:
	1) TCP does a good job converging on TCB state over time,
	   but a lousy job of guessing initial conditions

	2) TCP experiences stable stable net over the connection,
           and stable offered load

    Does the following:
	1) records TCB end-of-connection state, as well as
	   'kitchen sink' data (weather, endpoint loc, etc.)

	2) trains an adaptive learning module on the
	   state data (TCB state:kitchen sink state)

	3) sets TCBs of new connections based on predictive
	   lookup (i.e., lookup kitchen sink state and
	   retrieve expected TCB state)

This *could* to bad things over the long term. As you point out below,
there are ways to mitigate this:

	a) roll a dice to decide when to do it

	b) if predictions turn out to be bad, adjust the predictor

	c) remember that even a long-idle TCP connection will do some
	   of this anyway, so it just makes new TCPs look a little like
	   they were persistent

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

I'm not sure it requires the participation of routers; we're doing
measurements to see if it just works anyway.

FYI.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050927/caefef22/signature.bin