[mpls] [mpls-tp] Several open issues on draft-xiao-mpls-tp-throughput-estimation-00

xiao.min2@zte.com.cn Fri, 06 August 2010 05:36 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E5D3A684D; Thu, 5 Aug 2010 22:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.787
X-Spam-Level:
X-Spam-Status: No, score=-100.787 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faSPNZyrjJE0; Thu, 5 Aug 2010 22:36:07 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 2999A3A6832; Thu, 5 Aug 2010 22:36:04 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951570495873; Fri, 6 Aug 2010 13:35:25 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 14146.1570495873; Fri, 6 Aug 2010 13:27:50 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o765ZhQx023941; Fri, 6 Aug 2010 13:35:44 +0800 (CST) (envelope-from xiao.min2@zte.com.cn)
To: mpls@ietf.org, mpls-tp@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFB24FBA92.2A65AF1E-ON48257777.001E0969-48257777.001EB7AE@zte.com.cn>
From: xiao.min2@zte.com.cn
Date: Fri, 06 Aug 2010 13:35:13 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-08-06 13:35:35, Serialize complete at 2010-08-06 13:35:35
Content-Type: multipart/alternative; boundary="=_alternative 001EB7AB48257777_="
X-MAIL: mse2.zte.com.cn o765ZhQx023941
Subject: [mpls] [mpls-tp] Several open issues on draft-xiao-mpls-tp-throughput-estimation-00
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2010 05:36:10 -0000

Hi all,

In light of the previous comments and discussions on this draft, there are 
still some open issues which need to be closed before updating it, so I 
want to request for your opinions, details as follow:

1. Wouldn't it be better to have a threshold on the acceptable frame loss 
rate and not require absolutely no packet loss?
This question was raised by Ayal Lior (Ayal.Lior@celtro.com) As I know in 
practice the threshold is a configurable parameter when executing 
throughput measurement, but in RFC1242 and RFC2544 the throughput is 
defined as that way no packet loss permitted.

2. How to align the format of test data packets between 
draft-boutros-mpls-tp-li-lb-01 and this draft?
As I said in my presentation of this draft, IMO in order to simplify the 
implementation, the format of test data packets should be the same whether 
it's used for data plane loopback or throughput estimation. Now the format 
of data packets defined in section 5 of draft-boutros-mpls-tp-li-lb-01 is 
different from the format of test packets defined in section 3.2 of this 
draft. I prefer the format with OAM encapsulation defined in this draft, 
and my reason is that with this format it's easy to distinguish the test 
data packets from other packets when counting them.

3. Is there a need to simplify the procedures defined in this draft and 
how?
I received the comment both in the mailing list and in private discussions 
that the procedures defined in this draft are some complex, but I have no 
idea about the proposed simplified solution, and IMHO the procedures 
defined in this draft are enough efficient and also the usual operations 
for throughput measurement. Hope for your concrete suggestions.

Any other comment and discussion are welcome.

Best Regards,
Xiao Min