rohc team mailing list archive

["Wong, Tak - 0665 - MITLL" <Tak.Wong@xxxxxxxxxx>]

Didier:

>> The decompressor should be able to detect the inconsistency, 
>> particularly with an ACK packet that has more options than the option 
>> list, and a list struct that has options beyond the rohc packet.

>I think the decompressor detects the problem. The CRC shall catch that the decompressor generated a wrong IP/TCP packet and shall drop it. Do you experience a >different behaviour?

No, I see the same behavior.  What I meant was if the decompressor detects the problem, a NACK feedback should be sent to report that decompressor failed.  That is a more deterministic handling of the issue.

>> 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?

>> 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.

>> 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.

Thanks and kind regards,

TW