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

From: [email-masked]
Date: Wed, 15 Dec 2004 11:09:47 +0200

Keith,

thank you for the information. However, I want to point
out that if the statement about the multiplexing in draft-ietf-rohc-sigcomp-sip-01 
is the final one- it will cause unnecessary changes in the implementations
already supporting multiplexing (and will break backwards compatibility).
That's why I think that multiplexing should be allowed without any 
extra 'uncompressed SigComp headers".

regards,
	paulius

> -----Original Message-----
> From: ext Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2004 9:29 PM
> To: Meskauskas Paulius (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp 
> messages on
> t hesame TCP connection
> 
> 
> 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.
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > [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,
> > 
> > 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
> > 
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Dec 2004 10:31:11 +0100

> extra 'uncompressed SigComp headers".

Paulius,

this is surprising.
RFC3320 is quite clear about the way a stream-based (TCP) connection 
works: messages are delimited by the record marking scheme (section 
4.2.2).

The proposal that later came up to mix this SigComp framing with SIP 
framing on one connection has received nearly unanimous rejection by 
SIP implementers.
We have discussed this on the mailing list for a long time and, despite 
some vocal support for this, in each round this was generally seen as 
the wrong way to do this.

SigComp shim headers are a standard-conforming way to multiplex 
compressed and uncompressed messages on one SigComp TCP connection that 
is interoperable today.
I'd like to hear a good reason why we need something else that is not 
compatible with the SigComp architecture.

(An extension that would be compatible would be to allow uncompressed 
messages in the second and following records in the SigComp TCP record 
marking syntax.
[You can allow uncompressed messages in the first message only if you 
don't need to differentiate between SIP and SigComp connections.]
This is trivial to implement, but still an extension.  Again, I'd like 
to hear arguments why you need to save those 13 bytes.)

Gruesse, Carsten