>> From gab@Eng.Sun.COM Wed Jan 27 14:51:52 1999
>>
>> but perhaps it's better for the link layer to recover. after all, if it
>> is a local problem it may make sense to invoke a local mechanism
>> (link layer).
>>
>> along these lines, nitin vaidya has been working on delayed duplicate
>> acknowledgements in which the tcp receiver delays its dupacks in order
>> to give the link layer a chance to recover. the problem is that if you delay for
>> too long, the sender times out and you pay big. nitin's simulations
>> are somewhat encouraging, though. and it works with ipsec. nitin, care to comment?
Well, here is a somewhat long-winded answer.
Delayed Dupacks was motivated by the perceived need
for mechanisms that can work despite IPSEC type schemes
that may encrypt TCP headers.
There may be several ways to do this, one of them being designing
right link level schemes (such as retransmitting at most once/twice,
etc. and/or FEC). In my mind, this is certainly the preferred
mechanism wherever feasible. Other possibility is to try to
tweak TCP so as to get a decent performance despite transmission
errors.
Delayed dupacks is in the second class -- the schemes in the
second class are "end-to-end" since they cannot get much help
from the network. As such, one should expect these schemes
to perform no better (or worse) than what "TCP-aware" schemes
can do (such as split-connection approaches or Berkely Snoop).
Delayed dupacks is designed to (try to) approximate
Berkeley Snoop, but can be used despite IPSEC. Snoop, and
delayed dupacks, are both designed to work well on relatively
fast wireless links where link level retransmissions may
deliver packets quickly (compared to end-to-end RTT)
but out-of-order -- this can lead to TCP fast retransmits,
which is what Snoop and delayed dupacks try to prevent.
Delayed dupacks seems to work reasonably well (at least in the
simulations we did) in environments where Snoop can work well
(namely, when the delay-bandwidth product for the wireless
hop is at least 4 segments and wireless transmission time
is not too large).
A point in favor of Snoop is that while Snoop may not hurt
performance when it cannot help improve it, delayed dupacks
can hurt performance a bit.
When the wireless transmission time is large on an absolute
scale, as well as a large fraction of the end-to-end RTT,
fast retransmit -- as prevented by Snoop/delayed dupacks -- is
not a serious issue (since wireless link delay-bandwidth is small).
Such is the case when you are dealing with a slow wireless
link. In these circumstances, as has been pointed out
earlier, TCP would tend to timeout while the link layer
is busy doing retransmits.
In such a case, there seem to be few options, some of which
have been stated in the last few exchanges on this list.
My 2 cents ...
- nitin
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST