Re: [rohc] Making SigComp recognizable

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

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


"Dr. Carsten Bormann" wrote:
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc

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