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

Kristofer,

Thanks for your comments and suggestions.

> 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 agree with Colin and Lars-Erik that the requirement is that packet reordering not cause incorrectly decompressed packets to be forwarded on from the decompressor.  We'll clarify that and add the 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)."

Yes, this is the intention, thanks for the suggested rewording.

> 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 aggressive 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).

Fair comment.  We'll reword the discussion of ECRTP reordering to reflect your comments.

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

OK, I agree with Colin, we'll reword the discussion to avoid judging the suitability of either ECRTP or ROHC where reordering can occur.

Thanks,
Jerry 

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