rohc team mailing list archive

[faraz iqbal <faraz4557@xxxxxxxxx>]

Hi Didier
              With the reference of below discussion. I agreeded with your answer for question.

I noticed that ROHC behaviour is different for different traffic pattern. For example 
a/ it was more robust for a periodic traffic pattern. On the other hand, less robust for burst (VOIP) pattern.
b/ Mode is O-mode, with out periodic update but compressor send IR header for a queue time out (beyond 30 sec) at compressor end with out recovery request from de-compressor.
c/ Notice feedback recovery message at a latency of more than 30 sec for decompression failure.
e/ losing N packets in a row cause more damage.

  Please comment for b and c.

Thanks & Regards


Faraz


________________________________
 From: Didier Barvaux <didier@xxxxxxxxxxx>
To: ROHC Library <rohc@xxxxxxxxxxxxxxxxxxx> 
Sent: Sunday, March 24, 2013 11:38 AM
Subject: [Rohc] ROHC robustness (Was: Re:  Fw:  Linux kernel support)
 
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

_______________________________________________
Mailing list: https://launchpad.net/~rohc
Post to     : rohc@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~rohc
More help   : https://help.launchpad.net/ListHelp