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

From: Carl Knutsson <[email-masked]>
Date: Fri, 08 Apr 2005 14:00:16 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 8 Apr 2005 15:34:11 +0200

Carl,

Thanks for the review, proposed actions to your comments can be found inline.

/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Carl Knutsson
> Sent: den 8 april 2005 14:00
> To: [email-masked]
> Subject: [rohc] WG review: draft-ietf-rohc-over-reordering-02.txt
> 
> 
> Hi all,
> 
> 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.

OK, true, so what about:
"Fortunately, as the outcome of the decompression of updating packets can be verified, the decompressor can reliably detect decompression failures, including those caused by reordering, and discard the packet. Note that local repairs, subject to the limitations stated in [2] section 5.3.2.2.3, can still be performed."

> 5.3.2.2.3 is "Actions upon CRC failures".

Thanks, corrected!

> 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 packet, using the CRC to validate the 
> 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.
> 
> "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 

I'm happy with this text as suggested!

/L-E