Subject: RE: Comments: ppp-over-aal2

From: Bruce A Thompson <[email-masked]>
Date: Fri, 30 Mar 2001 11:57:19 -0800

>At 03:38 PM 03/29/2001 -0600, Ali Irfan-FIA225 wrote:
>
>Sorry, if this is a duplicate, but I have not seen this appear on the pppext
>mailing list.
>
>Irfan
>
>-----Original Message-----
>From: Ali Irfan-FIA225 
>Sent: Wednesday, March 21, 2001 11:47 AM
>To: Bruce A Thompson
>Cc: [email-masked]; Pazhyannur Rajesh-QA6283
>Subject: Comments: ppp-over-aal2
>
>
>
>Bruce,
>
>Some comments on the draft:
>
>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. 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 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?

>Section 5.2, para 2: This is not an attempt to nit-pick. You are right about
>the overhead associated with PPPMux/AAL5. However, for overhead comparisons,
>it might be better to just state the overheads and let the implementor
>figure out which implementation is more efficient for his/her case. 
>
>On a per-packet basis
>         PPP/AAL2 adds the following overhead: 
>                 3 bytes CPS-PKT-HDR + (1 or 2) bytes PPP-Protocol ID + (1 or
>2) bytes CRC. 
>         PPPMux/AAL5 adds the following overhead: 
>                 (1 or 2) byte Length field + (0-2) bytes PPP Protocol ID. 
>
>On a per-frame (or per muxed-packet) basis:
>         PPP/AAL2 adds the following overhead: 
>                 Padding only when TIMER_CU expires
>         PPPMux/AAL5 adds the following overhead:
>                 8 bytes of AAL5 trailer + Padding on the last ATM cell.
>
>On a per ATM cell basis PPP/AAL2 adds 1 additional byte overhead of STF when
>compared with PPPMux/AAL5.

I went through this level of detail in the presentation I made in December. We could make the changes you suggest, or remove section 5 entirely. This section was really meant as justification to get the draft accepted as a work group item.

Do you feel we should make changes to the section or remove it?

>Section 6.1.4: STF =?

Start Field in I.363.2.

>Section 6.2.1 : Is the CRC-16 computation a commonly used one or is this
>new. It might be helpful to provide a reference to a standard where this is
>commonly used.

We took this from Q.921. Q.921 does not reference a separate spec for the FCS computation.

>Section 6.2.2: Same as above for CRC-8.

We got this CRC spec from another ITU spec. I forgot which one at the moment. We decided at the last meeting to remove CRC-8 anyways.

>Section 7: The example is a little bit too long and contains many facts
>which have little relation to the PPP/AAL2 standard. It may be better to
>delete all the discussion above the PPP layer. Whether RFC2508 is used for
>compression is not related to PPP/AAL2.

I thought this section did add value. It sounds like your concern is that we describe too much about the application instead of just describing from PPP downward. We can make this change.

>Section 7: Between the length filter and the SSSAR should be the Service
>Specific Transmission Error Detection sublayer (SSTED), where the CRC
>computation occurs?

SSTED specifies a AAL-5 like structure on top of SSSAR. This draft is specifying the encapsulation for PPP over AAL2 which include CRC generation. So, CRC computation for PPP over AAL2 is part of this spec and not currently specified in any ITU document.

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

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

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

>The only reason for having the 8 bit CRC would be to cover the case when one
>wants to protect header and not the payload. If that is the objective, then
>the 8 bit CRC option should state this clearly. Also, there should be
>negotiation for this, and only one CRC algorithm (8 bit-on-header, or 16
>bit-on-payload) should be running on a PPP connection. My opinions.

Not true. We defined the max payload size for CRC-8 to be 32 bytes. That's 2**8 bits. So, CRC-8 was for applications that wanted high bandwidth efficiency with very small payloads (< 32 bytes). We decided at the mtg that the benefits did not warrant the complexity of including CRC-8 in the draft.

         Bruce T

>Regards
>Irfan 

Bruce Thompson
Cisco Systems
email: [email-masked]
office: (408)527-0446
home office: (408)868-0112
San Jose, CA