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

From: Sally Floyd <[email-masked]>
Date: Thu, 14 Jun 2007 14:12:40 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 14 Jun 2007 18:01:03 -0400 (EDT)

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

---

From: Salman Abdul Baset <[email-masked]>
Date: Fri, 15 Jun 2007 06:24:27 -0400 (EDT)

Consider this example:

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?

-s

On Thu, 14 Jun 2007, Jitu Padhye wrote:

> This concern was mentioned by Murari as well. (adding Murari to discussion).
>
> - Jitu
>
> -----Original Message-----
> From: Salman Abdul Baset [mailto:[email-masked]]
> 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?
>

---

From: John Heffner <[email-masked]>
Date: Mon, 18 Jun 2007 18:15:46 -0400

> Proposed Standard?  Any feedback would be welcome.

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.

   -John

---

From: Sally Floyd <[email-masked]>
Date: Wed, 27 Jun 2007 16:05:04 -0700

> 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

---

From: Sally Floyd <[email-masked]>
Date: Wed, 27 Jun 2007 16:44:45 -0700

John -

(Apologies, as always, for the late reply.)

> 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

---

From: Janardhan Iyengar <[email-masked]>
Date: Fri, 29 Jun 2007 22:23:28 -0400

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:
>> of any issues with the "not raising cwnd when application-limited" part.
> 

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