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

[Kristofer Sandlund <kristofer.sandlund at effnet.com>]

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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt