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

[Joe Touch <[e-mail]>]

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).

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.

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).

>> 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