The 1/2 second cut off is not just an arbitrary number I picked to get
better performance. RFC 1122 requries that a TCP implementation delay
ACKs by no more than 1/2 second. If we enforce this then when we
have interarrival times that are > 1/2 second we just skew the RTO
measure without gaining anything in the way of reduced traffic.
If the current measured packet interarrival time is <= 1/2 second
then we will delay the ACK for the time indicated by the current measure.
Obviously this 1/2 second cut-off means that delayed ACKs won't
help much for packet radio. (Although ignoring the cut-off would
allow them to help.)
>Well, usually the other end will be timing the roundtrip time (it MUST
>do so) and delaying the acks will increase the time before it retransmits
>a packet. When the link drops packets, the end result is that delaying
>acks decreases performance, and people start implementing schemes like
>the above to get performance back again.
>
>However, the bad thing about using fixed time thresholds is that the
>timers usually tick all the time (not only "between packets", but all
>the time from "end of first packet" to "end of second packet") and thus
>when the datarate is low their mechanism will trigger as well.
>Ironically, when the datarate is low, anything that saves traffic will
>help a lot to improve performance. So, while performance may increase
>on Eric's system, it will decrease on other people's systems.
I don't understand your critisism. There is no fixed timer in the linux
TCP code. ACKs get delayed for min(ato,1/2) seconds where ato is the
current estimate of the packet interarrival time.
Again, the 1/2 upper bound on the delay is mandated by RFC 1122.
>- make sure the timers tick only between packets.
> requires a lot of coupling to the lower layers (PPP, SLIP).
There is no timer "ticking", an alarm is set when a packet
passes through the system, and no alarms occur when no packets are flowing.
>- adjust such "fixed thresholds" depending on the bitrate of the link.
> doesn't always work, because the first visible link may be faster
> than further links in the chain.
See above. The only fixed threshold is the one mandated by RFC1122.
Otherwise the delay is determined by the sampled time packet
interarrival time.
>- setup some averager to dynamically measure the lower bound on packet
> arrival interval (for reasonably sized packets) and adjust the
> threshold when that turns out to be above (or near) 1/2 second.
We are already doing this. Every time a packet with data arrives
we update the "average". This average is used to determine how
long to delay an ACK. The current averaging code could be somewhat
better mind you. Something more like the RTO estimator might be a
good idea.
-- eric
---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto