Size of compressed packets in ROHC tunnel

Hello,

> I'm working on some experiments with the ROHC library
> and i'm little confused about the utilization of ROHC tunnel.
> I tried to send some icmp (ping) packets from host A to
> host B, using ROHC tunnel. The pings worked fine and I get
> the responses but looking for my captures in wireshark on
> my switch (between hosts A and B), I noticed that the ROHC
> frames were bigger than the originals icmp packets. I think
> that's because ROHC tunnel uses a UDP encapsulation, isn't it?

Yes, it is.

> Only for information, the originals icmp packets have 98 bytes
> lenght and the packets in ROHC tunnel have 109 bytes (the
> majority malformed packets).

If ICMP packets are 98-byte length, then they one 20-byte IPv4 payload and one 78-byte payload (ICMP header is not compressed by ROHC, so I count it as payload).
The 20-byte IPv4 header may be compressed at best to 1 byte. So, we have a 79-byte ROHC packet.
Then we have to add tunnel overhead: the 20-byte IPv4 header, the 8-byte UDP header and a 2-byte packet counter, ie. 79+20+8+2 = 109 bytes.

> Doing a similiar experiment with voip packets (udp/rtp) in a ROHC tunnel.
> Will I see bigger packets too?

RTP packets are much more compressed: the 20-byte IPv4 header, the 8-byte UDP header and the 12-byte RTP header may be compressed up to 1 byte. We thus saves 39 bytes per packets. The tunnel adds 20+8+2=30 bytes of overhead. So, you should see smaller packets.

On a side note: you seem to expect some performance gain from the ROHC tunnel, but you shouldn't. The ROHC over UDP tunnel was not created for that purpose. It was created for testing purpose: send ROHC-compressed traffic from one machine to another and watch how the compression behaves. The UDP encapsulation is not designed for efficiency but for ease of use. You might consume more bandwidth with the ROHC over UDP tunnel than without. If you seek efficiency, have a look at the [IP/ROHC tunnel](http://rohc-lib.org/wiki/doku.php#ip_rohc_tunnel).

Regards,
Didier

Hello again,

I have just decided to deprecate the ROHC over UDP tunnel. I don't use it for testing for a long time. I now use the sniffer and fuzzer tools for that. They are much better. For the tunnel features, the IP/ROHC tunnel now supersedes the ROHC over UDP tunnel: the IP/ROHC tunnel is designed for efficiency and may be used in production.

So, next 1.7.0 version of the ROHC library will still contain the ROHC over UDP tunnel but a deprecation warning will be present in the wiki, in the sources, in the configure script, in the program usage, and in the program man page. The version after will completely remove the ROHC over UDP tunnel from the sources.

Regards,
Didier

Deprecation commit: http://bazaar.launchpad.net/~didier-barvaux/rohc/main/revision/1017
ROHC over tunnel (deprecated): https://rohc-lib.org/wiki/doku.php#rohc_over_udp_tunnel
IP/ROHC (replacement): https://rohc-lib.org/wiki/doku.php#ip_rohc_tunnel

Hi Didier,

Thank you for your explanation. I'll take a look in the IP/ROHC tunnel.
I discovered that the rohc tunnel over ethernet can give me better results
than UDP one.

In my lab, I'm trying to create a ROHC tunnel between two Openflow (OF)
switches. My topology is linear (2 hosts and 2 switches):

Host A <-------> Switch 1 (S1) <--------> Switch 2 (S2) <-------> Host B

I'm using two PCs for the OF switches, each one with two ethernet cards
(eth0 and eth1).
I'm using the eth1 of S1 and eth1 of S2 to connect both switches.

On both switches, I created the rohc0 virtual interfaces (associated with
eth1) and attached them to the openflow switch.
The switches are prepared to forward L2 frames and they work fine with icmp
packets (pings) from host A to host B, when I'm not using the ROHC tunnel.

When I tried to ping Host B (from Host A), using the ROHC tunnel, I see the
following:
1- The first switch S1 received ICMP the packets;
2- The packets are forwarded to S1's rohc0 interface. All ARP packets are
compressed;
3- The ROHC (compressed) packets arrived at S2 through eth1 but not reach
rohc0 (of S2);
4- The S2's decompressor didn't see any ROHC packet;

The major question is that using switches I can't attach interfaces with
associated ip address. So my rohc tunnel doesn't have any ip address
associated. I think that's the problem of my experiment.

Do you have any idea about how can I make the rohc tunnel using switches?

Thanks in advance!

Edvar

2014-03-23 11:36 GMT-03:00 Didier Barvaux <
<email address hidden>>:

> Your question #245813 on rohc changed:
> https://answers.launchpad.net/rohc/+question/245813
>
> Didier Barvaux posted a new comment:
> Hello again,
>
> I have just decided to deprecate the ROHC over UDP tunnel. I don't use
> it for testing for a long time. I now use the sniffer and fuzzer tools
> for that. They are much better. For the tunnel features, the IP/ROHC
> tunnel now supersedes the ROHC over UDP tunnel: the IP/ROHC tunnel is
> designed for efficiency and may be used in production.
>
> So, next 1.7.0 version of the ROHC library will still contain the ROHC
> over UDP tunnel but a deprecation warning will be present in the wiki,
> in the sources, in the configure script, in the program usage, and in
> the program man page. The version after will completely remove the ROHC
> over UDP tunnel from the sources.
>
> Regards,
> Didier
>
> Deprecation commit:
> http://bazaar.launchpad.net/~didier-barvaux/rohc/main/revision/1017
> ROHC over tunnel (deprecated):
> https://rohc-lib.org/wiki/doku.php#rohc_over_udp_tunnel
> IP/ROHC (replacement): https://rohc-lib.org/wiki/doku.php#ip_rohc_tunnel
>
> --
> You received this question notification because you asked the question.
>

