[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