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

[Carsten Bormann <[e-mail]>]

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