David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 10 Mar 2006 17:15:14 -0800
/* RFC3465: Slow Start
* TCP sender SHOULD increase cwnd by the number of
* previously unacknowledged bytes ACKed by each incoming
* acknowledgment, provided the increase is not more than L
*/
if (tp->bytes_acked < tp->mss_cache)
return;
And only increasing cwnd after a full mss has been acked. Which IIRC is
not part of the ABC RFC.
It is a core part of the RFC.
But for a _byte_ based cwnd, not a packet based one. I've gone through
the RFC three times now and it all appears to be based on a byte-based
cwnd. I'll admit that I may be being dense, but when it is saying
things like increase cwnd by "1*SMSS" and "L=1*SMSS" that tells me it
is all byte-based cwnds not packet based ones.
IIRC all (most of) the RFC's talk about the cwnd in bytes because at the
time VJ did his work (in hnits of packets/segments) none of the (common
-MPE did :) stacks actually knew how many segments they had outstanding
at any one time. So, we have the "increase by an MSS on each ACK"
heuristic - it didn't overly penalize bulik transfers. It was a proxy
for tracking segments, and with the existence of the ABC RFC we can
assume not all that good a proxy.
In the original VJ paper, when a packet was known to have left the
network, the stack was free to replace it and add another. The queues
in the network are (as near as I can tell) in units of packets, not in
units of bytes.
Keep in mind that Van himself was one of the primary reviewers of the
ABC work. And this is even mentioned in the RFC.
And the RFC looks fine for byte based cwnd implementations. I think the
issue isn't in ABC itself, but in how it gets mapped to a packet-based
cwnd scheme.
I cannot prove it because I don't have a stack handy that is both ABC
and byte based, but strongly suspect that a byte-based cwnd stack doing
ABC would have grown the byte-based cwnd enough in short order to allow
those five segments per message to get onto the network.
rick
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
