Re: [tcpm] rfc2581bis-01 and RFC 2861

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

True. I guess the question is when/if RFC 2861 will be incorporated as a
Standards track rfc. As you are probably aware, Linux 2.4 and onwards
implement 2861. Ofcourse, this is not the reason for making an experimental
RFC a standard but I was hoping to find some effort towards it. Perhaps,
there is one but I have not scanned all the archives. Also, such an effort
is not evident from the WG description and 'Goals and Milestones'.

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

So I guess, there are two ways of increasing cwnd during CA. One is to
increase the window based on number of ACKs received (which is what Linux
is doing and eq (2) in RFC 2581) and the other is to increase it based on
number of bytes ACKed (2581: page 5, par 3). It appears that RFC 2581
recommends both. As you mentioned, the new draft recommends the later.

Now consider CBR over TCP. The window will increase quickly for the first
case assuming packets are smaller than MSS (100 byte packet and 1448 byte
MSS). It will increase slowly for the second case. For a MSS of 200 bytes
and packet size of 100 bytes, the cwnd increase rate is 1/2 of the first
case.

When there is a TDACK loss, cwnd will be reduced to half. The CBR over
TCP traffic is not impacted if after a loss cwnd is big enough to
maintain the rate.

Now consider RFC 2861. It says that cap the cwnd if application is
rate-limited. For a CBR rate of 100 packet/s (or every 10ms) and RTT of
100ms, the cwnd should not theoretically increase beyond 11 because the
number of packets inflight are 10. In practice, it increases to a higher
value (and stays there if there is no loss) because the packets are
buffered when cwnd < CBR rate.

A CBR over a TCP implementation that follows RFC 2861 is more likely to
suffer from cwnd limited delays than a TCP implementation that keeps
increasing cwnd.

Similarly, CBR over TCP also benefits from not doing byte counting during
slow start and CA.

Another interesting nuance is if cwnd is significantly higher than the
current traffic rate, shall it be slowly brought down? This phenomena is
different from the idle period reduction.

What do you think?

Regards,
Salman

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm