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

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 28 Mar 2003 08:25:53 +0100

Zhigang,

Both Richard and Adam have expressed a different opinion on this issue,
and I fail to see how this can be addressed in general, as it is about
possible application messages, and thus would be application dependent.

Anyway, submit a draft, that might enhance discussions.

BR
/L-E

> IMO, binary content in application message is a general issue for
> SigComp multiplexing. It's not specific to SIP. I already explained 
> this in rohc and sipping mailing list. But here is a simple example. 
> 
> Let's say endpoint A already knows endpoint B supports SigComp on TCP 
> port number 5000. A sends, on port 5000, uncompressed message 
> 1 followed 
> by message 2 compressed using SigComp. From RFC 3320, message 2 starts
> with bit pattern 11111. So, if message 1 has no binary 
> content, endpoint
> B can easily detect the beginning of message 2 (i.e. end of message 1)
> by detecting 11111. However, if message 1 contains binary content,
> that means the (uncompressed) binary part may contain byte 11111xxx.
> This "mimicking" will make endpoint B mistakenly think a new SigComp
> message starts at that byte. Obviously, things will be messed up
> from that point.
> 
> This is what I referred to as the multiplexing issue. I hope 
> I explained
> it better this time for you. 
> 
> Anyway, I'll submit a personal draft to help the discussion, 
> although the 
> above example should make it obvious already.
> 
> Zhigang
> 
> 
> > -----Original Message-----
> > From: ext Lars-Erik Jonsson (EAB)
> > [mailto:[email-masked]]
> > Sent: March 27, 2003 2:18 AM
> > To: Liu Zhigang.C (NRC/Dallas)
> > Cc: [email-masked]
> > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary 
> content SIP
> > messages
> > 
> > 
> > Zhigang,
> > 
> > > My question is the handling of binary content in application 
> > > messages. In my view, this is a generic issue although it started
> > > with SIP. My thought was to have a *separate* document that
> > > addresses this issue (and perhaps other generic SigComp "bugs" if
> > > we find out).
> > 
> > First of all, it is not yet clear to me that this is a 
> general issue,
> > at least I have not been able to see consensus on that. Secondly, if
> > we have general unclear issues with SigComp, those would go into the
> > Implementer's guide at this point.
> > 
> > Currently, I therefore think we can and should avoid having 
> even more
> > documents.  However, you can always provide input by 
> writing a draft,
> > that is up to you.
> > 
> > Regarding the SigComp&SIP document, it does not matter much
> > in which WG it is "hosted", as long as it is written and well 
> > reviewed 
> > by people from both sides.
> > 
> > 
> > Rgds,
> > /L-E 
> > _______________________________________________
> > 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: Carsten Bormann <[email-masked]>
Date: Fri, 28 Mar 2003 16:24:13 +0100

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