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

From: "Price, Richard" <[email-masked]>
Date: Wed, 27 Feb 2002 14:50:13 -0000

Hi Miguel and Carsten,

Just got back from holiday - mind if I join in this interesting
discussion? I'd be grateful for an answer to the following two
questions:

Miguel: Is it important from a technical perspective for 3GPP to
have an algorithm negotiation mechanism?

Section 6.5.6 of the 3GPP requirements draft seems to specify a
solution rather than a requirement, in the sense that entities
external to SigComp don't know (or care) whether a negotiation
mechanism is being employed. Surely what is more important is the
technical performance of the solution, measured using some or all
of the following:

*   Call setup time
*   Processing requirements
*   Memory requirements
*   Standardisation effort
*   Implementation effort
*   IPR concerns
*   Future-proofing
*   Any others I've forgotten?

If the ROHC WG can beat the algorithm negotiation approach in terms
of all of the above, is it still necessary to provide an algorithm
negotiation mechanism within SigComp?

Carsten: Do you have any objections to including an algorithm
negotiation mechanism, other than the additional standardisation
effort?

The reason I ask is that SigComp already has the ability to negotiate
algorithms - it comes for free as part of the "state claim" mechanism
that we provided to support explicit acks. So no additional effort is
needed to include algorithm negotiation.

Is it OK to provide both the UDVM approach and the algorithm
negotiation approach, and leave it to implementers to choose which to
adopt?

Regards,

Richard

> -----Original Message-----
> From: Miguel A. Garcia [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 1:53 PM
> To: Dr. Carsten Bormann
> Cc: [email-masked]; [email-masked]
> Subject: Re: SigComp Requirements (was Re: [rohc] RE: Default
> decompression algorithms)
> 
> 
> Hi:
> 
> No, these requirements were discussed prior to the UDVM approach.
> 
> As I said, a new version of this draft will be shortly submitted.
> I need to discuss with the rest of the co-authors some better wording
> that reflects the latest assumptions in Rohc and 3GPP.
> 
> I will announce the draft in this mailing list as well.
> 
> /Miguel
> 
> "Dr. Carsten Bormann" wrote:
> > 
> > Miguel,
> > 
> > does this list of requirements take into account the UDVM approach?
> > It does seem to predate its adoption.
> > 
> > Gruesse, Carsten
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
>

---

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

> have an algorithm negotiation mechanism?

Yes, it is important. Definitely. We don't want to stick to a 
single algorythm that is deployed to millions of terminals forever.
The software in those terminals are not easy to upgrade.
Further more, my personal opinion is that 3GPP should not enter the
battle of standardizing a default algorythm, and that should be left
open for the mobile manufactures. Sigcomp-04 is a nice framework,
as it allows the negotiation of the algorithm.

> *   Any others I've forgotten?

Yes, I commented also in a previous mail about section 6.5.6. I forgot
to mention, thouth, that yesterday all the authors decided to keep only
the first sentence: "There must be a mechanism to negotiate between the 
UA and the first SIP outbound proxy the compression algorithm to be used"

Regarding your concerns about Call Setup Time... I belive that in 3GPP
we will end up negotiating the compression during the time the mobile 
is registered/connected to the network. Therefore, that would be done
prior to setting up any call. So don't worry about Call Setup Time.

> negotiation mechanism within SigComp?

Yes, as I said before, Yes, it is a requirement. Mobile operators don't
want to restrict to a single algorythm in the network, they want
extensibility.

Removing the negotiation mechanism in SigComp is like removing the
codec negotiation in SIP.

/Miguel

>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit