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

[Wesley Eddy <[e-mail]>]

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


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


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

-- 
Wes Eddy
MTI Systems