Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t hesame TCP connection

From: [email-masked]
Date: Tue, 14 Dec 2004 11:11:13 +0200

hello,

OMA PoC mandates the usage of SigComp and in case IMS core
is used - the compression must take place between UE and P-CSCF.

IMHO there's no need for 'uncompressed SigComp header' in order
to keep SigComp generic and allow the multiplexing.. The main thing 
is to break the SigComp dependency to the transport layer in the implementation 
i.e. text-based protocols know their delimiters and SigComp knows its own. 

cheers,
	paulius

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Carsten Bormann
> Sent: Tuesday, November 16, 2004 5:31 PM
> To: Surtees, Abigail
> Cc: West, Mark; Sugar Robert (Nokia-NET/Budapest); Liu Zhigang.C
> (Nokia-NRC/Dallas); [email-masked]; Conroy, Lawrence (SMTP); Carsten
> Bormann
> Subject: Re: [rohc] Re: multiplexing SigComp and non-SigComp 
> messages on
> t hesame TCP connection
> 
> 
> Abbie,
> 
> 3GPP submission S2-043577 says:
> 
> > For TCP, none of the existing standards mandates whether or not 
> > endpoints must be able to multiplex SIP and SigComp messages on the 
> > same TCP connection however, the IETF currently see no need to 
> > multiplex and would like to mandate that it must not be 
> done. We note 
> > that with the IMS security architecture there are some constraints 
> > with regards to the usage of ports on the P-CSCF and the UE. During 
> > the establishment of the IPSec security association the UE and the 
> > P-CSCF negotiate 2 ports on each side. These ports are used as the 
> > selector for the corresponding security association and are 
> fixed for 
> > the duration of the security association. Consequently, if 
> there is a 
> > need to send both SIP and SigComp messages over TCP, they 
> would have 
> > to be on the same connection.
> >
> > It seems, however, that the issue is not a real issue for 
> IMS and PoC, 
> > as it is mandated that terminals and networks will support SigComp 
> > (though its use is not mandatory). Consequently a terminal 
> can decide 
> > on the first message whether or not it is going to use 
> SigComp and not 
> > change. In this case, if there is a need to send an uncompressed 
> > message (e.g. due to loss of sync between compressor and 
> decompressor, 
> > or to reduce processing load) when SigComp is in use, the 
> > 'uncompressed SigComp header' can be used. This is a set of 13 well 
> > known bytes that are prepended to the SIP message to make 
> it a SigComp 
> > message and are removed as a block at the decompressor.
> 
> This fits pretty well with what was said in the San Diego WG meeting 
> and hallway discussions, and this is what was intended by my slide in 
> Washington.
> 
> (Sorry if I'm incoherent -- I'm wrestling with my usual post-IETF 
> aircon-induced fever.)
> 
> Gruesse, Carsten
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 14 Dec 2004 19:29:12 -0000

For information, we ended up with the following text (unofficial version - official version of CR still being implemented) covering 3GPP IMS compression in 3GPP TS 24.229 as a result of the latest round of meetings.

Our discussions in 3GPP assumed that the statement regarding multiplexing of Sigcomp and non-Sigcomp in draft-ietf-rohc-sigcomp-sip-01 to stand.

regards

Keith

8	SIP compression

8.1	SIP compression procedures at the UE

8.1.1	SIP compression

The UE shall support SigComp as specified in RFC 3320 [32]. When using SigComp the UE shall send compressed SIP messages in accordance with RFC 3486 [55]. When the UE will create the compartment is implementation specific, but the compartment shall not be created until a set of security associations are set up. The compartment shall finish when the UE is deregistered. State creations and announcements shall be allowed only for messages received in a security association.

NOTE:	Exchange of bytecodes during registration will prevent unnecessary delays during session setup.

Editor's note: 	The draft-ietf-rohc-sigcomp-sip-01 [79] can lead to the need for additional changes or clarifications.

The UE shall support the SIP dictionary specified in RFC 3485 [42]. If compression is enabled, the UE shall use the dictionary to compress the first message. 

The following apply when signalling compression is used:

-	State Memory Size (SMS) greater than zero is needed to give room for the UDVM byte code and make dynamic compression possible. A State Memory Size of at least 4096 bytes shall be a minimum value; and

-	A Decompression Memory Size (DMS) of at least 8192 bytes should be a minimum value.

