Subject: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs-00.txt

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 28 Apr 2004 13:08:25 +0200

Hi all!

Here are some comments on draft-ietf-avt-hc-mpls-reqs-00.txt

Comment 1:
**********
When reordering is discussed in section 3, it is not made clear how the HC 
scheme is supposed to handle reordering. Is the requirement that the 
decompressor should be able to correctly decompress all reordered packets, or is 
it enough that it can ensure no incorrectly decompressed packets will be 
forwarded, i.e. avoid context damage? I assume that correct decompression is the 
intention, but it could be made more clear.

Comment 2:
**********
* Section 4:
 >[ECRTP] minimizes feedback based error recovery using CONTEXT_STATE
 >packets to make cRTP more tolerant of packet loss, <snip>

Unless I misread this, doesn't this say that sending less feedback will make 
cRTP more tolerant to packet loss?

Is the intention to say:
"ECRTP uses mechanisms that make cRTP more tolerant to packet loss and it 
thereby helps to minimize the use of feedback based error recovery 
(CONTEXT_STATE packets)."

Comment 3:
**********
* Section 4:
 > ECRTP also is able to accommodate out-of-sequence packets.

I am a little worried about this unconditional belief in eCRTPs ability to 
handle reordered packets. RFC3545 does not explicitly say HOW an eCRTP 
implementation should handle reordered packets and an agressive implementation 
of eCRTP will not have much higher protection against reordered packets than 
CRTP. Only if you adapt eCRTP to send absolute values more often will it handle 
reordering well (which is only hinted at the end of section 2.1 of RFC3545, but 
does not say explicitly that it is for reordering).

Therefore, a HC-over-MPLS solution using eCRTP would probably have to contain 
some eCRTP implementation guidelines, and it is not clear to me why such 
implementation concerns for eCRTP should differ much from those for ROHC (see 
below).

Comment 4:
**********
* Section 4:
 > However, ROHC currently does not accommodate packet reordering
 > needed to protect against out-of-sequence packets that can occur on MPLS
 > LSPs, and would need to be extended to do so.

What 3095 (ROHC) says is that the spec is not written with reordering in mind 
but it does not say if ROHC can handle some reordering anyway or not. Even a 
default implementation of ROHC RTP will be able to handle a small degree of 
reordering. Also, a ROHC implementation can be adapted in a similar way
as eCRTP (i.e. sending more bits) so that it handles reordering better. Exactly 
_how_ to do this is done needs to be explained though, but the same must be done 
for eCRTP.

Therefore, my conclusion is that from the specs (3095 and 3545), neither of the 
schemes is very good at handling reordering in their default configurations. 
But, with implementation adaptations (without modifying any of the specs) both 
can be made to handle reordering in a much better way. I thus think the text 
regarding the two compression schemes should be more similar to each other.

For example, the following text could be used in both:

"A default [eCRTP/ROHC] implementation will probably not be able to meet the 
requirements set up for reordering in this draft, and therefore some 
implementation adaptations to address this would have to be presented in a 
solution for HC over MPLS."

Best regards,
	Kristofer Sandlund, Effnet AB

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 28 Apr 2004 15:29:17 +0100

Hi,

On 28 Apr 2004, at 12:08, Kristofer Sandlund wrote:
> When reordering is discussed in section 3, it is not made clear how 
> the HC scheme is supposed to handle reordering. Is the requirement 
> that the decompressor should be able to correctly decompress all 
> reordered packets, or is it enough that it can ensure no incorrectly 
> decompressed packets will be forwarded, i.e. avoid context damage? I 
> assume that correct decompression is the intention, but it could be 
> made more clear.

I would suggest that the requirement is that packet reordering MUST NOT 
cause incorrectly decompressed packets to be forwarded on from the 
decompressor. We would clearly like a solution that lets the 
decompressor correctly decompress reordered packets, but that's an 
optimisation rather than a hard requirement.

> Unless I misread this, doesn't this say that sending less feedback 
> will make cRTP more tolerant to packet loss?
>
> Is the intention to say:
> "ECRTP uses mechanisms that make cRTP more tolerant to packet loss and 
> it thereby helps to minimize the use of feedback based error recovery 
> I am a little worried about this unconditional belief in eCRTPs 
> ability to handle reordered packets. RFC3545 does not explicitly say 
> HOW an eCRTP implementation should handle reordered packets and an 
> agressive implementation of eCRTP will not have much higher protection 
> against reordered packets than CRTP. Only if you adapt eCRTP to send 
> absolute values more often will it handle reordering well (which is 
> only hinted at the end of section 2.1 of RFC3545, but does not say 
> explicitly that it is for reordering).
>
> Therefore, a HC-over-MPLS solution using eCRTP would probably have to 
> contain some eCRTP implementation guidelines, and it is not clear to 
> me why such implementation concerns for eCRTP should differ much from 
> those for ROHC (see below).
>
> Comment 4:
> **********
> * Section 4:
> What 3095 (ROHC) says is that the spec is not written with reordering 
> in mind but it does not say if ROHC can handle some reordering anyway 
> or not. Even a default implementation of ROHC RTP will be able to 
> handle a small degree of reordering. Also, a ROHC implementation can 
> be adapted in a similar way
> as eCRTP (i.e. sending more bits) so that it handles reordering 
> better. Exactly _how_ to do this is done needs to be explained though, 
> but the same must be done for eCRTP.
>
> Therefore, my conclusion is that from the specs (3095 and 3545), 
> neither of the schemes is very good at handling reordering in their 
> default configurations. But, with implementation adaptations (without 
> modifying any of the specs) both can be made to handle reordering in a 
> much better way. I thus think the text regarding the two compression 
> schemes should be more similar to each other.
>
> "A default [eCRTP/ROHC] implementation will probably not be able to 
> meet the requirements set up for reordering in this draft, and 
> therefore some implementation adaptations to address this would have 
> to be presented in a solution for HC over MPLS."

I have no preference for the exact wording, but agree that it would be 
best if the draft can avoid making any judgement on the suitability of 
either ECRTP or ROHC in environments where reordering can occur.

I had a couple of other comments on the draft:

  - The last paragraph of section 4 suggests a couple of places where 
extensions
    to various MPLS-related protocols are needed. This may well be the 
case, but
    we haven't yet done the design work to know for certain. Can the 
draft be
    reworded to suggest that "new objects may need to be defined" and 
that
    "extensions to LDP may be needed", etc?

  - The definition of the RFC 2119 keywords is in the wrong place. Can 
it be moved
    to the start of Section 3, rather than being before the introduction 
(else the
    RFC editor will have to do it)?

These should all be relatively minor changes.

-- 
Colin Perkins
http://csperkins.org/