Re: [Rohc] rohc performance on lossy media

[mehmet sulak]

 Hi ,

For the final question I mean that;
Since increasing   "lsb_width " results less decompress ratio, we want to
adjust  "lsb_width " dynamically according to network quality conditions.
For examle initially I use  "lsb_width " = 256 and if network quality
become better I will set it to 16 while related compressor is in progress.
For the "lsb shift ", I think with new version " reorder_ratio " parameter
will satisfy us, because for example ratio 1/2 will generate always the
half of   "lsb_width ",
so there will be no need to change   " lsb shift ", changing  "lsb_width "
will change   "lsb shift " automatically.

Best Regards...


2018-02-19 16:27 GMT+03:00 mehmet sulak :

> Hi,
>
> Is it possible to make  "ROHC_WLSB_WIDTH_MAX 256U" in the next release so
> that a wide range of  width values can be used in
> rohc_comp_set_wlsb_window_width() method?
>
> Is it possible to make  "rohc_lsb_shift_t" values parametric in next
> release ? I mean to make lsb shift values parametric so that users can set
> any shift value from a related parameter?
>
> Final one is; is it possible to change lsb_width and shift values
> dynamically while related compressor/decompressors are in progress?
>
> Best Regards...
>
>
> 2018-02-12 14:39 GMT+03:00 mehmet sulak :
>
>> Hi ,
>>
>> Thank you for your response,
>>
>> Here are my changes;
>>
>> in file interval.h
>> //#define ROHC_WLSB_WIDTH_MAX to 64U (comment out)
>> #define ROHC_WLSB_WIDTH_MAX 256U  (new definition)
>>
>> also added new enum value at "rohc_lsb_shift_t"
>>
>> ROHC_LSB_SHIFT_UDP_SN = 128
>>
>> to be used in UDP traffic.
>>
>> also in files c_udp.c and d_udp.c
>>
>> instead of using  "ROHC_LSB_SHIFT_SN" which is  -1
>>
>> I used newly defined  "ROHC_LSB_SHIFT_UDP_SN" value
>>
>>
>> For the  trade-off between compression efficiency and robustness I
>> observed that for configurations
>>
>> higher then lsb_w = 32 and p=16 makes UDP/IP header to 7 bytes. So I
>> choose the lsb_w=256 and p = 128 for greatest coverage.
>>
>> Best Regards...
>>
>>
>> 2018-02-08 17:17 GMT+03:00 Didier Barvaux :
>>
>>> Hello,
>>>
>>> Sorry for not answering sooner. I could have saved you some time about
>>> the WLSB width :-/
>>>
>>> First of all, your changes seem correct. Please send me a patch, I'll
>>> check if I can integrate your changes in the next release.
>>>
>>> The increased size is indeed a consequence. You ask the library to be
>>> more robust, so it sends more information to achieve that goal.
>>>
>>> You have to choose a trade-off between a/ compression efficiency and b/
>>> robustness. Did you try to set smaller value for the WLSB width? Maybe
>>> 128 provides enough robustness? Maybe 192?
>>>
>>> Regards,
>>> Didier
>>>
>>>
>>> On Tue, 6 Feb 2018 17:31:18 +0300,
>>> mehmet sulak  wrote:
>>>
>>> > After some trials I saw that;
>>> >
>>> > rohc_comp_set_wlsb_window_width()  method is working correctly, the
>>> > second parameter is just width of LSB window however I toughed that
>>> > it was the number of bits that are for  LSB  width.
>>> >
>>> > I set it as 256 to handle large number of problematic cases(by setting
>>> > ROHC_WLSB_WIDTH_MAX to 256U). Also I set  ROHC_LSB_SHIFT_SN  as 128 to
>>> > handle delayed packets.
>>> > (I defined new enumeration field whose value is 128 by updating
>>> > interval.h and setting new value in c_udp.c and d_udp.c files)
>>> >
>>> > The results are seems to perfect. Rohc decomress errors are seems to
>>> > minimized to very small values which stems from loss of initial
>>> > context packages.
>>> >
>>> > The drawback is that 28 byte UDP headers were compressed to 4 bytes
>>> > previously but with the solution that I tried they are now compressed
>>> > to 7 bytes.
>>> >
>>> > Is this normal behavior?
>>> >
>>> > Best Regards..
>>> >
>>> >
>>> >
>>> > 2018-01-30 17:26 GMT+03:00 mehmet sulak :
>>> >
>>> > > Thanks for your detailed response first;
>>> > >
>>> > > First I tried method  rohc_comp_set_wlsb_window_width(comp,8) by
>>> > > giving 8bits window width but I still observe the following in the
>>> > > log files;
>>> > >
>>> > > rohc_decomp_rfc3095.c:1463 parse_uo0() 4 SN bits = 0xe
>>> > >
>>> > > So I think it still uses 4 bit window length? If yes did I do
>>> > > something wrong?
>>> > >
>>> > > Secondly I think for UDP packets ROHC_LSB_SHIFT_SN(-1) is used for
>>> > > compressor and decompressor which makes parsing delayed packets
>>> > > impossible.
>>> > >
>>> > > So I need to use something half of (2 ^ lsb_width)  instead of -1 by
>>> > > adding a new enumeration value.
>>> > >
>>> > > Do have any idea about this parameter?
>>> > >
>>> > > Best Regards..
>>> > >
>>> > > 2018-01-29 22:11 GMT+03:00 Didier Barvaux :
>>> > >
>>> > >> Hello,
>>> > >>
>>> > >> > I am using Rohc comressor/decomressor pair on a lossy
>>> > >> > media(sometimes at receiver side some packets are lost) and the
>>> 

