Subject: RE: PPP-Mux and ML-PPP

From: James Carlson <[email-masked]>
Date: Thu, 13 Jul 2000 14:52:47 -0400 (EDT)

Stacy Nichols (Ottawa) writes:
> 	1) PPP-Mux and ML-PPP should be orthogonal. That is 
> 	   We should be able to perform PPP-Mux on a single 
> 	   link of a Multi-link bundle. This is consistent with 
> 	   RFC-1990 which permits single-link and multi-link traffic 
> 	   on the same link.

OK, then what do you do if you want PPPMux at the bundle level?  I'd
be happy with the current proposal (negotiate PPPMux at LCP) if we do
NOT allow PPPMux to appear within a reassembled multilink frame.

Otherwise, I'd rather see a new NCP.  (I think a new NCP is cleaner in
any case, but the LCP option is already there ...)

I'd also be happy if we just said that MP and PPPMux may not be used
at the same time on the same link.  Period.  You pick one or the
other.

> 	2) LCP negotiation should be used for PPP-Mux (out on a limb here).
> 	   I think it gets trickier when we merge the two capabilities.
> 	   Do we need to negotiate link capabilities (PPP-Mux, ML-PPP) 
> 	   and then negotiate combinations in follow on LCP/NCP messages.

Only if we don't resolve the existing ambiguity in an explicit way.

(There should also be definitions for where PPPMux appears with
respect to CCP and ECP.  ECP is probably a bit more troublesome.)

Again, to keep the current model, PPPMux should appear as the
outermost protocol number only.  Not inside a decrypted packet, not
inside a decompressed packet, and not inside a reassembled MP packet.

> P.S. how do I subscribe to the mailing lists.

Send mail to:

	[email-masked]

See http://www.ietf.org/html.charters/pppext-charter.html for more
information.

-- 
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
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: Ali Irfan-FIA225 <[email-masked]>
Date: Wed, 19 Jul 2000 23:00:01 -0500

> One could imagine a configuration in which a mix of tiny packets and
> very large packets flows over a PPP session.  Everything goes through
> MP.  The tiny packets result in tiny fragments that get grouped
> together on each link and sent using PPPmux.  The larger fragments
> don't.  That seems to work.  It continues to work if the tiny frames
> are reordering insensitive and bypass MP.
> 
> Of course, this is part of the problem.  The folks who need this
> feature haven't really spoken up here.  What's the application?
> 

The key application we had in mind when formulating PPPmux was to transport
20 msec radio samples in a cellular system (cdma in particular) from
base-stations to the infrastructure over T1 links. The radio samples are in
the range of 10-30 bytes, which are encapsulated in IP/UDP. The IP/UDP
header is compressed, so we still have a large number of very small packets
to be transported over expensive (especially outside US) T1 links. (I do not
want to argue with folks who say that bandwidth is on the increase; I agree.
However, today and for the near future we have to contend with the issue of
T1/E1/J1s.) 

A similar application is VoIP traffic over low speed WAN links.
 > 
> MP is just the tip of the iceberg.  PPPmux needs to be defined in
> relation to CCP and ECP as well, just as MP/CCP/ECP are defined to
> preserve compress-then-encrypt semantics and to identify clearly
> during negotiation what architecture is assumed.

Definitely. The relation of PPPmux to encryption/compression needs to be
added to the draft. If for simplicity, PPPmux should be outside of
encryption and compression, this should get added to the draft.

> 
> Allowing arbitrary (and mutual) encapsulation makes a mess out of the
> implementations and likely results in a lack of interoperability,
> which, I think, is what sparked the question in the first place.  Can
> we have IP in PPPMux in MP in PPPMux in CCP in PPPMux in ECP in
> PPPMux?  If you agree to do PPPMux, what exactly are you agreeing to
> do?

Agreed. We will add further details to the draft.
> 
> If you allow LCP negotiation of PPPMux, but the actual multiplexing
> occurs above MP, then you need to amend RFC 1990 to indicate that if
> PPPMux is negotiated on one link, then it's negotiated on all links.
> I think that's really ugly, but otherwise, you likely run into trouble
> with multi-chassis systems.  If you do PPPMux with an NCP above MP,
> that's doesn't need an update, but it probably does need the careful
> consideration given CCP and ECP.

I agree that it is preferable to go with NCP rather than LCP and the draft
will be updated to reflect this.

Thanks

Irfan