RE: [rohc] RE: Default decompression algorithms

Miguel,

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

Well, it does, if the idea is that a decompressor announces the algorithms
it has.
Sending 1000 algorithm identifiers is more expensive than sending the
algorithm for most representations of these that I can think of.

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

OK, I see.  SDP uses MIME-style identifiers to indicate the codecs that the
application actually wishes to use.

In SDP, this makes sense, as both parties must have implementations of the
codec, or they can't interoperate.
So expending significant effort (often several hundreds of bytes) to find
that lowest common denominator is the right thing to do.

In Sigcomp, the effort to just mandate one algorithm (by simply sending its
decompressor) is in the same ballpark as interchanging the capability
information.
Why bother?  I'd like some numbers, please.

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

Yes, but in the form of state that will only influence the decompression of
its own packets.

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

The requirement is to reduce the signaling latency.
I believe we are discussing certain details of the solution right now, which
will influence its performance in one way or the other.
I'm trying to argue that the performance win of a specific approach that
increases complexity is negative or at least not very positive.

(Of course, the approach still remains possible if there is something as
simple as state claims in the protocol, so implementers can go ahead and
make use of these.  I'd still advise them not to bother.)

> So you don't honor the requirement? Then, I doubt SigComp can ever be
> used in real life.

Right now, I know of only one technical requirement, the one I cited.
(Well, actually, we have a whole document that essentially details that
technical requirement, draft-ietf-rohc-signaling-req-assump-04.txt; maybe we
have to amend that.)There also is a level 9 requirement to stay clear of
IPR, which I fully support.

Gruesse, Carsten

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