Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages

From: [email-masked]
Date: Tue, 1 Apr 2003 07:44:03 -0600

Robert,

>  I don't think it is a problem with SigComp multiplexing, but 
> more like a SIP internal issue. What if there is a TCP stream 
> of SIP messages and the Content-Length header is missing or 
> false? They will screw up the same way with or without 
> SigComp. 

Since TCP is a reliable transport, this only happens for a
mis-behaved SIP sender. But that is not the "multiplexing" problem 
I mentioned below, which happens even "during normal functioning" 
(see below).

> During normal functioning both SIP and SigComp 
> provide their own flow separation mechanism and they work just fine.

I don't think so. That is what I intended to show by the example,
i.e. the issue to "multiplex uncompressed application messages and 
SigComp messages on the same port". One solution, as I mentioned
before, is to require sigcomp receiver has the ability to parse
uncompressed application messages and detect the end. 

(Of course, I saw Carsten's email and I need understand his
point of view, which says there is no such "multiplexing" and
it is not possible and necessary.)

BR,
Zhigang
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Thu, 3 Apr 2003 11:29:23 -0600

Mark,
 
The problem I raised is how "to multiplex uncompressed application messages and SigComp messages on the same port" when application messages start with UTF-8 encoded text but contain binary data. For the problem itself, I don't assume where the demultiplexing is done (that goes to the solution space, see below). My point is that it needs to be done somewhere at the receiving endpoint (which by definition, is "one instance of an application, a SigComp layer, and a transport layer").
 
Now, the solutions:
 
- One is to let decompressor dispatcher do the demultiplexing (I won't repeat how it can be done), which means all bytes received on a port must go through SigComp layer first. This follows the SigComp architecture in RFC 3320. It makes the layering more clean, i.e., (de)compression and (de)multiplexing is handled completely by SigComp layer. The drawback is a bit redundancy in the sense that the decompressor dispatcher performs some parsing that the application layer will later do again. 
 
- The other one is to let the application do the demultiplexing as you described below. That means all received data must go through application first.
 
In my view, either one will work and the choice is a local implementation issue (although the latter is not described in RFC 3320). The difference boils down to where do put the demultiplexing function. It's a matter of preference of SW coding. However, what is NOT an implementation issue is that - looking at transport layer - a receiving endpoint must expect it may receive uncompressed messages interspersed with SigComp messages on the same port and demultiplex them using either of the above approaches (or any other working solutions). This needs to be spelled out in a document.
 
BR,
Zhigang

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: April 03, 2003 8:24 AM
To: Liu Zhigang.C (NRC/Dallas); Sugar Robert (NET/Budapest)
Cc: [email-masked]; [email-masked]
Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages

Zhigang, 

If I understand the solution described by Robert correctly, then the problem you describe below does not arise. Your problem seems to assume that demultiplexing of compressed and uncompressed messages will be done before the SIP parser is invoked, based on the 11111xxx delimiter.

My understanding is that messages are passed directly to the SIP parser. This software must be aware that SIGCOMP may be used, and checks the first octet of the input stream. If this is 11111xxx then it uses the sigcomp delimeter OxFFFF to find the end of the compressed message, and then sends it to the decompressor. If the first octets is not 11111xxx then it just starts parsing as normal.

The only assumption is that the SIP parser has its own way of recognising the end of an uncompressed message. 

Regards...Mark 

> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]] 
> Sent: 01 April 2003 14:44 
> To: [email-masked] 
> Cc: [email-masked]; [email-masked] 
> Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP 
> messages 
> 
> 
> Robert, 
>

---

From: [email-masked]
Date: Thu, 3 Apr 2003 14:19:31 -0600

> The mechanism in
> SigComp is not there to allow multiplexing of SigComp
> messages and raw messages within the same connection, 
> but only to identify whether the connection uses
> SigComp or not. 

If by "multiplex uncompressed application messages and
SigComp messages on the same port" RFC 3320 does not
mean what I thought it meant, I'd propose to add 
mutltiplexing (in the true meaning) capability as an
extension to RFC 3320. 

For details and arguments, please see my previous email:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01423.html

BR,
Zhigang

---

From: [email-masked]
Date: Thu, 3 Apr 2003 15:56:54 -0600

Richard,

> Regarding point a), I don't see how this can be done without
> talking about specific protocols. 

I agree if you mean the exact logic (see below). But what I had in 
mind for a) is a generic or abstract logic as follows:

0. Endpoint B informs endpoint A that it supports SigComp AND
multiplexing of uncompressed message and SigComp message on
a TCP connection. This should be part of the SigComp discovery.

1. Endpoint B reads in one byte. 

2. If the first 5 MSB of the byte is 11111. this is the beginning
of a SigComp message or a SigComp message delimiter (0xFFFF). 
Endpoint B enters "SigComp parsing mode" and processes byte stream
according to SigComp until it encounters END-MESSAGE instruction 
or Sigcomp delimiter. When that happens, go to 1. 

3. Else, this is the beginning of an uncompressed message. Endpoint
B enters "uncompressed parsing mode" and parses the byte stream 
according to the delimiting scheme of the application messages. 
When reaching the end of application message, go to 1. 

Note: it is assumed that uncompressed application messages start
with UTF-8 encoded character. Otherwise, the logic does not work.

Note: the sigcomp can deliver the bytes to application layer either as 
they are arriving or at the end of the application message.

Note: this abstract demultiplexing logic can be either done at
SigComp layer (decompressor dispatcher) or at application layer.
That is a choice of local implementation.

Now, back to your comment. I certainly agree with you that detecting 
end of application message in Step 3 depends on a particular application 
protocol. But other than that, the rest is pretty generic. We can 
consider the above as the abstract logic that will be "instantiated" 
when binding SigComp to a particular application.

> Regarding point b), it might be good to have some recommendations
> on how to implement an efficient compressor for messages with
> binary content. 

Yes.

> A suitable home for these would be the SigComp
> User Guide, which already talks about the various different
> compressors that can be used in conjunction with SigComp.

OK. I don't mind where it ends up as long as the issue finds
a home. I can provide some text.

BR,
Zhigang