[AVT] Comments on draft-ietf-avt-hc-mpls-reqs-00.txt
Kristofer Sandlund <kristofer.sandlund@effnet.com> Wed, 28 April 2004 12:22 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11849 for <avt-archive@odin.ietf.org>; Wed, 28 Apr 2004 08:22:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInxa-0000OV-Ow for avt-archive@odin.ietf.org; Wed, 28 Apr 2004 08:14:42 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCEg1F001514 for avt-archive@odin.ietf.org; Wed, 28 Apr 2004 08:14:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInoD-0005Mk-Iq; Wed, 28 Apr 2004 08:05:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BImxn-0005MS-Rq for avt@optimus.ietf.org; Wed, 28 Apr 2004 07:10:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06380 for <avt@ietf.org>; Wed, 28 Apr 2004 07:10:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BImxh-00046I-HC for avt@ietf.org; Wed, 28 Apr 2004 07:10:45 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BImwj-0003qZ-00 for avt@ietf.org; Wed, 28 Apr 2004 07:09:46 -0400
Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1BImvn-0003M1-00 for avt@ietf.org; Wed, 28 Apr 2004 07:08:47 -0400
Received: from effnet.com (c-307871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.48]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i3SA84U2000921 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Apr 2004 12:08:05 +0200
Message-ID: <408F90A9.1060108@effnet.com>
Date: Wed, 28 Apr 2004 13:08:25 +0200
From: Kristofer Sandlund <kristofer.sandlund@effnet.com>
Organization: Effnet
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
X-Enigmail-Version: 0.76.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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
- [AVT] Comments on draft-ietf-avt-hc-mpls-reqs-00.… Kristofer Sandlund
- Re: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs… Colin Perkins
- RE: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs… Lars-Erik Jonsson (LU/EAB)
- Re: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs… Colin Perkins
- RE: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs… Ash, Gerald R (Jerry), ALABS
- RE: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs… Ash, Gerald R (Jerry), ALABS