Messages in this thread | | | Date | Sat, 14 Nov 1998 20:05:11 -0800 | From | "David S. Miller" <> | Subject | Re: [patch] delayed acks decrease performances in congestioned networks |
| |
Date: Sat, 14 Nov 1998 12:50:44 -0800 (PST) From: Kaz Kylheku <kaz@cafe.net>
Just because you have been receiving segments are regular intervals, and there is a sudden lapse, doesn't mean that a packet has been lost.
Yes, we all know this.
But what he is implying is something all people who work on TCP queueing theory know, that "recovery from loss will always be better if delayed ACKs are not used". The reason is simple, it provides the maximum amount of feedback to the sender, and the more feedback the sender gets the faster fast retransmit and other recovery strategies can react.
Check out all TCP research done on loss recovery, almost all of their analysis is done with delayed acks turned off for this very reason. (For this core reason I consider %99 of all research papers on TCP completely bogus because they all show that their suggested scheme works extremely well in an unreal world, one where delayed acks are not the norm, whereas in the real world every host I have every watched on the wire speaks delayed acks) They do this for another reason, to eliminate a variable in the BSD stack. Depending upon when _exactly_ in time you run the tests, even with controlled and exact same network conditions, you'll get different results. This is due to BSD's extremely coarse and inexact timer implementation (ie. when you set the "200ms" timer to go off in BSD, it may go off any time between right now and 200ms in the future) Perhaps this is another argument for more TCP research to be done using Linux? :-)
For extremely shitty networks (I mean here, every other packet always dropped etc.), delayed acks are worse than non-delayed ones. But as you mention it contributes to congestion and degrades performance for people with at least half-way decent connectivity.
Later, David S. Miller davem@dm.cobaltmicro.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |