> I implemented the list_trans_nr as you suggested, and it seemed to > alleviate the mismatching list_option issue. However, I am getting > other decompression errors relating to CRC check. > > You said in a previous email: > > >> 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. > > I am seeing the following errors during test runs. Are these the > results of loss burst, as you mentioned? So, the proper way to > handle these is a feedback with a NACK? Thanks and kind regards, TW
Failure for CRC checks means that the decompression was not correct. It says nothing of the cause of that failure. It may be a bug in the TCP profile or a "normal" behaviour related to a loss burst. To distinguish the two cases, I would need more information. For example, a network capture of the last 100-200 packets or the library traces for the last 100-200 packets. 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
