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

From: [email-masked]
Date: Mon, 20 Oct 2003 10:17:46 +0200

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