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

[Janusz Jurski <jjurski at eti.pg.gda.pl>]

Hi James,
I am sorry for a long delay in replay. This is due to vacation time.
Please see my response in the text below.
Kind Regards,
Janusz


James Carlson wrote:
> 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.
>   
Yes, it is meant to be compatible. I just followed the convention of 
RFC3544, which was also compatible with RFC2509 and also obsoleted it. 
In my opinion, there are two equally good options:
- either the new document shall include all the information from the 
previous one and in such a case it makes sense to obsolete the previous 
one because the readers of the newer document do not need to check the 
older one
- or the new document shall describe just the new options (and shall not 
copy the previous document content)
I am not sure if this is the official rule. Please let me know if I am 
wrong.
> 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 main reason for the overlap is a higher precision/resolution of the 
flags. Flags A and B can be used separately to disable TCP differential 
encoding method or non-differential encoding method.

Because of the overlap, I stated that these two suboptions were mutually 
exclusive - to avoid inconsistency. Thinking about your comment now, I 
got into conclusion that it would be better to permit both these 
suboptions to be included in an NCP message and treated as a logical-or 
(the sum of all the limitations in all these flags shall be in effect). 
In such case, flag C could be removed (as it would be equivalent to 
suboption type 3 parameter = 2) and implementing suboption 4 shall also 
be required to implement suboption 3. There would still be an overlap, 
however, and the same limitation (no TCP compression) could be expressed 
in two different ways. This could cause a bit longer negotiation 
exchange than the optimal one. In order to avoid this, implementations 
shall use suboption 3 when disabling TCP compression, instead of or in 
addition to setting both flags A and B. I think that this would be OK.
> 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 lack of compression of a particular type may be because of a constant/permanent expectation of the system administrator or manufacturer. If there is no such *constant/permanent* expectation, the limited compression shall not be used. But I am sure that there are systems where 99% of traffic is easily predictable.

It is also tightly coupled with the limitations of the decompressing system, e.g. the decompressor can decompress either 1000 TCP flows with non-differential compression or just 500 TCP flows with the differential compression. If the expectation is that there will be 1000 flows, it may be more beneficial to ask the compressor to use only the non-differential compression.

> The original negotiation options were posed in terms of system limits
> rather than traffic behavior for that reason.
And the proposed extensions also impose system limits. However, since 
the mix of traffic is sometimes easily predictable, system limits can be 
tuned to get the maximum performance/minimum cost for the expected 
traffic mix. If there were no limitations of the system or the users did 
not care, full compression could be used.

New extensions to cover dynamic adaptation can still be introduced 
(AFAIK they are in ROHC in RFC3095) and these two kinds of protocol 
extensions are non-conflicting.
> 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.  
The set of packets passing over the link is known *after* the system 
limits are set up by the negotiation mechanism. Even if compressor or 
decompressor learn it, they will not be able to change the negotiated 
limits. In the proposed document, I want to introduce an administrative 
way of setting the limits already at the negotiation phase.
> 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.  
Yes - this is what I assumed in the cited paragraph: the compressor may 
be sometimes (perhaps usually is) in a better position than the 
decompressor. But I also noticed that the opposite may also happen: for 
example, the administrator or manufacturer of the decompressing system 
may know what the expected traffic is, while the compressor at the other 
end of the link may be a general purpose system with no expectation. The 
limitations of the decompressing system are also known to the 
decompressor only.
> 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. 
Such heuristics could lead to a better compression efficiency but it may 
also require higher resources at both the compressor and decompressor. 
There is no problem with compressor resources but the decompressor must 
always be ready to decompress everything according to the limits set 
during the negotiation.
> Having the decompressor "guess" that its exchanges
> in the future will be short and then disabling compression in advance
> seems fragile.  
It is fragile when the expected traffic is unknown and when the node 
tries to "guess" it without additional information. I agree that, if an 
administrator/manufacturer is unable to predict the expected traffic, 
the use of this mechanism is not recommended, as noted in the proposed 
document.