Re: [Rohc] rohc performance on lossy media

[Didier Barvaux]

Hello,

First of all, thank you for your patches.


> Is it possible to make  "ROHC_WLSB_WIDTH_MAX 256U" in the next
> release so that a wide range of  width values can be used in
> rohc_comp_set_wlsb_window_ width() method?

Yes, it is possible. Some code optimizations performed for the ARM
targets will allow that. I did it on the dev branch
dev_improve_perfs_decomp_on_arm :
https://github.com/didier-barvaux/rohc/commit/babff28f6c6c2882e2aa12065172499dc4808acc



> Is it possible to make  "rohc_lsb_shift_t" values parametric in next
> release ? I mean to make lsb shift values parametric so that users
> can set any shift value from a related parameter?

The LSB values are defined by the ROHCv1 standard, so I'm not sure that
I want to allow that.

The ROHCv2 standard added the reorder_ratio parameter for that purpose.
The next release will also provide some ROHCv2 profiles. You might use
them with a custom reorder_ratio.

 
> Final one is; is it possible to change lsb_width and shift values
> dynamically while related compressor/decompressors are in progress?

This is not possible in current versions. I'll try to add a way to
change the value dynamically. If possible, it would probably implies to
define a maximum value at startup. Would it be ok for you?

Regards,
Didier

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

Re: [Rohc] rohc performance on lossy media

[mehmet sulak]

Hi,

Is it possible to make  "ROHC_WLSB_WIDTH_MAX 256U" in the next release so
that a wide range of  width values can be used in rohc_comp_set_wlsb_window_
width() method?

Is it possible to make  "rohc_lsb_shift_t" values parametric in next
release ? I mean to make lsb shift values parametric so that users can set
any shift value from a related parameter?

Final one is; is it possible to change lsb_width and shift values
dynamically while related compressor/decompressors are in progress?

Best Regards...


2018-02-12 14:39 GMT+03:00 mehmet sulak :

