Subject: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-00.txt

From: [email-masked]
Date: Tue, 06 Mar 2001 06:51:21 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: PPP over AAL2
	Author(s)	: B. Thompson, b. Buffam, T. Koren
	Filename	: draft-ietf-pppext-ppp-over-aal2-00.txt
	Pages		: 
	Date		: 05-Mar-01
	
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of ATM Adaptation Layer 2 (AAL2) for
framing PPP encapsulated packets.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pppext-ppp-over-aal2-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ian Rytina <[email-masked]>
Date: Fri, 09 Mar 2001 16:31:01 +1100

Hi Bruce/Tmima,

I am a bit confused about the use of the UUI code-points in
Section 6.1.3 of PPP/AAL2.

It is proposed to use the values 1, 3 and 5 to indicate "non-final
packet" for the three different types of encapsulation. What is
the purpose of these values ? Can't you just use UUI=27 for all of
these non-final packet scenarios ?

Cheers,

Ian.

[email-masked] wrote:

>   ----------------------------------------------------------------------------------------

---

From: Bruce A Thompson <[email-masked]>
Date: Fri, 09 Mar 2001 08:28:34 -0800

Are you looking at the draft that was just submitted? Section 6.1.3 in that draft says the following:
  
>This proposal uses three UUI code-points as follows:
>
>    UUI Code-point       Packet Content
>    ++++++++++++++       ++++++++++++++
>
>    27                   Long    CRC encapsulation, non-final packet.
>
>    26                   Long    CRC encapsulation, final packet.
>
>    25                   Short   CRC encapsulation.

Code point 27 is the only code point we are using to indicate "non-final packet". Both code points 26 and 25 indicate final packet.

         Bruce T

> > implementation to automatically retrieve the ASCII version of the

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

---

From: Ian Rytina <[email-masked]>
Date: Tue, 13 Mar 2001 13:18:56 +1100

Hi Bruce,

Sorry - I was looking at the one that Tmima had distributed to me
a week before submission. It looks like it changed quite considerably
between that one and the submitted draft.......

I notice that the "minimal" payload encapsulation has disappeared (where
the CRC-8 only covers the PPP protocol id field). What was the reason
for leaving this out ?

/Ian.

---

From: Bruce A Thompson <[email-masked]>
Date: Tue, 13 Mar 2001 09:54:42 -0800

>the CRC-8 only covers the PPP protocol id field). What was the reason

We wanted to simplify the draft from the version you looked at. The version you looked at had 3 CRC options: 16 bit CRC (covers packets to 1500 bytes), 8 bit CRC (covers packets to 32 bytes), and minimal 8 bit CRC (covers the first 32 bytes of the packet).

We had a good deal of discussion about whether minimal 8 bit CRC should do a CRC on just 1 byte or multiple bytes or 32 bytes. We realized the answer was based on the trade off between allowing errors payloads (for codecs such as the AMR codec) and protecting compressed headers (compressed RTP and IP headers should really be covered by a CRC since the IP checksum is not transmitted).

Another issue that came up with minimal 8 bit CRC was the potential conflicts it caused with I.366.1. This issue was that we couldn't just use UUI code point 27 to indicate non-final packet with minimal 8 bit CRC. That's because we wanted to allow the receiver to identify the type of CRC a packet had before the last fragment was received. This allows the receiver to run a CRC check while the fragments of the packet are coming in. We didn't know how to solve this problem without conflicting with the current UUI definitions in I.366.1.

The final issue with minimal 8 bit CRC was the concern about applications that don't use UDP or TCP checksums and rely on the link layer checksums to discard packets. This is very common in networks today. This means that the only place that minimal 8 bit CRC could be used was a carefully engineered network where it was known that all the sources were generating proper transport and application layer checksums. In addition, we didn't know if there were other PPP payload types besides IP that depend on link layer checksums for error detection. This issues was going to cause us to have to write a large about of text trying to describe the conditions that it would actually be safe to cover less than a full packet with a CRC.

In the end, we decided that minimal 8 bit CRC was causing too many complexities in the draft compared to the added bandwidth savings for packets larger than 32 bytes. Our thought was that if bandwidth savings for VoIP was that important, you could run CRTP with a compressed codec (like AMR) and end up with packets less than 32 bytes. Regular 8 bit CRC could be used for these packets.

If this is still an issue for you I would be glad to discuss it further. Will you be at the mtg?

         Bruce T

Bruce Thompson
Cisco Systems
email: [email-masked]
office: (408)527-0446

---

