rohc team mailing list archive

[Didier Barvaux <didier@xxxxxxxxxxx>]

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

Attachment: signature.asc
Description: PGP signature