[e2e] rfc2581bis-01 and RFC 2861
Salman Abdul Baset
salman at cs.columbia.edu
Sat Jul 22 11:02:43 PDT 2006
(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).
More information about the end2end-interest