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
signature.asc
Description: PGP signature
_______________________________________________ Mailing list: https://launchpad.net/~rohc Post to : [email protected] Unsubscribe : https://launchpad.net/~rohc More help : https://help.launchpad.net/ListHelp