> Hi ,
>
> Thank you for your response,
>
> Here are my changes;
>
> in file interval.h
> //#define ROHC_WLSB_WIDTH_MAX to 64U (comment out)
> #define ROHC_WLSB_WIDTH_MAX 256U  (new definition)
>
> also added new enum value at "rohc_lsb_shift_t"
>
> ROHC_LSB_SHIFT_UDP_SN = 128
>
> to be used in UDP traffic.
>
> also in files c_udp.c and d_udp.c
>
> instead of using  "ROHC_LSB_SHIFT_SN" which is  -1
>
> I used newly defined  "ROHC_LSB_SHIFT_UDP_SN" value
>
>
> For the  trade-off between compression efficiency and robustness I
> observed that for configurations
>
> higher then lsb_w = 32 and p=16 makes UDP/IP header to 7 bytes. So I
> choose the lsb_w=256 and p = 128 for greatest coverage.
>
> Best Regards...
>
>
> 2018-02-08 17:17 GMT+03:00 Didier Barvaux :
>
>> Hello,
>>
>> Sorry for not answering sooner. I could have saved you some time about
>> the WLSB width :-/
>>
>> First of all, your changes seem correct. Please send me a patch, I'll
>> check if I can integrate your changes in the next release.
>>
>> The increased size is indeed a consequence. You ask the library to be
>> more robust, so it sends more information to achieve that goal.
>>
>> You have to choose a trade-off between a/ compression efficiency and b/
>> robustness. Did you try to set smaller value for the WLSB width? Maybe
>> 128 provides enough robustness? Maybe 192?
>>
>> Regards,
>> Didier
>>
>>
>> On Tue, 6 Feb 2018 17:31:18 +0300,
>> mehmet sulak  wrote:
>>
>> > After some trials I saw that;
>> >
>> > rohc_comp_set_wlsb_window_width()  method is working correctly, the
>> > second parameter is just width of LSB window however I toughed that
>> > it was the number of bits that are for  LSB  width.
>> >
>> > I set it as 256 to handle large number of problematic cases(by setting
>> > ROHC_WLSB_WIDTH_MAX to 256U). Also I set  ROHC_LSB_SHIFT_SN  as 128 to
>> > handle delayed packets.
>> > (I defined new enumeration field whose value is 128 by updating
>> > interval.h and setting new value in c_udp.c and d_udp.c files)
>> >
>> > The results are seems to perfect. Rohc decomress errors are seems to
>> > minimized to very small values which stems from loss of initial
>> > context packages.
>> >
>> > The drawback is that 28 byte UDP headers were compressed to 4 bytes
>> > previously but with the solution that I tried they are now compressed
>> > to 7 bytes.
>> >
>> > Is this normal behavior?
>> >
>> > Best Regards..
>> >
>> >
>> >
>> > 2018-01-30 17:26 GMT+03:00 mehmet sulak :
>> >
>> > > Thanks for your detailed response first;
>> > >
>> > > First I tried method  rohc_comp_set_wlsb_window_width(comp,8) by
>> > > giving 8bits window width but I still observe the following in the
>> > > log files;
>> > >
>> > > rohc_decomp_rfc3095.c:1463 parse_uo0() 4 SN bits = 0xe
>> > >
>> > > So I think it still uses 4 bit window length? If yes did I do
>> > > something wrong?
>> > >
>> > > Secondly I think for UDP packets ROHC_LSB_SHIFT_SN(-1) is used for
>> > > compressor and decompressor which makes parsing delayed packets
>> > > impossible.
>> > >
>> > > So I need to use something half of (2 ^ lsb_width)  instead of -1 by
>> > > adding a new enumeration value.
>> > >
>> > > Do have any idea about this parameter?
>> > >
>> > > Best Regards..
>> > >
>> > > 2018-01-29 22:11 GMT+03:00 Didier Barvaux :
>> > >
>> > >> Hello,
>> > >>
>> > >> > I am using Rohc comressor/decomressor pair on a lossy
>> > >> > media(sometimes at receiver side some packets are lost) and the
>> > >> > orderings of the  UDP packets are not guaranteed.(packets are
>> > >> > not coming in right order all the time).
>> > >> >
>> > >> > I am using Unidirectional mode and observe some decomression
>> > >> > failures about CRC check, malformed packets...
>> > >> >
>> > >> > Any recommendation to overcome these issues?
>> > >>
>> > >> The ROHC protocol provides several ways to handle packet loss or
>> > >> reordering:
>> > >>
>> > >> a/ Increasing the width of the window used by the W-LSB algorithm
>> > >>improves the robustness of the ROHC protocol by sending more
>> > >> bits for changing fields. Given a W-LSB width , up to
>> > >>( - 1) packets may be lost without causing
>> > >> additional loss.
>> > >>The default width is set to 4 by the ROHC library ; please use
>> > >> the rohc_comp_set_wlsb_window_width() function to 

