RE: [rohc] RE: Default decompression algorithms

Miguel,

thanks for the detailed explanation.

> You asked how many algorithms are going to be in the cache of a
> typical decompressor, and that question is related to how many users
> a proxy can support simultaneously, and how many different algorithms.
> In other words, it is implementation dependent, and the answer to the
> question does not have an impact on the standardization in Rohc.

Well, the technical parameters in the expected operating range typically do
have an influence on standardization, in particular for a standard the only
purpose of which is optimization.

BTW, I don't believe there is an appreciable technical limit to the number
of algorithms a decompressor can support, apart from the overall limit in
state capacity.
So the more interesting question is, how many algorithms are likely to be in
actual use at any point in time.
Counting all generations of equipment out there, of course, multiplied by
the number of manufacturers.
It may look nice three weeks from now...

> The cost of supplying the information: I don't have a strong opinion
> on how this can be done, but I will refer to examples that are working
> today in other protocols. For instance, RTP decided to use a profile
> for Audio/Video codecs (RFC 1890). Known codecs are assigned a Payload
> Type in RTP. So Payload Type 0 means PCM u-law codec, Payload 8 means
> PCM A-law codec.

It seemed like a good idea at the time, in 1996.
AVT has long since stopped to assign fixed payload types -- there are just
way too many of them for a small field.
(And it's way more expensive to invent a new payload type than a new
decompressor, I might surmise.)

> In SigComp, we could take the same approach, in a way that we define
> a standard way to refer to known algorithms. The decompressor, in
> the SigComp Capabilities Announcements would indicate the list of
> algorithms that are already uploaded (in a similar way of how SDP,
> RFC 2327 negotiates codecs).

Would you trust UE A to upload algorithm X for UE B?

I don't think the dynamic version of this can be made to work without secure
state identifiers.
These need to be at least 6 bytes (probably more; 12 is secure, we are still
investigating whether less can work).
Let's say 8 bytes, times maybe 20 algorithms out there.  Not a big win.
Oh, and you *still* need to upload any user dictionaries.

What you could do for a static solution is to actually tightly manage a
small number space (e.g., 16-bit numbers), by registering algorithms.
Now the problem is that you have to wait for the register updates to
percolate to both UE and fixed network equipment before you can take
advantage of them.

The reason I insist on discussing this seemingly small issue is that I
believe we can eliminate a lot of mechanism by just not doing it.

Or to put it another way, I have the impression we have a psychological
problem ("we can't exchange those bytes all the time, so let's do something
about it") instead of a technical one.  Of course, given that the UDVM
approach is new, this is understandable.  However, we are talking about
probably fewer bytes than the typical HTTP headers for a single web page hit
here.  Once, for registration.

Of course, my analysis may be completely broken.
If I'm right, the only remaining issue for me is whether not having an
ostensible solution for this alleged problem is going to hinder acceptance
of the UDVM.
This is a level 9 decision, not a technical one.

Gruesse, Carsten

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc