about feedback (2)

Asked by Friedrich on 2013-05-23

Hi Didier,

Thanks for your answer about feedback in the previous thread. It is very informative.

Following the two feedback methods, I am wondering at what kind of condition(s) the second feedback method (sent alone) will be triggered.

For example, I have a log under a high error-rate channel showing:

C_NUM_RECV_FEEDBACKS=41

/decomp/rohc_decomp.c:951 d_optimistic_feedback()] send a NACK feedback
/decomp/feedback.c:76 f_feedback2()] FEEDBACK-2: first 4 bits = 0x60 (ACK type = 1, mode = 2)
/decomp/feedback.c:80 f_feedback2()] FEEDBACK-2: transmit SN = 0x0000000a on 12 bits
/decomp/feedback.c:82 f_feedback2()] FEEDBACK-2: 4 bits of SN = 0x0
/decomp/feedback.c:84 f_feedback2()] FEEDBACK-2: 8 bits of SN = 0x0a
/decomp/feedback.c:387 f_wrap_feedback()] add CRC option to feedback
/comp/rohc_comp.c:1159 c_piggyback_feedback()] try to add 4 byte(s) of feedback to the next outgoing ROHC packet
/comp/rohc_comp.c:1191 c_piggyback_feedback()] 4 byte(s) of feedback added to the next outgoing ROHC packet

The version is 1.5.1. From this log, I presume it used piggyback feedback-2. Can you give me an example of rohc_debugf message showing the sent-alone feedback? (So that I can tell it from piggyback feedback in my log. )

Thanks,
Friedrich

Question information

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

Hello,

> Following the two feedback methods, I am wondering at what kind of
> condition(s) the second feedback method (sent alone) will be triggered.

Piggybacking is used if there is some traffic in the reverse direction. If not, feedbacks stay in the compressor context. In this case, you have to "flush" them manually. The 2nd feeback method is not triggered automatically, you have to do it yourself manually.

Regards,
Didier

Friedrich (hitlbs) said : #3

Hi Didier,

Thanks. My current situation is that I have to use the non-piggybacking method frequently since there is only one-way application. Can you illustrate how to flush the feedback MANUALLY?

Shall I call
rohc_feedback_flush(decomp->compressor, feedback, feedbacksize);
at anywhere having
c_piggyback_feedback(decomp->compressor, feedback, feedbacksize);
in your codes?

If so, how often shall I call the rohc_feedback_flush() function? Does it conform to the RFC3095? For example, in practice, several 4-byte feedbacks can be combined to send, e.g., two feedbacks with 8 bytes can be sent in one transmission. Does the rohc_feedback_flush() function consider this scenario? Or this logic of how often to send totally depends on me to implement?

Thanks,
Friedrich

Hello,

The c_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. Instead use the rohc_feedback_flush() to extract the feedbacks from the ROHC compressor.

You can call rohc_feedback_flush() at any rate you want. The more you wait, the more feedback data you will get: sending every feedback chunk separately may have a cost (more link layer overhead for example). The more you wait, the more delay you add to the transmission of the feedback: negative feedbacks are only useful if they reach quickly the other endpoint. So, you need to do some tradeoffs according to your own use case ;-)

When you call the rohc_feedback_flush() function, the ROHC library with glue together as many available feedback chunks as possible (the limit is the length of the buffer given to the function).

Regards,
Didier

Friedrich (hitlbs) said : #5

Thank you for your nice answer, Didier.

After using rohc_feedback_flush() to dump the feedback packet at the receiver side, how do we process this packet at the transmitter side?

For example, I "flushed" one feedback packet to obuf which contains only 5 bytes. This 5-byte packet goes through PDCP, RLC, PHY...PHY, RLC, PDCP, and shows up as the same but only at the transmitter side. Now I guess that RoHC compressor needs to recognize it, and to make use of this feedback information. Which function can I call to fulfill it?

I noticed there were two functions doing this kind of job in the decompressor: d_decode_feedback_first, d_decode_feedback. But for this particular 5-byte feedback-only packet, we don't need to decompress it since there was no compression at all. Could you please elaborate my concern then?

Thanks a lot,
Friedrich

Friedrich,

> After using rohc_feedback_flush() to dump the feedback packet at the
> receiver side, how do we process this packet at the transmitter side?
>
> For example, I "flushed" one feedback packet to obuf which contains
> only 5 bytes. This 5-byte packet goes through PDCP, RLC, PHY...PHY, RLC,
> PDCP, and shows up as the same but only at the transmitter side. Now
> I guess that RoHC compressor needs to recognize it, and to make use
> of this feedback information. Which function can I call to fulfill it?

Use rohc_decompress() on the decompressor associated with the compressor on the "transmitter" side.

> I noticed there were two functions doing this kind of job in the
> decompressor: d_decode_feedback_first, d_decode_feedback. But
> for this particular 5-byte feedback-only packet, we don't need to
> decompress it since there was no compression at all. Could you please
> elaborate my concern then?

Don't use them. They are private functions. The 5-byte feedback-only packet does not need to be decompressed but the way to parse the feedback data is through rohc_decompress(). Parsing a feedback+compressed-data packet and a feedback-only packet is done with the same code. When the rohc_decompress() function hits feedback, it decodes it and gives it to its associated local compressor. With a feedback-only packet, the rohc_decompress() function will return ROHC_FEEDBACK_ONLY and the obuf buffer will be empty.

Regards,
Didier

Friedrich (hitlbs) said : #7

Thanks Didier Barvaux, that solved my question.