[e2e] rfc2581bis-01 and RFC 2861

[Salman Abdul Baset]

(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:

http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-01.txt

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

Regards,
Salman