Re: [rohc] Making SigComp recognizable

["Miguel A. Garcia" <[e-mail]>]

"Dr. Carsten Bormann" wrote:
> 
> 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.

<miguel>

So why do you want to make packets recognizable?

</miguel>

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

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

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

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

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

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

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

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[e-mail]     Phone:  [phone]
mailto:[e-mail]        Mobile: [phone]

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