8.1.2	Compression of SIP requests and responses transmitted to the P-CSCF

The UE should compress the requests and responses transmitted to the P-CSCF according to subclause 8.1.1.

NOTE 1:	Compression of SIP messages is an implementation option. However, compression is strongly recommended.

NOTE 2:	Since compression support is mandatory, the UE may send even the first message compressed. Sigcomp provides mechanisms to allow the UE to know if state has been created in the P-CSCF or not.

8.1.3	Decompression of SIP requests and responses received from the P-CSCF

The UE shall decompress the compressed requests and responses received from the P-CSCF according to subclause 8.1.1.

If the UE detects a decompression failure at the P-CSCF, the recovery mechanism is implementation specific and this may, as an example, include resetting the compartment, changing the algorithm.

8.2	SIP compression procedures at the P-CSCF

8.2.1	SIP compression

The P-CSCF shall support SigComp as specified in RFC 3320 [32]. When using SigComp the P-CSCF shall send compressed SIP messages in accordance with RFC 3486 [55]. When the P-CSCF will create the compartment is implementation specific, but the compartment shall not be created until a set of security associations are set up. The compartment shall finish when the UE is deregistered. State creations and announcements shall be allowed only for messages received in a security association.

The P-CSCF shall support the SIP dictionary specified in RFC 3485 [42]. If compression is enabled, the P-CSCF shall use the dictionary to compress the first message.

NOTE:	Exchange of bytecodes during registration will prevent unnecessary delays during session setup.

Editor's note: 	The draft-ietf-rohc-sigcomp-sip-01 [79] can lead to the need for additional changes or clarifications.

The following apply when signalling compression is used:

-	State Memory Size (SMS) greater than zero is needed to give room for the UDVM byte code and make dynamic compression possible. A State Memory Size of at least 4096 bytes shall be a minimum value; and

-	A Decompression Memory Size (DMS) of at least 8192 bytes should be a minimum value.

8.2.2	Compression of SIP requests and responses transmitted to the UE

The P-CSCF should compress the requests and responses transmitted to the UE according to subclause 8.2.1.

NOTE:	Compression of SIP messages is an implementation option. However, compression is strongly recommended.

8.2.3	Decompression of SIP requests and responses received from the UE

The P-CSCF shall decompress the compressed requests and responses received from the UE according to subclause 8.2.1.

If the P-CSCF detects a decompression failure at the UE, the recovery mechanism is implementation specific and this may, as an example, include resetting the compartment, changing the algorithm.

> [email-masked]
> Sent: 14 December 2004 09:11
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp 
> messages on
> t hesame TCP connection
> 
> 
> hello,
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > ext Carsten Bormann

---

From: [email-masked]
Date: Wed, 15 Dec 2004 15:01:32 +0200

> Figure 1 is pretty much an illustrative figure, it can't tell 
> the whole 
> picture.
> 4.2.2 clearly says it is the dispatcher that parses the data stream.
> 
> The main point in the architecture is that SigComp handles the 
> transport interface.
> It cannot do this if it has to apply both SIP message parsing 
> rules and 
> SigComp message parsing rules -- then the SIP implementation comes in 
> in a way that implementors did *not* like.

So RFC3320 actually mandates that SigComp handles tranport-layer?
If SIP handles the transport layer (as it normally does) and uses 
SigComp just for compression/decompression - mixing in the same TCP
connection is not the problem, because SIP knows its delimeters and SigComp
knows its own. When SIP reads the stream and encounters SigComp magic bits
it just passes the message to the SigComp. SIP (or whatever text based
protocol) does not have to know the SigComp magic bits but is sure knows that
the message can be compressed since it wanted compression to take place.
And SIP anyway must implement compartment handling logic etc... 
This is an alternative way how to implement it without the need to involve
the SigComp in case the compression must not take place.

I do agree that if RFC3320 architecture is followed in the implementation
the 3) is the best way to go. 

regards,
	paulius

> 
> So in summary:
> 
> 1) Mixing SIP message parsing and SigComp record marking in one 
> connection: bad.
> 
> 2) Mixing uncompressed and compressed messages in a SigComp record 
> marked stream: good, but not necessarily already required by the 
> standard.
> 
> 3) Mixing compressed and uncompressed messages in a SigComp record 
> marked stream by sending the latter with a SigComp shim header: 
> standard, interoperable now.