Phil R. Karn at mouton.ARPA (karn@mouton.ARPA)
Tue, 14 Jan 86 01:59:12 est
Delaying acknowledgements with timers has always bothered me. Either the
application will send something in reply almost immediately (e.g., Telnet
echoing) or it will take so long that the acknowledgment timer will expire
with nothing to send, increasing the effective round trip time and limiting
throughput when the windows are small.
In an upcall environment, it would seem better to just note the fact that an
ack is owed and upcall the user, giving him a chance to send some data. Once
the user returns, you immediately invoke the tcp output routine which sends
the ack plus reply data, if any. This avoids having to set a short timer,
which is often hard to do efficiently in an operating system environment.
Of course, the user cannot be permitted to block.
Another approach is to look at the incoming PSH bit. Since PSH from the
remote TCP usually means "I think my client doesn't have any more data to
send for a while", you could start the acknowledgement delay timer only if
PSH is clear; otherwise you would immediately return an ACK. This would
have the additional advantage of allowing you to acknowledge a burst of
segments with a single response.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:39 GMT