Subject: [rohc] Making SigComp recognizable

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Tue, 26 Feb 2002 02:29:03 +0100

In a phone conversation today, it occurred to us that it would be a good
idea to make SigComp packets clearly distinguishable from uncompressed
packets.
For SIP, this is easy, as all methods and reply codes are ASCII, so setting
the MSB in the first byte of all packets would suffice.
However, it's probably a good idea not to trigger the link-layer RTP ROHC
heuristics, which tend to look for 10xxxxxx in the first byte (RTP V=2) of
UDP packets.
More generally, I think we want to cater for general UTF-8-based signalling
protocols. Looking at RFC2044, we have:

   UCS-4 range (hex.)           UTF-8 octet sequence (binary)
   0000 0000-0000 007F   0xxxxxxx
   0000 0080-0000 07FF   110xxxxx 10xxxxxx
   0000 0800-0000 FFFF   1110xxxx 10xxxxxx 10xxxxxx

   0001 0000-001F FFFF   11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
   0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   0400 0000-7FFF FFFF   1111110x 10xxxxxx ... 10xxxxxx

Now, since RFC2044 (October 1996), Unicode has been decided to stop at 0010
FFFF, so the code combinations

   0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   0400 0000-7FFF FFFF   1111110x 10xxxxxx ... 10xxxxxx

never can appear in real UTF-8.

Leaping to a conclusion, it seems a SigComp/UDP packet should start with

	11111xxx

Sigcomp-04 uses 0xFF as an escape character, so xxx=111 should probably also
be avoided.
Alternatively, we could simply define a single byte distinguisher for UDP
and start all TCP streams with the escape sequence (and not use the UDP
distinguisher here).

Any other things we should avoid?  General comments on the whole approach?
(I just wish UDP had a protocol field.)

Gruesse, Carsten

PS.: Anyone for defining an RFC2246 (TLS) CompressionMethod value for
SigComp?
Should be fun, and would save the 0xFFFFs.
Can't even find an IANA registry for TLS, though.

PPS.: RFC2817 section 1 (motivation) is interesting reading.
Has anyone implemented that spec?
Could be done for SIP, too.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Allison Mankin <[email-masked]>
Date: Mon, 25 Feb 2002 20:40:00 -0500

> Can't even find an IANA registry for TLS, though. 

There isn't one now, but the IESG discussed it, and I think
perhaps it is a subject for RFC2246bis, of which an i-d has
just come out.

Allison

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 27 Feb 2002 10:40:20 +0200

Hi Caster:

So, if I understand correctly, the discussion here is about two possibilities:

a) SigComp is listening to the same port number than the application (e.g., 5060 for SIP)
b) SigComp is listening to a different port number than the application.

So far, my understanding is that SigComp is a shim layer that is reused by 
many applications that are running on the same host. As such, the SigComp
layer software is used by SIP, HTTP, RTSP, etc.

Therefore, I see that if the SigComp layer should not be aware of the 
parsing rules of any protocol running on top. I wouldn't like to see
SigComp parsing message to distinguish whether they are SIP, HTTP or RTSP.
And I would like to use a shim layer that I can instantiate per application.
That's why my assumption was always that SIP/SigComp will be listening to
a determined port number, HTTP/SigComp will be listening to another, and so on.
Those port numbers are different than the respective non compressed applications.

Further more: SigComp-04 specifies a SigComp negotiation mechanism and UDVM
upload. These are SigComp related mechanisms that have nothing to do with 
the compressed protocol carried in the payload.

Option a above is a very bad design choice. Multiplexing two different
protocols into the same port number, just because it happens that one of
the protocols carries payload of the other, it is IMHO, a bad design
decision. It implicitly requires that the "shim" layer is heavily integrated
into the application. This prevents me to design a shim layer that is reusable
by many application protocols.

As an example, somebody could argue that why don't we send SIP messages to
port number 25 (SMTP). They are all both text messages, so, why do we need
port numbers to differentiate the protocol???

I would like to have a deterministic way to trace messages in a network,
and see by the destination port number whether the message is compressed
or not, and whether the message is syntactically correct or not.

