Subject: RE: Comments: ppp-over-aal2

From: Karl Fox <[email-masked]>
Date: Thu, 05 Apr 2001 11:32:41 -0400

At 03:57 PM 3/30/01, Bruce A Thompson wrote:
>>At 03:38 PM 03/29/2001 -0600, Ali Irfan-FIA225 wrote:
>>Section 8: Should mention that PPP LCP FCS-alternatives extensions is
>>described in RFC1570. (Any reason for using option values 32 and 64 and not
>>8 and 16 for 8-bit CRC and 16-bit CRC? Is there a specific name to the 8 and
>>16 bit CRCs described in the draft?
>
> From the last meeting, we decided to get rid of CRC-8. This will get rid of much of the complexity described in the draft. It also means that there will be no negotiation for CRC via LCP. This section will now just say that CRCs cannot be negotiated via LCP and that only CRC-16 is supported.

There's no need to do that.  Simply say that CRC-16 is the default FCS.  If 
someone wants to implement RFC 1570, then let them.  Those who don't will 
just reject the option.

>>Section 8, last sentence: See first comments. Also Is the following
>>statement from RFC2364 applicable here:
>>
>>The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
>>    larger size than the maximum CPCS-SDU size specified in the
>>    associated direction for the virtual connection's traffic contract.
>
>The SSSAR function does not have any maximum payload defined for it. We should define the maximum payload based on CRC length from comments above.

Better yet, ignore all the discussion about CRC length and payload length 
and just define the default packet size and default CRC type.  That's what 
other PPP encapsulation documents do.

>>Bigger question on section 6.2: In previous email-trains, there was concern
>>that allowing multiple options for CRC based on length of payload causes
>>complexity and should be avoided; however, the current draft still has two
>>options CRC-8 and CRC-16 based on the length of the payload. The difference
>>is only one byte. In most cases, the smallest size payload including the
>>PPP-protocol id will be about 10 bytes. The difference between 8 and 16 bit
>>CRC is 10% and will be lower for smaller sized payloads. Can we not just
>>stick with the 16 bit CRC? 
>
>That's what we decided in the last mtg. Note though the complexity is optional since 8 bit CRC is negotiated.

If an 8-bit FCS would be useful, you could always write an enhancement to 
the FCS-Alternatives option described in RFC 1570.

Karl Fox <[email-masked]>
Key fingerprint = 4159 B4AD 339D 4E2A 255F  9CC4 9DA9 CB4B B16D E2B1

---

From: Dennis Ferguson <[email-masked]>
Date: Wed, 11 Apr 2001 20:38:56 -0700

Bruce,

I don't get around to reading this list very often, but I wanted
to comment on this since no one else did.

> >Section 4, para 2: Is the limitation of 1500 bytes MRU for CRC-16 a
> >hard-limit? Is this necessary? The MRU probably depends on the
> >error-characteristics of the link. Probably leave it as an exercise to the
> >configurator to determine the appropriate MRU for a link using CRC-16. The
> >same comment carries over to the last sentence in Section 8.
> 
> I think you may be right about the 1500 byte CRC being incorrect. We put
> the 1500 byte MRU in because I thought that this was the maximum payload
> size that a CRC-16 could protect. From talking to people more knowledgeable
> than I about CRC's, I understood that in general a CRC of X bits can
> protect for errors in a payload of up to 2**X bits. I assume this formula
> is for single bit errors.

I'm sure this is not correct.  The CRC-16 will protect against all errors
in a frame with a burst length (i.e. the number of bits between the
first bit in the frame in error and the last bit in error) of 16 bits
or less.  A single bit error in a frame has a burst length of 1 bit, so
single bit errors will always be detected independent of frame length.
Note that the standard CRC-16 also has the feature (misfeature in some
contexts) that it detects all errors where an odd number of bits in the
packet have errors.  1 is an odd number of bits so, again, all single bit
errors in a frame will always be detected.  This all is a consequence of
the fact that the CRC computation is a modulus operation on the packet
data, which means that undetectable errors will be even (polynomial)
multiples of the (prime) CRC polynomial.  Since the CRC-16 polynomial
is 17 bits long it has no even multiples (i.e. undetectable error
patterns) which are less than 17 bits long.  Since the standard CRC-16
polynomial has an even number of terms, it has no even multiples with
an odd number of terms.

> Now that I run the numbers though, it looks like 2**16 bits comes
> to a protected payload size of 8K bytes instead of 1500 bytes. So the
> 1500 byte MRU is incorrect based on the formula above.

I don't get what you mean by "protected".  Note that it is possible for
a 1 byte packet (i.e. an N+1 byte frame when the N-byte FCS is added) to
have an error which can't be detected by the CRC-16, or by the CRC-32
for that matter.  With an n-bit FCS, random burst errors greater than
n-bits long will only be detected statistically, with a probability of
1/2^n, so all frames that are longer than the FCS itself can have
undetectable errors.

Given this, I can't figure out how there could be any magic frame length,
below which a packet is "protected" and above which it isn't.  I do
understand that the probability that any particular packet will have
an undetected error is (p * 1/2^n), where p is the probability that a
frame has at least two bits in error separated by more than n bits,
and that theoretical models which consider bit errors to occur
independently and randomly to individual bits will have p increasing
at a greater-than-linear rate with increasing frame length, but
(1) the increase is continuous, i.e. there is no magic frame length
where this suddenly goes from being ok to really bad, and (2) the
assumption of independent bit errors doesn't necessarily match
reality, there are a lot of ways data circuits can screw up causing
errors to occur in bursts which leave you solely at the mercy of
the (1/2^n) error detection probability of the FCS independent of
frame length.

> I think we should base Max MRU in this draft on the CRC length.
> Above a certain payload size, CRC become ineffective. I'm not sure
> though what formula we should be using for CRC length to max payload
> length. Do you have better info on the relationship between CRC
> length and payload protection again errors?

I'm not sure the formula you want exists.  I think that the choice of
FCS length is far less a function of maximum frame size than it is of the
expected error rate on the circuit, the nature of those errors, and
your (very subjective) risk tolerance for undetected errors in the
frames you receive.  At a high error rates you may wish you limited
your MRU even when the 32-bit FCS is in use, while at very low error
rates it hardly matters which FCS you choose no matter what your MRU.

Dennis Ferguson

---

From: Tmima Koren <[email-masked]>
Date: Sat, 14 Apr 2001 15:50:32 -0700

At 11:32 AM 4/5/2001 -0400, Karl Fox wrote:
> > From the last meeting, we decided to get rid of CRC-8. This will get 
> rid of much of the complexity described in the draft. It also means that 
> there will be no negotiation for CRC via LCP. This section will now just 
> say that CRCs cannot be negotiated via LCP and that only CRC-16 is supported.
>
> >The SSSAR function does not have any maximum payload defined for it. We 
> should define the maximum payload based on CRC length from comments above.
>

Thanks for the comments
We'll include them in the next revision of the draft
Tmima