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
signature.asc
Description: PGP signature
_______________________________________________ Mailing list: https://launchpad.net/~rohc Post to : [email protected] Unsubscribe : https://launchpad.net/~rohc More help : https://help.launchpad.net/ListHelp
