rohc team mailing list archive

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

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

Hi Didier:

You said: 

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

Will sending these packets first eliminate the problem?   I think there are still chances the inconsistent list struct will occur.  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.
Shouldn't the decompressor send a feedback with a NAK at this point?  By the way, is the feedback always sent piggybacked on an outgoing packet?  In my test,
the data is always transmitted one direction.   How is the feedback sent, if the receiver fails to send and ACK?

Thanks and kind regards,

TW