Subject: Request to accept PPP over AAL2 as a PPPEXT Work Group Item

From: Bruce A Thompson <[email-masked]>
Date: Wed, 13 Dec 2000 12:48:02 -0800

We presented PPP over AAL2 (draft-buffam-avt-crtp-over-aal2-01.txt) in the PPPEXT working group in IETF San Diego.

The presentation we gave gives an overview of the draft and the benefits of running PPP over AAL2 as opposed to PPP over AAL5 and PPP/PPPMUX/AAL5. As was stated in the presentation, PPP over AAL2 is more efficient than PPP over AAL5 when the average packet size for the PPP session is less than 440 bytes.

We are proposing PPP over AAL2 as a transport encapsulation for ATM networks. It is being proposed as an alternative to PPP over AAL5. The main reason for the proposal is to gain bandwidth efficiency for PPP links that will be used predominately for small packet traffic (like RTP encapsulated voice).

We are requesting that this draft becomes a working group item in PPPEXT.

Thanks greatly,

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

---

From: Ian Rytina <[email-masked]>
Date: Mon, 18 Dec 2000 15:06:10 +1100

Hi Bruce,

To me, this seems to be a good solution for running IP applications on
AAL2. I support your view that this should be a work item in PPPext.

Please note that if you require an impact on Q.2630.2, this will have to be
a Proposed/Draft Standard RFC in order for ITU-T to be able to reference
the RFC in normative text. If it is accepted as such an RFC by PPPext then
there should be no problem in getting this work also included in SG11 (via
contributions, of course).

Regards,

Ian.

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Dec 2000 17:31:09 -0500 (EST)

> We are requesting that this draft becomes a working group item in PPPEXT.

I think that the AAL2 mapping, at least, should become a pppext wg
item.  I'm not so sure about the split CID usage, though.

As I read the usage of the CID values in this draft, this is intended
to split the underlying physical link into a "fast" and "slow" path.
This appears to me to be orthogonal to the rest of the draft.  You
could just as easily specify this type of split over AAL5 (using
multiple VCs) or over any other medium with multiple channels.  In
fact, taking advantage of this split in a well-designed system would
appear to require more effort than described in the draft.  (For
instance, one would not want to put *all* small packets on a separate
channel.  Just those that aren't PPP control protocols and don't
relate to any flow over the large packet channel.)

The rest of the draft appears to stand well on its own in defining the
use of PPP on AAL2.  If you agree, could you submit just that part as
a draft-ietf-pppext-* document?

I'm not sure where the multiple-physical-layer proposal belongs.  I
suspect that it falls in a crack between the pppext working group and
one of the other groups.  (pilc?  issll?  diff-serv?)

(I have several comments on the rest of the draft, but I'll hold those
for a new version.)

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

---

From: Bruce A Thompson <[email-masked]>
Date: Wed, 20 Dec 2000 16:24:20 -0800

>item.  I'm not so sure about the split CID usage, though.

Great comments. I appreciate the detailed feedback.

>relate to any flow over the large packet channel.)

Note that this part of the draft is "should" vs. "must". I thought I worded the draft so that am implementation of PPP over AAL2 could use a single CID and still be compliant. If I didn't do this, then it was a mistake.

The reason that an implementation of PPP over AAL2 "should" use 2 CIDs is that it gives you an link fragmentation mechanism over a single ATM VC. I.366.1 does fragmentation and the CID scheduler in the AAL2 CPS layer will do the interleaving between CIDs. Most AAL2 SAR chips do this already.

With PPP over AAL5, you only get a link fragmentation mechanism if you run traffic over different ATM VCs, so I think it's a bit different.

The multiple CID usage is definitely an implementation optimization rather than an essential part of the draft. However, I still want to include multiple CID usage in the draft since an implementation that uses multiple CIDs will definitely have better latency characteristics over low speed links. I would be glad to move info on multiple CID usage to an appendix instead of the main body of the draft. Does this seem reasonable?

>one of the other groups.  (pilc?  issll?  diff-serv?)

