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

[[e-mail]]

Carsten and all,

The reason I raised the "binary multiplexing", as you found out, 
is the following text in RFC 3320. I took the sentence literally, 
i.e., uncompressed application messages and SigComp messages can 
be transmitted on the same (destination UDP or TCP) port, one 
followed by another. If that understanding is incorrect, I'm wondering
what else it means or is intended to mean.

  "... for applications which use this 
  encoding (or ASCII encoding) it is possible to multiplex uncompressed
  application messages and SigComp messages on the same port."

In addition, the above text works - in my mind - at least for case
00, 01, and 10 listed below. Note I assume we are talking about application
messages that start with UTF-8 encoding (my interpretation of "use" in
above text). Also, I try to visualize the issue in two dimensions: encoding
of application messages and transport below SigComp.

					message-based	stream-based
					transport		transport
					(e.g. UDP)		(e.g. TCP)

  contain no binary data	case 00		case 01

  contain binary data		case 10		case 11

Here is why/how I see it works for case 00-10:

- For case 00 and 10, RFC 3320 says "In case of a message-based
transport such as UDP, a SigComp message corresponds to exactly one 
datagram." So, it is trivial for the receiver to tell if a UDP packet
carries uncompressed message or sigcomp message by inspecting 
the first byte.

- For case 01, the receiver can detect the beginning of a SigComp
message by bit pattern "11111" and the end by END-MESSAGE instruction.
Of course, the SigComp message delimiter also works for this purpose. 

As to case 11, I think we can also make it work, if sigcomp receiver
can detect the end of an uncompressed message. Obviously, that means 
the receiver needs to have some knowledge about the application 
message format. This is why I separate case 11 from the rest (which
are application independent). 

Now come to the question if the multiplexing is necessary. I think it
is useful in cases where a sigcomp sender does not want to compress 
every application message even though the other end has indicated its 
support of sigcomp. The reason could be CPU load of the compressor, 
message uncompressible, etc.

I could be wrong by thinking the multiplexing works. But if it indeed
works, the next question is whether RFC 3320 already covers some of 
this or we add extension to RFC 3320.

BR,
Zhigang


> -----Original Message-----
> From: ext Carsten Bormann [mailto:[e-mail]]
> Sent: March 28, 2003 9:24 AM
> To: [e-mail]
> Cc: Carsten Bormann
> Subject: Re: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP
> messages
> 
> 
> ROHCers,
> 
> in San Francisco, I promised to come back to the "binary multiplexing"
> issue after the IETF.
> 
> It has taken me a while to even understand what is being talked about:
> There is an assumption in this whole thread that I don't know where it
> came from.
> 
> We designed SigComp messages so that they always start with a byte
> that cannot be used as a coding symbol in UTF-8 (see
> draft-yergeau-rfc2279bis-04.txt for the updated version of RFC2279
> that defines the contemporary version of UTF-8).  The assumption was
> that most signalling protocols would use UTF-8 headers, so this would
> allow some self-describing-ness of SigComp messages.
> 
> RFC3320 says:
> 
>     All SigComp messages contain a prefix (the five 
> most-significant bits
>     of the first byte are set to one) that does not occur in UTF-8
>     encoded text messages [RFC-2279], so for applications 
> which use this
>     encoding (or ASCII encoding) it is possible to multiplex 
> uncompressed
>     application messages and SigComp messages on the same port.
>     Applications can still reserve a new port specifically for SigComp
>     however (e.g., as part of the discovery mechanism).
> 
> I now see that this might be phrased a bit misleading
> ("multiplexing").  But clearly, the scheme discussed is about using
> the same port for two different *transports*: the raw transport and
> the SigComp-compressed transport.  Nowhere does it say that you would
> multiplex messages from these two *on the same connection*.  I don't
> believe this is possible or even necessary.
> 
> Record Marking (4.2.2) is used to delimit SigComp messages on stream
> transports (TCP, TLS).  The assumption, of course, is that the
> connection carrying these messages already has been disambiguated to
> run SigComp instead of the raw transport protocol.
> 
> This is the end of my main argument for this message.  If you disagree
> with it, please discuss it and not the interesting speculation below.
> 
> <div class="speculation">
> 
> It is somewhat conceivable to occasionally intersperse uncompressed
> messages in the SigComp record marking transport, but it remains clear
> that the record marking layer is in effect at all times:
> 
>     For a stream-based transport, the dispatcher delimits messages by
>     parsing the compressed data stream for instances of 0xFF 
> and taking
>     the following actions:
> 
> So, we are talking about a situation where the data flows to a SigComp
> dispatcher, not to an entity that still needs to find out whether we
> are running SigComp or not.
> 
> Could SigComp record marking be used to carry both compressed and
> uncompressed messages on one connection?  (Remember that this is not
> part of the standard, but of course could be part of an extension to
> RFC 3320.)
> 
> In principle, yes, but there is a problem (see below).  In any case,
> though, Content-Length headers or any other application message
> delimiting protocol would not enter the picture at all -- the SigComp
> record marking layer remains in effect throughout a SigComp
> connection.
> 
> Now the problem: If you don't have any other way to find out (e.g.,
> different port numbers for compressed and uncompressed), it becomes
> hard to decide whether such a compressed/uncompressed multiplexed
> stream is SigComp or not.  If it starts with a non-UTF-8 coding
> symbol, you know it's SigComp.  But if the first message you want to
> send on the connection happens to be uncompressed, you need another
> way of indicating that a SigComp transport is being used.  Of course,
> you could simply send 0xFFFF and trust that the receiver will discard
> empty messages.  So to make this multiplexing business work, you will
> have to add a mandate that says empty messages (or at least one 0xFFFF
> at the beginning of the connection) are discarded.
> 
> Of course, none of this applys to any hypothetical SigComp application
> that does not use UTF-8 headers in their messages -- the multiplexing
> would not work this way at all, period.  So you would devise another
> way of multiplexing, which I'm too lazy to do right now.
> 
> </div>
> 
> Oh, and we still have to do the work on the SIP binding for SigComp,
> which is completely unrelated to this whole thread.  There is no known
> problem with SigComp-compressing large binary layloads in SIP messages
> (except, maybe, that there won't be very good compression schemes for
> data that already have been compressed).
> 
> Gruesse, Carsten
> 
> _______________________________________________
> Rohc mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc