Subject: [rohc] ROHC compression ratio

From: Jürgen Quittek <[email-masked]>
Date: Wed, 30 Jul 2003 10:11:44 +0200

Hi all,

These is questions on the compression ratio were raised by Mike Heard
when he reviewed the ROHC MIB:

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

-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

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

---

From: Alan Kennington <[email-masked]>
Date: Wed, 30 Jul 2003 18:46:06 +0930

> 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