Wouldn't it make sense to strech the ACK when the previous ACK is still in
the TX queue of the device? I know that sort of behaviour was always an
issue on modem links where you don't want to send out redundant ACKs.
Perhaps, but it isn't clear that it would be worth the cycles to check.
I doubt that a simple reference count on the ACK skb would do it
since if it were a bare ACK I doubt that TCP keeps a reference to the
skb in the first place?
Also, what would be the "trigger" to send the next ACK after the
previous one had left the building (Elvis-like)? Receipt of N in-order
segments? A timeout?
If you are going to go ahead and try to do stretch-ACKs, then I suspect
the way to go about doing it is to have it behave very much like HP-UX
or Solaris, both of which have arguably reasonable ACK-avoidance
heuristics in them.
But don't try to do it quick and dirty.
rick "likes ACK avoidance, just check the archives" jones
on netdev, no need to cc me directly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
