[rohc] WG review: draft-ietf-rohc-over-reordering-02.txt

[Carl Knutsson <carl.knutsson at effnet.com>]

Hi all,

I think the draft is in good shape. I have some comments and suggestions 
concerning the handling of decompression failures and local repairs 
caused by late packets.

From 5.2.3 Detected Decompression failures:

"Fortunately, as the outcome of the decompression of updating packets 
can be verified, the decompressor can reliably detect decompression 
failures caused by reordering and discard the packet."

When reading this sentence, you get the impression that the decompressor 
can detect if the decompression failure is caused by reordering. That is 
not the case, decompressor failures are detected, but whether it is 
caused is packet loss bit errors or reordering is unknown. The sentence 
is correct, but when I read it the first time, I got the impression that 
the cause of the decompression failure could be identified.

I believe the reference to in section 5.3.2.3 in rfc3095, in the last 
sentence of this section, should be changed to section 5.3.2.2.3. 
Section 5.3.2.3 is "Feedback in Unidirectional mode" and section 
5.3.2.2.3 is "Actions upon CRC failures".

6.1.2.3. Considerations for Local Repair Mechanisms

I have some comments on the local repair for late updating packets. The 
decompressor should not always try local repair for late packets. Late 
packets, decompressed by moving backwards into the interpretation 
interval, could cause the decompressor to revert to an old context. If 
the local repair for the late packet is successful, the next in-order 
packet could potentially be outside the interpretation interval. This 
will decrease the robustness against packet loss. The algorithm 
suggested in rfc3095 section 5.3.2.2.5 would discard at least two 
packets, if not more, when repairing the context.

Instead, if the decompressor is confident that the packet is late, it 
may be allowed to pass the packet on to upper layers or discard the 
packet without updating the context. The compressor can be confident 
that a packet is late by going backwards in the interpretation interval 
and try to decompress the the packet, using the CRC to validate the 
attempt (as suggested in this section).

In rfc 3095 section 5.3.2.2.3, a decompression failure caused by a late 
packet outside the interpretation interval, will add to the k out of n 
check. Several late packets could cause decompressor, with a correct 
context, to discard all packets until the context state is refreshed. 
Allowing the decompressor to ignore context updates from suspected late 
packet could decrease it vulnerability against late packets.

I suggest that we change the this section to something like this:

"When decompression fails, and if reordering is believed to be cause of 
this failure, subsequent decompressions may be attempted for 
sequentially late packets by going backwards in the interpretation 
interval (as opposed to moving forward for local repair). If one of the 
decompression attempt is successful, the late packet may be passed on to 
upper layers with or without updating the decompressor context. If the 
subsequent decompression attempt fails, the packet should be handled 
according to [3] section 5.3.2.2.3."

[3] is rfc3095 and section 5.3.2.2.3 is "Action upon CRC failure". We 
leave it up to the implementor determine if it is a late packet and if 
the decompressor context should be updated or not. A late packet could 
include a new update vital to the decompressor context, but it could 
also include an old update that will destroy the context. The 
implementor have the choice to ignore any special treatment for late 
packet and handle it according to section 5.3.2.2.3 of rfc3095. To hint, 
without getting to much into detail, that it is not always for the best 
to immediately update the context for a late packet, even if it is 
decompressed successfully and validated by the CRC.


Brgds,

/Carl Knutsson, Effnet AB

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc