Subject: RE: [rohc] "SC-FC ping pong"

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 26 May 2006 20:01:14 +0200

Hi Lajos,

The situation that you are describing seems to be an example
of a very bad compressor and a very bad decompressor
implementation. You are addressing parts of the 3095
specifications that are left open to implementers, i.e.
decompressor feedback logic, recovery and compressor robustness.

I understand that you would like to ensure that a good
implementation does not suffer from interacting with another,
less good implementation. Specifications cannot cover for bad
design choices. So, I do not think that this needs be solved
through more standard text.

A smart implementer will make sure that its decompressor
monitors what it has tried to update in conjunction with the
SN received in the feedback to produce proper repairs when
receiving NACKs (and/or Static-NACKs). Similarly, a smart
implementer will make sure that upon repeated failures of
packet types other than IR and/or IR-DYN, i.e.
repeated failures of packets that verify the outcome of the
decompression process (thus including the static part), a
Static-NACK would ultimately be sent.

Note finally that it would be a rather bad design choice for
a compressor not to make use of the SN it receives in a
feedback, e.g. in a NACK(SN=X), to figure out that it has
sent IR packets since that particular SN=X.

/Ghyslain

> Hi RoHCers,
> 
> Say the decompressor is in state FC, and the compressor wants to
> update a field in static part (O-mode). Say the OA period is short
> and all updating IR packets are lost. The subsequent UO-0 packets
> cannot be successfully decompressed due to the old static field. As
> a result, the decompressor transits to state SC and probably sends
> NACK, after some CRC failures (there is no way for the decompressor
> to find out what went wrong). In this case, it is completely legal
> for the compressor to send IR-DYN - even though the earlier update
> of a field in the static part may be a good reason not to do so. On
> receipt of the IR-DYN, the decompressor happily transits from SC to
> FC (even though the IR-DYN is also incorrect as the
> CRC-8 does not protect the original header), but alas, the UO-0
> packets would fail again, driving the couple to a neverending story.
> The decompressor would produce only packets with incorrect header
> when IR-DYN received and nothing (besides CRC failure) otherwise.
> 
> I think, the problem is that the specification does not prohibit such
> a situation. We may call it deadlock, because there is no way to
> recover. This (maybe simple but still RFC 3095 compliant) compressor
> would never learn about the failure.
> 
> I can recommend two alternatives that guarantee recovery:
> a) Explicitly require compressors to avoid sending IR-DYN in such
> cases; or b) do not let decompressors to transit from SC to FC after
> successful decompression of IR-DYN, which would drive it to state SC
> after some CRC failures and so to send STATIC-NACK.
> 
> Looking forward to reading your opinion and comments.
> 
> Best regards,
> Zacco

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc