rohc team mailing list archive

[Didier Barvaux <didier@xxxxxxxxxxx>]

Hi,

>     I am Msc (ICT) student in final year at University of Agder ,
> Norway.  I am doing thesis work on ROHC based Linux router (vyatta).
> My task is to analyze the ROHC performance for one hop/multihops
> Adhoc nodes. I have linux based routers with ROHC implemented.

I didn't know that vyatta put the ROHC library in their software. I
found nothing about ROHC on http://vyatta.org/. Am I looking at the
right place?


> For a real scenario testbed  i have added Netem queue at the
> compressor outgoing interface and add loss, delay etc parameters. In
> this case i observed the behavior at de-compressor end.
> 
> Observation: 
> 1. Beyond 46% loss (netem root queue), de-compressor send error
>    recovery compressed message to compressor and then compressor send
>    full header.
> 2. When de-compressor missed 30 or more then 30 packets
>    then it send error recovery request to compressor.
> 
> Questions
> 1. How much loss (percentage) for which ROHC is robust.?

There is no absolute answer. That depends on several things:
 a/ the kind of traffic you're compressing: ROHC on a very regular
    stream (= packets with headers that don't change much) will be more
    robust to network loss than a stream with big changes.
 b/ the ROHC mode in which you run: U-, O-, or R-mode.
 c/ your network latency when feedbacks are used to report
    decompression failures.
 d/ the parameters used for ROHC: the widths of the W-LSB windows, the
    context refreshes timeouts...
 e/ the kind of network loss you emulate: losing N packets in a row
    will probably cause more more damage than losing 1 packet N times.

For example, if your traffic is a single IPv4/UDP stream with constant
IP-ID, the robustness should be quite important: if N packets are lost
in a row between the compressor and the decompressor, the decompressor
should not fail to decompress the next packets. If not, tell me, there
is perhaps a problem with your test and/or with the ROHC library.


> 2. Sometime compressor sends full header at packet loss instant
>    without error recovery request  from de-compressor.

Difficult to say without more information. One possible hypothesis is
that the compressor decided it was time for periodic refresh of the
context. In such a case the compressor goes back to a lower compression
state (IR or FO) to send more information to the decompressor.

Regards,
Didier

Attachment: signature.asc
Description: PGP signature