Subject: Re: SUGGESTED ARQ TEXT Advice for Internet Subnetwork Designers ID

From: Phil Karn <[email-masked]>
Date: Wed, 20 Jun 2001 00:25:32 -0700

Hi. I am *finally* updating the LINK document with the text submitted
since the Minneapolis IETF. Dan Grossman's stuff in security (with my
editorial rewordings) is in, and I'm now working on your ARQ text. I
have some comments and suggestions.

>Error recovery generally involves the retransmission of lost or
>corrupted data when explicitly or implicitly requested by the
>receiver. It can also involve the generation and transmission of
>redundant information that lets the receiver regenerate or correct
>some amount of lost or corrupted data without needing explicit
>retransmission of that amount.

Actually, both ARQ and FEC rely entirely on the transmission of
redundant information. It's just that FEC sends much more redundant
information than ARQ -- enough to correct some number of errors
without a transmission.  The redundancy in ARQ is much more limited,
just enough to reliably detect that an error has occurred without
actually being able to correct it.

>The redundant information approach, using error control coding (of
>which Forward Error Correction, or FEC, is a well-known example)
>takes place in the data-link layer, very close to the physical
>layer. Many link layers use a combination of both coding and ARQ
>retransmissions to improve performance.

In most systems that I know, FEC is implemented entirely in what we'd
usually call the physical layer. ARQ is generally in the link layer or
above.  Of course, some systems have multiple levels of ARQ, or have
ARQ that is more tightly bound with FEC than in others.

The rest of your text looks very good and I propose to include it
almost as-is, with just a few rewordings and sentence tightenings.

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 20 Jun 2001 13:03:17 +0100 (BST)

On Wed, 20 Jun 2001, Phil Karn wrote:

> redundant information.

I'd argue that if it's requested by the other end, it's not redundant.

(Interleaving is an error-protection strategy that arguably doesn't
include redundancy. Not sure I'd call it error recovery though.)

> It's just that FEC sends much more redundant
> usually call the physical layer.

FEC is logical, not physical...

L.

> ARQ is generally in the link layer or

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Phil Karn <[email-masked]>
Date: Wed, 20 Jun 2001 11:58:05 -0700

>FEC is logical, not physical...

I don't understand what you mean here. Traditionally, FEC is almost
always integrated within a modem, making it part of the physical
layer. Except for the effect of FEC on error statistics and
transmission latency, it is essentially invisible to the link
layer. On the other hand, ARQ can be and frequently is implemented at
many protocol layers, including the physical layer (V42bis), link
layer (LAPB), transport layer (TCP), etc. As I now say in the LINK
draft, FEC is beginning to be applied above the physical layer, most
notably in reliable multicast, but this is a pretty recent
development.

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 20 Jun 2001 20:58:31 +0100 (BST)

On Wed, 20 Jun 2001, Phil Karn wrote:

> I don't understand what you mean here.

FEC is a logical process (walk the trellis, do the coding) that
doesn't involve obviously physical quantities; just the information
that all other layers also use.

> Traditionally, FEC is almost
> layer.

I really don't see how that follows. Integration of circuitry and
logical layer separation are different things. FEC is before the
modulation stage, and after demodulation - so it's not physical.

> Except for the effect of FEC on error statistics and
> layer.

s/FEC/ARQ, making ARQ a physical process... so ARQ has a buffer and
some overhead - so?

If one end of a link disables its FEC, the other doesn't, and they
can't communicate as a result, they're now using different physical
layers? I'd be uncomfortable with that thought.

> As I now say in the LINK draft, FEC is beginning to be applied above
> the physical layer, most notably in reliable multicast, but this is
> a pretty recent development.

To me, the fact that FEC can be applied at other layers shows that
it's not a physical process; nothing uniquely physical about it.

This is no doubt all safely rhetorical, a la presentation/session...

L.

---

From: Phil Karn <[email-masked]>
Date: Wed, 20 Jun 2001 13:11:28 -0700

>This is no doubt all safely rhetorical, a la presentation/session...

Exactly. Years ago it became obviously silly to argue about what "layer number"
some function belongs to; what really matters is the ordering of the layers,
not their total number or names.

Phil