From: Ian Rytina <[email-masked]>
Date: Fri, 16 Mar 2001 11:59:22 +1100

Hi Bruce......comments below.......Ian.

> Another issue that came up with minimal 8 bit CRC was the potential conflicts it caused with I.366.1. This issue was that we couldn't just use UUI code point 27 to indicate non-final packet with mi…

I am not sure I follow this entirely (however my CRC knowledge is a bit rusty these
days). Don't you need the CRC in the final packet, and the whole packet reassembled
before you can use the CRC ? I guess you could do some sort of computation as
the packets come in, but ultimately you still have to wait until the final packet and then
do your CRC. So practically speaking, what do you gain by knowing the eventual
type of the CRC.

> The final issue with minimal 8 bit CRC was the concern about applications that don't use UDP or TCP checksums and rely on the link layer checksums to discard packets. This is very common in network…

I thought the text was ok as it was. The protocol RFC provides support of the function,
it is up to the implementors/network operators to decide how and when it is appropriate
to use it.

> In the end, we decided that minimal 8 bit CRC was causing too many complexities in the draft compared to the added bandwidth savings for packets larger than 32 bytes. Our thought was that if bandwi…

FR, EFR and some modes of AMR (plus header) won't fit into 32 bytes. For AMR, this
complicates things somewhat, since the sender would have to be aware of the AMR mode,
or continuously checking the length of packets before deciding which CRC option to use.

> If this is still an issue for you I would be glad to discuss it further. Will you be at the mtg?

I still think this is minimal CRC valid practical option, since the ATM/AAL2 CRCs and
the UDP CRC can validly cover the other parts of the packet. I'll be in Minneapolis
next week, so we can further develop things there.

---

From: Bruce A Thompson <[email-masked]>
Date: Fri, 16 Mar 2001 11:03:29 -0800

Specifying the CRC type before the last fragment first requested by James Carlson in an earlier thread when he went through the initial version of the draft. I think the issue is that the receiver may build up a running CRC as the fragments of a packet are received. Here is what he said in that thread:

>If you're talking about the variable CRC scheme, I think the
>consequences of this might be fairly serious, and that's the part of
>my comment that I was holding until later to see where the dust
>settled.  For both software and hardware, the implication is that both
>CRC-16 and CRC-32 must be run in parallel on all data received on a
>given CID.  For hardware implementations, it means that two pipelines
>are required.  For software implementations (think 860SAR on a T1
>line), it means that the inner loop does twice as work.  For both,
>this bumps up the intermediate state storage requirement for each of
>these streams and the I/O rate to that storage.
>
>I'm not an AAL2 expert, and I don't know the restrictions on UUI
>values (why is 27 'continue' and what are 28-31?), but it certainly
>would be nice to alert the receiver about the CRC mode in use before
>the first chunk has to be processed rather than as the last one is.

According to his comments, if you don't specify the CRC type until the last fragment is received the receiver must do a running CRC calculation for all possible CRC's in parallel.

>it is up to the implementors/network operators to decide how and when it is appropriate

I think at least the text for minimal CRC should describe the assumptions made to allow it's use. I.E., that layers above PPP are separately providing protection via CRC/checksum for important parts of the payload since the link layer CRC is not covering the entire payload.

I have a question in this regard. Are there any standardized link layers that provide transport for IP and/or PPP that don't include a CRC over the entire payload? If not, it seems like we'll be breaking new ground here for PPP transport by creating a mode that don't cover the entire payload. That's my main concern here. I would like to hear some consensus from the group that it's OK to leave portions of the PPP payload uncovered by the CRC.

>or continuously checking the length of packets before deciding which CRC option to use.

Are you then advocating we run only 1 CRC method per PPP session? If not, the receiver would have to check incoming packets for which CRC to run on them. 

If we ran 1 CRC method per PPP session, this would simplify things again. We could then go to just 2 possible CRC modes where a single mode is negotiated per PPP session. It could be just CRC-16 as the base mode and minimal CRC-8 as a negotiated mode. Once the CRC was negotiated, it would be the only CRC method used for that PPP session. This would get rid of the issue described above about specifying the CRC type in fragments.

The only issue I would have with an option like this is whether it OK to define a PPP transport where portions of the PPP payload are uncovered by the CRC.

>next week, so we can further develop things there.

We should meet before the working group mtg to resolve this. Please send me some contact info so we can get together before the mtg on Tuesday.

         Bruce T

Bruce Thompson
Cisco Systems
email: [email-masked]
office: (408)527-0446