Duplicate Feedback

Asked by Mohammad Abyan Abdullah on 2015-05-09

Hi!!
    is there anyway to remove the duplicate feedback from sending by the compressor ? I can see there are too many duplicate feedback been added from the compressor to send. And at decompressor also receives too many duplicate feedback. For same CID I can see many feedback receives from the compressor when packet failed and decompressor sends a negative feedback. What I can see here is for each bad packet decompressor sends a negative feedback so for all those negative feedback other side compressor generates feedback and sends.

Regards
Abyan

Question information

Language:
English Edit question
Status:
Answered
For:
rohc Edit question
Assignee:
No assignee Edit question
Last query:
2015-06-02
Last reply:
2015-06-13
Launchpad Janitor (janitor) said : #1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Hello,

I'm currently reworking the way feedbacks are sent. This includes rate-limiting for ACKs and NACKs. I'll make the changes public soon.

Regards,
Didier

Hello,

Rate-limiting was added with change [1]. Follow instructions at [2] to build the library from the GIT repository.

[1] https://github.com/didier-barvaux/rohc/commit/89735bfafb318cca6a5354ad17d5f2e0d82d1bed
[2] https://rohc-lib.org/wiki/doku.php?id=library-install-sources#native_build_on_unix-like_systems

Regards,
Didier

Hi!!
  Thanks for the update. Is thre any way I can apply this patch at ROHC 1.7.0 version ? Since I haven't tried the latest one yet. And already working the the version 1.7.0 and got some update patch from u too for that version. Yet I'm confused to move to new one. And also I don't have the proper documentation for the new version yet :(

Regards
Abyan

Hello,

> Thanks for the update. Is thre any way I can apply this patch at ROHC 1.7.0 version ?

I'm afraid there is no easy way. Changes to fix that problem are quite invasive.

> Since I haven't tried the latest one yet. And already working the the version 1.7.0 and
> got some update patch from u too for that version. Yet I'm confused to move to new
> one.

The following problems are fixed in the master branch of the GIT repository:
  https://answers.launchpad.net/rohc/+question/264189
  https://bugs.launchpad.net/rohc/+bug/1439727

Do you have any other patch?

> And also I don't have the proper documentation for the new version yet :(

Once the GIT repository is cloned and sources were built (see previous link), run the following commands to get the latest documentation:
  $ make -C doc/
  $ firefox doc/html/index.html # replace firefox by your favourite web browser

Regards,
Didier

Ok. Like one change ..
  At Outer IP-ID patch you told me that it's not fixable at the first error packet. It has to fixed 3 packet to get a valid packet. So I did modified the code a bit to get the packet valid at first CRC error. What I saw at the log I provided to you is whenever the packet comes late the IP-ID value mismatch at that time. So at
d_generic.c
At
static bool decode_values_from_bits(struct rohc_decomp_ctxt *const context,
                                    const struct rohc_extr_bits bits,
                                    struct rohc_decoded_values *const decoded)
{
        struct d_generic_context *g_context;
        bool decode_ok;
        bool packet_late = false;

.....
...

  else if(decoded->sn < expected_next_sn)
                {
                        /* smaller SN: order was changed on the network channel */
                        rohc_info(context->decompressor, ROHC_TRACE_DECOMP, context->profile->id,
                                  "packet seems to come late (SN jumped back from 0x%x "
                                  "to 0x%x)", sn_context, decoded->sn);
                        context->nr_lost_packets = 0;
                        context->nr_misordered_packets = expected_next_sn - decoded->sn;
                        context->is_duplicated = false;
                        packet_late = true;
                }

......
...
      if(packet_late)
        {
        decode_ok = decode_ip_values_from_bits(context, g_context->outer_ip_changes,
                                               g_context->outer_ip_id_offset_ctxt,
                                                decoded->sn, ROHC_LSB_REF_MINUS_1, bits.outer_ip,
                                               "outer", &decoded->outer_ip);
        rohc_decomp_debug(context, "Using Late Packet Reference");
        }
        else
        {
        /* decode fields related to the outer IP header */
        decode_ok = decode_ip_values_from_bits(context, g_context->outer_ip_changes,
                                               g_context->outer_ip_id_offset_ctxt,
                                                decoded->sn, bits.sn_ref_type, bits.outer_ip,
                                               "outer", &decoded->outer_ip);
        }

So whenever I see a packet comes late from the sn difference I can use ROHC_LSB_REF_MINUS_1 to determine the outer-ip-id for that late packet. So I don't get anymore CRC error packets for that scenario. I don't if that feasible or not. :)

Regards
Abyan

Hi!!
  Another confusion here for me is at rohc_decompress3() previously we use to send feedback_send data using piggy_back. It seems its been deprecated at new version. So how we can send the feedback_send data from now on ?

Regards
Abyan

Hello,

> So whenever I see a packet comes late from the sn difference I can use
> ROHC_LSB_REF_MINUS_1 to determine the outer-ip-id for that late
> packet. So I don't get anymore CRC error packets for that scenario.
> I don't if that feasible or not. :)

I'm afraid that your solution is quite specific to your use case. You avoid a CRC failure* if the SN is correctly decompressed but not the IP-ID. This means that the SN was more protected (against packet loss or reordering) than IP-ID. A better way to fix your problem is probably to increase the protection of the IP-ID. This could be performed by increasing the width of the W-LSB window. See the rohc_comp_set_wlsb_window_width() function**. Default value is 4. So, by default a packet reordering of more than 4 packets might lead to a decompression failure (in fact it depends of how quickly the IP-ID value changes). Change it for another power of 2 value such as 64 for example.

* CRC matches but is the decompressed packet correct? several different packets may have the same CRC, especially with packet types that are only protected with CRC-3. So maybe decompression fails but it is not detected by CRC.
** https://rohc-lib.org/support/documentation/API/rohc-doc-1.7.0/group__rohc__comp.html#ga2b68070dddbc038cd55490952a7b3fa4

> Another confusion here for me is at rohc_decompress3() previously
> we use to send feedback_send data using piggy_back. It seems its been
> deprecated at new version. So how we can send the feedback_send data
> from now on ?

Yes, the function was deprecated in 1.7.x versions and removed for future versions 2.0.x. The master branch from Git is close to the future 2.0.0 version.

The migration between library versions is explained on the wiki:
  https://rohc-lib.org/support/wiki/doku.php?id=library-migration

However, the migration from 1.6.x to 1.7.x version that you need is incomplete at the moment. I forgot to update it when I released the final 1.7.0 version. I'll update it asap. Stay tuned.

Regards,
Didier

Hello,

I have just updated the migration instructions on the wiki:
https://rohc-lib.org/wiki/doku.php?id=library-migration#api_changes_between_16x_and_17x

Let me know if some information is missing or not clear enough.

Regards,
Didier

Can you help with this problem?

Provide an answer of your own, or ask Mohammad Abyan Abdullah for more information if necessary.

To post a message you must log in.