Re: [tcpm] Request for input regarding the initial window increase

[Jerry Chu <[e-mail]>]

Hi Joe,

On Wed, Jul 13, 2011 at 2:04 PM, Joe Touch <[e-mail]> wrote:
>
>
> On 7/12/2011 5:53 PM, Wesley Eddy wrote:
>>
>> My personal responses as a WG participant are below:
>>
>> On 7/12/2011 7:54 PM, SCHARF, Michael wrote:
>>>
>>> ...
>>>
>>> Question 1: Moving forward a fixed increase of the permitted TCP initial
>>> congestion window (draft-ietf-tcpm-initcwnd-01)?
>>>
>>> Answer 1A: Fixed upper limit to proposed standard
>>> Answer 2B: Fixed upper limit to experimental
>>> Answer 3C: Something else (e. g., some adaptive scheme, or no change at
>>> all compared to RFC 3390); this would imply a substantial change of
>>> draft-ietf-tcpm-initcwnd-01
>>
>> I think B (Experimental) is a conservative approach. I'm happy with
>> that and scoping the "experiment" for general use on the Internet, with
>> intent to come back and go to Proposed Standard at some point.
>> Essentially, it already has close to that status ;).
>
> +1
>
> I would like to also see some discussion of a metric to know whether this is
> working or not (i.e., it's been deployed, but just because we don't see a
> problem doesn't mean one isn't happening).
>
>>> Question 2: Maximum permitted initial congestion window?
>>>
>>> Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by
>>> draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD)
>>> Answer 2B: Another value (please suggest and justify)
>>
>> I think 2A is appropriate due to the volume of analysis that used the
>> same value (10MSS). Anything greater hasn't been looked at as much,
>> and anything lesser sacrifices the intent.
>
> I think it should mirror how it was stated previously: M segments OR N
> bytes, whichever is *smaller*.
>
> As to the M and N, there is clearly a goal of 10 1500-byte packets (15,000
> bytes). Compared to RFC 3390, that's 3.4x more bytes *and* 5x more segments
> (at 1500 bytes, 3390 would yield 2 MSS).

I am confused. I thought all the numbers in RFC3390 are based on MSS, not
MTU, so it's 3.33x, # of bytes as well as segments.

"Equivalently, the upper bound for the initial window size is based on
   the MSS, as follows:

       If (MSS <= 1095 bytes)
           then win <= 4 * MSS;
       If (1095 bytes < MSS < 2190 bytes)
           then win <= 4380;
       If (2190 bytes <= MSS)
           then win <= 2 * MSS;
"

So IW=10 may not have been as aggressive as you might have thought. Will that
be enough to swing your vote :)?

>
> The arguments in favor appear to be based on the 99% - or even 99.5% - case,
> and too much focused on current (and, IMO, likely ephemeral) transfer size
> measurements. I prefer to consider the increased variety of links and uses
> and trade safety for over-optimizing performance.

draft-ietf-tcpm-initcwnd-01.txt already contains the following paragraph:
"8.  Mitigation of Negative Impact

   Much of the negative impact from an increase in the initial window is
   likely to be felt by users behind slow links with limited buffers.
   The negative impact can be mitigated by hosts directly connected to a
   low-speed link advertising a smaller initial receive window than 10
   segments. This can be achieved either through manual configuration by
   the users, or through the host stack auto-detecting the low bandwidth
   links.

   More suggestions to improve the end-to-end performance of slow links
   can be found in RFC 3150 [RFC3150].
"

It the above is the only road block to standard we can certainly try to expand
on it.

>
> I personally would be more comfortable with doubling the numbers from RFC
> 3390, i.e., "4 segments or 8760 bytes whichever is smaller", as well as
> adding "SHOULD round down to an even number of segments" (to avoid creating
> compressed ACK stalls).

Again it should be "6 segments or 8760 bytes whichever is smaller".

Jerry

>
>>> Question 3: Adaptive solution as an alternative?
>>>
>>> Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item
>>> heading towards experimental
>>> Answer 3B: No adoption
>>
>> I favor 3A, sort-of. I would rather see it generalized to explain how
>> the same algorithm can be used for tuning SCTP and potentially a subset
>> of CCIDs for DCCP. Otherwise we're begging someone to write more
>> documents later in order to tell us how the same thing applies to those
>> other protocols.
>
> +1 on all points (FWIW, it was always intended to apply across all AIMD
> congestion control scenarios).
>
> Joe
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>