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

[Jerry Chu <[e-mail]>]

On Tue, Jul 12, 2011 at 5:53 PM, Wesley Eddy <[e-mail]> 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

I'm curious about how to scope an "experiment" for "general use". I didn't
know one can have both at the same time...

>
> intent to come back and go to Proposed Standard at some point.
> Essentially, it already has close to that status ;).

Yes and our "very large" ;-) experiment with IW=10 has been ongoing for
more than a year. I wonder how much more experiment is required for 1A,
which is my preference, unless you have IW > 10 in mind.

BTW, with Linux adopting IW=10 a few month back, the "experiment" has
been getting even larger everyday.

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

Agreed.

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

Jerry

>
> --
> Wes Eddy
> MTI Systems
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm