Re: [rohc] RE: Default decompression algorithms

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

Hi Caster:

See my comments inline.

"Dr. Carsten Bormann" wrote:
> 
> 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.

I believe we are speaking about the Capabilities Announcement message in
SigComp. This message, as you said, will carry the range of parameters
that will constrain the algorithm selection at the compressor. What I was
suggesting is that the decompressor already includes a list of algorithms
that, in case one of the them is chosen by the compressor, does not need
to be uploaded to the decompressor.

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

Agree.

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

Yes, but that does not impact standardization. Whether the decompressor 
contains already the code for 1 or for 1,000 algorithms is not affecting
the performance nor the standard. In a similar example, when my SIP 
terminal publishes support for certain codecs, I may support a big
number of codecs, whereas another terminal not. So what?
 

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

Certainly static payload types are not assigned nor recommended to use.
However, dynamic payload types are. The point here in the comparison
with SDP was that, there should be a mechanism whereby the decompressor
informs the compressor about already uploaded algorithms. Whether the 
actual mechanism includes static or dynamic payload types, I don't care.
The important thing is to fulfill the requirement to avoid unnecessary
air interface traffic. 

One way to fulfill the requirement is to define a similar mechanism
as in RTP, even with dynamic payload types if you want. 

But in order to progress this, first we need to understand whether the
requirement is reasonable or not. If it is, we can start the discussion
on how to solve the problem.


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

Aren't we doing it now??? Don't we have a UDVM upload whereby an endpoint
uploads the algorithm X to another endpoint?

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

Like I said before. Do we agree on the requirement? If Yes, we can discuss
technical proposals. If Not, we should stop the discussion.

If the requirement is agreed, my suggestion may not be the best one. I don't
have any problem with that. If you think it is not agreeable, let's look 
for other solutions.

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

Agree.

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

So you don't honor the requirement? Then, I doubt SigComp can ever be
used in real life.
 
> 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.

Well, it is not a level 9 decision. There are several organizations waiting
for the SigComp to be finalized and ready to use it (3GPP being one of them).
We need to understand the requirements and honor them, otherwise we may 
take the risk to deliver something that the customer does not want. That is
not a level 9 decision.

/Miguel

> 
> Gruesse, Carsten

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