Re: [Rohc] rohc performance on lossy media

[Didier Barvaux]

Hello,

Sorry for not answering sooner. I could have saved you some time about
the WLSB width :-/

First of all, your changes seem correct. Please send me a patch, I'll
check if I can integrate your changes in the next release.

The increased size is indeed a consequence. You ask the library to be
more robust, so it sends more information to achieve that goal.

You have to choose a trade-off between a/ compression efficiency and b/
robustness. Did you try to set smaller value for the WLSB width? Maybe
128 provides enough robustness? Maybe 192?

Regards,
Didier


On Tue, 6 Feb 2018 17:31:18 +0300,
mehmet sulak  wrote:

> After some trials I saw that;
> 
> rohc_comp_set_wlsb_window_width()  method is working correctly, the
> second parameter is just width of LSB window however I toughed that
> it was the number of bits that are for  LSB  width.
> 
> I set it as 256 to handle large number of problematic cases(by setting
> ROHC_WLSB_WIDTH_MAX to 256U). Also I set  ROHC_LSB_SHIFT_SN  as 128 to
> handle delayed packets.
> (I defined new enumeration field whose value is 128 by updating
> interval.h and setting new value in c_udp.c and d_udp.c files)
> 
> The results are seems to perfect. Rohc decomress errors are seems to
> minimized to very small values which stems from loss of initial
> context packages.
> 
> The drawback is that 28 byte UDP headers were compressed to 4 bytes
> previously but with the solution that I tried they are now compressed
> to 7 bytes.
> 
> Is this normal behavior?
> 
> Best Regards..
> 
> 
> 
> 2018-01-30 17:26 GMT+03:00 mehmet sulak :
> 
> > Thanks for your detailed response first;
> >
> > First I tried method  rohc_comp_set_wlsb_window_width(comp,8) by
> > giving 8bits window width but I still observe the following in the
> > log files;
> >
> > rohc_decomp_rfc3095.c:1463 parse_uo0() 4 SN bits = 0xe
> >
> > So I think it still uses 4 bit window length? If yes did I do
> > something wrong?
> >
> > Secondly I think for UDP packets ROHC_LSB_SHIFT_SN(-1) is used for
> > compressor and decompressor which makes parsing delayed packets
> > impossible.
> >
> > So I need to use something half of (2 ^ lsb_width)  instead of -1 by
> > adding a new enumeration value.
> >
> > Do have any idea about this parameter?
> >
> > Best Regards..
> >
> > 2018-01-29 22:11 GMT+03:00 Didier Barvaux :
> >  
> >> Hello,
> >>  
> >> > I am using Rohc comressor/decomressor pair on a lossy
> >> > media(sometimes at receiver side some packets are lost) and the
> >> > orderings of the  UDP packets are not guaranteed.(packets are
> >> > not coming in right order all the time).
> >> >
> >> > I am using Unidirectional mode and observe some decomression
> >> > failures about CRC check, malformed packets...
> >> >
> >> > Any recommendation to overcome these issues?  
> >>
> >> The ROHC protocol provides several ways to handle packet loss or
> >> reordering:
> >>
> >> a/ Increasing the width of the window used by the W-LSB algorithm
> >>improves the robustness of the ROHC protocol by sending more
> >> bits for changing fields. Given a W-LSB width , up to
> >>( - 1) packets may be lost without causing
> >> additional loss.
> >>The default width is set to 4 by the ROHC library ; please use
> >> the rohc_comp_set_wlsb_window_width() function to change the
> >> value ; see [1] for more details.
> >>
> >> b/ Increasing the number of transmissions N required for a changing
> >>static fields or a changing pattern for a dynamic field ensures
> >> that the loss of N-1 packets during such a change will cause no
> >>additional loss.
> >>The default number of transmissions is set to 3 by the ROHC
> >>library ; there is no API to change the value at that time, but
> >> you may change the value of the constant MAX_IR_COUNT in the
> >> source file src/comp/rohc_comp_internals.h and re-build/re-install
> >> the library.
> >>
> >> c/ Same as b/ but for lists of extensions headers (such as IPv6
> >>extension headers, GRE, AH...). Use the function
> >>rohc_comp_set_list_trans_nr() to change the value ; the default
> >>value is set to 5 ; see [2] for more details.
> >>
> >> d/ You may enable packet/context repair upon CRC failures, so that
> >> the decompressor tries to fix the context or packet if it detects a
> >>decompression problem (due to packet loss/reordering for
> >> example). The feature is disabled by default. Enable it with the
> >> function rohc_decomp_set_features() and the feature
> >>ROHC_DECOMP_FEATURE_CRC_REPAIR ; see [3] for more details.
> >>
> >> Configuring options a-c is easier if you know the largest number of
> >> consecutive losses that you may expect and/or you want to be
> >> protected against.
> >>
> >> Let me know if my explanations are clear enough or if you need more
> >> details. And, of course, let me know if one of the options solves
> >> your problem.
> >>
> >> Regards,
> >> Didier
> >>
> >>

