rohc team mailing list archive

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

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:rohc-bounces+tak.wong=ll.mit.edu@xxxxxxxxxxxxxxxxxxx] On Behalf Of Didier Barvaux
Sent: Sunday, April 20, 2014 4:12 PM
Cc: rohc@xxxxxxxxxxxxxxxxxxx
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