-----Original Message-----
From: Gabriel Montenegro [SMTP:gab@Eng.Sun.COM]
Sent: Wednesday, January 27, 1999 2:31 PM
To: Sen, Sanjoy [RICH2:2S52:EXCH]
Cc: 'adfalk@mail.hac.com'; padmanab@microsoft.com;
karn@homer.ka9q.ampr.org; rludwig@cs.berkeley.edu; pilc@lerc.nasa.gov
Subject: RE: LL ARQ on LD links [was: PILC: prioritization]
> There is perhaps no need for the link layer ARQ mechanism to tell
TCP to
> retransmit, since, as Phil has rightly pointed out, it can do the
> retransmission itself. BUT, there is always a need for the link
layer to
> tell TCP NOT TO RETRANSMIT when it itself is doing
retransmissions. One way
> to achieve the same goal is to stop the link layer retransmissions
and let
> TCP recover. Question is when?
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?
Again, the question is "how long you want to delay DUPACKs in order
to give the link layer a chance to recover"? This may call for link-layer
awareness. This "awareness" may be static in nature - e.g, given a link
layer recovery takes X msec, I would not have to delay DUPACKs by more than
Y ms, where Y = F(X).
>
> The link layer retransmissions should be continued to the
maximum possible
> amount of time in order to get the maximum benefit out of it,
making sure
> that TCP's RTT doesn't timeout. But since this RTO estimation can
be a
> highly variable quantity (thanks to some previous retransmissions
over a
> GSM/CDMA radio link with ~ 100 ms delay and Jacobsen's algorithm),
there
> seems to be a need of "link-layer awareness for TCP " or
"TCP-layer
> awareness for the link layer", particularly for high FER
conditions.
>
> -Sanjoy
conversely, sometimes there is a need for the link layer to not try
too
hard to patch things up (for time-bounded traffic). From our
pilc draft:
Notice that sometimes it may be desireable to forgo ARQ
because of the additional delay it implies. In particular, time
sensitive traffic (video, audio) must be delivered within a
certain time limit beyond which the data is obsolete. Exhaustive
retransmissions in this case merely succeed in wasting time in
order to deliver data that will be discarded once it arrives at
its destination. This indicates the desireability of augmenting
the protocol stack implementation on devices such that the upper
protocol layers can inform the link and MAC layer when to avoid
such costly retransmission schemes.
Generally, I wouldn't expect that any link layer ARQ mechanism (unless its
real fast) will be used for real-time (delay constrained) services. TCP is
also not a preferred mechanism for such services.
Sanjoy
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST