[catching up] > One separate thing to note with regards to ABC is that the RFC2581bis > document in TCPM right now RECOMMENDS to increase CWND by the number > of bytes ACKed during slow-start - i.e. ABC is RECOMMENDED by that > document intended as an update to RFC 2581. It is not quite that easy and I think this is a bit mis-leading. So, I want to clear this up. The ABC that has been discussed in this thread is absolutely not being recommended or RECOMMENDED in 2581bis. What the ABC spec. says is that on an incoming ACK during slow start the TCP can increase cwnd based on the number, N, of bytes newly covered by this incoming ACK up to some limit L. The ABC spec. further goes on to say that L=2*SMSS, which was chosen to exactly counter-act delayed ACKs (i.e., ACKing every second packet). This is in contrast to the traditional scheme which increments cwnd by SMSS on each incoming ACK. So, RFC 3465 allows for more aggressive window growth in the face of delayed ACKs---which is pretty much what people have been discussing in this thread, I believe. RFC 3465 also notes that if L=1*SMSS then you get some protection against receivers that are trying to game CC by dividing ACKs (say, ACKing each byte in the hopes that the peer will bump cwnd by SMSS bytes on each ACK). So, the idea is that you increment cwnd by the number of new bytes ACKed, but not more than SMSS bytes (the traditional increment). This is strictly *more conservative* than specified in RFC 2581 (and, I agree with Joe that this is always allowed as compliant). Now, the 2581bis document RECOMMENDs this latter form of byte counting. From that document we see that cwnd is incremented by the number of bytes newly ACKed, N, up to SMSS bytes: cwnd += min (N, SMSS) (2) This is more conservative than RFC 2581. We do not tackle the question of whether there is enough evidence from experiments with ABC to suggest that using L=2*SMSS is safe or useful. (If people have experimental results involving RFC 3465, it would be great if you could drop me a note.) allman