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

From: [email-masked]
Date: Wed, 27 Feb 2002 10:23:54 -0600

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. 

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

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

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?

BR,
Zhigang

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

---

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

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

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

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

> does not create new risk. But do I missed something?

I have no opinion on this subjec.

/Miguel

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