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

[[e-mail]]

Richard,

Re your comments on where to put the text, I don't think
adding it to the SigComp draft will slow things down. 
Technically, it is simple (adding two fields to the 
capability announcement block). What we need to agree
is if it is useful.

Re the "1-byte state identifiers", I would rather prefer
using hash as in my original proposal. Carsten already
commented on this. Below are detailed reasons from me:

- Statically assigned ID needs to be standardized somewhere
(either 3GPP or IETF). Hash does not.

- Hash is more generic and "algorithm blind". It does not 
matter how the decompression code is obtained by the decompressor,
whether it is documented somewhere (case 1) or it is 
previously uploaded from a compressor (case 2).

- Hash is virtually a CRC on the decompression code so that
both ends can be confident they hold the same piece of code.
Any corruption in the hash value (e.g. due to transmission
errors) or code itself can be detected.

BR,
Zhigang

> -----Original Message-----
> From: ext Price, Richard [mailto:[e-mail]]
> Sent: February 27, 2002 11:55 AM
> To: Liu Zhigang.C (NRC/Dallas); [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: SigComp Requirements (was Re: [rohc] RE: Default
> decompression algorithms)
> 
> 
> 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.

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