[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ns] delayed sack
On Mon, 11 Dec 2000, Prashant Desai wrote:
> I would like to understand the behaviour of "Agent/TcpSink/Sack1/DelAck".
> I am confused as to how delayed acks work with selective acks....
They shouldn't interact. If you read RFC2001 section 3 and RFC2581 end
of section 4.2, you'll see that acks to segments filling in holes in
window data should be sent immediately. So, you should only delay new
stuff at the right edge of the window - i.e. when you're not going to
be using SACK, so when you do need SACK the sender should get more
timely info. (you might argue that delaying is some protection against
mimsordering, but if you've got losses elsewhere in the window -
three SACK blocks don't go that far, and window growth is
probably more important. This cuts the Gordian knot.)
Hence the April change for delacks in ns and RFC2581_immediate_ack_
to bring ns more into line with the RFCs.
What actual implementations do is open to question. It's only a
should, and delayed acks create this massive area of vagueness
that is quite good at making a mockery of a lot of TCP
performance-tweaking papers which set up very limited test scenarios
and completely ignore delack impact...
See also allman's ack paper, which is the standard reference in this
sadly neglected field.
Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM
Computer Communication Review, 28(5), October 1998.
http://roland.grc.nasa.gov/~mallman/papers/
L.
<[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>