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

From: Kevan Hobbis <[email-masked]>
Date: Wed, 27 Feb 2002 13:57:17 -0000

Carsten

High-level requirements should not be affected by a particular proposed
implementation or solution, hence they ought to pre-date any proposed
solution. 

Thanks

Kevan Hobbis

-----Original Message-----
From: Dr. Carsten Bormann [mailto:[email-masked]]
Sent: 27 February 2002 13:47
To: Miguel A. Garcia
Cc: [email-masked]; [email-masked]
Subject: RE: SigComp Requirements (was Re: [rohc] RE: Default
decompression algorithms)

Miguel,

does this list of requirements take into account the UDVM approach?
It does seem to predate its adoption.

Gruesse, Carsten

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________________________

If this email isn't for you then we'd be grateful if you could let our
helpdesk know there's been a mistake by putting 'received in 
error' in the subject box and sending it to [email-masked]. 
If it isn't for you, we're sure you'll understand that you're not 
allowed to copy, disclose or distribute any of its contents.  
This email is private and confidential and may also be privileged,
so if you shouldn't have received it, we'd be grateful if you could delete it.
Thanks.
________________________________________________________________

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Wed, 27 Feb 2002 14:50:27 +0100

Miguel,

Here are some immediate comments on these requirements.

Cheers,
/L-E

6.5 Compression of SIP signaling 
    
   As the radio interface is a scarce resource, the transport of SIP 
   messages over the radio interface must be done efficiently. 
    
   Therefore, there must be a mechanism to efficiently transport SIP 
   signaling packets over the radio interface, by compressing the SIP 
   signaling messages between the UA and the SIP outbound proxy, and by 
   compressing the IP and transport layer protocol headers that carry 
   these SIP messages. 
   
-> LEJ: Yes, this is why we do SigComp, in addition to link-layer
   IP/UDP header compression.

6.5.1 Extensibility of the SIP compression 
    
   The chosen solution(s) must be extensible to facilitate the 
   incorporation of new and improved compression algorithms in a backward 
   compatible way, as they become available.

-> LEJ: The UDVM approach should fully meet this requirement. 

6.5.2 SIP compression and roaming 
    
   The chosen solution(s) for SIP compression must work in roaming 
   scenarios. 
    
-> LEJ: This was one of the reasons we decided to do compression end2end (not per link).

6.5.3 Minimal impact of SIP compression on the network 
    
   Application specific compression must minimize impacts on existing 
   3GPP network, e.g. the compression must be defined between the UA at 
   the SIP terminal and the outbound SIP Proxy in the visited network.

-> LEJ: Luckily, there were also technical arguments for placing SigComp at
   the application layer (UA<->Proxy). 

6.5.4 Optionality of SIP compression 
    
   It must be possible to leave the usage of compression for SIP 
   signaling optional. 

-> LEJ: No problem, we do not expect everyone to suddenly use compressed SIP.

6.5.5 Default algorithm for SIP compression 
    
   If SIP signaling compression is used, a default algorithm must be 
   supported by the UA and the network elements involved for compression. 
    
-> LEJ: Why?? We are currently having a discussion about this on the list, 
   and we will see what the outcome will be. ROHC is not at all discussing
   algorithms, and will therefore not define any default algorithm. What is
   still under consideration is whether we should provide mechanisms to
   announce decompressor-supported algorithms. However, the usefulness of
   this is still not clearly proven, and if we want to support this we must
   consider the security aspects of it and the added complexity of the 
   solution. 

6.5.6 Compression Negotiation 
    
   There must be a mechanism to negotiate between the UA and the first 
   SIP outbound proxy the compression algorithm to be used. The type of 
   negotiation mechanism that should be implemented is that the UAC 
   includes a list of compression algorithms and the first SIP outbound 
   proxy responds with the selected one. Subsequent SIP messages are 
   compressed based on the agreed algorithm.

-> LEJ: This is not a requirement, its is a proposed solution/mechanism.
   Further, only the Proxy->UA traffic direction is addressed above.

> 
> 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-3g
> pp-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

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Thu, 28 Feb 2002 09:12:13 +0100

> > RP: Is it important from a technical perspective for 3GPP to
> > have an algorithm negotiation mechanism?
> 
> MG: Yes, it is important. Definitely. We don't want to stick to a 
> single algorithm that is deployed to millions of terminals forever.

OK, and with the UDVM-approach, you can use any algorithm at any time.

> > RP: 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?
> 
> MG: Yes, as I said before, Yes, it is a requirement. Mobile 
> operators don't want to restrict to a single algorithm in
> the network, they want extensibility
> 
> Removing the negotiation mechanism in SigComp is like removing the
> codec negotiation in SIP.

The UDVM provides you with total flexibility regarding compression
algorithm, and you do not necessary need an explicit negotiation 
mechanism.

/L-E