> Thank you for your explanation. I'll take a look in the IP/ROHC tunnel.
> I discovered that the rohc tunnel over ethernet can give me better results
> than UDP one.

The IP/ROHC tunnel does not use UDP, but raw IP packet. Overhead is therefore smaller.

The ROHC over Ethernet tunnel got an even smaller overhead if you use end-to-end Ethernet links. That's OK on a LAN (with no IP router involved) or on some rare WAN with Ethernet as a convergence layer.

> In my lab, I'm trying to create a ROHC tunnel between two Openflow (OF)
> switches. My topology is linear (2 hosts and 2 switches):
> [...]
> The major question is that using switches I can't attach interfaces with
> associated ip address. So my rohc tunnel doesn't have any ip address
> associated. I think that's the problem of my experiment.

If you specified "ethernet" as type for the rohctunnel application, you have specified a destination MAC address. Did you specified the MAC address of the eth1 interface of S2 ?

A network capture of the traffic between S1 and S2 could help you diagnose the problem. Check the Ethernet addresses.

Please check if eth1 is not part of a Linux bridge. That might explain that packets cannot be retrieved by the rohctunnel app.

Regards,
Didier

Hi Didier,

I managed to adapt the rohc tunnel (ehernet) with my openflow switch. It´s working fine and the major question was that i had to use the linux kernell to inject packets into the rohc tunnel. Thanks for your help.

Now, I´m working in another issue... I´m trying to modify the destination mac address of the outcoming compressed packets, using the ethernet rohc tunnel app.
To achieve this, I think the way is modify the rohc code. Do you know if is it possible to implement this idea without modify several parts of the code?

1- A packet (P1), with destination MAC address X, is sent out to the roch0 interface. This rohc0 interface is associated with eth1 interface whose mac address is Y;
2- Normaly, P1 is compressed and the roch packet is sent with Y destination mac address;
3- Is it possible to send the compressed roch packet with X destination Mac address instead of Y? Is it hard to modify the code this way?

P.S.: For the decompressor recognize the rohc packet, I have a tool that change the mac address again to the Y (eth1 interface) before the packet reach the decompressor;

> 3- Is it possible to send the compressed roch packet with X destination
> Mac address instead of Y? Is it hard to modify the code this way?

The 'remote' parameter does exactly that:
  # rohctunnel rohc0 ethernet remote 01:02:03:04:05:06 local eth1

Regards,
Didier

Thanks Didier, but i think my previous explanation wasn't complete.

My goal is to dynamically change the destination or source mac address of the rohc packets. For example, despite a ethernet rohc tunnel have been created with remote mac address X, I would like that a packet P1 be compressed and sent through the rohc tunnel with destination mac address Y. Another packet P2, arriving at the same rohc tunnel, be compressed and sent with destination mac address Z.
The numbers Y and Z could be the original mac address of P1 and P2, a function parameter to the rohc tunnel app or a number previous registered in a memory address.
Like I said before, I have a tool to change the mac address of rohc packets (to the original one, X) before they arrive the decompressor.

Thanks in advance for any help.
Regards, Edvar

Thanks Didier Barvaux, that solved my question.

Hello,
 In my academic project i'm applying some wan optimization techniques with SDN. (I'm using Floodlight controller with mininet virtual topology). Now that i have arrived to compression, i would like to ask you some questions.

i want to do something like this:
Host A <-------> OpenFlowSwitch(S1) <----anything----> OpenFlowSwitch(S2) <-------> Host B
i want the compression/decompression to be on the switches level(S1,S2) and not on hosts.

1) How do i create virtual interfaces rohc0 between the switches? I am confused because the installation and configuration here is done on hosts and not the switches http://rohc-lib.org/wiki/doku.php?id=rohc-tunnel
2) Is there a specific advantage for doing ROHC using the centralized control provided by SDN ?
3) Are there any specific requirements for the switches to support ROHC ?

sorry for these questions as i'm new this environment. Thanks in advance.

Johnny

Johnny,

> 1) How do i create virtual interfaces rohc0 between the switches?
> I am confused because the installation and configuration here is done
> on hosts and not the switches http://rohc-lib.org/wiki/doku.php?id=rohc-tunnel

If your OpenFlow switches are Linux or Unix compatible, then it will work.

Note that the ROHC tunnel tool will be soon deprecated (with release 1.7.0), then removed with next release (2.0.0). Don't use it for a long term setup.

> 2) Is there a specific advantage for doing ROHC using the centralized
> control provided by SDN ?

Maybe for setting ROHC parameters, or for defining RTP stream detection?

> 3) Are there any specific requirements for the switches to support ROHC ?

The ROHC library works on any Linux. There is no dependency on external libraries except libc.

Regards,
Didier

Thank you very much for your help Didier Barvaux!

Johnny