[Iccrg] improvement of tcp slow start

Stefan Hirschmann krasnoj at gmx.at
Fri Mar 16 19:56:48 GMT 2007


Hi!

Lachlan Andrew schrieb:
> Greetings Stefan,
>
> The main problem with increasing the rate of increase of slow start is
> that it creates larger overshoot when the correct rate is reached.  If
> we triple the rate each RTT instead of doubling it (or multiplying by
> 1.5 -- see the recent discussion on the end2end-interest list), then
> we are transmitting at three times too fast when we finish.

Youre argument is a good one. But it is only so in the extreme 
szenarios, where cwnd=maxBandWith.
In the average szenarios, it can happen, that current +=1 makes a bigger 
overshoot than +=2, e.g. with 8 KByte/sec. You have 1,2,4,8,16  
overshoot=16-8=8. But with +=2 you have 1,3,9, overshoot=9-8=1. So in 
some cases, the +=2 may be even better, than the current +=1; I made a 
tabulary with the most common speeds in the internet:
===========================================================================
max Speed is in KBit/s and in () is the value for KByte/s, but Plus1, 
Plus2, Plus3 are in KByte/sec
max Speed [KBit/s] (in KByte/s)   Plus1    Plus2    Plus3
56 (7)                       5                    2        5
64 (8)                       4                    1        4
128 (16)                   8                   11        32
512 (64)                   32                17        128
768  (96)                  96              147        96
1024 (128)               64              115        64
2048  (256)              128            473        512
3072  (384)              384            345        384
4096  (512)              256            217        256
10240 (1280)           256            907        1792
102400 (12800)   11776            6883       36352
===========================================================================
As you can see, sometimes the plus2 is much better (e.g. 100MBit), in 
other cases it is worser.  I don't think that it is has any sense to 
make a mean or median over tit, because you have to use the real 
bandWith distribution in the internet. In this table the worst cases are 
in percentage (overshoot+bandwith)./bandwith :
===========================================================================
| Format: Plus1    Plus2    Plus3
| Min: 1.2000    1.1250    1.5000
| Max:  2.0000    2.8477    3.8400
| Mean: 1.6213    1.7463    2.3140
| Median:  1.5000    1.6875    2.0000
===========================================================================
Like already said, the mean and median should not messed too much, but 
if you say, that this type of connection are all used equal, than the 
number of overshoot packaged would increase by 18%. But most of the file 
transfer does'nt leave the slowStart, so this problem is in praxis much 
smaller. A connection has to transfer at least 60KByte (for plus2, plus1 
were 100 KByte) to leave the slow start for a 1MBit/s, so many 
WebTraffic won't even make an overhead.

But maybe it would be a good idea, to look, at which cwnd the biggest 
overshoot is, and be less aggressive in this area. Something like:
if (criticalArea)
    tp->snd_cwnd++
else
    tp->snd_cwnd+=2;

 > [...] see the recent discussion on the end2end-interest list [...]
I didn't found this discussion. I looked for march and february. Can you 
tell me the topic, because I would like to read it?


> What would be more useful would be something which can detect when
> slow-start is nearing its end -- like measuring queueing delay or some
> property of the RTT-level burstiness -- so that we can start
> aggressively but back off when we're nearing the end.
This idea sounds interesting. I don't know how complicated it is to 
implement. Maybe you make a simulation and look how effizient it works.
But what is the best way dealing with changing routes, that can also 
change the RTT (or wireless connection with the resend of broken packets)?

> There are also fairness issues with having some sources using  
> "improved" slow start and some using the existing algorithm, although
> I think they're often overstated.
I hope that the internet connection of the most server is good enough, 
that it can stand the slow start phase ;)
To be serious: It is true, that you get more packets than someone use 
the conventionell plus1. But: After the slow start it is equal, and if 
you loose a packet because of the congestion, you restart by 1, like the 
other one. If the connection is good enough, that the congestion 
avoidance phase is possible, both will reach them.


Cheers Stefan



More information about the Iccrg mailing list