rohc team mailing list archive

[Didier Barvaux <question671329@xxxxxxxxxxxxxxxxxxxxx>]

Question #671329 on rohc changed:
https://answers.launchpad.net/rohc/+question/671329

    Status: Open => Answered

Didier Barvaux proposed the following answer:
Hello Fatih,

> In order to answer those, could you provide me any support with a more
> explanatory tutorial about the states, profiles and modes of ROHC?

The ROHC protocol defines 3 modes of operations: one for unidirectional communication links (Unidirectional Mode), and 2 for bidirectional communication links (Bidirectional Optimistic Mode and Bidirectional  Reliable Mode):
* The U-Mode does not use feedback from decompressor to compressor, so it is simpler. It might also be a little less efficient because it has to repeat every change several times in a row in order to be robust to packet loss on the network link. 
* The O-mode does use feedback to report success or failures from the decompressor to the compressor. It might therefore be more efficient than U-Mode while ensuring the same robustness to packet loss. However its configuration is less simpler than U-mode since you might need to tweak the feedback parameters.
* The R-mode is similar to the O-mode, but with stricter rules to ensure even more robustness than O-Mode. More robustness means also less compression efficiency than O-mode.

To go further, please read:
* There is a short presentation on the website: https://rohc-lib.org/presentation/rohc-protocol/#modes-of-operation
* The RFC3759 explains some terms used by the ROHC protocol : https://tools.ietf.org/html/rfc3759
* The RFC3095 defines the modes of operations too: https://tools.ietf.org/html/rfc3095#section-4.4

Choosing the best mode of operation depends on your use case. In case of
doubt, start with the U-Mode (Unidirectional Mode), it is simpler to
use.


The ROHC profiles are just methods to compress a stream. The RTP profile is a standardized way to compress a flow of IP/UDP/RTP packets that share some properties. Every ROHC profile defines a way to compress the network headers of the corresponding flow. The UDP profile defines how to compress the IP header and the UDP header. The RTP profile defines how to compress the IP header, the UDP header and the RTP header.


The ROHC states defines the level of compression that is used for a network stream. When a new stream is compressed, the compressor shall send many information to the decompressor to initiate the stream. This is called the "Initialization & Refresh (IR)" state. When the stream compression is initialized, the compressor may transit the 2nd state. In that 2nd state, the compressor is allowed to compress more information or even to not transmit it anymore at all. This is possible because the decompressor received the information and recorded it. The decompressor then uses the recorded information to decompress the next packets. If the stream of packets becomes regular (ie. header fields evolve as expected), the compressor transits to the 3rd state. In that 3rd state, the compressor generally transmits only the stream identifier and the change of the sequence number since last packets.


> Also, the example applications are insufficient to clearly see what it is. They just contain
> one packet compression and decompression. So, could you provide me any example code
> or software design documents to aim at compressing and decompressing many more
> packets including mode, state transitions with respect to each profile including NACK
> conditions and retransmission.

Beside the "getting started" tutorial (https://rohc-lib.org/presentation
/getting-started/) and the sample code found the examples/ subdir in the
sources (https://github.com/didier-barvaux/rohc/tree/master/examples),
there is the detailed documentation of the library API: https://rohc-
lib.org/support/documentation/#library-api

There are several applications that you might look at:
* ROHC sniffer: https://rohc-lib.org/wiki/doku.php?id=rohc-sniffer
* ROHC stats: https://rohc-lib.org/wiki/doku.php?id=rohc-stats

There is also the non-regression test application, located in the
test/non_regression/test_non_regression.c source file, that might help
you understand how the ROHC library works. See the beginning of the
source file for the description of the test application:
https://github.com/didier-
barvaux/rohc/blob/master/test/non_regression/test_non_regression.c#L20


> Because, I still do not know how and when to manage mode and state transitions
> for each profile in case of both successful and unsuccessful decompression?

The ROHC library is in charge of that:
* You choose a target mode at the beginning when you create a ROHC decompressor (see the "mode" parameter of https://rohc-lib.org/support/documentation/API/rohc-doc-2.2.0/group__rohc__decomp.html#ga329c76eacc4036190e7cd680d2d4f6b3), then the library handles the needed transitions alone.
* You don't have to change the state manually. Every network stream starts in IR state and transits alone in upper states according to positive/negative feedbacks.

> Also, you can lead me to grasp when to leave IR state after how many packets
> have been sent. Is only one packet enough to leave that?

The number of transmitted packets required to leave the IR state is not defined by the ROHC protocol. It is left to the implementation.
* Up to version 2.2.0, the ROHC library does not allow to dynamically configure that value. It is defined by MAX_IR_COUNT in sources, see https://github.com/didier-barvaux/rohc/blob/master/src/comp/rohc_comp_internals.h#L64).
* Starting with the upcoming 2.3.0 release, the value may be dynamically configured with the new rohc_comp_set_optimistic_approach() API function (see https://github.com/didier-barvaux/rohc/blob/dev_be_more_robust_to_pkt_loss/src/comp/rohc_comp.c#L1975).


Regards,
Didier

-- 
You received this question notification because your team ROHC Team is
an answer contact for rohc.