Subject: Re: PPPmux and MP

From: Vernon Schryver <[email-masked]>
Date: Wed, 5 Jul 2000 17:55:24 -0600 (MDT)

> From: Dan Wing <[email-masked]>

> ...
> Quite true for reasonably-sized IP payload sizes.
>
> But header compression remains useful when the payloads are 10 or 20 bytes
> such as with voice samples.

That assumes facts not in evidence.

If (1) the link (or total path for some compression schemes) is carrying
only 10-20 byte TCP/IP or UDP/IP payloads, (2) if nothing can be done to
make those payloads larger and less frequent, and (3) if the link (or
total path) is running at a significant fraction of its available capacity,
then header compression sounds useful.  However, failing to demonstrate
all of those facts simultaneously in at least one plausible scenario
invalidates claims about the utility of PPPMux and the new compression
schemes.

As it stands, PPPMux and the compression schemes somewhat less so are
merely standarizing the optimum performance of flying pigs.  If you
assume pigs will be flying, they're good ideas.  Good engineering ought
to demand a little evidence that pigs can get airborne before writing
standards--assuming that the purpose of the RFC's is to standardize
technical stuff instead of only satisfying a publish-or-perish need.

Vernon Schryver    [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Wed, 5 Jul 2000 19:46:37 -0700 (PDT)

On Wed, 5 Jul 2000 17:55 -0600, Vernon Schryver wrote:

> only 10-20 byte TCP/IP or UDP/IP payloads,

A voice-only network would be designed for such short payloads.

Some common compression algorithms provide 10 (G.729), 15 (G.729e), and 40
(G.726-32K) byte payloads every 10ms.  There are tradeoffs with each
compression type (generally the typical CPU-versus-quality).

> (2) if nothing can be done to make those payloads larger and less
> frequent, 

A larger payload can be had with (a) less efficient compression algorithms
or (b) higher (longer) packetization interval.  

Of those, (a) isn't desirable because one of the benefits of voice over
packet networks is its ability to save bandwidth.  If packet voice
continues to consume 64Kb of bandwidth there isn't a large win over
traditional PSTN (which uses 64Kb).

Solution (b) causes a degradation in voice quality.  Additionally, losing
a larger sound sample (due to a packet drop, for example) is more
noticable than losing a smaller sound sample.

> and (3) if the link (or total path) is running at a significant
> fraction of its available capacity, then header compression sounds
> useful. 

To save costs, customers prefer running links as close to capacity as
possible.

And some access technologies such as xDSL or cable become bandwidth
constrained with multiple derived voice lines, so those links are running
at capacity.  CRTP can help here, but CRTP doesn't solve network core
bandwidth utilization which, for a voice-only network, is quite a lot of
overhead for tiny payloads.

> However, failing to demonstrate all of those facts simultaneously in
> at least one plausible scenario invalidates claims about the utility
> of PPPMux and the new compression schemes.
> 

As far as I'm aware, there is no publish-or-perish requirement at my
employer.  As to flying pigs, they should fly high and land softly.

-Dan Wing