RE: [rohc] Making SigComp recognizable

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.

> 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.

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

> 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.

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
> application.

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.

> 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.

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
> 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.

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).

> 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???

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

> 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.

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.)

> 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.

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

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc