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

["Miguel A. Garcia" <[e-mail]>]

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:
> 
> 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.
> 
>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[e-mail]     Phone:  [phone]
mailto:[e-mail]        Mobile: [phone]

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