Re: [Rohc] rohc performance on lossy media

[mehmet sulak]

After some trials I saw that;

rohc_comp_set_wlsb_window_width()  method is working correctly, the second
parameter is just width of LSB window however I toughed that  it was the
number of bits that are for  LSB  width.

I set it as 256 to handle large number of problematic cases(by setting
ROHC_WLSB_WIDTH_MAX to 256U). Also I set  ROHC_LSB_SHIFT_SN  as 128 to
handle delayed packets.
(I defined new enumeration field whose value is 128 by updating interval.h
and setting new value in c_udp.c and d_udp.c files)

The results are seems to perfect. Rohc decomress errors are seems to
minimized to very small values which stems from loss of initial context
packages.

The drawback is that 28 byte UDP headers were compressed to 4 bytes
previously but with the solution that I tried they are now compressed to 7
bytes.

Is this normal behavior?

Best Regards..



2018-01-30 17:26 GMT+03:00 mehmet sulak :

> Thanks for your detailed response first;
>
> First I tried method  rohc_comp_set_wlsb_window_width(comp,8) by giving
> 8bits window width but I still observe the following in the log files;
>
> rohc_decomp_rfc3095.c:1463 parse_uo0() 4 SN bits = 0xe
>
> So I think it still uses 4 bit window length? If yes did I do something
> wrong?
>
> Secondly I think for UDP packets ROHC_LSB_SHIFT_SN(-1) is used for
> compressor and decompressor which makes parsing delayed packets impossible.
>
> So I need to use something half of (2 ^ lsb_width)  instead of -1 by
> adding a new enumeration value.
>
> Do have any idea about this parameter?
>
> Best Regards..
>
> 2018-01-29 22:11 GMT+03:00 Didier Barvaux :
>
>> Hello,
>>
>> > I am using Rohc comressor/decomressor pair on a lossy media(sometimes
>> > at receiver side some packets are lost) and the orderings of the  UDP
>> > packets are not guaranteed.(packets are not coming in right order all
>> > the time).
>> >
>> > I am using Unidirectional mode and observe some decomression failures
>> > about CRC check, malformed packets...
>> >
>> > Any recommendation to overcome these issues?
>>
>> The ROHC protocol provides several ways to handle packet loss or
>> reordering:
>>
>> a/ Increasing the width of the window used by the W-LSB algorithm
>>improves the robustness of the ROHC protocol by sending more bits for
>>changing fields. Given a W-LSB width , up to
>>( - 1) packets may be lost without causing additional
>>loss.
>>The default width is set to 4 by the ROHC library ; please use the
>>rohc_comp_set_wlsb_window_width() function to change the value ; see
>>[1] for more details.
>>
>> b/ Increasing the number of transmissions N required for a changing
>>static fields or a changing pattern for a dynamic field ensures that
>>the loss of N-1 packets during such a change will cause no
>>additional loss.
>>The default number of transmissions is set to 3 by the ROHC
>>library ; there is no API to change the value at that time, but you
>>may change the value of the constant MAX_IR_COUNT in the source file
>>src/comp/rohc_comp_internals.h and re-build/re-install the library.
>>
>> c/ Same as b/ but for lists of extensions headers (such as IPv6
>>extension headers, GRE, AH...). Use the function
>>rohc_comp_set_list_trans_nr() to change the value ; the default
>>value is set to 5 ; see [2] for more details.
>>
>> d/ You may enable packet/context repair upon CRC failures, so that the
>>decompressor tries to fix the context or packet if it detects a
>>decompression problem (due to packet loss/reordering for example).
>>The feature is disabled by default. Enable it with the function
>>rohc_decomp_set_features() and the feature
>>ROHC_DECOMP_FEATURE_CRC_REPAIR ; see [3] for more details.
>>
>> Configuring options a-c is easier if you know the largest number of
>> consecutive losses that you may expect and/or you want to be protected
>> against.
>>
>> Let me know if my explanations are clear enough or if you need more
>> details. And, of course, let me know if one of the options solves your
>> problem.
>>
>> Regards,
>> Didier
>>
>>
>> [1] documentation of rohc_comp_set_wlsb_window_width():
>> https://rohc-lib.org/support/documentation/API/rohc-doc-2.1.
>> 0/group__rohc__comp.html#ga2b68070dddbc038cd55490952a7b3fa4
>>
>> [2] documentation of rohc_comp_set_list_trans_nr():
>> https://rohc-lib.org/support/documentation/API/rohc-doc-2.1.
>> 0/group__rohc__comp.html#ga32608bc06e1b0d1656e463eeb1ccbd7f
>>
>> [3] documentation of rohc_decomp_set_features():
>> https://rohc-lib.org/support/documentation/API/rohc-doc-2.1.
>> 0/group__rohc__decomp.html#ga2298148ca8dc277a1c1905f550f21f7b
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~rohc
>> Post to : rohc@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~rohc
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
___