With the multiple encapsulation proposal, I was more asking the group if it was even worthwhile pursuing. It would save 1-2 bytes per PPP payload from things like RTP encapsulated voice with RTP header compression (RFC 2508). If people thought it was worthwhile pursuing, then I guess we would move to the next step of how it should be presented.

         Bruce T

>(I have several comments on the rest of the draft, but I'll hold those

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

---

From: James Carlson <[email-masked]>
Date: Thu, 21 Dec 2000 06:50:55 -0500 (EST)

Bruce A Thompson writes:
> Note that this part of the draft is "should" vs. "must". I thought I
> worded the draft so that am implementation of PPP over AAL2 could
> use a single CID and still be compliant. If I didn't do this, then
> it was a mistake.

Yes, I did note that.  The problem is that the solution offered is too
specific to one domain.  Leaving in a note that CID can be used to
split up the streams for any desired purpose between consenting peers
is probably sufficient.  This could be the equivalent of RFC 2686 for
AAL2 users.

> The reason that an implementation of PPP over AAL2 "should" use 2
> CIDs is that it gives you an link fragmentation mechanism over a
> single ATM VC. I.366.1 does fragmentation and the CID scheduler in
> the AAL2 CPS layer will do the interleaving between CIDs. Most AAL2
> SAR chips do this already.

Right.  Again, a handy mechanism, but I think the draft presupposes
too much of the problem to be solved.

What I'd rather see is a more generic AAL2 draft that says, in effect,
"here's how you run PPP over AAL2 and here are some of the extra
physical layer features available."  You'd then have a second draft
specifying how to use the CIDs in PPP over AAL2 in the specific
context of (say) voice over IP.

This makes the draft more application-neutral and frees up the CID
mechanism for folks who might do different things with it.  For
instance, in the spirit of RFC 2686, it could be used for supporting
Integrated Services over PPP/AAL2.  In that case, you would not
specifically be segregating packets based on length.

> With PPP over AAL5, you only get a link fragmentation mechanism if
> you run traffic over different ATM VCs, so I think it's a bit
> different.

It's different in specific mechanism and TM consequences, but
otherwise I think it's very similar.

> The multiple CID usage is definitely an implementation optimization
> rather than an essential part of the draft. However, I still want to
> include multiple CID usage in the draft since an implementation that
> uses multiple CIDs will definitely have better latency
> characteristics over low speed links. I would be glad to move info
> on multiple CID usage to an appendix instead of the main body of the
> draft. Does this seem reasonable?

I think the multiple CID usage is an important feature of the
implementation.  Some reference to it should stay.  I don't think the
draft needs the stream splitting based on packet length language,
though; even in an appendix.

> With the multiple encapsulation proposal, I was more asking the
> group if it was even worthwhile pursuing. It would save 1-2 bytes
> per PPP payload from things like RTP encapsulated voice with RTP
> header compression (RFC 2508). If people thought it was worthwhile
> pursuing, then I guess we would move to the next step of how it
> should be presented.

Are you talking about the distinguished types for selecting CRC-16
versus CRC-32, or about further extensions to 2508?

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.

As a slightly simpler way of accomplishing the same thing, why not
just nail down the CRC choice on a per-CID basis?  For your proposed
VoIP usage, you'd have one CRC-16 only stream for C-RTP data, and
another CRC-32 only stream for regular IP.

---

From: Bruce A Thompson <[email-masked]>
Date: Fri, 22 Dec 2000 10:16:03 -0800

>specifically be segregating packets based on length.

OK, I understand your point. It sounds like you are recommending splitting PPP over AAL2 into 2 drafts.

One would be the generic "PPP over AAL2" which would describe the basic encapsulation and allow the use of one or more CIDs but not describe the application of multiple CIDs. The second would be "Integrated  Services using PPP over AAL2". It would describe the usage of multiple CIDs for LFI when multiple classes of delay sensitive traffic are carried over an AAL2 link.

I don't have a problem with doing this if this is the right thing to do. I would note though the RFC 2686 actually describes an extension to the encapsulation format described by RFC 1990. I thought this may be why it was created as a separate RFC and not a different version of RFC 1990.

Does anyone else have an opinion as to whether PPP over AAL2 should be split into different drafts?

One more question. I noticed that RFC 2686 has some new LCP options for negotiating the number of classes that will be used between peers. I wondering whether a method like this should also be used for the multi CID usage of PPP over AAL2. You could have single CID usage by default for PPP over AAL2 and then  have an LCP option for negotiating the usage of multiple CIDs by PPP over AAL2. One complication here is that this signaling is somewhat redundant to Q.2630.2 signaling that allows you to allocate multiple CIDs to an application. Any opinions on this?

>the first chunk has to be processed rather than as the last one is.

This is a good point. I didn't think of this. You're right. On the receiver you couldn't run the CRC check algorithm until you received the entire packet. I agree that doing a dynamic CRC based on packet length doesn't sound like a good idea.

>another CRC-32 only stream for regular IP.

This seems like a reasonable alternative. However, I'm not sure it's even necessary to use different CRC lengths for different CIDs.

Another alternative that was suggested by one of the other authors was to do CRC-16 only in the base protocol and allow CRC-32 as an optional negotiated format. The number of CRC bits used only limits your maximum payload size. As an example, PPP over HDLC runs with a 16 bit FCS with an optionally negotiated 32 bit FCS. What do you think about this method?

         Bruce T

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

---

From: James Carlson <[email-masked]>
Date: Fri, 22 Dec 2000 16:58:49 -0500 (EST)

> splitting PPP over AAL2 into 2 drafts.

Yes.

> One would be the generic "PPP over AAL2" which would describe the
> basic encapsulation and allow the use of one or more CIDs but not
> describe the application of multiple CIDs. The second would be
> "Integrated  Services using PPP over AAL2". It would describe the
> usage of multiple CIDs for LFI when multiple classes of delay
> sensitive traffic are carried over an AAL2 link.

Or perhaps "Multiple Service Classes using PPP over AAL2" or even
"Mapping VoIP using PPP over AAL2."  Yes, that's the idea.

> I don't have a problem with doing this if this is the right thing to
> do. I would note though the RFC 2686 actually describes an extension
> to the encapsulation format described by RFC 1990. I thought this
> may be why it was created as a separate RFC and not a different
> version of RFC 1990.

That's true; I just referenced that as an example way to describe the
mechanism without assuming a particular service to be delivered.

> One more question. I noticed that RFC 2686 has some new LCP options
> for negotiating the number of classes that will be used between
> peers.

Right.  Other than static configuration, there's no way to do this.

> I wondering whether a method like this should also be used
> for the multi CID usage of PPP over AAL2. You could have single CID
> usage by default for PPP over AAL2 and then  have an LCP option for
> negotiating the usage of multiple CIDs by PPP over AAL2. One
> complication here is that this signaling is somewhat redundant to
> Q.2630.2 signaling that allows you to allocate multiple CIDs to an
> application. Any opinions on this?

If the ATM UNI signaling already buys you this, then I don't see a
reason for PPP to mirror the same features.  Simply specify that the
number of CIDs in use must be negotiated by standard ATM signaling,
and that PPP implementations must abide by what ATM has negotiated.

At best, if you allowed LCP to negotiate, you'd duplicate what's
already there.  More likely, you'd set up new failure modes where one
part negotiates something different from the other.

For things that don't *have* to be negotiated, we do try to avoid
negotiating.

> This is a good point. I didn't think of this. You're right. On the
> receiver you couldn't run the CRC check algorithm until you received
> the entire packet. I agree that doing a dynamic CRC based on packet
> length doesn't sound like a good idea.

Actually, it can (as I suggest) also run both CRCs in parallel and
select the right one at the end.  Either way, it's a complication.

> This seems like a reasonable alternative. However, I'm not sure it's
> even necessary to use different CRC lengths for different CIDs.

Well, I was trying to preserve this since I didn't want to argue (yet)
about the necessity of it.  Yes, I would generally say that this is an
unnecessary complication.  If ATM were to be carried over PDH links
where bit flips rather than bursts are arguably more likely in some
deployment, I might see a reason for this complication.

(But, then, I can't say I'm an expert in ATM deployment or, for that
matter, error control theory.)

> Another alternative that was suggested by one of the other authors
> was to do CRC-16 only in the base protocol and allow CRC-32 as an
> optional negotiated format. The number of CRC bits used only limits
> your maximum payload size.

Not exactly.  It just changes the probability of undetected error and,
for a given error distribution, the probability versus packet size.
There's no actual payload limit.

> As an example, PPP over HDLC runs with a 16 bit FCS with an
> optionally negotiated 32 bit FCS. What do you think about this
> method?

RFC 1570 is a clumsy method at best, but it's hard to see how to do
better for a negotiated feature.

The problem is that since you have sublinks below PPP (rather than
individual parallel PPP links) over those CID channels, you can't
negotiate the parameters separately.

One thing you could do would be to negotiate PPP separately on each
CID and use LBD to tie them together.  That would give you the FCS
flexibility at the cost of a single extra LCP negotiation per CID.

If ATM signaling can carry additional information to indicate the FCS
type to be used on each CID, then you could use that instead and
retain the original sublink model.

Finally, in your second draft you could just establish conventions for
CID usage, such as lowest-numbered CID in use is CRC-32, and any
others are CRC-16.

---

From: Bruce A Thompson <[email-masked]>
Date: Sat, 23 Dec 2000 08:20:40 -0800

>There's no actual payload limit.

Right. The probability of an undetected error goes up as the packet size increases. The packet size limit is where the probability of an undetected error increases past some predefined acceptable limit. I thought this was obvious, so I didn't state it.

I'm also not an error control theory expert. It would be great if we could get someone who was an error control theory expert with knowledge of error distribution on typical ATM physical links to propose a CRC strategy.

>flexibility at the cost of a single extra LCP negotiation per CID.

I don't know what "LBD" stands for. Can you expand this TLA?

>retain the original sublink model.

This could be done. However, PPP over AAL2 will often run over statically configured PVCs. Many (most) AAL2 deployments do not use Q.2630 at all. This would also be an argument for using PPP to negotiate the number of CIDs. The PPP negotiation could be used when Q.2630 was not used to establish the CIDs and usage of the CIDs

>CID usage, such as lowest-numbered CID in use is CRC-32, and any

Seems like we need to have CRC expert decide the CRC strategy before we go too much further down any of these paths. It's still not clear to me when a CRC-32 might really be necessary vs. just CRC (or FCS) 16. I don't know the acceptable undetected error rate orthe error distributions for likely ATM physical layers. Because of this I don't know that max packet size where a CRC-16 can be used. If it's above 1500 bytes, then it seems like going to a static CRC size for the PPP session would be just fine.

         Bruce T

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

---

From: James Carlson <[email-masked]>
Date: Sat, 23 Dec 2000 13:37:21 -0500 (EST)

Bruce A Thompson writes:
> I'm also not an error control theory expert. It would be great if we
> could get someone who was an error control theory expert with
> knowledge of error distribution on typical ATM physical links to
> propose a CRC strategy.

Maybe one of the Lucent guys who lurks here will speak up ...

> I don't know what "LBD" stands for. Can you expand this TLA?

http://www.ietf.org/internet-drafts/draft-ietf-pppext-lbd-02.txt

The idea is that you use MP-style negotiation, but you don't actually
fragment or reassemble.  Thus, each member link needs to do LCP (and
authentication, if used), but the NCPs are held in common.

> Seems like we need to have CRC expert decide the CRC strategy before
> we go too much further down any of these paths. It's still not clear
> to me when a CRC-32 might really be necessary vs. just CRC (or FCS)
> 16.

Nor to me.  (For what it's worth, the "FCS" term comes from the ISO
3309 name for that field.  CRC-16 and CRC-32 are two possible check
values that can be used for the PPP FCS.  There's also a CRC-48, but
that's patented by DEC and not generally used.)

> I don't know the acceptable undetected error rate orthe error
> distributions for likely ATM physical layers. Because of this I
> don't know that max packet size where a CRC-16 can be used. If it's
> above 1500 bytes, then it seems like going to a static CRC size for
> the PPP session would be just fine.

That would certainly be the simplest and most commonly-used strategy.

-- 
James Carlson                                  <[email-masked]>
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp