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

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

[e-mail] wrote:
> 
> Hi,
> 
> Just try to make things simple:
> 
> 1) The major (if not only one) requirement of SigComp
> is to reduce latency. I agree with Carsten.

I agree. But you need to be very carefull to not cause
an extra overhead when you implement the mechanisms to
dismiss that latency. 

I am referring to the algorithm upload. If every time 
I switch a mobile phone it has to send 500 bytes of 
algorithm to its proxy, and the proxy has to do the same
in the reverse side, even in the case that both the proxy
and the terminal already contain the algorithm, then we
are doing something wrong. We are generating a lot of 
unneeded traffic over the scarce air interface.

> 
> 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

I like this text, and I think it should be covered somewhere
in the next version of the Sigcomp draft.

There is a minor thing for discussion though. In step 3 you
are assuming that the compressor selects the algorithm prior
to contacint the decompressor. However, I can envision another
model where the compressor selects the algorithm to upload
once it gets the list of algorithms from the decompressor.

An example: Terminal T contacts proxy P. P sends the list of
algorithms already uploaded, let's say, 1, 2 and 7. T supports
algorithms 2 and 8. 8 is preferred for the terminal, but 
because the compression performance in 2 and 8 are similar,
and because 2 is already uploaded in P, T decides to use 2.

 
> 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 (?).

That is Ok. Obviously, anything that requires a roundtrip is 
not for free. Still, if the algorithm cost is 500 bytes, there
is a saving in bandwidth if the number of algorithms already
uploaded are not extremely high.

> 
> 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?

I have no opinion on this subjec.

/Miguel


> 
> BR,
> Zhigang

-- 
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