My suggestion, humble though, is to keep the assumption that SigComp is a 
protocol by itself, and it has to be identified by a port number, different
from the port number of the application that is carried within SigComp 
(option b). Note that there is not need to standardize a well know port
number for SigComp. We can rely on NAPTR/SRV in DNS to do this job.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 28 Feb 2002 00:05:21 +0100

Miguel,

I wasn't even talking about port numbers.
Making compressed packets recognizable might be used in lieu of other
multiplexing, but it does not preclude using other multiplexing.

> layer software is used by SIP, HTTP, RTSP, etc.

I believe this is the general consensus in the WG (although HTTP may be
stretching "signaling" a bit).

> SigComp parsing message to distinguish whether they are SIP, HTTP or RTSP.

I believe that compressors and/or user dictionaries might well want to be
aware of the specific protocol being used.
SigComp the protocol (and the decompressor UDVM) should not have to, I
agree.

> And I would like to use a shim layer that I can instantiate per

I'm not sure if you are saying this on a conceptual level or on an
implementation level.
On an implementation level, you do need a little help from the application
to decide whether to grant state establishment requests or not.
So there already is a slightly tighter coupling between SigComp and
application than we originally thought.

> Those port numbers are different than the respective non

This is one way of doing the multiplexing.
SigComp is currently neither precluding nor specifically supporting this
way.

> Option a above [sharing a port] is a very bad design choice. Multiplexing
two different
> by many application protocols.

I'm sure there are ways for a modular implementation even in the absence of
port number multiplexing.
SigComp could be a library; it could be a separate process ("proxy"-style).

> port numbers to differentiate the protocol???

SIP messages and SMTP messages go to different applications.
SIP-uncompressed and SIP-compressed messages go to the same app.

> or not, and whether the message is syntactically correct or not.

I'm all for self-describing packets [insert my usual lament about UDP not
having protocol identifiers here].
As you don't necessarily know the port usage of an end-system in a monitor,
this is one more reason to make SigComp packets recognizable from
uncompressed packets.
(For a monitor, you would want to have a more distinguishing signature.  I
was not arguing for that simply to save bytes.)

> number for SigComp. We can rely on NAPTR/SRV in DNS to do this job.

Now this is actually an interesting discussion, which is going beyond the
charter of ROHC alone.
Remember that compressed vs. uncompressed is not the only parameter here, we
also have secure vs. non-secured.
I don't believe we can completely solve the general SIP variant discovery
problem in time for 3GPP R5, so it seems prudent to cater for as many
possible outcomes as possible.

Making SigComp packets recognizable comes at a cost of 5 bits (if my
proposal works right).
A small price to pay for more future flexibility.

Gruesse, Carsten

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 28 Feb 2002 10:07:13 +0200

> multiplexing, but it does not preclude using other multiplexing.

<miguel>

So why do you want to make packets recognizable?

</miguel>

> application than we originally thought.

<miguel>
I was thinking of an application that instantiates a SigComp layer 
optimized (e.g., dictionaries loaded) for that particular application.
The SigComp code is still the same. It is just invoked with certain
parameters to load certain dictionaries.

I agree with you that there is a need for an API between the SigComp
layer and the application. That is an internal API and we don't need
to mention here in ROHC, although somebody could write an informational
internet draft with a suggested API (like it happened with SCTP).

</miguel>

> SigComp is currently neither precluding nor specifically supporting this

<miguel>

Ok, so then my question comes back, why is there a need to differentiate
the SigComp messages from others, if we can differentiate them by the port
number?

</miguel>

> SIP-uncompressed and SIP-compressed messages go to the same app.

<miguel>
I disagree. This is a fundamental difference between our visions. SIP uncompressed
and SIP compressed EVENTUALLY reach the same application. But, just eventually.
SIP-Compressed messages can't be treated by the SIP layer without any help from
the SigComp layer. It does not matter whether the message is, at the end of the
day, received by the same applicaiton layer. If it was compressed, that layer 
is not able to do anything with it.

SigComp also defines some negotiation mechanisms that have nothing to do with
the application layer. SigComp is a protocol per se.
</miguel>