Subject: [Pppext] draft-jurski-pppext-iphc-00.txt

From: Janusz Jurski <[email-masked]>
Date: Fri, 07 Jul 2006 17:45:59 +0200

Hi All,

I have submitted the following Internet draft: 
http://www.ietf.org/internet-drafts/draft-jurski-pppext-iphc-00.txt. The 
document adds an extension to IP Header Compression negotiation for PPP. 
The abstract of the document is as follows:

   This document extends RFC 3544 (which extended its predecessor,
   RFC 2509) by specifying additional negotiation options to PPP Control
   Protocols for IPv4 and IPv6 (see RFC 1332, RFC 2472).  The
   negotiation options specified in RFC 2509 defined an all-or-nothing
   strategy for applying header compression: peers were assumed to
   support compression for any combination of headers.  RFC 3544 refined
   that strategy to make it possible to negotiate header compression for
   only TCP or only non-TCP packets.  The current document further
   refines the strategy by also making it possible to negotiate header
   compression for only particular combinations of headers or header
   types.

I would like to discuss the proposal / request your comments. Note that 
the most of the document is copied from RFC 3544 (and RFC 2509). A new 
suboption is defined in Section 2.5. Section 5.2 explains the reasons 
for this new suboption and discusses the advantages and disadvantages.

Kind regards,

Janusz

_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: James Carlson <[email-masked]>
Date: Thu, 20 Jul 2006 16:51:04 -0400

> for this new suboption and discusses the advantages and disadvantages.

I don't quite see why this must obsolete RFC 3544.  It looks to me
like a compatible extension to that RFC.

There are overlaps in the functionality -- in the 'A', 'B', and 'C'
bits.  This adds complexity, but for no apparent reason.  Why do this?
Doesn't the existing suboption work well enough?  Why must everyone
end up with two different ways of invoking those features?

The lack of dynamic adaptation seems like a flaw to me.  Just because
a node expects one mix of traffic at one point in time is no good
reason to suppose that the traffic mix will not be different later.
The original negotiation options were posed in terms of system limits
rather than traffic behavior for that reason.

In particular, this section:

   Note that, while the compressor could use heuristics to determine the
   most efficient way to compress flows, the decompressor may be in a
   much better position to know the expected traffic type.  For example,

makes no sense to me.  The compressor and decompressor have almost
*exactly* the same set of information.  It's the set of packets
passing over the link.  One thing the compressor has that the
decompressor doesn't is the instantaneous queue depth.  I can see
nothing that the decompressor has that the compressor does not.

A compressor that notices that it's wasting compression state on
short-lived exchanges could alter its behavior over time so that it
doesn't do that.  Having the decompressor "guess" that its exchanges
in the future will be short and then disabling compression in advance
seems fragile.

Perhaps it'd be better to write a paper about the best way for a
compressor to use a limited number of contexts when the traffic mix is
unknown in advance.

But those are possibly nits.  The big problem here is in the
motivation.  Why is it exactly that the existing MAX_HEADER and
*_SPACE variables aren't sufficient to limit resource consumption?
Besides bytes of storage required (already controlled by the existing
parameters), what do extension headers have to do with complexity on
the decompressor side?  How does failing to compress some UDP headers
when RTP is running help?

If you're really constrained but still need compression, why wouldn't
you set the number of contexts to 1, and the maximum header size as
small as practical (say, 64 octets)?

It looks to me like the motivation in section 5.2 switches back and
forth between memory and CPU power.  Clearly, the existing options
already give you a chance (and a seemingly adequate one) to control
memory consumption.  Moreover, the proposed new feature does _NOT_ add
anything that will help to further reduce memory consumption by adding
any new limits to the required storage.

So, the real rationale must be CPU power, not "gigabytes" of space.

When the memory arguments are dispensed with, though, there seems to
be little to support the idea; it becomes just another tiny-CPU-too-
much-code argument.  I don't think that permanently burdening everyone
else (until the end of time) to support a temporary design problem is
a good use of the standards process.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677