Re: [tcpm] rfc2581bis-01 and RFC 2861

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

I have cut end2end off this reply as this seems to be a WG matter and we
probably do not need to clutter e2e.

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

This is incorrect.  The goal of the above listed I-D is to fix problems
with the current congestion control *specification* (not algorithmic
problems).  And, further to roll in a couple of quite minor *standards
track* extensions to TCP (namely a larger initial cwnd (RFC 3390) and
limited transmit (RFC 3042).

We explicitly *do not* roll in Appropriate Byte Counting (RFC 3465)
because, as you note, it is not a standards track extension at this
time.

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

Note that this is only a slight change from RFC 2581 and the above is
*not* ABC.  First, ABC is about how to increase cwnd during *slow start*
while the above paragraph discusses congestion avoidance.  Second, the
byte counting method for increasing cwnd during congestion avoidance is
specifically allowed in RFC 2581.  The change is that it is RECOMMENDED
in the latest draft.  (The change is an attempt to mitigate a security
problem with receiver's ACKing each byte in a packet separately to try
to artificially inflate the sender's cwnd.)

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

I do not follow the problem you are getting at here.  If you traffic is
CBR and you have enough cwnd to send at that CBR then why would
increasing it beyond what will provide the given rate impact the
traffic?  I just can't see the point you're trying to make here, can you
try again?

allman