about feedback

Asked by regulararmy on 2013-05-23

hello Didier,
         Firstly,ROHC feebacks may be transmitted in 2 different ways: piggybacking or alone, If traffic is asymmetric, there are perhaps not enough reverse traffic to transmit all the ROHC piggybacking feedbacks, In such a case, feedbacks are sent alone,however,how can we realize it in the codes? the logic may be not clear. In additon,I wonder if the feedback data sent alone
do not need to be compressed and if it is received by the another end, we do not bulid and send a feedback data for it?
        Secondly, As for the three parameters:feedbacks_first, feedbacks_first_unlocked and feedbacks_next,what is the relationship among them , and what is the meaning for "lock" or "unlocked" ?

Question information

Language:
English Edit question
Status:
Solved
For:
rohc Edit question
Assignee:
No assignee Edit question
Solved by:
Didier Barvaux
Solved:
2013-06-05
Last query:
2013-06-05
Last reply:
2013-06-04

This question was reopened

regulararmy (regulararmy) said : #1

what is the mechanism and effect for function :rohc_feedback_remove_locked(comp) and
rohc_feedback_unlock(comp)? can you explain them in detail? Thanks very much!

Hello,

> In such a case, feedbacks are sent alone,however,how can we realize
> it in the codes? the logic may be not clear.

Call the rohc_feedback_flush() function of the ROHC library. It will write a ROHC packet (full of feedback data) in the obuf buffer and will return the length of that packet. You can then transmit it as any other ROHC packet.

[1] http://bazaar.launchpad.net/~didier-barvaux/rohc/1.5.x/view/head:/src/comp/rohc_comp.c#L1294

> In additon,I wonder if the feedback data sent alone do not need to be
> compressed

No, a feedback packet does not need to be compressed!

Please the project wiki and the relevant parts of the RFC:
http://rohc-lib.org/wiki/doku.php?id=rohc-protocol
https://tools.ietf.org/html/rfc3095#section-5.2.1
https://tools.ietf.org/html/rfc3095#section-5.2.2

> and if it is received by the another end, we do not bulid and
> send a feedback data for it?

A feedback packet will not generate a feedback packet on the other side.

> Secondly, As for the three parameters:feedbacks_first,
> feedbacks_first_unlocked and feedbacks_next,what is the
> relationship among them , and what is the meaning for "lock" or
> "unlocked" ?

The rohc_feedback_flush() returns you some feedbacks. You try to transmit them. If it succeeds, that's great. If it fails, the feedbacks are lost because the library don't remember them: the next call to rohc_feedback_flush() will give you other feedbacks. You can record the feedbacks in your own program, but that's not very practical.

So, in order to handle that case the locked/unlocked status was added: when you call the rohc_feedback_flush() function, the library returns you some feedbacks (maybe not all the feedbacks it got if your buffer is too small), but keeps those feedbacks in its buffers: they are locked.
If your transmission succeeds, you can tell the library to remove the locked feedbacks with the rohc_feedback_remove_locked() function.
If your transmission fails, you can tell the library to keep and unlock the feedbacks with the rohc_feedback_unlock() function: they will therefore be returned by the next call to rohc_feedback_flush().

That's a kind of transaction to gracefully handle failure cases.

Regards,
Didier

regulararmy (regulararmy) said : #4

Thanks Didier Barvaux, that solved my question.

regulararmy (regulararmy) said : #5

Dear Barvaux:
          when we call the rohc_feedback_flush() function alone after compression,We must call the rohc_feedback_unlock() or rohc_feedback_flush()? If so, in the tunnel test example, there is a call for rohc_feedback_unlock() at the end of main(),however,after that,you do not call rohc_feedback_unlock() or rohc_feedback_flush().can you explain it? Thanks

I do not understand your question at all. You seem to mix function names in your sentences... What are you trying to do? What tunnel test example are you talking about?

Regards,
Didier

regulararmy (regulararmy) said : #7

I am sorry.
ROHC over UDP tunnel: http://rohc-lib.org/wiki/doku.php#rohc_over_udp_tunnel,for that test example,
rohc_feedback_unlock() is called at the end of main()function,however,after that,you do not call rohc_feedback_unlock() to unlock the feedback data if transmission fails,you do not call the rohc_feedback_remove_locked() to remove the feedback data if transmission succeeds. Is it against to what you answered above? If not,can you explain it?

Hi,

The ROHC over UDP tunnel is not correct. It should call rohc_feedback_unlock()/rohc_feedback_remove_locked(). For an example, please see http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/test/functional/feedback_ring/test_feedback_ring.c

Regards,
Didier

regulararmy (regulararmy) said : #9

As for the http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/test/functional/feedback_ring/test_feedback_ring.c, I can not understand the mechanism and function of rohc_comp_piggyback_feedback(comp, feedback_data, FEEDBACK_SIZE) clearly,can you explain it? Thanks.

regulararmy (regulararmy) said : #10

which library is the /test/functional/feedback_ring/test_feedback_ring.c in ? I can not find it in rohc-1.5.1 or rohc-1.5.2.

Hello,

The rohc_comp_piggyback_feedback() function is used by one ROHC decompressor to give feedback data to its associated ROHC compressor. You don't have to use it in your application, except if you want to some advanced things with feedbacks.

The test_feedback_ring test is available on the dev branch. It is not provided with 1.5.x versions. It will be part of the next 1.6.0 version.

Regards,
Didier

regulararmy (regulararmy) said : #12

Thanks Didier Barvaux, that solved my question.

regulararmy (regulararmy) said : #13

hello,
        I find that there are only 10 elements(see FEEDBACK_RING_SIZE in rohc-1.5.1 )to piggyback feedback,
however, As for the http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/test/functional/feedback_ring/test_feedback_ring.c, it seems as if there are 1000 elements to piggyback,can you explain it? Thanks.

I changed it in the main branch after the 1.5.0 release (so it only appears in next 1.6.0). Value 10 was too short in case of bursts of decompression errors and therefore bursts of feedbacks.

For this kind of questions, the source revision system got the answer:

  $ bzr branch lp:rohc rohc-main
  $ cd rohc-main
  $ bzr blame src/comp/rohc_comp_internals.h | grep FEEDBACK_RING_SIZE | grep define
  568 didier@ | #define FEEDBACK_RING_SIZE 1000

  $ bzr log -r 568
  ------------------------------------------------------------
  revno: 568
  committer: Didier Barvaux <HIDDEN_EMAIL>
  branch nick: rohc-main
  timestamp: Sat 2012-11-17 10:58:33 +0100
  message:
    Increase default feedback ring size.
  modified:
    src/comp/rohc_comp_internals.h

  $ bzr diff -r 567..568
  === modified file 'src/comp/rohc_comp_internals.h'
  --- src/comp/rohc_comp_internals.h 2012-11-11 20:16:44 +0000
  +++ src/comp/rohc_comp_internals.h 2012-11-17 09:58:33 +0000
  @@ -42,7 +42,7 @@
   #define C_NUM_PROFILES 6

   /** The maximal number of outgoing feedbacks that can be queued */
  -#define FEEDBACK_RING_SIZE 10
  +#define FEEDBACK_RING_SIZE 1000

   /** Print a debug trace for the given compression context */
   #define rohc_comp_debug(context, format, ...) \

Regards,
Didier

regulararmy (regulararmy) said : #15

Thanks Didier Barvaux, that solved my question.