Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard?

[Janardhan Iyengar <[e-mail]>]

Sally/all,

I'm not sure what it takes for an experimental RFC to go to proposed.

I'm generally happy enough with RFC 2861 to support it to go to Proposed 
Standard. But, if we do not know more (or enough) about the implications 
of CWV than we did when RFC2861 was published, on what basis do we 
recommend that it change status?

A show of hands by folks who know that it is used and has not caused 
complaints would also be very useful, IMHO.

- jana

Sally Floyd wrote:
> John -
> 
> (Apologies, as always, for the late reply.)
> 
>> There have been enough reports of performance problems with 
>> intrinsically bursty applications that an option was added to Linux to 
>> disable cwnd decay.  (It is still enabled by default.)  I'm not aware 
>> of any issues with the "not raising cwnd when application-limited" part.
> 
> I understand that bursty applications would often rather not reduce
> cwnd after an idle or application-limited periiod.  (It *might* be
> in their own interests, if it helps the flow to avoid unnecessary
> packet drops, but it *might not* be in their own interests, e.g.,
> if that flow doesn't receive any packet drops when bursting after
> an idle period.
> 
> But the following question also matters:
> 
> (1) What about when there are N possibly-bursty flows sharing the
> same congested link?  Are there any reports about whether the *N
> flows* do better when all flows use CWV, or whether they do better
> when none of them use CWV, and none of them reduce cwnd after an
> idle period?
> 
> (If there is no congestion, I would expect that the N flows do
> better without CWV.   If there *is* congestion, I would expect that
> the N flows in general do better *with* CWV, as opposed to not
> reducing cwnd after idle periods.  But it is not something that one
> could tell from reports from individual users...)
> 
> ------------------------------------------------------------------
> 
> The current Proposed Standard behavior in this area, from Section
> 4.1 of RFC 2581, says that TCP "SHOULD" reduce cwnd to the initial
> window after an idle period exceeding the RTO.  RFC 2861 is
> considerably more moderate than this.  Does anyone know if there
> are TCP implementations out there that follow the "SHOULD" from
> RFC 2581, just out of curiosity?
> 
> Is the feedback that the Congestion Window Validation mechanism in
> RFC 2861 should be modified?  Or that CWV is useful but is just
> fine to be left as Experimental?  (That would be fine by me.
> Less work...)
> 
> - Sally
> http://www.icir.org/floyd/
> 
> 
> Original email:
> 
>> Sally Floyd wrote:
>>> This email is to ask the working group if RFC 2861 on Congestion
>>> Window Validation (CWV) should be left at Experimental, or whether
>>> it is time to start the process of moving it to Proposed Standard.
>>> RFC 2861, from June 2000, "describes a simple modification to TCP's
>>> congestion control algorithms to decay the congestion window cwnd
>>> after the transition from a sufficiently-long application-limited
>>> period, while using the slow-start threshold ssthresh to save
>>> information about the previous value of the congestion window.
>>> RFC 2861 also recommends that "the TCP sender should not increase
>>> the congestion window when the TCP sender has been application-limited
>>> (and therefore has not fully used the current congestion window)".
>>> My understanding is that CWV has been included in Linux since
>>> Linux 2.4, but that it is not included in Microsoft.
>>> Are there any experience reports about CWV (positive or negative),
>>> or experience reports of problems (or the absence of problems) for
>>> TCP connections without CWV?  Or are there other opinions about
>>> whether it is time to start the process of moving RFC 2861 to
>>> Proposed Standard?  Any feedback would be welcome.
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm