Subject: RE: [rohc] ROHC compression ratio

From: Remi Pelland <[email-masked]>
Date: Wed, 30 Jul 2003 09:41:52 -0400

Alan,

I used your IR packet to validate my parsing algorithm, and I found that in
the RTP part of the dynamic context an empty Generic CSRC List is present
although the associated CC field is 0.  Section 4.3.3 of the Implementer's
Guide says that when the CC field is 0, the Generic CSRC List is not
included in the dynamic chain.

Salut,
Remi.

-----Original Message-----
From: Alan Kennington [mailto:[email-masked]]
Sent: Wednesday, July 30, 2003 5:16 AM
To: Jürgen Quittek
Cc: ROHC mailing list; Alan Kennington
Subject: Re: [rohc] ROHC compression ratio

On Wed, Jul 30, 2003 at 10:11:44AM +0200, Jürgen Quittek wrote:
> 
> Is there a theoretical proof that compressed headers are always
> shorter than uncompressed ones (for the already standardized profiles)?
> 
> If not, is there a theoretical limit of how much a compressed
> header can exceed the size of an uncompressed one?

Juergen,

Individual compressed packets are often larger than the original IPv4
packet.
I see this often when I am sending IR packets in ROHC RTP profile 0x0001.

Here is an example from one of my packet logs:

===============================================================
TX context: CID=5 profile=1 mode=U trans=D tss=44960 RND=1 NBO=1 rtype=IR
ROHC packet type=IR CRC=0xf3
IP version=4 protocol=17(UDP) IP src=192.168.0.1 IP dst=192.168.0.2
UDP src=5060 UDP dst=5000 SSRC=0x3afc4712
TOS=0x00000010 TTL=64 IP-ID=0x0000 DF=1 RND=1 NBO=1
Extn header list: ET=0 GP=0 PS=1 CC=0 UDP-CS=0x757d
RTP: V=2 P=0 RX=1 CC=0 M=1 PT=0x03 SN=0x9030(36912) TS=0x0000b040(45120)

ROHC packet length = 178 octets.
ROHC=0005 fd0501f3 4011c0a8 0001c0a8 000213c4 13883afc 47121040 0000e010
757d908
3 90300000 b0401007 c0afa000 d820a2e1 5a500049 24924924 50004924 92492450
004924
92 49245000 49249249 24d820a2 e15a5000 49249249 24500049 24924924 50004924
92492
450 00492492 4924d820 a2e15a50 00492492 49245000 49249249 24500049 24924924
5000
4924 924924d8 20a2e15a 50004924 92492450 00492492 49245000 49249249 24500049
249
24924

IPv4 packet length = 174 octets.
IP=0021 451000ac 00004000 4011b8dd c0a80001 c0a80002 13c41388 0098757d
80839030 
0000b040 3afc4712 d820a2e1 5a500049 24924924 50004924 92492450 00492492
49245000
 49249249 24d820a2 e15a5000 49249249 24500049 24924924 50004924 92492450
0049249
2 4924d820 a2e15a50 00492492 49245000 49249249 24500049 24924924 50004924
924924
d8 20a2e15a 50004924 92492450 00492492 49245000 49249249 24500049 24924924
===============================================================

Normally only IR packets will be larger than the corresponding IPv4 packets.
The "negative compression" can be larger than 4 bytes if you have a CSRC
list or some other kinds of context set-up.
There is a limit to the "negative compression" size difference, but
I don't know what it is. Perhaps it is about 20 or 24 octets maximum,
maybe a bit more. 
I think it would be difficult, but not impossible, for a UOR-2 or IR-DYN
packet to be larger than the original IP packet.

This is, of course, a big issue for implementers who have to keep within
the MTU for a PPP interface for example. If the "negative compressed"
packet is larger than the MTU, it may be rejected by the decompressor end
of the link. This is rare for RTP because RTP packets are usually small.
But I imagine that this happens very often for plain UDP and plain IP.
To fix this problem, you need to set the MRU about 24 bytes or so larger
than the MTU which the IP layer sees.
You can see that if UDP packets are sent out with size equal to the MTU,
then all of the "negative compressing" IR packets will be lost by the RX
side
if the MRU equals the MTU of the TX side. Therefore the context will never
be established, and communication will be impossible.

Cheers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
 website: http://www.topology.org/
    city: Adelaide, South Australia
  coords: 138.59 E, 34.88 S
