negative feedback & rate limit mechamism

Asked by teloniatis on 2018-07-13

Hi,

I am quite confused regarding 'rohc_decomp_feedback_nack' function in rohc_decomp.c, in the part where it is decided if feedback will be sent depending on rate-limiting mechanism for successive feedbacks (lines 2229-2271, git branch 2.2.x).

I am not yet very familiar how this mechanism works and its benefits, but the 'if-else if' I am referring to, it makes no difference regarding the nested 'if-else' statements; they are the same:

  if(do_build_ack && infos->do_change_mode)
  {
   rohc_debug(decomp, ROHC_TRACE_DECOMP, infos->profile_id,
              "force negative ACK because mode changed or compressor "
              "reported a different mode");
   do_build_ack = true;
  }
  else
  {
   do_build_ack = false;
  }
  do_downward_transition = false;

Was it intended to be like that?
Is there some kind of documentation or other discussion regarding feedback rate-limiting mechanism? Code review is not enough to find out the logic behind that.
Finally, do we need that mechanism? Is there any way to disable it?

Regards,
Evangelos

Question information

Language:
English Edit question
Status:
Solved
For:
rohc Edit question
Assignee:
No assignee Edit question
Solved by:
Didier Barvaux
Solved:
2018-07-27
Last query:
2018-07-27
Last reply:
2018-07-13

Hello,

The rate limiting is specified by the ROHC standard. See RFC3095, ยง5.7.6 named "Feedback packets and formats":

   When the round-trip time between compressor and decompressor is
   large, several packets can be in flight concurrently. Therefore,
   several packets may be received by the decompressor after feedback
   has been sent and before the compressor has reacted to feedback.
   Moreover, decompression may fail due to residual errors in the
   compressed header.

   Therefore,

   a) in O-mode, the decompressor SHOULD limit the rate at which
      feedback on successful decompression is sent (if it is sent at
      all);
   b) when decompression fails, feedback SHOULD be sent only when
      decompression of several consecutive packets has failed, and when
      this occurs, the feedback rate SHOULD be limited;
   c) when packets are received which belong to a rejected packet
      stream, the feedback rate SHOULD be limited.

   A decompressor MAY limit the feedback rate by sending feedback only
   for one out of every k packets provoking the same (kind of) feedback.
   The appropriate value of k is implementation dependent; k might be
   chosen such that feedback is sent 1-3 times per link round-trip time.

So, the ROHC library implements a rate-limiting algorithm as follow: a NACK is not sent after every decompression failure, we wait for several failures before sending a NACK :
* if there is less than k failures out of the last n decompressions
   (successful or not), no feedback is sent
* if there is more than k failures out of the last n decompressions
   (successful or not):
    * if there is more than k feedbacks transmitted out of the last n
       decompression (failures only), no feedback is sent
    * if there is less than k feedbacks transmitted out of the last n
       decompression (failures only), one feedback is sent

The k and n values are configurable. They are specific per type of feedbacks (ACK, NACK, STATIC-NACK). If you set k = 1 and n = 32, it should disable the rate-limiting.

See the documentation of the rohc_decomp_set_rate_limits() function for more details:
https://rohc-lib.org/support/documentation/API/rohc-doc-2.2.0/group__rohc__decomp.html#gafb8a16da304917f1f820f4b95ab2438b

Regards,
Didier

teloniatis (teloniatis) said : #2

Hi Didier,

Thank you for your response.
Finally, feedback worked as I want it.

Regards,
Evangelos

teloniatis (teloniatis) said : #3

Thanks Didier Barvaux, that solved my question.