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

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

Hi Carsten:

I changed the subject of the discussion, just to focus in this e-mail on 
requirements.

A group of individuals collected the 3GPP requirements related to SIP and
write them down in an Internet Draft,

http://search.ietf.org/internet-drafts/draft-garcia-sipping-3gpp-reqs-02.txt

Version -03 is on its way and will be submitted before the deadline to MN.

I will encourage to read the actual section 6.5 in that document. There are
several requirements affecting compression.

I will also recommend to read requirements 6.1.1 and 6.1.2. Although these
are general requirements, they are applicable to all the rest of the 
requirements and possible solutions.

/Miguel

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

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