Re: [Rohc] rohc performance on lossy media

[mehmet sulak]

Thanks for your detailed response first;

First I tried method  rohc_comp_set_wlsb_window_width(comp,8) by giving
8bits window width but I still observe the following in the log files;

rohc_decomp_rfc3095.c:1463 parse_uo0() 4 SN bits = 0xe

So I think it still uses 4 bit window length? If yes did I do something
wrong?

Secondly I think for UDP packets ROHC_LSB_SHIFT_SN(-1) is used for
compressor and decompressor which makes parsing delayed packets impossible.

So I need to use something half of (2 ^ lsb_width)  instead of -1 by adding
a new enumeration value.

Do have any idea about this parameter?

Best Regards..

2018-01-29 22:11 GMT+03:00 Didier Barvaux :

> Hello,
>
> > I am using Rohc comressor/decomressor pair on a lossy media(sometimes
> > at receiver side some packets are lost) and the orderings of the  UDP
> > packets are not guaranteed.(packets are not coming in right order all
> > the time).
> >
> > I am using Unidirectional mode and observe some decomression failures
> > about CRC check, malformed packets...
> >
> > Any recommendation to overcome these issues?
>
> The ROHC protocol provides several ways to handle packet loss or
> reordering:
>
> a/ Increasing the width of the window used by the W-LSB algorithm
>improves the robustness of the ROHC protocol by sending more bits for
>changing fields. Given a W-LSB width , up to
>( - 1) packets may be lost without causing additional
>loss.
>The default width is set to 4 by the ROHC library ; please use the
>rohc_comp_set_wlsb_window_width() function to change the value ; see
>[1] for more details.
>
> b/ Increasing the number of transmissions N required for a changing
>static fields or a changing pattern for a dynamic field ensures that
>the loss of N-1 packets during such a change will cause no
>additional loss.
>The default number of transmissions is set to 3 by the ROHC
>library ; there is no API to change the value at that time, but you
>may change the value of the constant MAX_IR_COUNT in the source file
>src/comp/rohc_comp_internals.h and re-build/re-install the library.
>
> c/ Same as b/ but for lists of extensions headers (such as IPv6
>extension headers, GRE, AH...). Use the function
>rohc_comp_set_list_trans_nr() to change the value ; the default
>value is set to 5 ; see [2] for more details.
>
> d/ You may enable packet/context repair upon CRC failures, so that the
>decompressor tries to fix the context or packet if it detects a
>decompression problem (due to packet loss/reordering for example).
>The feature is disabled by default. Enable it with the function
>rohc_decomp_set_features() and the feature
>ROHC_DECOMP_FEATURE_CRC_REPAIR ; see [3] for more details.
>
> Configuring options a-c is easier if you know the largest number of
> consecutive losses that you may expect and/or you want to be protected
> against.
>
> Let me know if my explanations are clear enough or if you need more
> details. And, of course, let me know if one of the options solves your
> problem.
>
> Regards,
> Didier
>
>
> [1] documentation of rohc_comp_set_wlsb_window_width():
> https://rohc-lib.org/support/documentation/API/rohc-doc-2.
> 1.0/group__rohc__comp.html#ga2b68070dddbc038cd55490952a7b3fa4
>
> [2] documentation of rohc_comp_set_list_trans_nr():
> https://rohc-lib.org/support/documentation/API/rohc-doc-2.
> 1.0/group__rohc__comp.html#ga32608bc06e1b0d1656e463eeb1ccbd7f
>
> [3] documentation of rohc_decomp_set_features():
> https://rohc-lib.org/support/documentation/API/rohc-doc-2.
> 1.0/group__rohc__decomp.html#ga2298148ca8dc277a1c1905f550f21f7b
>
>
> ___
> Mailing list: https://launchpad.net/~rohc
> Post to : rohc@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~rohc
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~rohc
Post to : rohc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~rohc
More help   : https://help.launchpad.net/ListHelp