timezone: UTC+0930 http://www.topology.org/site/timezone.html
 pgp-key: http://www.topology.org/ak/key_ak2.asc
    note: My e-mail address often changes due to spam abuse.
        : If your e-mail bounces, please visit topology.org/extra/email.php

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

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

---

From: Alan Kennington <[email-masked]>
Date: Wed, 30 Jul 2003 23:59:21 +0930

> included in the dynamic chain.

Remi,

Well, that's delightful. That's the first time anyone's checked the
correctness of my encoding.

Now the ROHC implementer's guide, version 3, part 4.3.1, says

===================================================
   The generic extension header list starts with an octet that is always
   present, so its length is one octet, at least.  If the 'GP' bit in
   the first octet is set to 1 then the length of the list is two
   octets, even if the list is empty.
===================================================

Then section 4.3.2 says:

===================================================
   Section 5.7.7.6 defines the static and dynamic parts of the RTP
   header.  This section indicates a 'Generic CSRC list' field in the
   dynamic chain, which has a variable length.  This field uses the same
   encoding rules as the 'Generic extension header list' in the IPv4
   header, so the same rules apply to its length.
===================================================

This seems pretty clear to me - the CSRC list must have at least 1 octet
even if CC equals 0.

Hmmm. Then this is contradicted in 4.3.3 of the implementer's guide:

===================================================
   Section 5.7.7.6 defines the static and dynamic parts of the RTP
   header.  In the dynamic part, a 'CC' field indicates the number of
   CSRC items present in the 'Generic CSRC list'. It should be noted
   that when the value of this CC field is equal to zero, there is no
   Generic CSRC list present in the dynamic chain, i.e. the field
   comment should have said "variable length, present if CC > 0". A 'CC'
   field can also be found within the 'Generic CSRC list' (when
   present), and these fields would then have the same meaning. In order
   to decode a compressed packet correctly it's necessary to know the
   'CC' value because it has serious impact on the packet's length.  In
   normal case, the values of the fields are equal.

   Proposed behavior if the values are different:
      Both fields are within the RTP dynamic part but only the second
      'CC' field resides inside the 'Generic CSRC list' together with
      the XI items.  Since the 'CC' value determines the number of XI
      items in the CSRC list and isn't used otherwise, the first CC
      field should be ignored and only the second field (inside the CSRC
      list) should be used for incoming packets.  For outgoing packets
      both fields should be set to the same value.
===================================================

So this means that if CC == 0, then the CSRC list is not present.
This is very confusing. It seems to me that even the "clarifications"
in the Implementer's guide might be contradictory.

So what is the real answer?

Salut aussi,
Alan Kennington.

--------------------------------------------------------------------
     nom: Dr. Alan Kennington
 website: http://www.topology.org/
   ville: Adelaide, Australie Me'ridionale
  coords: 138.59 E, 34.88 S
zone UTC: +0930 http://www.topology.org/site/timezone.html
clef-pgp: http://www.topology.org/ak/key_ak2.asc
    note: Mon adresse de courriel se change souvent a` cause du spam.
        : Si votre courriel bounce, visiter SVP topology.org/extra/email.php

---

From: Alan Kennington <[email-masked]>
Date: Thu, 31 Jul 2003 08:38:31 +0930

Remi,

Since you were able to test interoperability of my single packet
using a hex dump over the e-mail, this makes me think of an extension of
this idea. For people like me who do not have a big travel budget,
it would be possible to test interoperability by using "ROHC over UDP/IP".
In other words, instead of putting ROHC PDUs in L2 packets, we could
define UDP/IP as a kind of link layer substitute.
Then we could all test interoperability of our ROHC implementations
every day over the net.

I guess that one little problem with this is the packet ordering guarantee,
but this can be fixed by adding sequence numbers to all ROHC packets and
inserting a small delay on the RX side to re-order packets - or else out-of-
order packets could be discarded. I guess jitter could be rather high.

But certainly "ROHC over UDP/IP" would give a better assessment of
interoperability than exchanging hex dumps over e-mail.
A really crazy person could define "ROHC over SMTP", I guess.
(This reminds me of Carrier Pigeon IP:
http://www.ietf.org/rfc/rfc1149.txt?number=1149
http://www.blug.linux.no/rfc1149/ )

Cheers,
Alan Kennington.