Subject: [rohc] A question about profile definition scheme in ROHC

From: "Wang Haiguang" <[email-masked]>
Date: Thu, 12 Dec 2002 13:09:12 +0800

Hi, all.

In RFC3095, profiles such as IP/UDP/RTP  are defined to compress/decompress the headers in various conditons such as IP-tunneling,
IPv6 extension headers etc. 

My questions is:

Did anybody consider the possibility of define a profile for each protocol and use them together to compress/decompress the headers in a 
stream?

For example, we define profiles for IP, UDP and RTP separately, when compress/decompress the IP/UDP/RTP packets, we just use the profiles to compress/decompress the relatvie headers. Thus we don't need to take too much care about the ip-tunneling and also don't need to define a separate IP/UDP profiles.

Best regards.

Wang Haiguang

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

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 16 Dec 2002 10:04:21 +0100

Wang,

> My questions is:
> 
> Did anybody consider the possibility of define a profile for 
> each protocol and use them together to compress/decompress 
> the headers in a stream?

Of course we did. But not seriously, for various reasons, e.g.:
1) It is more efficient (compression wise) to compress all headers
   together, which is something that was observed in the early 
   header compression works (read 1144, 2507, 2508).

2) It would be useless to have a UDP-only profile, better then
   to define it as IP/UDP (IP is always on top of UPD).

3) There must be a way to initiate compression, i.e. to indicate
   in initial packets the type of compression used. To optimize
   compression performance, it is desirable to minimize the size
   of the profile identifier(s), and one single identifier has
   the advantage of minimizing the overhead, and complexity.

4) One will have to consider the combination of headers when
   defining compression. We have for example noticed that IP
   compression introduces issues that are different than when
   we considered the combination of IP and UDP.

5) We have shown that we can easily add things to an existing
   profile by defining an extension, and allocate a new profile
   ID for the combination (although we will of course never do 
   that without a good motivation for doing such work).

Anyway, this discussion is irrelevant at this point in time,
because we already have the profile concept established. We 
also have the most important profiles already defined, and we
are concentrating at verifying that everything works as intended.

BR
/Lars-Erik