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

[Colin Perkins <csp at csperkins.org>]

Hi,

On 28 Apr 2004, at 12:08, Kristofer Sandlund wrote:
> 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.
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.

> 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."
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/


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt