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

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Wed, 27 Feb 2002 14:04:03 +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

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

---

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

> Here are some immediate comments on these requirements.
[snip]

>    consider the security aspects of it and the added complexity of the

<miguel>
Yes, I fully agree with you. This is not a requirement. It is a solution to
a requirement that is not stated, and I don't know which one is that.

However, not all the authors of this I-D are able to differentiate a 
requirement from a solution. This is the reason why the text in there 
remains.

Just for your information, this is not the only place in the document where
we are mixing requirements with solutions. I have been trying to convince 
the others that requiring a solution without stating the requirement has
no sense... But I need to keep on trying.

As a short term solution, I would recommend the ROHC WG to answer to this
requirement: "In IETF we have taken the decision to not standardize a 
default algorithm. If other organizations, such as 3GPP want to standardize
a default algorithm in their networks, that's fine".
</miguel>

>    Further, only the Proxy->UA traffic direction is addressed above.

<miguel>
The first sentence is a requirement. The rest is just additional information
or suggestions. I understand that "The type of negotiation mechanism that 
should be implemented is that the UAC includes a list of compression ..."
it is a solution, not a requirement.

I agree with you that this paragraph is considering only the case of the UA
to the Proxy, and not viceversa. Perhaps when these requriments were written
most people were thinking of a bidirectional case, so negotiation and compression
in one direction will imply the same results in the reverse direction.
</miguel>

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002