[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] WG review: draft-ietf-rohc-over-reordering-02.txt
Carl,
Thanks for the review, proposed actions to your comments can be found inline.
/L-E
> -----Original Message-----
> From: rohc-bounces at ietf.org [mailto:rohc-bounces at ietf.org]On Behalf Of
> Carl Knutsson
> Sent: den 8 april 2005 14:00
> To: rohc at ietf.org
> Subject: [rohc] WG review: draft-ietf-rohc-over-reordering-02.txt
>
>
> 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.
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."
> 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".
Thanks, corrected!
> 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 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."
I'm happy with this text as suggested!
/L-E
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc