Subject: Re the link draft...

From: "John Border" <[email-masked]>
Date: Wed, 3 Nov 1999 13:14:37 -0500

Phil,

    I reread the ltn draft last night and it triggered a thought re the link
draft.  This is probably already in the "planned to be covered" category.  But,
just in case...

    The ltn draft points out (in Section 2.1) that end-to-end checksums are
relatively weak.  Should the link draft recommend the use of a strong CRC at
the link layer?  These relates to the FEC issue but is not quite the same
thing...

								John

---

From: Phil Karn <[email-masked]>
Date: Wed, 3 Nov 1999 14:02:19 -0800 (PST)

>the link layer?  These relates to the FEC issue but is not quite the same

I think that's a good idea. What does the group think?

I could write some text along these lines. Basically, the end-to-end
principle notwithstanding, there's rarely much cost to putting strong
error detection at the link layer. On most wired networks the error
rates are so low it hardly matters whether you have a CRC, except for
Ethernet, where the CRC is an intrinsic part of the collision
resolution scheme.

On modern radio channels, the coding is usually strong enough that
when a decoding error does occur the whole packet (or a good chunk of
it) is damaged, so there's little reason to forward it just in case
the application can tolerate some errors. So again there's little
reason to not do a strong link layer CRC, even though it doesn't
really fix the weak end-to-end TCP checksum.

Phil

---

From: Mikael Degermark <[email-masked]>
Date: Thu, 04 Nov 1999 01:02:23 +0100

>really fix the weak end-to-end TCP checksum.

I'd say that for TCP, there is no question that a strong CRC is needed on the 
link layer. 

For applications such as voice, however, it is not clear at all that there
should
be a strong CRC covering the *entire* frame. Some future cellular systems
could have worse performance if there was a strong CRC over the entire
frame. So if this language is put in there, it should be made clear that it
is about
TCP. Not necessarily all UDP-based applications.

Micke

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 4 Nov 1999 00:03:27 +0000 (GMT)

On Thu, 4 Nov 1999, Mikael Degermark wrote:

> should be a strong CRC covering the *entire* frame. Some future
> cellular systems could have worse performance if there was a strong
> CRC over the entire frame. 

Are there any existing systems where performance suffers because of
this?

> So if this language is put in there, it should be made clear that it
> is about TCP. Not necessarily all UDP-based applications.

That suggestion would encourage link designers to attempt to
distinguish between TCP and UDP traffic.

Is that a good thing?

L.

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

---

From: Mikael Degermark <[email-masked]>
Date: Thu, 04 Nov 1999 02:55:52 +0100

>Are there any existing systems where performance suffers because of

Well, if I were to design an IP telephony service over a link with 
the properties of a current GSM link, I would not want all damaged frames
to be discarded. Of the next-generation cellular systems, I would guess
that two out of three would have worse performance. Exactly how much
worse is an open question, as far as I know.

>distinguish between TCP and UDP traffic.

In an ideal world, one wouldn't have to distinguish. But if one wants
different tradeoffs between delay and error rate for TCP and some (not all!)
UDP traffic, it seems inevitable. Over cellular one would have to do
header compression to have reasonable spectrum efficiency, so the
distinguishing element is a part of the system whether one likes
it or not. 

Cheers,

Mikael Degermark

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 4 Nov 1999 01:06:17 +0000 (GMT)

> >Are there any existing systems where performance suffers because of

paraphrasing, "No." so, not BCP.
 
> the properties of a current GSM link,

Why on earth would you want to do that?

L.

thinking gateways.

---

From: Kevin Grace <[email-masked]>
Date: Thu, 04 Nov 1999 07:23:35 -0500

> distinguishing element is a part of the system whether one likes

We here at MITRE have been looking at this issue as part of our
research program. As we see it, applications (voice, email, etc. )
have their own unique delivery requirements which can be described in
terms of three variables: bandwidth, delay, and reliability. A link,
particulary a wireless link, can be adapted to try to meet the
delivery requirements of the applications. Bandwidth can be traded for
reliability by performing FEC. Delay can be traded for reliability by
performing ARQ.

For example, applications which are not delay sensitive but want
reliable delivery (eg. email, pager) could have their delivery
requirements met by the link performing ARQ. Applications like voice
which are latency/jitter sensitive could be better served by the link
layer performing FEC as long as enough bandwidth was still delivered.

The next question becomes, how do we communicate the application's
delivery requirements to the link layer? One possible way is to use
the existing IP header's TOS (type of service) field. There are
other's way too. The goal is that packets need to be tagged with
something that indicates their application's delivery
requirements. Then, link designers have a mechanism which helps them
know how they should perform the trade off.

-Kevin

---------------------------------------------
Kevin Grace          The MITRE Corporation 
781-271-8388         202 Burlington Rd
[email-masked]     Bedford MA, 01730

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 04 Nov 1999 15:16:02 +0100

>know how they should perform the trade off.

Kevin,

I encourage you to look into
http://iceberg.cs.berkeley.edu/papers/Ludwig-FlowAdaptive/index.html and also
http://iceberg.cs.berkeley.edu/papers/Ludwig-WINET99/

Both papers argue strongly in favor of distinguishing flow types such as 
UDP and TCP (but not limited to those two) at the link layer to adapt link 
layer error control. It also discusses the "how do we communicate the 
application's delivery requirements to the link layer?".

///Reiner