[Tmrg] Proposal to increase TCP initial CWND

[krasnoj at gmx.at (Stefan Hirschmann)]

Lachlan Andrew wrote:
> On 20 July 2010 08:13, Stefan Hirschmann <krasnoj at gmx.at> wrote:
>> Six:
>> HTTP Pipelining is AFAIK not widely used by now.
> ...
>> So the browser producer would slow down the connection
>> if he/she reduces the number of parallel connections. So I am sure the
>> browsers won't reduce this number.
>> For TMRG the consequence is: We have to model it with six parallel
>> connections because this will be the real world.
> 
> Interesting point.  Do you think that the "test suite" draft* should
> include one scenario where all flows are split into six, or should all
> tests be like that?

It depends what the "target" of the evaluation suite should be:
====================================
? [...] For each run, the following metrics will be collected for the 
central
link in each direction: the aggregate link utilization, the average packet
drop rate, and the average queuing delay, all over the second half of
the run [...]? (cited [1, Section IV])
=====================

So this version does not want to consider the Slow-Start phase. The main 
problem of TCP in Slow-Start phase is, that it is very sensitive to 
packet drops. If you compare two TCP flows, both exact the same 
algorithm, there can be transfer time difference of factor 3 and more, 
depending which packet was dropped. E.g: 1 MBit over an 1Mbps wire. The 
minimum transfer time is 1 second. But if there are timeouts take two 
seconds, the total transfer time is 3 seconds. In a 50 seconds 
simulation this two seconds are not relevant, but for a one second flow 
it is relevant.

In my own master thesis [5] I chose this sequence of simulations (all 
simulation run twice, first with std alg, second with changed version):

1) 1 TCP flow.
1a) Using an optimal scenario for the new algorithm (mostly with 
unlimited queue-size)
1b) 1 TCP flow using a 64 Kbps connection.


2) Use a "corrupt link", an error model, something which droppes packets 
without congestion and investigate the recovery behavior.

3) 1 TCP flow, 1 UDP flow, UDP flow uses 50% of available bandwidth.

4) 1 std TCP against 1 "improved" TCP flow

The main ideas:
1a: Show the best case of the new algorithm compared to std TCP. If this 
is not good enough, the algorithm should be changed.

1b: Show the worst and that it still is not risky for the network.

2: Investigate if the algorithm is also usable for W-LANs

3: 50% of all flows are less than 4K and end in one RTT. Compare my 
other mail in this thread.

4: Compare the new algorithm in a scenario together with classical TCP 
flows as it will happen for years in the real world.


I think this should be the scenarios which should be covered for each 
Slow-Start evaluation suite. Additionaly, and this is individual for 
each algorithm, the authors should think what is the _worst_ possible 
(and realistic) case for their algorithm and should simulate this 
scenario and show how worse it is compared to std TCP.

For each algorithm using IW=4KB there is no need to model 6 connections 
over an ISDN link. The reason is:
[3] showed that Tele2 Austria uses a queue size of 35 for 56 Kbps and 
[4] showed that the queue size of AT&T in Pasadena, CA, is 30.
30/4 > 7, so seven flows can the link bear in the first step without any 
packet drops.

Also a 64 Kbps link is able to transfer 8 KByte per second -> 5 packets 
(size: 1,46).
The consequence is: There will be exact 5 ACKS reach the sender per 
second independent of the number of flows, so there is no need to model 
different number of flows in the following RTTs.


But the situation is completely different, if  IW*6 >30 -> IW>5, here IW=10:
30/10=3
But there should be 6 flows. So this scenario has to be modeled, because 
there are already packet drops before the congestion controlled second 
RTT has been reached.


I hope I made clear what I want to say.


Cheers Stefan



[1] Lachlan Andrew, Cesar Marcondes, Sally Floyd, Lawrence Dunn, Romeric
      Guillier, Wang Gang, Lars Eggert, Sangtae Ha and Injong Rhee. 
Towards a Common TCP Evaluation Suite. In Protocols for Fast, Long 
Distance Networks (PFLDnet), 5-7 Mar 2008.

[2] Stefan Hirschmann. Improving the Start-up Behavior of TCP, Master 
Thesis, http://heim.ifi.uio.no/~michawe/teaching/dipls/hirschmann.pdf

[3] Stefan Hirschman. Queue size - Towards a Common TCP Evaluation 
Suite,  Oct 2008. Mailing list of the TMRG.

[4] Tom Quetchenbach. Queue size - Towards a Common TCP Evaluation 
Suite, Oct 2008. Mailing list of the TMRG.

[5] Stefan Hirschmann, "Improving the Start-up Behavior of TCP", 
Universit?t Innsbruck, 
http://heim.ifi.uio.no/~michawe/teaching/dipls/hirschmann.pdf