But in a specific situation, it may not be fragile, e.g.: if the 
manufacturer knows the expected traffic precisely, it is not a "guess" 
but a fact.
> 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.
>   
I do not agree. Limiting the number of contexts by the compressor may 
help to save its resources but it helps nothing to the decompressor 
because the decompressor is obliged by limits set during the negotiation 
phase.
> 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)?
>   
I do not agree that the bytes of storage are completely controlled by 
the existing MAX_HEADER and *_SPACE variables. The size of the context 
which must be maintained by a decompressor (and also by a compressor but 
it can control the problem itself) is also (in addition to MAX_HEADER) 
dependent on whether the compression is differential or non-differential 
and on what header combinations are considered. The size of the context 
for the non-differential method is just a set of octets. But in the 
non-differential method, there is a potentially large number of "delta 
fields" and the number of bytes for these fields is also large (these 
are fields of variable size, such as options or padding). Obviously, at 
least twice more information must be stored for the "delta fields" than 
for "non-delta fields" (the delta and the last value must be stored at 
least). Therefore, it also matters what types of headers are compressed 
(e.g. extension headers do not contain "delta fields"). Thus, in the 
worst case when MAX_HEADER is large, the amount of memory to store the 
same number of contexts for one compression method or combination of 
headers may be even almost twice higher than for some other 
method/combination. Hence, a node with a given amount of memory can 
serve either, for example, 1000 non-differential contexts or 500 
differential ones.

If the expected compression method and combination of headers is known, 
the size of the context may be controlled more precisely with the 
proposed changes and we can save some memory (maybe even up to half) 
which is currently wasted.

Regarding the proposed changes, I even wonder if the "resolution" of 
limitations shouldn't be more precise:
- maybe it would be worth to add the following limitation: UDP headers 
with non-zero checksum shouldn't be compressed (I previously didn't 
notice that the size of the context for UDP with and without checksum 
differ by 2 bytes - this is, for example, ca. 13% difference in memory 
usage for IPv4/UDP header combination)
- maybe it would be worth to separate flags into separate sets for TCP 
and non-TCP compression methods: the spaces are separate and it may be 
worth to use limited compression only for one of these spaces; maybe 
even separate flag sets could be defined for: (1) differential TCP (2) 
non-differential TCP (3) UDP (header chain ended with UDP) (4) RTP 
(header chain ended with RTP) (5) other
- maybe it would be worth to add a separate suboption for 
EXPECT_REORDERING flag - if a node knows that the underlaying 
lower-level mechanisms do or do not reorder packets, the node would 
explicitly request that its peer uses or does not use more complex 
algorithms of decompression (section 11 in RFC2507); this may be 
important due to higher complexity of these algorithms
These would add some complexity but it is perhaps still worth for some 
applications. I will analyze these additional extensions and propose 
something more precisely if we agree to the principal idea whether the 
extension are OK at all.
> 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.  
I think that the new options will help to reduce memory consumption, as 
explained above. Of course, if  "thousands" of compression sessions are 
considered, this saving may be equivalent to "gigabytes" of memory. :)
In my opinion, CPU power is also an important factor: the decompressor 
may be able to handle 1000 non-differential flows or 500 differential 
ones due to CPU power limitations and higher complexity of the 
differential algorithms, for example.
> 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.  
I do not agree - CPU limitations are not a temporary design problem and 
this change in the protocol can help in using CPU resources in a more 
efficient manner for many designs and till the end of time. It is 
because here again I can see a trade-off between compression efficiency 
and CPU resources, similarly as with memory capacity. As I gave an 
example above, having a CPU of a specific processing power, one can 
either compress/decompress a bigger number of flows with a simpler 
method/combination of headers or a smaller number of flows with a more 
complex method/combination. Of course, the per-flow compression 
efficiency is limited by using the simpler method but sometimes it is 
still beneficial because one can get a higher overall compression 
efficiency.

Also a good effect of the proposed changes is related to the 
hardware/software complexity: it may be sometimes beneficial to limit 
the number of supported compression methods/header combinations and 
implement only the ones which are used for 99% of traffic, especially in 
a hardware acceleration module. This may be beneficial because of a much 
cheaper or less power consuming equipment, for example. This argument 
alone would not be a good enough reason to change a protocol definition 
but I think that is a good accompanying argument.

Summarizing, I think that the proposed changes make the protocol more 
flexible and suitable in more various usage scenarios because they 
permit controlling the trade-off between:
- per-flow compression efficiency
- memory capacity used
- CPU power
- hardware/software complexity
More flexibility may be also beneficial for reasons which cannot be 
directly seen. For example, with the higher flexibility of the protocol, 
one can support all system users with equal capabilities (e.g. instead 
of supporting full compression for 500 users, one can provide a limited 
compression to1000 users). So, flexibility is an important factor of the 
protocol. Since the changes are compatible with the current systems, 
i.e. they do not require existing implementations to implement the 
extensions, I believe that the additional flexibility is a valuable benefit.

Please comment if you do not agree with my statements/opinions/thoughts 
or have some ideas.
Thank you again for your time!



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