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

From: "Price, Richard" <[email-masked]>
Date: Wed, 27 Feb 2002 17:55:23 -0000

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.

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Wed, 27 Feb 2002 20:26:31 +0100

> if they believe the effort to be worthwhile.

Richard,

this is not state referencing in the sense it is being used in the UDVM
draft.
(It's not a hash, either.)
I'm not quite sure I understand your mechanism, but it seems to be the
worst-of-worlds between the existing state identifier mechanism and a
registration-based mechanism, in the sense that it inherits all problems of
both and then some more.

I'm strongly opposed to adding new mechanisms of this kind at this stage.
(I also have a lot of problems with the approach, which I already have
detailed on this list, but this does not matter at this point.)

Gruesse, Carsten

PS.: As with all messages on Sigcomp this week, the above was written with
my WG member hat on; as I'm getting involved in the details, I'll have to
leave the WG hat to Lars-Erik on this.

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 28 Feb 2002 09:45:43 +0200

Richard:

Just one comment.

I understand the effort you are doing on the 1-byte state identifiers to 
identify algorithms. I trend to like it. But I am not sure if this list
should be standardize in 3GPP or in IETF. I was thinking that it should 
be in IETF. I would like to understand why IETF can't typify certain
well-known algorithms.

/Miguel

"Price, Richard" wrote:
>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002