RE: SigComp Requirements (was Re: [rohc] RE: Default decompressio n algorithms)

["Price, Richard" <[e-mail]>]

Hi,

Just a few comments on your summary of the "algorithm announcement" debate.

Regards,

Richard


> Just try to make things simple:
> 
> 1) The major (if not only one) requirement of SigComp 
> is to reduce latency. I agree with Carsten.
>
> 2) Here we are talking about a simple optimization to
> reduce the latency. Does anyone has comment on it?
> http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00065.html

My only comment is that since the mechanisms needed for "algorithm announcement"
are already built into SigComp, I can't see any reason *not* to make this
functionality available to implementers.

Should the above text be placed in the SigComp draft itself, or should a
separate "Implementer's Guide" draft be considered? The latter approach might be
very useful for getting SigComp standardised more quickly. The draft already
contains a lot of text that explains how the technical mechanisms might be used;
this is valuable for implementers but doesn't need to be standardised per se.

I think that it would be OK to have an implementer's guide in Internet Draft
form for now, and then publish it later when there's less time pressure (perhaps
as an Informational RFC, or perhaps by folding it into the SigComp RFC when it
reaches Draft Standard).

> 3) Now, the question is cost/gain evaluation. I've made some attempt in
> http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00064.html.
> Comment? The hash size might be increased to 9 bytes (?).

The minimum hash size of 9 bytes only applies to algorithms (and other kinds of
state information) that are downloaded to the UDVM and stored on the fly. In
the case of well-known algorithms that have been documented somewhere the
state identifier for the algorithm can be any length and any value - after all
there's no point keeping an algorithm secret if it's in an Internet Draft!

For example, the following list of 1-byte state identifiers might be reserved:

ID    Corresponding algorithm

0          UNCOMPRESSED
1          DEFLATE
2          LZO
3          LZJH
4          EPIC
:            :

The IETF doesn't need to define the above list - the task can be left to 3GPP,
if they believe the effort to be worthwhile.

> 4) Also, what about security? I don't see it is a problem
> as long as the use of feedback (capability announcement)
> does not create new risk. But do I missed something?

Since the needed mechanisms are already provided by SigComp, the use of
"algorithm announcement" doesn't create any new security risks that we
don't already have.