Subject: RE: [rohc] Old issue - multiplexing compressed and uncompressed messages in the same TCP connection - long

From: [email-masked]
Date: Wed, 12 Nov 2003 16:25:26 -0500

Hello All,

Thanks for Robert to raise this old issue again. My personal 
view has been that multiplexing is really good (and easy) to 
have. Below Robert has given a good in-depth description of the
reasons. I'd like also to hear opinions from other people,
especially if they are different. Otherwise, I plan to update
sigcomp-sip I-D accordingly.

BR,
Zhigang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: October 20, 2003 03:18 AM
> To: [email-masked]
> Subject: [rohc] Old issue - multiplexing compressed and uncompressed
> messages in the same TCP connection - long
> 
> 
> Hi all,
> 
>  You probably remember that discussion over $subject. As far 
> as I can remember, conclusion was that although it could be 
> implemented with a common transport layer, there is really no 
> need to add the extra complexity. 
> 
> RFC3486 has the following, reflecting that:
> "If a SIP client sends a compressed request and the client 
> transaction times out without having received any response, 
> the client SHOULD retry the same request without using 
> compression.  If the compressed request was sent over a TCP 
> connection, the client SHOULD close that connection and open 
> a new one to send the uncompressed request. Otherwise the 
> server would not be able to detect the beginning of the new message."
> 
> So, why do we need compressed and uncompressed messages 
> multiplexed in the first place?
> 
> 1. Fallback to uncompressed mode (also suggested in RFC3486)
> 2. Large messages: OUTPUT instruction stops after 64Kbytes of 
> data, so SIP messages larger than 64K are to be sent 
> uncomperssed. This is not an impossible case, since SIP 
> messages may carry arbitrary MIME attachments, such as XML 
> (->presence info), WAV (->ringing tone), JPG (-> caller's photo), etc.
> 3. If there is no comp=sigcomp URI to the proxy (proxy 
> discovery usually yields only the IP address), initial 
> messages are to be sent uncompressed, but subsequent messages 
> could be sent compressed if comp=sigcomp is inserted into the 
> Record-Route by the proxy. If no comp=sigcomp contact is 
> given later, all initial requests will be sent uncompressed.
> 4. RFC3486 allows inserting comp=sigcomp into SIP headers 
> anytime. Preference for insertion might be for example the 
> load of the proxy. If there are parallel sessions in the same 
> compartment, at least one compressed and one uncompressed, 
> TCP connections should be closed and re-opened anytime 
> messages interleave. This would cause unnecessary extra 
> delays and roundtrips due to the TCP handshake.
> 
> Why is it hard to close and re-open the TCP connections?
> 
>  Problem is that if we use lower-layer security, such as 
> IPSec (as in 3GPP for one example), we cannot open and close 
> ports at will, because security associations have fixed 
> selectors (source IP, source port, destination IP, 
> destination port, protocol). The only way we could open a new 
> TCP connection is to use exactly the same 5 selectors as the 
> original one.
> According to TCP: "Another effect of this 2MSL wait is that 
> while the TCP connection is in the 2MSL wait, the socket pair 
> defining the connection (client IP address, client port 
> number, server IP address, server port number) cannot be 
> reused.  That connection can only be reused when the 2MSl 
> wait is over."
> MSL is the maximum segment lifetime, which is by RFC 
> recommendation 2 minutes, but many implementations use 30 
> seconds. Effectively, it means that the connection cannot be 
> reused for 1-4 minutes after closure.
> 
> How it could be implemented?
> 
> A possible implementation could be:
> -	Transport looks at the first byte of the message, and 
> cheks whether it starts with 11111.
> -	If yes, the stream is passed to SigComp that reads it 
> till 0xFFFF and returns
> -	If no, the stream is passed to SIP that reads it as 
> long as indicated by Content-Length
> -	Rinse, Repeat
> 
>  Of course if the Content-Length is improperly filled, 
> missing or SigComp messages contain additional 0xFFFF or do 
> not end with 0xFFFF, it might happen that a parser receives 
> messages that are erroneous, partial or belong to the other 
> protocol. In that case the next message or all messages 
> inside that stream could be lost. But similar problems also 
> arise in a stream containing SIP or SigComp messages only.
> 
> What do you think?
> 
> BR,
> Robert
> 
> _______________________________________________
> 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: "West, Mark" <[email-masked]>
Date: Wed, 12 Nov 2003 22:39:43 +0000 (GMT Standard Time)

Hi all,

I still go along with what I still believe was the majority view from S-F,
which was: 'yeah, you could do this, but why would you want to..?'

But first of all, can I be *really* pedantic about terminology..?  We
should differentiate between:
- SigComp message; and
- non-SigComp message

With respect to the former, these can be compressed or uncompressed.
(Further, the compression used can make use of states at the remote
end-point, or be state-less).

The main justification given for multiplexing sigcomp and non-sigcomp
messages seems to be that it's too hard to re-open a new TCP connection.
Now, there may be transport-friendliness issues with continually closing &
opening TCP connections, but the idea of having a fixed rather than
ephemeral source port seems slightly weird...  not least because that
seems to break recovery if you close a session on detection of wrong
content-length, for example?

I agree that there are many reasons for needing to be able to send a mix
of SigComp & non-SigComp messages between 2 SIP peers.  These are not
necessarily reasons for multiplexing these messages on the same TCP flow,
though.

If you were allowed to have multiple TCP connections or to re-open a new
connection easily, why would you want to do multiplexing on a single
connection..?

> > long as indicated by Content-Length

makes it sound easy, but the throw-away 'is passed to' seems to me to
conceal all of the complexity / layering problems / tricky stuff...

So, no, I don't like the idea of putting SigComp & non-SigComp messages on
the same connection...

... but feel free to try and convince me otherwise..!

Cheers,

Mark.

On Wed, 12 Nov 2003 [email-masked] wrote:

> Date: Wed, 12 Nov 2003 16:25:26 -0500
> From: [email-masked]
> To: [email-masked], [email-masked]
> Subject: RE: [rohc] Old issue - multiplexing compressed and uncompressed