Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes

[Joe Touch <[e-mail]>]

On 11/18/2010 1:10 PM, David Borman wrote:
...
>> To be more clear, here's the case:
>>
>> 	start 1000 connections in a row.
>>
>> 	during the first connection, lose some packets and do
>> 	normal TCP backoff
>>
>> 	so what do the other 999 connections start with?
>> 	ans: 10 packets
>>
>> The point is that subsequent connections don't do anything different. If you have 1000 connections, you're sending a certain amount of data into the network without reacting. We're tripling that.
>>
>> That can easily cause congestion. At which point the *existing* connections will backoff, but new connections keep making problems.
>
> If you are doing the 1000 connections serially, then any connection
> that experiences packet loss will slow down that connection, and delay
> the creation of all the successive connections, and hence delay the next
> IW burst. Seems to me that that is reacting to congestion across
> connections.

That's true if the connections are serial, but I didn't say that. I said
try to start 1000 connections. They'll start in a sequence, but they 
don't get delayed based on what other connections are doing necessarily.

> If you are doing 1000 connections in parallel, well, you are now
> spitting out 3,000 packets with IW=3 and 10,000 packets with IW=10, both
> of which are probably going to cause congestion.

The 10,000 packets cause more congestion, or causes congestion more of 
the time - depending on the network parameters. I.e., it *increases* the 
congestion, regardless.

> Remember, from the end-point of a TCP connection, it is not aware of
> congestion unless there is packet loss or an ECN indication. There may
> be congestion on the path, but if the packets gets through, TCP is
> unaware of the congestion, other than the RTO going up due to delayed
> packets, and will continue to open up its idea of the congestion window.

Agreed.

> But here's a thought: Any TCP connection with a large IW that has to
> retransmit or gets an ECN notification during the initial 3-way
> handshake must clamp down its IW to a small value. That won't catch
> every case, but it'll catch some.

Sure - that's basically what I'm suggesting. We can refine the feedback 
mechanism (packet loss detected via SACK or ACK gaps vs. ECN 
notification vs retransmit). I'm also suggesting that the IW should 
increase over time, too - so that we don't need to revisit this issue 
explicitly.

Joe