[tcpm] rfc2581bis-01 and RFC 2861

Salman Abdul Baset <salman@cs.columbia.edu> Sat, 22 July 2006 18:02 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4LoS-0007JU-Lz; Sat, 22 Jul 2006 14:02:52 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4LoR-0007JO-6r for tcpm@ietf.org; Sat, 22 Jul 2006 14:02:51 -0400
Received: from cs.columbia.edu ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4LoP-0002xJ-Ti for tcpm@ietf.org; Sat, 22 Jul 2006 14:02:51 -0400
Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu []) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6MI2nl5027538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Jul 2006 14:02:49 -0400 (EDT)
Received: from dynasty.cs.columbia.edu (localhost []) by dynasty.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6MI2nE6003395; Sat, 22 Jul 2006 14:02:49 -0400 (EDT)
Received: from localhost (salman@localhost) by dynasty.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id k6MI2hV9003392; Sat, 22 Jul 2006 14:02:43 -0400 (EDT)
X-Authentication-Warning: dynasty.cs.columbia.edu: salman owned process doing -bs
Date: Sat, 22 Jul 2006 14:02:43 -0400
From: Salman Abdul Baset <salman@cs.columbia.edu>
To: tcpm@ietf.org, end2end-interest@postel.org
Message-ID: <Pine.GSO.4.58.0607221343270.3180@dynasty.cs.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Subject: [tcpm] rfc2581bis-01 and RFC 2861
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

(Note: This post is being sent to tcpm and end2end-interest mailing lists)

The issue is that RFC 2861 (Experimental) suggests to cap cwnd if application
is rate limited. For example, for sending CBR over TCP with RTT of 100ms
and CBR rate of 10ms, the cwnd should not theoretically increase beyond 11.

The latest TCP congestion control draft:


does not allude to RFC 2861. This latest draft perhaps tries to combine
the RFC 2581 (TCP Congestion Control) and RFC 3465 (Appropriate Byte Couting) in
one document. In $3.1, (page 5, par 5) it suggests:

"The RECOMMENDED way to increase cwnd during congestion avoidance is
    to count the number of bytes that have been acknowledged by ACKs for
    new data.  (A drawback of this implementation is that it requires
    maintaining an additional state variable.)  When the number of bytes
    acknowledged reaches cwnd, then cwnd can be incremented by up to
    SMSS bytes.  Note that during congestion avoidance, cwnd MUST NOT be
    increased by more than SMSS bytes per RTT.  This method both allows
    TCPs to increase cwnd by one segment per RTT in the face of delayed
    ACKs and provides robustness against ACK Division attacks."

It clearly states that cwnd should be increased if number of bytes in
current cwnd have been acknowledged. This implies that cwnd increase will
also happen for CBR traffic, albeit at a slower rate because of
application rate limitation.

I am not sure if it is an intentional omission by the authors but this
seems to have significant implications for sending CBR over TCP. For
example, delays incurred by CBR stream can be quite different because of
cwnd limitation (due to application rate).


tcpm mailing list