rohc team mailing list archive

[Didier Barvaux <didier@xxxxxxxxxxx>]

Hello,


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

I think that the current library sends only one single
co_common/seq_8/rnd_8 packet when the list of TCP options changes its
structure. If that packet is lost, the structure change is lost as well.

To circumvent this, the ROHC protocol requires that the compressor
sends the changes until it is confident enough that the decompressor
got the changes.

So, one packet is not enough. It is not robust enough to packet loss or
reordering. It should be sent N times at least. N shall be configurable
because it depends on network type and conditions.


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

I think the decompressor detects the problem. The CRC shall catch that
the decompressor generated a wrong IP/TCP packet and shall drop it. Do
you experience a different behaviour?


> Shouldn't the decompressor send a feedback with a NAK at this point?

Yes, it should. The library however rate-limit the NACK, so maybe
several errors should be required for a NACK to be transmitted.


> By the way, is the feedback always sent piggybacked on an outgoing
> packet?  In my test, the data is always transmitted one direction.

The feedback could be piggybacked or not.


> How is the feedback sent, if the receiver fails to send and ACK?

Sorry I doesn't understand the last question.


Regards,
Didier

Attachment: signature.asc
Description: PGP signature