Subject: Re: pilc minutes for IETF 48

From: Vernon Schryver <[email-masked]>
Date: Thu, 5 Oct 2000 15:58:10 -0600 (MDT)

> From: Dr G Fairhurst <[email-masked]>
> To: Reiner Ludwig <[email-masked]>

> 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?
> ...

I also tried to point out that ARQ (persistent or otherwise) does not
necessarily implies that all other streams must wait for one stream that
is stuck.  Not even TCP is still limited to go-back-N recovery tactics,
so why would a newfangled radio link layer be so limited?

Isn't it common common wisdom that go-back-N or stop-everything-until-a-
sick-packet-gets-through is ok only when both the bandwidth*delay product
and the probability of error are low?  In other cases, aren't you supposed
to overlap as much as possible, and so have selective ACKs or NACs and
selective retransmissions?

Moreover, by Dr. Fairhurst's assumptions, either
  1. no other packets for any TCP stream are flowing because the link
     is very sick.
  2. this particular packet will soon get through because the problem
     was temporary.
  3. something is very badly broken in the design or implementation of
      the link layer, because one particular packet cannot get through
      but others can.

(#3 is not in the least theoretical to those of us who've fought hardware
and software problems that corrupt some packets but not others.)

Vernon Schryver    [email-masked]

---

From: Dr G Fairhurst <[email-masked]>
Date: Fri, 06 Oct 2000 10:52:17 +0100

I don't think we differ as much as you may think we do.

> so why would a newfangled radio link layer be so limited?

The Selective Repeat ARQ is definitely recommended (I think you'll find
when we first wrote the words for the draft it does say this already).

Sorry, this debate is less than clear.  I was talking only about WINDOW size,
in many link ARQ schemes there is a fixed modulus or window which
limits the maximum number of packets in flight.  This may be determined by
either amount of buffer memory or size of frame number field (before everyone
shouts and says "but not all" - I know there are exceptions). The HDLC standard
works this way - and so do nearly all variants of it, I have seen.

Out-of-order forwarding is allowed (again in the draft) - although current
recommendations are that this is only allowed when it preserves in-order
delivery within each flow. This still doesn't mean an ARQ protocol can transmit
for ever if it says it is RELIABLE and if there is a packet still unacknowledged
at the low window edge, this can still cause window exhaustion with
a finite numbering space (or available memory).

> selective retransmissions?

Sure you are (the draft says this, I am sure it meant to anyway).

> and software problems that corrupt some packets but not others.)

If I understand you:

1 is what I call an OUTAGE - we have text already which recommends what
to do (hang on to the last few packets if you can and send them once you
are able - not quite the same as recommending persistence!)

2 may happen - but I have seen cases where this can take a long time
- particularly with a big packet and periodic interference.

3. This happens too... and can be bizarre.

The non-persistent argument seems to help with 2,3.  At least it clears out all
that
old link state and any buffers tied up, so that things can resume orderly in the
future.

The persistent argument is equivalent to 1 for an outage.

What I'm trying to find out is what we should recommend when we have a
high (or moderately high) packet loss rate.

If we have only one TCP flow, do we care?
Probably not, as long the ARQ tries (a few attempts) or forever.  The latter may
even be better. Good versions of HDLC could work fine with segmentation.

If we have many flows - are there other issues?
I can think of these two:

1) The ability to classify UDP form TCP seems very desirable (although
difficult with tunnels/encapsulation and fundamentally problematic with IPSEC)

2) I suggest sharing with other TCP flows can become an issue - perhaps less
so if you are end-system connected to a mobile net, but more so if you are
connecting
a remote LAN with many hosts over a wireless (or any RF) link. Several factors
here:
    per-flow state,
    head-of-line block when buffer/window exceeded,
    forwarding delay (out of order delivery may be desirable)

3) Anything else?

> Vernon Schryver    [email-masked]

Gorry Fiarhurst.

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