Re: [Rohc] rohc performance on lossy media

[Didier Barvaux]

Hello,

> I am using Rohc comressor/decomressor pair on a lossy media(sometimes
> at receiver side some packets are lost) and the orderings of the  UDP
> packets are not guaranteed.(packets are not coming in right order all
> the time).
> 
> I am using Unidirectional mode and observe some decomression failures
> about CRC check, malformed packets...
> 
> Any recommendation to overcome these issues?

The ROHC protocol provides several ways to handle packet loss or
reordering:

a/ Increasing the width of the window used by the W-LSB algorithm
   improves the robustness of the ROHC protocol by sending more bits for
   changing fields. Given a W-LSB width , up to
   ( - 1) packets may be lost without causing additional
   loss.
   The default width is set to 4 by the ROHC library ; please use the
   rohc_comp_set_wlsb_window_width() function to change the value ; see
   [1] for more details.

b/ Increasing the number of transmissions N required for a changing
   static fields or a changing pattern for a dynamic field ensures that
   the loss of N-1 packets during such a change will cause no
   additional loss.
   The default number of transmissions is set to 3 by the ROHC
   library ; there is no API to change the value at that time, but you
   may change the value of the constant MAX_IR_COUNT in the source file
   src/comp/rohc_comp_internals.h and re-build/re-install the library.

c/ Same as b/ but for lists of extensions headers (such as IPv6
   extension headers, GRE, AH...). Use the function
   rohc_comp_set_list_trans_nr() to change the value ; the default
   value is set to 5 ; see [2] for more details.

d/ You may enable packet/context repair upon CRC failures, so that the
   decompressor tries to fix the context or packet if it detects a
   decompression problem (due to packet loss/reordering for example).
   The feature is disabled by default. Enable it with the function
   rohc_decomp_set_features() and the feature
   ROHC_DECOMP_FEATURE_CRC_REPAIR ; see [3] for more details.

Configuring options a-c is easier if you know the largest number of
consecutive losses that you may expect and/or you want to be protected
against.

Let me know if my explanations are clear enough or if you need more
details. And, of course, let me know if one of the options solves your
problem.

Regards,
Didier


[1] documentation of rohc_comp_set_wlsb_window_width():
https://rohc-lib.org/support/documentation/API/rohc-doc-2.1.0/group__rohc__comp.html#ga2b68070dddbc038cd55490952a7b3fa4

[2] documentation of rohc_comp_set_list_trans_nr():
https://rohc-lib.org/support/documentation/API/rohc-doc-2.1.0/group__rohc__comp.html#ga32608bc06e1b0d1656e463eeb1ccbd7f

[3] documentation of rohc_decomp_set_features():
https://rohc-lib.org/support/documentation/API/rohc-doc-2.1.0/group__rohc__decomp.html#ga2298148ca8dc277a1c1905f550f21f7b


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