rohc team mailing list archive

[Didier Barvaux <didier@xxxxxxxxxxx>]

Re,
 
> >> Shouldn't the decompressor send a feedback with a NAK at this
> >> point?
> 
> > Yes, it should. The library however rate-limit the NACK, so maybe
> > several errors should be required for a NACK to be transmitted.
> 
> I am taking  the above statement as saying when my list struct is
> inconsistent and causes the problem I saw, a NACK might not be sent
> to the compressor, unless there are several errors?

CRC mismatches might happen in real world because a loss burst. In this
case, all following packets might well cause CRC mismatches too until
the situation becomes fine again.

Sending a NACK for every CRC mismatch is not a good thing. It will cause
the compressor to lower its compression level much more than required.
That's the reason of the rate-limiting algorithm.

The current algorithm doesn't however conform to RFC. See open bug:
 https://bugs.launchpad.net/bugs/902465

 
> >> By the way, is the feedback always sent piggybacked on an outgoing 
> >> packet?  In my test, the data is always transmitted one direction.
> 
> >The feedback could be piggybacked or not.
> 
>   How is this done in the library?  Does the library create a TCP
> packet just for the feedback, without data? If you can point me to
> the code where it is done, I will greatly appreciate it.

If piggybacking is used, the library does everything alone. Otherwise,
you have to transmit the feedback yourself. The ROHC library is
transport-agnostic, so it cannot decide to create a TCP packet. The
developer that uses the library has to.

See the rohc_feedback_*() functions on:
http://rohc-lib.org/doc/rohc-doc-r1027/group__rohc__comp.html

 
> >> How is the feedback sent, if the receiver fails to send and ACK?
> 
> >Sorry I doesn't understand the last question.
> 
>    In my test cases, all data are transmitted one way.  The only
> packet coming back from the receiver, excluding the initial and final
> handshakes, should be just ACK's.  I assume that any feedback is
> piggybacked on the ACK to the sender.  But you said a feedback can be
> sent without piggybacking.  My question was how the feedback can be
> sent by itself.

Ok, I understand now. When saying "ACK", you mean "TCP ACK", not "ROHC
feedback ACK" :)

If you don't handle the feedback yourself, it is piggybacked with the
next ROHC packet in the associated return channel. If the traffic is
scarce on the return channel, it won't be efficient.
In such a case, call the rohc_feedback_flush() function to retrieve the
feedback (see previous link for doc). For the best reactivity, call it
after every successful/failed decompression.

Regards,
Didier

Attachment: signature.asc
Description: PGP signature