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

[James Carlson <james.d.carlson at sun.com>]

Janusz Jurski writes:
> 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.

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                    <james.d.carlson at sun.com>
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

_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www1.ietf.org/mailman/listinfo/pppext