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

[Sally Floyd <[e-mail]>]

> Suppose there is a flow which sends one packet per RTT and RFC 3390 
> was inplace so initial window was four. Also, suppose there was no 
> loss. Since the application was sending one packet per RTT, the cwnd 
> should be adjusted to one (is this correct?) after an application 
> limited period. Is this an acceptable behavior?

That is what is described in RFC 2861 (which was written before RFC 
3390).

However, I think that the correct way to update RFC 2861 in light of 
RFC 3390
would be to say that cwnd is never reduced to less than the *initial 
window*
in response to an application-limited period.  This is pretty much what
TFRC does (in Section 4.4 of RFC 3448, which came *after* RFC 3390,
but which uses ideas from RFC 2861).

This is also quite explicit in Section 5.1 of CCID-3 (RFC 4342) for the
response to idle periods:

    "In [RFC3448], Section 4.4, the allowed
    sending rate is never reduced to fewer than two packets per round-
    trip time as the result of an idle period.  CCID 3 revises this to
    take into account the larger initial windows allowed by [RFC3390]:
    the allowed sending rate is never reduced to less than the [RFC3390]
    initial sending rate as the result of an idle period.  If the allowed
    sending rate is less than the initial sending rate upon entry to the
    idle period, then it will still be less than the initial sending rate
    when the idle period is exited.  However, if the allowed sending rate
    is greater than or equal to the initial sending rate upon entry to
    the idle period, then it should not be reduced below the initial
    sending rate no matter how long the idle period lasts."

(We should make this change even if we leave RFC 2861 as
Experimental, so that cwnd is not reduced to below the initial window
after an idle or application-limited period.  It would be nice if I 
could do
that just with an Errata...)

- Sally
http://www.icir.org/floyd/




>> -----Original Message-----
>> From: Salman Abdul Baset [mailto:[e-mail]]
>> Sent: Thursday, June 14, 2007 3:01 PM
>> To: Sally Floyd
>> Cc: tcpm; Jitu Padhye; Mark Handley; Eli Brosh
>> Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to 
>> Proposed Standard?
>>
>> For application limited workloads such as streaming over TCP, we have
>> found that the CW validation mechanism, which decays CW for a 
>> sufficiently
>> long application-limited period, can increase sensitivity to timeouts.
>> -s
>>
>>
>> On Thu, 14 Jun 2007, 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.
>>>
>>> - Sally
>>> http://www.icir.org/floyd/
>>>
>>> In the spirit of doing due diligence with old Experimental RFCs...
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/tcpm
>>>


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