Subject: Re: Re the link draft...

From: Joe Touch <[email-masked]>
Date: Wed, 3 Nov 1999 17:13:37 -0800 (PST)

> From [email-masked]  Wed Nov  3 17:11:22 1999
> Delivery-Date: Wed, 03 Nov 1999 17:11:22 -0800
> Return-Path: [email-masked]
> Date: Thu, 4 Nov 1999 00:03:27 +0000 (GMT)
> From: Lloyd Wood <[email-masked]>
> To: Mikael Degermark <[email-masked]>
> cc: Phil Karn <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: Re the link draft...
> X-no-archive: yes
> 
> On Thu, 4 Nov 1999, Mikael Degermark wrote:
> 
> > At 02:02 PM 99/11/03 -0800, Phil Karn wrote:
> > >>    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...
> > >
> > >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.
> > 
> > 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. 
> 
> 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.

I'm not sure it is about TCP. Even UDP benefits from detection
and removal of corrupted packets. 

Joe

---

From: Mikael Degermark <[email-masked]>
Date: Thu, 04 Nov 1999 15:24:46 +0100

At 17:13 1999-11-03 -0800, Joe Touch wrote:
>> Mikael Degermark wrote:

I agree that most current UDP applications do want detection and removal
of corrupted packets. But perhaps not all.

I was thinking of a class of applications that can utilize the information
in damaged packets, provided that the damage isn't too severe.
The codecs are explicitly designed for this, and can conceal some 
damage.

These applications can deliver higher quality service to the users using
less radio resources if damaged packets are delivered rather than
discarded. Most voice codecs intended for cellular links are examples of such
applications. There are a couple of exceptions, since the error patterns
on some links (e.g., CDMA-2000) are such that when there is damage, it
is highly likely that the damage is extensive and covers the entire
payload as well as headers.

So I guess that I'm arguing that if we recommend that there should always
be a strong CRC covering the entire frame, we are unnecessarily restricting
the kinds of applications and the technical solution space available 
to engineers. Why would we want to do that? 

By the way. It should be obvious that no packet with a damaged header
should ever be delivered to an application. I'd be wary of any system
where the rate of erroneous headers is nontrivial. 

Micke