Gabriel-
Your excerpt below doesn't seem to apply to TCP. I mean, why use a
reliable protocol at all (link or transport) if you can't wait for
retransmissions?
It seems that a reliable link protocol would benefit by knowing if
there is TCP or UDP in the packet and, if UDP, if late is as good as
missing.
---aaron
______________________________ Reply Separator _________________________________
Subject: RE: LL ARQ on LD links [was: PILC: prioritization]
Author: gab@Eng.Sun.COM at mime
Date: 1/27/99 12:30 PM
> 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?
>
> 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.
-gabriel
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST