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

[Jerry Chu <[e-mail]>]

On Thu, Nov 18, 2010 at 1:10 PM, David Borman
<[e-mail]> wrote:
>
> On Nov 18, 2010, at 2:43 PM, Joe Touch wrote:
>
>>
>>
>> On 11/18/2010 12:32 PM, David Borman wrote:
>> ...
>>>> Consider that there are three cases:
>>>>
>>>> A) connections so small the IW doesn't matter (they already fit in IW=3)
>>>>
>>>> B) connections 4-20 or so segments range
>>>>
>>>> C) connections much longer than 20 or so segments
>>>>
>>>> (A) isn't affected by this proposed change at all, so we don't need to consider it.
>>>>
>>>> (C) adjusts to the IW using AIMD, so even if we guess wrong, TCP will "react to congestion" here.
>>>>
>>>> And then there's (B). (B) doesn't react to congestion. Every new connection uses IW=10. Even after repeated attempts - to a given address, or, e.g., to every address - end up dropping, e.g., half of those segments. (B) will sit there and beat its head against the wall.
>>>
>>>>
>>>> That's the congestion-increasing case. Will this cause collapse? I don't know. But it's definitely NOT reacting to congestion.
>>>
>>> No, (B) will also react to congestion, if the congestion causes
>>> packet loss. For any given flow, if all the packets get through the
>>> first time, from it's viewpoint there is no congestion. If they don't
>>> all get through, that connection does normal TCP backoff and
>>> retransmits.
>>
>> 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.
>
> 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.
>
> 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.
>
>
> 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.

Agreed. In fact, RFC3390 already contains a similar clause:

         "If the SYN or SYN/ACK is lost, the initial window used by a
         sender after a correctly transmitted SYN MUST be one segment
         consisting of MSS bytes."

We welcome any contingency that may ease concerns as long as the condition
can be detected during 3WHS. (We have a self-imposed KISS design principle.
See slides 9 of http://www.ietf.org/proceedings/77/slides/tcpm-4.pdf)

Jerry

>
>                        -David
>
>>
>> Joe
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>