Subject: RE: PPP-Mux and ML-PPP

From: Ali Irfan-FIA225 <[email-masked]>
Date: Wed, 19 Jul 2000 14:10:35 -0500

> > I would suggest (possibly) a two level negotiation.
> > LCP for the link and then NCP for the bundle.
> 
> Only if it's useful at all at the bundle level.  I think the answer to
> that might be 'no.'  At least I've heard no compelling argument for
> just prohibiting PPPMux outright at the bundle level.
> 

I have a different opinion here. The very reasons for using PPPmux on a
single link apply to that for using it on a bundle: bandwidth efficiency.
Infact if MP is used, and a MP header is applied for each packet
(irrespective of whether the packet is fragmented or not) sent on a link,
then the motivation to use PPPmux on the bundle level is even greater.  The
MP tax is now on a PPPmux frame than on individual frames. 

From previous discussions in the mailing-list, there does not appear to be a
compelling reason for having PPPmux on each link of a bundle (i.e. on a link
the PPPmux header should never be outside a MP header). I would recommend
prohibiting it on the link.

Moving PPPmux from an LCP to NCP option, results in the desired behavior,
i.e. PPPmux used on a bundle and not on an individual link. Also the other
arguments of doing PPPmux negotiations after authentication, in previous
emails on this topic, are satisfied by having PPPmux as an NCP option. 

I am not sure of the next steps now. Do the authors of the draft now go to
the chair of PPPext and ask for an NCP option number? Do we somehow giveup
the LCP option number assigned to PPPmux? Suggestions would be most
welcomed.

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

I do not completely understand why this restriction is good. From a protocol
perspective PPPmux could be inside a decrypted packet. On links with small
packets, this MAY reduce the encryption/decryption and
compression/decompression CPU processing and interrupts (I am not too sure
of this). PPPmux in itself does not put any requirements of where it should
exist with respect to either encryption or compression. I am not against
requiring that PPPmux be the outermost protocol number wrt encryption and
compression. I do not understand why.

Irfan

---

From: James Carlson <[email-masked]>
Date: Wed, 19 Jul 2000 15:41:47 -0400 (EDT)

> single link apply to that for using it on a bundle: bandwidth efficiency.

If bandwidth efficiency matters so much that an extra couple of bytes
per packet matter, then why use MP at all?  MP adds overhead.  If you
run PPPmux over MP, then you might remove some potential overhead, but
you add fragmentation overhead, increased latency, and the obvious
cost of complexity.  How is that helpful?

(The latency increases because MP fragments on arbitrary boundaries
and you've now got to wait until you reassemble everything in a frame
in order to begin plucking out anything safely.  I was under the
impression that telco folks asking for this feature didn't much
appreciate added latency.)

> MP tax is now on a PPPmux frame than on individual frames. 

That's not so clear.  You end up with PPPmux frames that are larger
and need to be fragmented, and overhead added to each.  This may end
up being a wash.

If the motivation is that you don't care about latency but you do want
to handle excruciatingly tiny packets with slightly greater
efficiency, then I now see why you want PPPmux over MP.  But I don't
see why those two assumptions should hold.

> prohibiting it on the link.

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?

> emails on this topic, are satisfied by having PPPmux as an NCP option. 

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.

> the LCP option number assigned to PPPmux? Suggestions would be most

You'd go to IANA.  Of course, you have a ready-made NCP number --
8059.

> compression. I do not understand why.

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?

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.

On the other hand, I'd argue that if we can't figure out where it
belongs in the puzzle, then, like Compound-Frames, it doesn't belong
at all.  This isn't a telecommunications body.  ;-}

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