Subject: Re: PPPmux and MP

From: Vernon Schryver <[email-masked]>
Date: Sun, 2 Jul 2000 11:44:26 -0600 (MDT)

> From: Tmima Koren <[email-masked]>

> ...
> >I'd be interested in hearing the opinions and/or experiences from anyone
> >whose implementation does/would support either compound frames or pppmux.
> >Is it "worth it"? Why?
>
> Multiplexing is useful when the PPP packets are tunneled: 
>the overhead of the tunneling header is amortized over the multiplexed packets 
> see: http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-00.txt

Competent engineering is not about optimizing one single parameter while
ignoring all others.  Both of the proposals strain to remove a few bits
of PPP overhead, but ignore their costs.  Those costs include CPU cycles,
implementation complexity including inevitable interoperability problems
and bugs, complications for diagnostic tools such as PPP frame monitors
and decoders, and the bandwidth spent negotiating the options (successfully
or not).  The old PPP multi-frame proposal was never significantly
implemented, if at all.  This new proposal will have the same fate.  Both
are like WAP and try to optimize bandwidth as if today were 1980, while
ignoring other costs and not looking for a plausible 21st Century use.

In other words, as I often say, albeit a little more colorfully, "Anyone
can always find something to add to anything.  The trick that requires a
very thick skin, hard work, a little experience, some skill, and perhaps
talent is leaving out everything but required features."

However, this multi-frame PPP proposal is innocuous, because it will not
be implemented, unlike some useless protocols like BAP/BACP it doesn't
have a lot of marketing muscle flogging it, and it doesn't require crazy,
incompatible, non-interoperable changes like the AO stuff.  It will get
an RFC number and be forgotten.

Yes, I read http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-00.txt
No, I'm not convinced.  L2TP tunnels across the wide Internet?--Even
if such things were good ideas and if this were 1990 when bandwidth
was harder to get than low end-to-end latency over the public Internet,
Microsoft, Cisco, a zillion other proprietary VPN vendors, and even ssh
own that market.

Another part of competent engineering is assessing and dealing with
non-technical issues, from esthetics and economics in bridge building
to the discouraging effects of existing good-enough network protocols
on better ideas.  For example and as James Carlson said, the world
needs PPP authentication fixed (moved entirely into LCP) far more than
PPP multi-frames, but there's no hope of fixing authentication.  Having
authentication separate continues to cause problems (e.g. forcing LCP
renegotiations that waste time and don't work with junk PPP
implementations), while PPP multi-frames would be at best a marginal
optimization.

Vernon Schryver    [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 2 Jul 2000 20:12:56 +0200 (MET DST)

Vernon Schryver writes:
> Both of the proposals strain to remove a few bits
> or not).  

True.  Like header compression.

> Both

Nope.  WAP changes entire end systems, warps security architectures,
requires new boxes in the middle of the network.  Header compression,
PPPMUX and things like that change consenting routers and, if
successful, cause localized changes in host stacks.
Totally different space.

Gruesse, Carsten

PS.: It would help if certain PPP veterans would occasionally read up
on the technical parameters of VoIP, all-IP fixed networks for
wireless, etc.  I'm not sure I like PPPMUX too much (even with my
little change :-), but I can already guess who will be implementing
it.