Subject: Re: pilc minutes for IETF 48

From: Dr G Fairhurst <[email-masked]>
Date: Thu, 05 Oct 2000 20:34:50 +0100

Reiner Ludwig wrote:

> At 14:01 21.09.00 +0100, Dr G Fairhurst wrote:
> > > ***However***, you have to ensure that the link layer does this _only_ for
> > > the reliable flows such as the TCP-based flows.
> >
> >Well, here I think you need to be much more specific.  What you are proposing
> >may well be of merit where you are able to  differentiate individual flows
> >AND reliably indicate which are TCP and which are UDP. It also implies
> >a sufficiently large link layer retransmission window, so that
> >window does not stall during the time to recover the worst case
> >loss pattern (which could be a challenge on long-delay links (e.g.
> >100 Mbps satellite circuit).
>
> Sure, a link layer retransmission window should be well designed for its
> environment of operation but when it stalls, it stalls. So what? That's not
> any different from a link outage caused by some other reason.

Who said OUTAGE?

There are links out there which do not suffer complete outages for prolonged
periods of tens of seconds (or more), but which do exhibit high rates of
loss: either through bursts of errors or some other error distribution.

Reliable link ARQ with full persistence usually implies you work on retransmitting
the
oldest packet until the link window runs out, or the transmission suceeds.

In traditional link ARQ protocols, this means that you hold other data,
when you are having a rough time forwarding one particular packet.

When the link consists of many TCP flows, this holds all flows. Even those
flows which have sent relatively little data, and are unlikely to be the one
needing the retransmission.

> As Vernon has pointed out in his last mail: if the link layer cannot get
> the packet across the link, TCP won't be able to do that either. So for the
> receiving application it doesn't make a difference whether packets cannot
> be delivered to it because they are held in some link layer or by TCP.

Again, what about the other hosts down-stream which have their packets queued?

> >Recommendations for fully reliable ARQ may also need to consider the impact
> >of alternate network paths which do not pass over the errored wireless link.
>
> We are talking of recommendations for a designer of a specific link layer.
> Why does that require considering the impact of paths that do not pass over
> that very link.

> >[...]
> >While this may be true in these studies, I'd like a clearer understanding of
> >the factors, which influence this before we leap into general conclusions.
> >
> >Many, although I have not examined all of these, refer to cellular
> >phone/wireless
> >links, and not to generic radio links which include satellite, high bandwidth
> >line of sight, very low bit rate, etc.
>
> I forgot to mention the Internet Draft presented by NTT DoCoMo about TCP
> performance over W-CDMA. W-CDMA clearer qualifies as high bandwidth x
> delay. One of their key results (which unfortunately was not on their
> conclusion slide) was that they got the best TCP performance when the link
> layer error recovery persistency was high.

I will be most surprised if this is the case for many TCP flows sharing the link.

> >I think there is evidence that at least some of
> >these
> >links have in the past performed very poorly with reliable ARQ protocols.

> ......
> ///Reiner

Gorry Fairhurst

--
------------------------------
http://www.erg.abdn.ac.uk/users/gorry

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 06 Oct 2000 09:31:12 +0200

>needing the retransmission.

You describe a poorly designed link layer ARQ protocol causing the 
head-of-line blocking problem. In this case, the problem is caused only for 
the other *TCP flows* since my argument was that non-TCP flows are treated 
separately.

To avoid that problem, you can allow the link layer to do out-of-order 
delivery of packets belonging to different flows. You should only enforce 
in-order delivery for packets belonging to the same TCP flow to not falsely 
trigger fast retransmit / fast recovery.

Caveat: the link layer must be given the opportunity to distinguish flows.

///Reiner