I would have thought that byte based growth of the CWND would have meant
that the ACK's above would have allowed more bytes to flow, yet more
bytes are not flowing. That makes it seem like cwnd isn't strictly
bytes, but is also tracked in terms of number of outstanding segments.
Linux cwnd is in packets.
How is the ABC cwnd of bytes mapped to packets? Does it only go up by
one packet after an MSS has been ACKed then?
Think of congestion window as measurement of the available sewer pipe.
If everyone thinks the congestion window is too large, then the sewer pipe
would back up and nothing would overflow.
Small packets are like a leaky faucet dripping, just because a drip goes
down the drain doesn't tell you much about the available pipe diameter.
I agree that if I can have five drips outstanding I should not be able
to then put five buckets out there, but should I have to exchange
another 1460 drips before I can have six drips outstanding?
Admittedly, this specific application is a bad client for the case I'm
trying to make, but if it were properly putting messages to the
transport in one call, but trying to have five of them outstanding at a
time I get the impression it would be a very long time before it could
get all five outstanding. I guess netperf TCP_RR with configured with
--enable-burst would be one way to check that.
rick jones
-
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
