Didier: Thanks for the detailed reply. My understanding of the problem is similar to yours, and I agree that it is mostly likely causes 3 and 4. Again, we are running tests with namespaces on the same kernel, so the packets are transmitted and received very fast. If we slow down the transmission rate - such as using much smaller packets and waiting a few milliseconds between each packet, the problems do not appear even after the same amount of bytes have been transmitted. Also, when I extend the sizes of the tcp_txmem and tcp_rxmem in the kernel, and disable tcp_timestamps, tcp_sack, and set tcp_low_latency to run, the tests run much better with occasional hangs - which I believe have to do with the namespace rather than the ROHC code.
Thanks and kind regards, TW -----Original Message----- From: Rohc [mailto:[email protected]] On Behalf Of Didier Barvaux Sent: Sunday, April 20, 2014 4:12 PM Cc: [email protected] Subject: Re: [Rohc] ROHC TCP dynamic field changes Hello, > Here are a few packets I captured that caused the issues I sent to > you: > > packet before compression: > [...] The ROHC packets seem well formed. It is one seq_1 packet. The structure of the list at decompressor does not match the one of the ROHC packet: the seq_1 got some bits for one SACK option, but the decompressor doesn't know that option. The seq_1 packet is not allowed if the structure of the TCP option list changes, so either: 1/ The ROHC compressor didn't detected the change in the list structure: not very probable since the option is present in the seq_1 packet. 2/ The ROHC compressor created a ROHC seq_1 packet when it should have not. I checked the code, there is no way to create a seq_1 packet if the list structure changed, only co_common/seq_8/rnd_8 are possible. 3/ The seq_1 packet is a late arrival. The list structure changed a few packets before (SACK added), then changed a few packet after (SACK removed). The packet is late, so it is received while the list already changed back to its previous structure. 4/ The packets before the seq_1 packet were lost. The list structure changed a few packet (SACK added), then changed a few packet after (SACK removed). Because the packets that changed the list structure were lost, the seq_1 packet is received with the old list structure. The most probable cases are 3 and 4. To mitigate them, the compressor should send several co_common/seq_8/rnd_8 packets with the changed list structure before using other packet types, such as seq_1. If I got enough time tomorrow, I'll try to make a change in this way. Regards, Didier _______________________________________________ Mailing list: https://launchpad.net/~rohc Post to : [email protected] Unsubscribe : https://launchpad.net/~rohc More help : https://help.launchpad.net/ListHelp
