From yaakov_s@rad.com Sun Aug 1 23:30:04 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CFD3A67D4 for ; Sun, 1 Aug 2010 23:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_20=-0.74] 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 tBAiQLWjzeih for ; Sun, 1 Aug 2010 23:29:58 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id 3966D3A67AF for ; Sun, 1 Aug 2010 23:29:56 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 02 Aug 2010 09:30:22 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Mon, 2 Aug 2010 09:29:37 +0300 From: Yaakov Stein To: Henk Uijterwaal , Tempia Bonda Alberto Date: Mon, 2 Aug 2010 09:29:37 +0300 Thread-Topic: [ippm] WG interest in Multicast performance monitoring drafts Thread-Index: AcsvFJSQ6ktDUAnFTFCag+CLAly5DQC9fr7w Message-ID: <48E7911F78327A449A9FB95637667286828EFF8C@exrad4.ad.rad.co.il> References: <9FCB2ACF14591E4DAF4180D4010E3618A777ECCD07@GRFMBX702BA020.griffon.local> <9FCB2ACF14591E4DAF4180D4010E3618A7786D7685@GRFMBX702BA020.griffon.local> <4C4FF248.1020109@ripe.net> <4C516B9A.1080502@ripe.net> In-Reply-To: <4C516B9A.1080502@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "matt@internet2.edu" , IETF IPPM WG Subject: Re: [ippm] WG interest in Multicast performance monitoring drafts X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 06:30:04 -0000 I see two distinct issues here : 1) passive monitoring=20 2) multicast performance If IPPM is interested in entering into passive monitoring methods, then perhaps it should define these for unicast flows first. (As I mentioned at the meeting, MEF has developed a lot of this for layer-2= .) Multicast performance is indeed an important topic to be studied. Y(J)S -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: Thursday, July 29, 2010 14:53 To: Tempia Bonda Alberto Cc: matt@internet2.edu; IETF IPPM WG Subject: [ippm] WG interest in Multicast performance monitoring drafts IPPM Group, Last Monday, Alberto and others presented this set of drafts: > > at the upcoming IPPM meeting in Maastricht we will present a draft abou= t > > multicast performance monitoring > > (draft-bipi-mboned-ip-multicast-pm-requirement-01). > > Requirement draft: > > http://tools.ietf.org/html/draft-bipi-mboned-ip-multicast-pm-requiremen= t-01 > > Solution drafts: > > http://tools.ietf.org/html/draft-liu-mboned-multicast-realstream-monito= r-02 > > http://tools.ietf.org/html/draft-cociglio-mboned-multicast-pm-00 We would like to know if people consider this topic appropriate for the IPPM WG, and if so, if there is interest to work on this topic. The drafts discuss passive measurements of actual traffic streams, using the metrics developed in IPPM. In the current charter, this work is out of scope, so picking it up would require a charter change. Obviously, we only want to do this if there is sufficient interest in the work. Please respond to the list or the chairs in private by September 13. Matt & Henk --=20 ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.ne= t RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------= --- I confirm today what I denied yesterday. Anonymous Politician. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From yaakov_s@rad.com Mon Aug 2 00:04:03 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC363A67D3 for ; Mon, 2 Aug 2010 00:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_20=-0.74] 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 Jzv7HmGddO71 for ; Mon, 2 Aug 2010 00:03:59 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id B71303A6834 for ; Mon, 2 Aug 2010 00:03:57 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 02 Aug 2010 10:04:20 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Mon, 2 Aug 2010 10:03:38 +0300 From: Yaakov Stein To: IETF IPPM WG Date: Mon, 2 Aug 2010 10:03:38 +0300 Thread-Topic: TCP-layer performance metrics Thread-Index: AcsvFJSQ6ktDUAnFTFCag+CLAly5DQC9fr7wAABompA= Message-ID: <48E7911F78327A449A9FB95637667286828F0023@exrad4.ad.rad.co.il> References: <9FCB2ACF14591E4DAF4180D4010E3618A777ECCD07@GRFMBX702BA020.griffon.local> <9FCB2ACF14591E4DAF4180D4010E3618A7786D7685@GRFMBX702BA020.griffon.local> <4C4FF248.1020109@ripe.net> <4C516B9A.1080502@ripe.net> <48E7911F78327A449A9FB95637667286828EFF8C@exrad4.ad.rad.co.il> In-Reply-To: <48E7911F78327A449A9FB95637667286828EFF8C@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ippm] TCP-layer performance metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 07:04:03 -0000 I am working my way through draft-ietf-ippm-tcp-throughput-tm-04 . The draft is not defined with the accuracy and precision I have come to exp= ect=20 in IPPM documents. The efficiency measure is well-defined as the number of bytes NOT retransmi= tted. As Al mentioned, the example thereafter then gives a different measure -=20 the number of segments not retransmitted. Actually, both may be interesting= , but it needs to be clarified which is intended. The second metric is not a well defined performance measure at all. It is the amount of time needed to transfer some undefined amount of data u= sing some number of connections, and thus is highly dependent on the amount of data and the number of connec= tions. I understand that given the parameters you can come up with a number to exp= ect and compare what you measure to the expected, but if so, let's define this = comparison. I would propose normalizing by defining the ratio of the actual transfer ti= me=20 to the expected time (given the layer-3 1-way delay and bandwidth). This is a pure TCP-layer measure. Unfortunately, this measure is not completely divorced from the efficiency. One reason that it takes longer to transfer at the TCP-layer than at the IP= -layer is because of the retransmissions! =20 However, TCP's inherent flow control, and ECN if used, and the various algo= rithms for determining the RTT, etc. all have their effects. This is why the number of connections is important - using multiple connect= ions fools the transport into giving the user more weight. Regarding the traffic shaping/policing section, I am confused.=20 The traffic shaping and policing I am familiar with are done at layer-2, and are thus layer-2 quantities, although they of course affect TCP perform= ance. (W)RED is of course a transport quantity - but what is it that we are tryin= g to quantify here ?=20 The number of dropped packets is already covered in the efficiency measure. Y(J)S From L.Liang@surrey.ac.uk Mon Aug 2 01:20:03 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A683A6AD6 for ; Mon, 2 Aug 2010 01:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vVeUbyRrebZD for ; Mon, 2 Aug 2010 01:20:02 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 922C23A6ADB for ; Mon, 2 Aug 2010 01:20:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Liang@surrey.ac.uk X-Msg-Ref: server-12.tower-78.messagelabs.com!1280737228!25077011!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 13836 invoked from network); 2 Aug 2010 08:20:28 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-12.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 2 Aug 2010 08:20:28 -0000 Received: from EXMB05CMS.surrey.ac.uk ([169.254.1.86]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 2 Aug 2010 09:20:27 +0100 From: To: , , Date: Mon, 2 Aug 2010 09:20:18 +0100 Thread-Topic: [ippm] WG interest in Multicast performance monitoring drafts Thread-Index: AcsvFJSQ6ktDUAnFTFCag+CLAly5DQC9fr7wAAQVxiA= Message-ID: <8DD560EFEEC4004FA01F809C284B79755CF60E6966@EXMB05CMS.surrey.ac.uk> In-Reply-To: <48E7911F78327A449A9FB95637667286828EFF8C@exrad4.ad.rad.co.il> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] WG interest in Multicast performance monitoring drafts X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 08:20:03 -0000 Hi, guys,=20 I agree with Yaakov. All the existing group RFCs are based on active meas= urement. Passive measurement could be interesting but we need some foundati= on before calling it.=20 The performance of multicast is an important matter to study and it is wi= thin the group charter.=20 Cheers, Lei =20 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Yaa= kov Stein Sent: 02 August 2010 07:30 To: Henk Uijterwaal; Tempia Bonda Alberto Cc: matt@internet2.edu; IETF IPPM WG Subject: Re: [ippm] WG interest in Multicast performance monitoring drafts I see two distinct issues here : 1) passive monitoring 2) multicast performance If IPPM is interested in entering into passive monitoring methods, then per= haps it should define these for unicast flows first. (As I mentioned at the meeting, MEF has developed a lot of this for layer-2= .) Multicast performance is indeed an important topic to be studied. Y(J)S -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: Thursday, July 29, 2010 14:53 To: Tempia Bonda Alberto Cc: matt@internet2.edu; IETF IPPM WG Subject: [ippm] WG interest in Multicast performance monitoring drafts IPPM Group, Last Monday, Alberto and others presented this set of drafts: > > at the upcoming IPPM meeting in Maastricht we will present a draft=20 > > about multicast performance monitoring=20 > > (draft-bipi-mboned-ip-multicast-pm-requirement-01). > > Requirement draft: > > http://tools.ietf.org/html/draft-bipi-mboned-ip-multicast-pm-require > > ment-01 > > Solution drafts: > > http://tools.ietf.org/html/draft-liu-mboned-multicast-realstream-mon > > itor-02=20 > > http://tools.ietf.org/html/draft-cociglio-mboned-multicast-pm-00 We would like to know if people consider this topic appropriate for the IPP= M WG, and if so, if there is interest to work on this topic. The drafts discuss passive measurements of actual traffic streams, using th= e metrics developed in IPPM. In the current charter, this work is out of s= cope, so picking it up would require a charter change. Obviously, we only = want to do this if there is sufficient interest in the work. Please respond to the list or the chairs in private by September 13. Matt & Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.ne= t RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------= --- I confirm today what I denied yesterday. Anonymous Politician. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Barry.Constantine@jdsu.com Mon Aug 2 06:15:11 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE5D3A687E for ; Mon, 2 Aug 2010 06:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 pUL+IPSwu2VN for ; Mon, 2 Aug 2010 06:15:08 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with SMTP id 52C3E3A688C for ; Mon, 2 Aug 2010 06:14:52 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTFbE52nH0ej5ATPc6tMCXGoX17Ogban0@postini.com; Mon, 02 Aug 2010 06:15:34 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 06:15:13 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Mon, 2 Aug 2010 06:15:13 -0700 From: Barry Constantine To: Yaakov Stein , IETF IPPM WG Date: Mon, 2 Aug 2010 06:15:10 -0700 Thread-Topic: TCP-layer performance metrics Thread-Index: AcsvFJSQ6ktDUAnFTFCag+CLAly5DQC9fr7wAABompAACacvQA== Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B97CF646@MILEXCH1.ds.jdsu.net> References: <9FCB2ACF14591E4DAF4180D4010E3618A777ECCD07@GRFMBX702BA020.griffon.local> <9FCB2ACF14591E4DAF4180D4010E3618A7786D7685@GRFMBX702BA020.griffon.local> <4C4FF248.1020109@ripe.net> <4C516B9A.1080502@ripe.net> <48E7911F78327A449A9FB95637667286828EFF8C@exrad4.ad.rad.co.il> <48E7911F78327A449A9FB95637667286828F0023@exrad4.ad.rad.co.il> In-Reply-To: <48E7911F78327A449A9FB95637667286828F0023@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Aug 2010 13:15:13.0707 (UTC) FILETIME=[BE00A7B0:01CB3244] Subject: Re: [ippm] TCP-layer performance metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 13:15:11 -0000 Yaakov, Thank you for taking the time to read the draft in detail, your comments ar= e all very good. Let me try to answer them here: 1. You and Al both caught a typo in the draft for the TCP Efficiency metric= . It is definitely in bytes and the example was shown in segments; the ver= sion 5 will correctly show the example in bytes. 2. As for TCP Transfer time, I like what you propose and we have considered= this in the past "I would propose normalizing by defining the ratio of the= actual transfer time to the expected time". I think some network operator= s will like to see this as a single time (predicted versus measured) and ot= her cases where a ratio is preferred. I think a good compromise will be to= discuss both techniques and provide examples in the next version of the dr= aft. 3. "Unfortunately, this measure (TCP Transfer Time) is not completely divor= ced from the efficiency. One reason that it takes longer to transfer at th= e TCP-layer than at the IP-layer is because of the retransmissions!" - Als= o a very good point, we have considered spelling this out explicitly in the= document and that TCP Efficiency per connection should be measured along w= ith the overall TCP Transfer time. This too will be added into draft-05. 4. Traffic shaping versus policing. You are correct that traffic shaping /= policing are done at Layer 2 and that traffic shaping is a technique commo= nly used to smooth the bursty nature of TCP. RED techniques are also Layer = 2 oriented (buffer queue management), but are intended to directly affect T= CP by causing "early" loss which in turn causes TCP to decrease its transmi= ssion rate.=20 Traffic shaping and RED could be tested at Layer 2, although it would re= quire the emulation of TCP's burstiness, retransmission behavior, congestio= n control, etc.; the draft specifies a guideline to test for proper shaping= / RED settings in the network using actual TCP layer traffic. =20 So long answer to the question: this traffic shaping / policing section = shows how to test for proper traffic shaping configuration and RED by using= multiple TCP connections; very useful technique which is not well known. Again, your comments will be added to the next version 5 of the draft and t= hank you for taking the time to read in this detail! Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Yaa= kov Stein Sent: Monday, August 02, 2010 3:04 AM To: IETF IPPM WG Subject: [ippm] TCP-layer performance metrics I am working my way through draft-ietf-ippm-tcp-throughput-tm-04 . The draft is not defined with the accuracy and precision I have come to exp= ect=20 in IPPM documents. The efficiency measure is well-defined as the number of bytes NOT retransmi= tted. As Al mentioned, the example thereafter then gives a different measure -=20 the number of segments not retransmitted. Actually, both may be interesting= , but it needs to be clarified which is intended. The second metric is not a well defined performance measure at all. It is the amount of time needed to transfer some undefined amount of data u= sing some number of connections, and thus is highly dependent on the amount of data and the number of connec= tions. I understand that given the parameters you can come up with a number to exp= ect and compare what you measure to the expected, but if so, let's define this = comparison. I would propose normalizing by defining the ratio of the actual transfer ti= me=20 to the expected time (given the layer-3 1-way delay and bandwidth). This is a pure TCP-layer measure. Unfortunately, this measure is not completely divorced from the efficiency. One reason that it takes longer to transfer at the TCP-layer than at the IP= -layer is because of the retransmissions! =20 However, TCP's inherent flow control, and ECN if used, and the various algo= rithms for determining the RTT, etc. all have their effects. This is why the number of connections is important - using multiple connect= ions fools the transport into giving the user more weight. Regarding the traffic shaping/policing section, I am confused.=20 The traffic shaping and policing I am familiar with are done at layer-2, and are thus layer-2 quantities, although they of course affect TCP perform= ance. (W)RED is of course a transport quantity - but what is it that we are tryin= g to quantify here ?=20 The number of dropped packets is already covered in the efficiency measure. Y(J)S _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Sun Aug 8 20:59:38 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3173A6A33 for ; Sun, 8 Aug 2010 20:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.496 X-Spam-Level: X-Spam-Status: No, score=0.496 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_40=-0.185, STOX_REPLY_TYPE=0.001] 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 eEH+lxdSf1-a for ; Sun, 8 Aug 2010 20:59:38 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B4A0C3A6A30 for ; Sun, 8 Aug 2010 20:59:37 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6V0016I9Q2KW@szxga04-in.huawei.com> for ippm@ietf.org; Mon, 09 Aug 2010 11:58:50 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L6V000YS9Q1LZ@szxga04-in.huawei.com> for ippm@ietf.org; Mon, 09 Aug 2010 11:58:50 +0800 (CST) Date: Mon, 09 Aug 2010 11:58:49 +0800 From: Xiangsong Cui To: ippm@ietf.org Message-id: <00a701cb3777$2cc70ef0$80106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 03:59:39 -0000 Hi folks, I'm reading RFC5136 "Defining Network Capacity", and I have some question/comment on it. In section 2.1, the definition of link and path, it reads: We then define a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and destination D reside at N1 and Nn+1, respectively. I'm a bit confused by this definition, it seems the middle-boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the path between N1 and Nn+1, is this right? it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box should be a part of the path? Well, if the middle-boxes were part of the path, how about the "path capacity"? In section 2.3.3, it specifies, C(P,T,I) = min {1..n} {C(Ln,T,I)} I think this should be updated, as C(P,T,I) = min ( X, Y) X = min {2..n} {C(Nn,T,I)} Y = min {1..n} {C(Ln,T,I)} Of course, we should additionally define the capacity of node (transmitting/receiving/forwarding aspect), I think that is necessary. And there are also some other text need modification, such as IP-type-P Available Path Capacity. For example, in the path between node A and B as follows, A------link1------Router------link2------B For some certain packet/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of the router is 2G bps, how much is the capacity of the path between A and B? I believe the capacity is 2G bps (the neckbottle is the middle-box), but not 3G bps (as definition of RFC5136). Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft, to update this RFC. Any thought? Regards, Xiangsong From Xiangsong.Cui@huawei.com Sun Aug 8 22:12:42 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362CC3A68B9 for ; Sun, 8 Aug 2010 22:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 UF+2VMZLEQta for ; Sun, 8 Aug 2010 22:12:36 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3D8333A68B8 for ; Sun, 8 Aug 2010 22:12:36 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6V00CZXD5LUA@szxga01-in.huawei.com> for ippm@ietf.org; Mon, 09 Aug 2010 13:12:57 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L6V00JQ3D5LDY@szxga01-in.huawei.com> for ippm@ietf.org; Mon, 09 Aug 2010 13:12:57 +0800 (CST) Date: Mon, 09 Aug 2010 13:12:56 +0800 From: Xiangsong Cui To: ippm@ietf.org Message-id: <00eb01cb3781$87710130$80106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00a701cb3777$2cc70ef0$80106f0a@china.huawei.com> Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 05:12:45 -0000 I think the middle-boxes MUST be part of the path now, because if not, the path would lost connectivity. The links are not jointed each other, they must be connected by the middle-boxes. Regards, Xiangsong ----- Original Message ----- From: "Xiangsong Cui" To: Sent: Monday, August 09, 2010 11:58 AM Subject: [ippm] Question/comment on RFC5136 > Hi folks, > > I'm reading RFC5136 "Defining Network Capacity", and I have some question/comment on it. > > > In section 2.1, the definition of link and path, it reads: > > We then define a path P of length n as a series of > links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., > Nn+1). A source S and destination D reside at N1 and Nn+1, > respectively. > > I'm a bit confused by this definition, > it seems the middle-boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the path between N1 and Nn+1, is > this right? > it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box > should be a part of the path? > > > Well, if the middle-boxes were part of the path, how about the "path capacity"? > In section 2.3.3, it specifies, > > C(P,T,I) = min {1..n} {C(Ln,T,I)} > > I think this should be updated, as > > C(P,T,I) = min ( X, Y) > X = min {2..n} {C(Nn,T,I)} > Y = min {1..n} {C(Ln,T,I)} > > Of course, we should additionally define the capacity of node (transmitting/receiving/forwarding aspect), I think that is > necessary. > And there are also some other text need modification, such as IP-type-P Available Path Capacity. > > > For example, in the path between node A and B as follows, > > A------link1------Router------link2------B > > For some certain packet/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of the > router is 2G bps, how much is the capacity of the path between A and B? I believe the capacity is 2G bps (the neckbottle is the > middle-box), but not 3G bps (as definition of RFC5136). > > > Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft, > to update this RFC. > > Any thought? > > > Regards, > Xiangsong > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From vze275m9@verizon.net Mon Aug 9 05:25:52 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED5828C0E0 for ; Mon, 9 Aug 2010 05:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 nbqWMdhqkGem for ; Mon, 9 Aug 2010 05:25:51 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 2FB743A68DC for ; Mon, 9 Aug 2010 05:25:51 -0700 (PDT) Received: from vms170003.mailsrvcs.net ([unknown] [172.18.12.133]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6V009F1X7H6SQ0@vms173003.mailsrvcs.net> for ippm@ietf.org; Mon, 09 Aug 2010 07:26:06 -0500 (CDT) Received: from 128.244.9.9 ([128.244.9.9]) by vms170003.mailsrvcs.net (Verizon Webmail) with HTTP; Mon, 09 Aug 2010 07:26:05 -0500 (CDT) Date: Mon, 09 Aug 2010 07:26:05 -0500 (CDT) From: vze275m9@verizon.net To: Xiangsong.Cui@huawei.com Message-id: <1715847396.1637770.1281356765785.JavaMail.root@vms170003.mailsrvcs.net> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Originating-IP: [128.244.9.9] Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pfc@ieee.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 12:25:52 -0000 Remember, what we are talking about here is the IP capacity, not raw link c= apacity. So the definition includes the number of IP layer bits that can be= transmitted by the source and received by the destination. Lots of things = make this capacity smaller than the nominal link capacity measured at the p= hysical layer. Some things that can reduce the IP layer capacity include: n= ode backplane capcity, NIC implementation, queueing structure, buffer manag= ement, etc. etc. The notion of "middle-box" capacity is, in effect, include= d in the definition of IP capacity.

Regards,
Phil Chimento
Aug 9, 2010 12:00:47 AM, Xiangsong.Cui@huawei.com wrote:
Hi folks,

I'm re= ading RFC5136 "Defining Network Capacity", and I have some question/comment= on it.


In section 2.1, the definition of link and path, it read= s:

We then define a path P of length n as a series of
links= (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ...,
Nn+1)= . A source S and destination D reside at N1 and Nn+1,
respectively.
I'm a bit confused by this definition,
it seems the middle-boxes (= i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the p= ath between N1 and Nn+1, is
this right?
it is very strange to me, be= cause I remember we often mentioned "the middle-box in the path", does that= means the middle-box should
be a part of the path?


Well, if= the middle-boxes were part of the path, how about the "path capacity"?
= In section 2.3.3, it specifies,

C(P,T,I) =3D min {1..n} {C(Ln,T,I)}<= br>
I think this should be updated, as

C(P,T,I) =3D min ( X, Y)X =3D min {2..n} {C(Nn,T,I)}
Y =3D min {1..n} {C(Ln,T,I)}

Of co= urse, we should additionally define the capacity of node (transmitting/rece= iving/forwarding aspect), I think that is necessary.
And there are also = some other text need modification, such as IP-type-P Available Path Capacit= y.


For example, in the path between node A and B as follows,
=
A------link1------Router------link2------B

For some certain pack= et/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is= 3G bps, while the capacity of the
router is 2G bps, how much is the ca= pacity of the path between A and B? I believe the capacity is 2G bps (the n= eckbottle is the
middle-box), but not 3G bps (as definition of RFC5136)= .


Since this is a very late comment (on a frozen RFC document), = if you agree these are serious issues, I would submit a new draft, to
u= pdate this RFC.

Any thought?


Regards,
Xiangsong
_______________________________________________
ippm mailing list
ip= pm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
<= /body> From gfortaine@live.com Mon Aug 9 06:38:20 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681CD3A6AD7 for ; Mon, 9 Aug 2010 06:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_60=1] 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 rzAruC1LJ5iw for ; Mon, 9 Aug 2010 06:38:19 -0700 (PDT) Received: from blu0-omc4-s5.blu0.hotmail.com (blu0-omc4-s5.blu0.hotmail.com [65.55.111.144]) by core3.amsl.com (Postfix) with ESMTP id 220B63A695A for ; Mon, 9 Aug 2010 06:38:19 -0700 (PDT) Received: from BLU135-W17 ([65.55.111.137]) by blu0-omc4-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 06:38:52 -0700 Message-ID: X-Originating-IP: [90.34.179.207] From: Guillaume FORTAINE To: Date: Mon, 9 Aug 2010 15:38:52 +0200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2010 13:38:53.0041 (UTC) FILETIME=[34E21610:01CB37C8] Subject: [ippm] Extracting Performance Metrics from NetFLOW in Enterprise Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:38:20 -0000 Misters=2C FYI : http://emanics.org/component/option=2Ccom_remository/Itemid=2C97/func=2Cfil= einfo/id=2C209/ Best Regards=2C Guillaume FORTAINE = From johan.foldoy@npt.no Thu Aug 5 03:24:44 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006F03A6AE7 for ; Thu, 5 Aug 2010 03:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 EKwWQPyemk7j for ; Thu, 5 Aug 2010 03:24:43 -0700 (PDT) Received: from smtp01-out.isp.tdc.no (smtp01-out.isp.tdc.no [85.19.210.243]) by core3.amsl.com (Postfix) with ESMTP id A2F633A6AC8 for ; Thu, 5 Aug 2010 03:24:41 -0700 (PDT) Received: from mail1.npt.no (unknown [213.225.64.130]) by smtp01-out.isp.tdc.no (Postfix) with ESMTP id 6D7D21285 for ; Thu, 5 Aug 2010 12:25:10 +0200 (CEST) X-AuditID: 0a340114-b7bd5ae00000393b-15-4c5a9185a0c5 Received: from mailserv.npta.no (Unknown_Domain [10.10.2.70]) by mail1.npt.no (Symantec Mail Security) with SMTP id FC.72.14651.5819A5C4; Thu, 5 Aug 2010 12:25:09 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Aug 2010 12:25:08 +0200 Message-ID: In-reply-to: <48E7911F78327A449A9FB95637667286828F0023@exrad4.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] TCP-layer performance metrics Thread-Index: AcsvFJSQ6ktDUAnFTFCag+CLAly5DQC9fr7wAABompAAnj8eIA== References: <9FCB2ACF14591E4DAF4180D4010E3618A777ECCD07@GRFMBX702BA020.griffon.local><9FCB2ACF14591E4DAF4180D4010E3618A7786D7685@GRFMBX702BA020.griffon.local><4C4FF248.1020109@ripe.net> <4C516B9A.1080502@ripe.net><48E7911F78327A449A9FB95637667286828EFF8C@exrad4.ad.rad.co.il> <48E7911F78327A449A9FB95637667286828F0023@exrad4.ad.rad.co.il> From: =?iso-8859-1?Q?Fold=F8y=2C_Johan?= To: "IETF IPPM WG" X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 09 Aug 2010 12:36:30 -0700 Subject: Re: [ippm] TCP-layer performance metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 10:24:44 -0000 Hi all, Reading draft-ietf-ippm-tcp-throughput-tm-04, there is a minor editorial = point (which may or may not have been discussed already) that might = strengthen the draft: it seems most of the example scenarios* describe = issues relevant to an IPv4-only context? If so, maybe this could be = clearly stated at the beginning of the document, or one could add text = which explains how the same issues are handled in IPv6 implementations = as well? =20 *e.g section 3.1 Best Regards =A0 Mr. Johan Foldoy Senior Engineer =A0 Terminals and Networks Department/Section for Networks Norwegian Post and Telecommunications Authority -----Opprinnelig melding----- Fra: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] P=E5 vegne av = Yaakov Stein Sendt: 2. august 2010 09:04 Til: IETF IPPM WG Emne: [ippm] TCP-layer performance metrics I am working my way through draft-ietf-ippm-tcp-throughput-tm-04 . The draft is not defined with the accuracy and precision I have come to = expect=20 in IPPM documents. The efficiency measure is well-defined as the number of bytes NOT = retransmitted. As Al mentioned, the example thereafter then gives a different measure - = the number of segments not retransmitted. Actually, both may be = interesting, but it needs to be clarified which is intended. The second metric is not a well defined performance measure at all. It is the amount of time needed to transfer some undefined amount of = data using some number of connections, and thus is highly dependent on the amount of data and the number of = connections. I understand that given the parameters you can come up with a number to = expect and compare what you measure to the expected, but if so, let's define = this comparison. I would propose normalizing by defining the ratio of the actual transfer = time=20 to the expected time (given the layer-3 1-way delay and bandwidth). This is a pure TCP-layer measure. Unfortunately, this measure is not completely divorced from the = efficiency. One reason that it takes longer to transfer at the TCP-layer than at the = IP-layer is because of the retransmissions! =20 However, TCP's inherent flow control, and ECN if used, and the various = algorithms for determining the RTT, etc. all have their effects. This is why the number of connections is important - using multiple = connections fools the transport into giving the user more weight. Regarding the traffic shaping/policing section, I am confused.=20 The traffic shaping and policing I am familiar with are done at layer-2, and are thus layer-2 quantities, although they of course affect TCP = performance. (W)RED is of course a transport quantity - but what is it that we are = trying to quantify here ?=20 The number of dropped packets is already covered in the efficiency = measure. Y(J)S _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Mon Aug 9 18:26:47 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8457B3A6818 for ; Mon, 9 Aug 2010 18:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 3VlAZB-9pPKi for ; Mon, 9 Aug 2010 18:26:46 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D40043A68AF for ; Mon, 9 Aug 2010 18:26:44 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6W00LCFXD906@szxga05-in.huawei.com> for ippm@ietf.org; Tue, 10 Aug 2010 09:27:09 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L6W0013IXD7SJ@szxga05-in.huawei.com> for ippm@ietf.org; Tue, 10 Aug 2010 09:27:09 +0800 (CST) Date: Tue, 10 Aug 2010 09:27:07 +0800 From: Xiangsong Cui To: pfc@ieee.org Message-id: <001801cb382b$265c3f40$80106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; format=flowed; charset=utf-8; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1715847396.1637770.1281356765785.JavaMail.root@vms170003.mailsrvcs.net> Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 01:26:47 -0000 Hi Phil, Thank you for your quick feedback! I do agree your statement about IP capacity, but I think that is a higher level concept, here I just want to talk about Path Capacity. You said "The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity.", my questions are: Does the notion of "middle-box" capacity is included in the definition of Path Capacity? Should it be or not? Additionally, I want to clarify my example, I also talked about IP capacity. A------link1------Router------link2------B Node A sends IP packets to B at the rate of 5G bps, and all the packets are transferred by the router. The router forwards the packets, but the rate exceeds its capacity, so unfortunately bit error happens in 60% packets, and what more unfortunately is, the error bit is in IP header checksum. Node B receives packets from the router, it detects the IP header checksum errors, so the accepted IP flow rate is 2G bps (the capacity of the neckbottle, the router). How should we say the capacity of the path between A and B? I guess the capacity of the path is 2G bps, the invalid IP bandwidth is not our expected IP capacity (neither the link nor the path), right? Thanks and regards Xiangsong ----- Original Message ----- From: To: Cc: Sent: Monday, August 09, 2010 8:26 PM Subject: Re: [ippm] Question/comment on RFC5136 Remember, what we are talking about here is the IP capacity, not raw link capacity. So the definition includes the number of IP layer bits that can be transmitted by the source and received by the destination. Lots of things make this capacity smaller than the nominal link capacity measured at the physical layer. Some things that can reduce the IP layer capacity include: node backplane capcity, NIC implementation, queueing structure, buffer management, etc. etc. The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity. Regards, Phil Chimento Aug 9, 2010 12:00:47 AM, Xiangsong.Cui@huawei.com wrote: Hi folks, I'm reading RFC5136 "Defining Network Capacity", and I have some question/comment on it. In section 2.1, the definition of link and path, it reads: We then define a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and destination D reside at N1 and Nn+1, respectively. I'm a bit confused by this definition, it seems the middle-boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the path between N1 and Nn+1, is this right? it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box should be a part of the path? Well, if the middle-boxes were part of the path, how about the "path capacity"? In section 2.3.3, it specifies, C(P,T,I) = min {1..n} {C(Ln,T,I)} I think this should be updated, as C(P,T,I) = min ( X, Y) X = min {2..n} {C(Nn,T,I)} Y = min {1..n} {C(Ln,T,I)} Of course, we should additionally define the capacity of node (transmitting/receiving/forwarding aspect), I think that is necessary. And there are also some other text need modification, such as IP-type-P Available Path Capacity. For example, in the path between node A and B as follows, A------link1------Router------link2------B For some certain packet/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of the router is 2G bps, how much is the capacity of the path between A and B? I believe the capacity is 2G bps (the neckbottle is the middle-box), but not 3G bps (as definition of RFC5136). Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft, to update this RFC. Any thought? Regards, Xiangsong _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From vze275m9@verizon.net Tue Aug 10 05:38:07 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C1D3A69A6 for ; Tue, 10 Aug 2010 05:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MIME_HTML_ONLY=1.457] 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 r0eEpLK3hcv5 for ; Tue, 10 Aug 2010 05:38:06 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id D0B5E3A6990 for ; Tue, 10 Aug 2010 05:38:05 -0700 (PDT) Received: from vms170003.mailsrvcs.net ([unknown] [172.18.12.133]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6X00LJUSG6RX84@vms173005.mailsrvcs.net> for ippm@ietf.org; Tue, 10 Aug 2010 07:38:30 -0500 (CDT) Received: from 128.244.9.9 ([128.244.9.9]) by vms170003.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 10 Aug 2010 07:38:30 -0500 (CDT) Date: Tue, 10 Aug 2010 07:38:30 -0500 (CDT) From: vze275m9@verizon.net To: Xiangsong.Cui@huawei.com Message-id: <127762737.1666465.1281443910227.JavaMail.root@vms170003.mailsrvcs.net> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Originating-IP: [128.244.9.9] Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pfc@ieee.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 12:38:07 -0000 Hi Xiangsong:
The rfc  is actually about IP capacity, not about pa= th capacity per se. The whole idea behind the rfc was to explore what
m= any of the "bandwidth" measurement tools were trying to measure. We settled= on IP capacity because that is what a user sees; i.e.
what he can send= and have correctly received from point A to point B at layer 3. This inclu= des all the impairments from, say, a wireless link which
has variable c= apacity and variable quality, or from an intermediate node (router, switch,= security device, take your pick) which has its backplane overloaded.
I= n your example, you are right, the rate is 2Gb/s because that is the rate o= f the correctly received IP bit stream.

Defining "path capacity" on= a lower level is a daunting task because of the very large variety of midd= leboxes that exist (not just L2/L3 transport elements, but also NATs, load = balancers, security devices, etc etc), many of which can have peculiar beha= viors, not to mention the wide variety of link types that exist and do not = have a fixed capacity. Anyway, I believe that it is out of scope of the IPP= M WG (Henk, Matt, correct me if I am wrong).
Regards,
Phil Chimento=

Aug 9, 2010 09:27:19 PM, Xiangsong.Cui@huawei.com wrote:
Hi Phil,

T= hank you for your quick feedback!

I do agree your statement about IP= capacity, but I think that is a higher level concept, here I just want to = talk about Path
Capacity.
You said "The notion of "middle-box" capac= ity is, in effect, included in the definition of IP capacity.", my question= s are:
Does the notion of "middle-box" capacity is included in the defin= ition of Path Capacity? Should it be or not?


Additionally, I wan= t to clarify my example, I also talked about IP capacity.

A------lin= k1------Router------link2------B

Node A sends IP packets to B at the= rate of 5G bps, and all the packets are transferred by the router.
The = router forwards the packets, but the rate exceeds its capacity, so unfortun= ately bit error happens in 60% packets, and what more
unfortunately is,= the error bit is in IP header checksum.
Node B receives packets from th= e router, it detects the IP header checksum errors, so the accepted IP flow= rate is 2G bps (the
capacity of the neckbottle, the router).

Ho= w should we say the capacity of the path between A and B?
I guess the ca= pacity of the path is 2G bps, the invalid IP bandwidth is not our expected = IP capacity (neither the link nor the
path), right?


Thanks a= nd regards
Xiangsong


----- Original Message -----
From: <= vze275m9@verizon.net>
To:
Cc:
Sent: Monday, August 09, 2010 8:26 PM
Subject: Re: [ippm] Questio= n/comment on RFC5136


Remember, what we are talking about here is= the IP capacity, not raw link capacity. So the definition includes the num= ber of IP
layer bits that can be transmitted by the source and received= by the destination. Lots of things make this capacity smaller than the nominal link capacity measured at the physical layer. Some things that can= reduce the IP layer capacity include: node backplane
capcity, NIC impl= ementation, queueing structure, buffer management, etc. etc. The notion of = "middle-box" capacity is, in effect,
included in the definition of IP c= apacity.

Regards,
Phil Chimento

Aug 9, 2010 12:00:47 AM, X= iangsong.Cui@huawei.com wrote:

Hi folks,

I'm reading RFC5= 136 "Defining Network Capacity", and I have some question/comment on it.

In section 2.1, the definition of link and path, it reads:
We then define a path P of length n as a series of
links (L1, L2, = ..., Ln) connecting a sequence of nodes (N1, N2, ...,
Nn+1). A source = S and destination D reside at N1 and Nn+1,
respectively.

I'm = a bit confused by this definition,
it seems the middle-boxes (i.e., no= des N2, N3, ..., Nn) are not included (in this definition) in the path betw= een N1 and Nn+1, is
this right?
it is very strange to me, because= I remember we often mentioned "the middle-box in the path", does that mean= s the middle-box
should
be a part of the path?


Well, = if the middle-boxes were part of the path, how about the "path capacity"? In section 2.3.3, it specifies,

C(P,T,I) =3D min {1..n} {C(Ln,= T,I)}

I think this should be updated, as

C(P,T,I) =3D min= ( X, Y)
X =3D min {2..n} {C(Nn,T,I)}
Y =3D min {1..n} {C(Ln,T,I)= }

Of course, we should additionally define the capacity of node (t= ransmitting/receiving/forwarding aspect), I think that is
necessary. And there are also some other text need modification, such as IP-type-P = Available Path Capacity.


For example, in the path between node= A and B as follows,

A------link1------Router------link2------B
For some certain packet/traffic, if the capacity of link1 is 5G bps = and the capacity of link2 is 3G bps, while the capacity of the
router = is 2G bps, how much is the capacity of the path between A and B? I believe = the capacity is 2G bps (the neckbottle is the
middle-box), but not 3G = bps (as definition of RFC5136).


Since this is a very late comm= ent (on a frozen RFC document), if you agree these are serious issues, I wo= uld submit a new draft,
to
update this RFC.

Any thought?<= br>

Regards,
Xiangsong

_____________________________= __________________
ippm mailing list
ippm@ietf.org
https://w= ww.ietf.org/mailman/listinfo/ippm

 From Xiangsong.Cui@huawei.com Tue Aug 10 06:09:04 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2B53A68FC for ; Tue, 10 Aug 2010 06:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RDNS_NONE=0.1] 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 jYhrg52GL1ai for ; Tue, 10 Aug 2010 06:09:02 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 484313A67C2 for ; Tue, 10 Aug 2010 06:09:02 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6X0093GTVQG4@szxga01-in.huawei.com> for ippm@ietf.org; Tue, 10 Aug 2010 21:09:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6X00E9JTVQYS@szxga01-in.huawei.com> for ippm@ietf.org; Tue, 10 Aug 2010 21:09:26 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [123.113.123.7]) by szxmc03-in.huawei.com (mshttpd); Tue, 10 Aug 2010 21:09:26 +0800 Date: Tue, 10 Aug 2010 21:09:26 +0800 From: Xiangsong Cui In-reply-to: <127762737.1666465.1281443910227.JavaMail.root@vms170003.mailsrvcs.net> To: pfc@ieee.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_jV7p4WIHF9nMqrfCRcOxkw)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <127762737.1666465.1281443910227.JavaMail.root@vms170003.mailsrvcs.net> Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:09:04 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jV7p4WIHF9nMqrfCRcOxkw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi Phil, I'm more confused now, You said "Defining "path capacity" on a lower level is a daunting task ......", and "Anyway, I believe that it is out of scope of the IPPM WG". I agree this is a diffucult task, but let's take a look at the table of content of RFC5136, which reads: 2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7 2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7 2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7 2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8 2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8 2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8 In these sections, many formula are specified, such as C(P,T,I) = min {1..n} {C(Ln,T,I)} I think this RFC did specify the link capacity and path capacity (without consideration on the middle-boxes), and my questions come from these sections. I am sorry I don't know well the history of this RFC, but I noticed you are the author of this document, so could you please tell me more information, e.g. the WG discussion? Thanks and Best Regards Xiangsong --Boundary_(ID_jV7p4WIHF9nMqrfCRcOxkw) Content-type: message/rfc822 Content-disposition: inline Return-path: Received: from szxga04-in.huawei.com ([172.24.2.12]) by szxmc03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6X00LHLSK88S@szxmc03-in.huawei.com> for Xiangsong.Cui@huawei.com; Tue, 10 Aug 2010 20:40:56 +0800 (CST) Received: from szxga04-in (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6X00FS5SHWQ4@szxga04-in.huawei.com> for Xiangsong.Cui@huawei.com; Tue, 10 Aug 2010 20:40:56 +0800 (CST) Received: from szxrg05-in.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6X00C6ASIYFY@szxga04-in.huawei.com> for Xiangsong.Cui@huawei.com (ORCPT Xiangsong.Cui@huawei.com); Tue, 10 Aug 2010 20:40:34 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by szxrg05-in.huawei.com (MOS 3.10.8-GA) id FIF92801; Tue, 10 Aug 2010 20:39:35 +0800 (CST) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by szxrg05-in.huawei.com (MOS 3.10.8-GA) with ESMTP id FIF92339; Tue, 10 Aug 2010 20:38:37 +0800 (CST) Received: from vms170003.mailsrvcs.net ([unknown] [172.18.12.133]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6X00LJUSG6RX84@vms173005.mailsrvcs.net> for Xiangsong.Cui@huawei.com; Tue, 10 Aug 2010 07:38:30 -0500 (CDT) Received: from 128.244.9.9 ([128.244.9.9]) by vms170003.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 10 Aug 2010 07:38:30 -0500 (CDT) Date: Tue, 10 Aug 2010 07:38:30 -0500 (CDT) From: vze275m9@verizon.net Subject: Re: Re: [ippm] Question/comment on RFC5136 X-Originating-IP: [128.244.9.9] To: Xiangsong.Cui@huawei.com Cc: pfc@ieee.org, ippm@ietf.org Reply-to: pfc@ieee.org Message-id: <127762737.1666465.1281443910227.JavaMail.root@vms170003.mailsrvcs.net> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mirapoint-Received-SPF: 206.46.173.5 vms173005pub.verizon.net 0 pass X-Junkmail-Status: score=35/50, host=szxrg05-in.huawei.com X-Junkmail-SD-Raw: score=suspect(0), refid=str=0001.0A150203.4C614887.00B0,ss=2,fgs=0, ip=206.46.173.5, so=2009-09-21 22:56:10, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false X-Mirapoint-RAPID-Raw: score=unknown(0), refid=str=0001.0A150203.4C614887.00B0,ss=2,fgs=0, ip=206.46.173.5, so=2009-09-21 22:56:10, dmn=5.7.1/2009-08-27 X-Mirapoint-Loop-Id: 21482623fc34d7c464a616b75eb252f3 X-Mirapoint-Loop-Id: 5156b7ef0d480a2ed32371b9dd96a476 Original-recipient: rfc822;@szxmc03-in.huawei.com:Xiangsong.Cui@huawei.com Hi Xiangsong:
The rfc  is actually about IP capacity, not about pa= th capacity per se. The whole idea behind the rfc was to explore what
m= any of the "bandwidth" measurement tools were trying to measure. We settled= on IP capacity because that is what a user sees; i.e.
what he can send= and have correctly received from point A to point B at layer 3. This inclu= des all the impairments from, say, a wireless link which
has variable c= apacity and variable quality, or from an intermediate node (router, switch,= security device, take your pick) which has its backplane overloaded.
I= n your example, you are right, the rate is 2Gb/s because that is the rate o= f the correctly received IP bit stream.

Defining "path capacity" on= a lower level is a daunting task because of the very large variety of midd= leboxes that exist (not just L2/L3 transport elements, but also NATs, load = balancers, security devices, etc etc), many of which can have peculiar beha= viors, not to mention the wide variety of link types that exist and do not = have a fixed capacity. Anyway, I believe that it is out of scope of the IPP= M WG (Henk, Matt, correct me if I am wrong).
Regards,
Phil Chimento=

Aug 9, 2010 09:27:19 PM, Xiangsong.Cui@huawei.com wrote:
Hi Phil,

T= hank you for your quick feedback!

I do agree your statement about IP= capacity, but I think that is a higher level concept, here I just want to = talk about Path
Capacity.
You said "The notion of "middle-box" capac= ity is, in effect, included in the definition of IP capacity.", my question= s are:
Does the notion of "middle-box" capacity is included in the defin= ition of Path Capacity? Should it be or not?


Additionally, I wan= t to clarify my example, I also talked about IP capacity.

A------lin= k1------Router------link2------B

Node A sends IP packets to B at the= rate of 5G bps, and all the packets are transferred by the router.
The = router forwards the packets, but the rate exceeds its capacity, so unfortun= ately bit error happens in 60% packets, and what more
unfortunately is,= the error bit is in IP header checksum.
Node B receives packets from th= e router, it detects the IP header checksum errors, so the accepted IP flow= rate is 2G bps (the
capacity of the neckbottle, the router).

Ho= w should we say the capacity of the path between A and B?
I guess the ca= pacity of the path is 2G bps, the invalid IP bandwidth is not our expected = IP capacity (neither the link nor the
path), right?


Thanks a= nd regards
Xiangsong


----- Original Message -----
From: <= vze275m9@verizon.net>
To:
Cc:
Sent: Monday, August 09, 2010 8:26 PM
Subject: Re: [ippm] Questio= n/comment on RFC5136


Remember, what we are talking about here is= the IP capacity, not raw link capacity. So the definition includes the num= ber of IP
layer bits that can be transmitted by the source and received= by the destination. Lots of things make this capacity smaller than the nominal link capacity measured at the physical layer. Some things that can= reduce the IP layer capacity include: node backplane
capcity, NIC impl= ementation, queueing structure, buffer management, etc. etc. The notion of = "middle-box" capacity is, in effect,
included in the definition of IP c= apacity.

Regards,
Phil Chimento

Aug 9, 2010 12:00:47 AM, X= iangsong.Cui@huawei.com wrote:

Hi folks,

I'm reading RFC5= 136 "Defining Network Capacity", and I have some question/comment on it.

In section 2.1, the definition of link and path, it reads:
We then define a path P of length n as a series of
links (L1, L2, = ..., Ln) connecting a sequence of nodes (N1, N2, ...,
Nn+1). A source = S and destination D reside at N1 and Nn+1,
respectively.

I'm = a bit confused by this definition,
it seems the middle-boxes (i.e., no= des N2, N3, ..., Nn) are not included (in this definition) in the path betw= een N1 and Nn+1, is
this right?
it is very strange to me, because= I remember we often mentioned "the middle-box in the path", does that mean= s the middle-box
should
be a part of the path?


Well, = if the middle-boxes were part of the path, how about the "path capacity"? In section 2.3.3, it specifies,

C(P,T,I) =3D min {1..n} {C(Ln,= T,I)}

I think this should be updated, as

C(P,T,I) =3D min= ( X, Y)
X =3D min {2..n} {C(Nn,T,I)}
Y =3D min {1..n} {C(Ln,T,I)= }

Of course, we should additionally define the capacity of node (t= ransmitting/receiving/forwarding aspect), I think that is
necessary. And there are also some other text need modification, such as IP-type-P = Available Path Capacity.


For example, in the path between node= A and B as follows,

A------link1------Router------link2------B
For some certain packet/traffic, if the capacity of link1 is 5G bps = and the capacity of link2 is 3G bps, while the capacity of the
router = is 2G bps, how much is the capacity of the path between A and B? I believe = the capacity is 2G bps (the neckbottle is the
middle-box), but not 3G = bps (as definition of RFC5136).


Since this is a very late comm= ent (on a frozen RFC document), if you agree these are serious issues, I wo= uld submit a new draft,
to
update this RFC.

Any thought?<= br>

Regards,
Xiangsong

_____________________________= __________________
ippm mailing list
ippm@ietf.org
https://w= ww.ietf.org/mailman/listinfo/ippm

 --Boundary_(ID_jV7p4WIHF9nMqrfCRcOxkw) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for Xiangsong Cui begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_jV7p4WIHF9nMqrfCRcOxkw)-- From vze275m9@verizon.net Tue Aug 10 07:07:04 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B293A69E6 for ; Tue, 10 Aug 2010 07:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 J2erDy2Oc4in for ; Tue, 10 Aug 2010 07:07:03 -0700 (PDT) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by core3.amsl.com (Postfix) with ESMTP id 77A813A6405 for ; Tue, 10 Aug 2010 07:06:25 -0700 (PDT) Received: from vms170003.mailsrvcs.net ([unknown] [172.18.12.133]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6X00AZWWIM67C4@vms173015.mailsrvcs.net> for ippm@ietf.org; Tue, 10 Aug 2010 09:06:23 -0500 (CDT) Received: from 128.244.9.9 ([128.244.9.9]) by vms170003.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 10 Aug 2010 09:06:22 -0500 (CDT) Date: Tue, 10 Aug 2010 09:06:22 -0500 (CDT) From: vze275m9@verizon.net To: Xiangsong.Cui@huawei.com Message-id: <1951144877.1668412.1281449182600.JavaMail.root@vms170003.mailsrvcs.net> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Originating-IP: [128.244.9.9] Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pfc@ieee.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 14:07:04 -0000 Xiangsong:
Please notice that these are "IP-type-P ...Capacity". The sa= me physical/logical path can have different capacities depending on the typ= e of IP packets sent, for example, packets with different DSCP values may s= ee different capacities (because of traffic class definitions in routers, f= or example). We were not trying to define this at Layer 1 or Layer 2. The f= ormulas should all refer to IP capacity of links and paths, not to the phys= ical capacity per se (which is an upper bound that in practice is never rea= ched).

Regards,
Phil Chimento

Aug 10, 2010 09:09:43 AM, = Xiangsong.Cui@huawei.com wrote:
Hi Phil,

I'm more confused now,
You said= "Defining "path capacity" on a lower level is a daunting task ......", and= "Anyway, I believe that it is out of scope of the IPPM WG". I agree this i= s a diffucult task, but let's take a look at the table of content of RFC513= 6, which reads:

2.3.2. Definition: IP-type-P Link Capacity = . . . . . . . . . 7
2.3.3. Definition: IP-type-P Path Capacity = . . . . . . . . . 7
2.3.4. Definition: IP-type-P Link Usage . = . . . . . . . . . . 7
2.3.5. Definition: IP-type-P Link Utiliza= tion . . . . . . . . 8
2.3.6. Definition: IP-type-P Available L= ink Capacity . . . . 8
2.3.7. Definition: IP-type-P Available = Path Capacity . . . . 8

In these sections, many formula are specif= ied, such as

C(P,T,I) =3D min {1..n} {C(Ln,T,I)}


I think= this RFC did specify the link capacity and path capacity (without consider= ation on the middle-boxes), and my questions come from these sections.
<= br>I am sorry I don't know well the history of this RFC, but I noticed you = are the author of this document, so could you please tell me more informati= on, e.g. the WG discussion?


Thanks and Best Regards
Xiangsong=


Hi Xiangsong:
The rfc  is actually about IP capacity, not about pa= th capacity per se. The whole idea behind the rfc was to explore what
m= any of the "bandwidth" measurement tools were trying to measure. We settled= on IP capacity because that is what a user sees; i.e.
what he can send= and have correctly received from point A to point B at layer 3. This inclu= des all the impairments from, say, a wireless link which
has variable c= apacity and variable quality, or from an intermediate node (router, switch,= security device, take your pick) which has its backplane overloaded.
I= n your example, you are right, the rate is 2Gb/s because that is the rate o= f the correctly received IP bit stream.

Defining "path capacity" on= a lower level is a daunting task because of the very large variety of midd= leboxes that exist (not just L2/L3 transport elements, but also NATs, load = balancers, security devices, etc etc), many of which can have peculiar beha= viors, not to mention the wide variety of link types that exist and do not = have a fixed capacity. Anyway, I believe that it is out of scope of the IPP= M WG (Henk, Matt, correct me if I am wrong).
Regards,
Phil Chimento=

Aug 9, 2010 09:27:19 PM, Xiangsong.Cui@huawei.com wrote:
Hi Phil,

T= hank you for your quick feedback!

I do agree your statement about IP= capacity, but I think that is a higher level concept, here I just want to = talk about Path
Capacity.
You said "The notion of "middle-box" capac= ity is, in effect, included in the definition of IP capacity.", my question= s are:
Does the notion of "middle-box" capacity is included in the defin= ition of Path Capacity? Should it be or not?


Additionally, I wan= t to clarify my example, I also talked about IP capacity.

A------lin= k1------Router------link2------B

Node A sends IP packets to B at the= rate of 5G bps, and all the packets are transferred by the router.
The = router forwards the packets, but the rate exceeds its capacity, so unfortun= ately bit error happens in 60% packets, and what more
unfortunately is,= the error bit is in IP header checksum.
Node B receives packets from th= e router, it detects the IP header checksum errors, so the accepted IP flow= rate is 2G bps (the
capacity of the neckbottle, the router).

Ho= w should we say the capacity of the path between A and B?
I guess the ca= pacity of the path is 2G bps, the invalid IP bandwidth is not our expected = IP capacity (neither the link nor the
path), right?


Thanks a= nd regards
Xiangsong


----- Original Message -----
From: <= br>To:
Cc:
Sent: Monday, August 09, 2010 8:26 PM
Subject: Re: [i= ppm] Question/comment on RFC5136


Remember, what we are talking a= bout here is the IP capacity, not raw link capacity. So the definition incl= udes the number of IP
layer bits that can be transmitted by the source = and received by the destination. Lots of things make this capacity smaller = than the
nominal link capacity measured at the physical layer. Some thi= ngs that can reduce the IP layer capacity include: node backplane
capci= ty, NIC implementation, queueing structure, buffer management, etc. etc. Th= e notion of "middle-box" capacity is, in effect,
included in the defini= tion of IP capacity.

Regards,
Phil Chimento

Aug 9, 2010 12= :00:47 AM, Xiangsong.Cui@huawei.com wrote:

Hi folks,

I'm = reading RFC5136 "Defining Network Capacity", and I have some question/comme= nt on it.


In section 2.1, the definition of link and path, it = reads:

We then define a path P of length n as a series of
lin= ks (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ...,
Nn+1= ). A source S and destination D reside at N1 and Nn+1,
respectively.
I'm a bit confused by this definition,
it seems the middle-box= es (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in t= he path between N1 and Nn+1, is
this right?
it is very strange to= me, because I remember we often mentioned "the middle-box in the path", do= es that means the middle-box
should
be a part of the path?

=
Well, if the middle-boxes were part of the path, how about the "path = capacity"?
In section 2.3.3, it specifies,

C(P,T,I) =3D min {= 1..n} {C(Ln,T,I)}

I think this should be updated, as

C(P,= T,I) =3D min ( X, Y)
X =3D min {2..n} {C(Nn,T,I)}
Y =3D min {1..n= } {C(Ln,T,I)}

Of course, we should additionally define the capacit= y of node (transmitting/receiving/forwarding aspect), I think that is
n= ecessary.
And there are also some other text need modification, such a= s IP-type-P Available Path Capacity.


For example, in the path = between node A and B as follows,

A------link1------Router------lin= k2------B

For some certain packet/traffic, if the capacity of link= 1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of the<= br> router is 2G bps, how much is the capacity of the path between A and B= ? I believe the capacity is 2G bps (the neckbottle is the
middle-box),= but not 3G bps (as definition of RFC5136).


Since this is a ve= ry late comment (on a frozen RFC document), if you agree these are serious = issues, I would submit a new draft,
to
update this RFC.

A= ny thought?


Regards,
Xiangsong

_________________= ______________________________
ippm mailing list
ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm

From Barry.Constantine@jdsu.com Tue Aug 10 08:45:43 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F153A6884 for ; Tue, 10 Aug 2010 08:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 cYEvZ-eu4UYh for ; Tue, 10 Aug 2010 08:45:42 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with SMTP id CDFB33A67A1 for ; Tue, 10 Aug 2010 08:45:38 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTGF0RoUkG1lzdBXbtP+GrrdXXRiK2N8V@postini.com; Tue, 10 Aug 2010 08:46:17 PDT Received: from milexhtca2.ds.jdsu.net ([10.75.2.122]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 08:43:58 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca2.ds.jdsu.net ([::1]) with mapi; Tue, 10 Aug 2010 08:43:58 -0700 From: Barry Constantine To: =?iso-8859-1?Q?Fold=F8y=2C_Johan?= , IETF IPPM WG Date: Tue, 10 Aug 2010 08:43:56 -0700 Thread-Topic: [ippm] TCP-layer performance metrics Thread-Index: AcsvFJSQ6ktDUAnFTFCag+CLAly5DQC9fr7wAABompAAnj8eIAEHXOcw Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B9A7A5F6@MILEXCH1.ds.jdsu.net> References: <9FCB2ACF14591E4DAF4180D4010E3618A777ECCD07@GRFMBX702BA020.griffon.local><9FCB2ACF14591E4DAF4180D4010E3618A7786D7685@GRFMBX702BA020.griffon.local><4C4FF248.1020109@ripe.net> <4C516B9A.1080502@ripe.net><48E7911F78327A449A9FB95637667286828EFF8C@exrad4.ad.rad.co.il> <48E7911F78327A449A9FB95637667286828F0023@exrad4.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Aug 2010 15:43:58.0846 (UTC) FILETIME=[D91AC9E0:01CB38A2] Subject: Re: [ippm] TCP-layer performance metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 15:45:43 -0000 Hello Johan, As far as TCP's behavior is concerned, there is no difference if it is runn= ing over IPv4 or IPv6. Only difference is the TCP checksum calculation usin= g either IPv4 pseudo header or IPv6 pseudo header. Let me add a note to the introduction stating the fact that the methodology= pertains to IPv4 and v6. Thank you for the comment, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Fol= d=F8y, Johan Sent: Thursday, August 05, 2010 6:25 AM To: IETF IPPM WG Subject: Re: [ippm] TCP-layer performance metrics Hi all, Reading draft-ietf-ippm-tcp-throughput-tm-04, there is a minor editorial po= int (which may or may not have been discussed already) that might strengthe= n the draft: it seems most of the example scenarios* describe issues releva= nt to an IPv4-only context? If so, maybe this could be clearly stated at th= e beginning of the document, or one could add text which explains how the s= ame issues are handled in IPv6 implementations as well? =20 *e.g section 3.1 Best Regards =A0 Mr. Johan Foldoy Senior Engineer =A0 Terminals and Networks Department/Section for Networks Norwegian Post and Telecommunications Authority -----Opprinnelig melding----- Fra: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] P=E5 vegne av Yaa= kov Stein Sendt: 2. august 2010 09:04 Til: IETF IPPM WG Emne: [ippm] TCP-layer performance metrics I am working my way through draft-ietf-ippm-tcp-throughput-tm-04 . The draft is not defined with the accuracy and precision I have come to exp= ect=20 in IPPM documents. The efficiency measure is well-defined as the number of bytes NOT retransmi= tted. As Al mentioned, the example thereafter then gives a different measure -=20 the number of segments not retransmitted. Actually, both may be interesting= , but it needs to be clarified which is intended. The second metric is not a well defined performance measure at all. It is the amount of time needed to transfer some undefined amount of data u= sing some number of connections, and thus is highly dependent on the amount of data and the number of connec= tions. I understand that given the parameters you can come up with a number to exp= ect and compare what you measure to the expected, but if so, let's define this = comparison. I would propose normalizing by defining the ratio of the actual transfer ti= me=20 to the expected time (given the layer-3 1-way delay and bandwidth). This is a pure TCP-layer measure. Unfortunately, this measure is not completely divorced from the efficiency. One reason that it takes longer to transfer at the TCP-layer than at the IP= -layer is because of the retransmissions! =20 However, TCP's inherent flow control, and ECN if used, and the various algo= rithms for determining the RTT, etc. all have their effects. This is why the number of connections is important - using multiple connect= ions fools the transport into giving the user more weight. Regarding the traffic shaping/policing section, I am confused.=20 The traffic shaping and policing I am familiar with are done at layer-2, and are thus layer-2 quantities, although they of course affect TCP perform= ance. (W)RED is of course a transport quantity - but what is it that we are tryin= g to quantify here ?=20 The number of dropped packets is already covered in the efficiency measure. Y(J)S _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Tue Aug 10 18:34:55 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47F93A69E3 for ; Tue, 10 Aug 2010 18:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 4WEvDf4x3xko for ; Tue, 10 Aug 2010 18:34:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DE5AE3A6877 for ; Tue, 10 Aug 2010 18:34:52 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6Y00BYTSEP0Z@szxga03-in.huawei.com> for ippm@ietf.org; Wed, 11 Aug 2010 09:35:13 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L6Y00FLQSEP6E@szxga03-in.huawei.com> for ippm@ietf.org; Wed, 11 Aug 2010 09:35:13 +0800 (CST) Date: Wed, 11 Aug 2010 09:35:12 +0800 From: Xiangsong Cui To: pfc@ieee.org Message-id: <008501cb38f5$71a5b7e0$80106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; format=flowed; charset=utf-8; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1951144877.1668412.1281449182600.JavaMail.root@vms170003.mailsrvcs.net> Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 01:34:55 -0000 Hi Phil, I know the precondition of IP-type-P, in my initial example, the first sentence is " For some certain packet/traffic,...", so we are both talking about the capacity for IP-type-P and all we are discussing is about IP-type-P. I'm not discussing Layer 1 or layer 2 either, I'm talking about path and path capacity (in the precondition of IP-type-P, not physical capacity but IP capacity). My concerns are: the middle-box should be included in the definition of path, the IP-type-P IP capacity of the middle-box should be considered in IP-type-P Path Capacity. I believe IP-type-P Path Capacity is a very important metric, I like it, and just want to make it more accurate although that is a hard job. Regards, Xiangsong ----- Original Message ----- From: To: Cc: Sent: Tuesday, August 10, 2010 10:06 PM Subject: Re: [ippm] Question/comment on RFC5136 Xiangsong: Please notice that these are "IP-type-P ...Capacity". The same physical/logical path can have different capacities depending on the type of IP packets sent, for example, packets with different DSCP values may see different capacities (because of traffic class definitions in routers, for example). We were not trying to define this at Layer 1 or Layer 2. The formulas should all refer to IP capacity of links and paths, not to the physical capacity per se (which is an upper bound that in practice is never reached). Regards, Phil Chimento Aug 10, 2010 09:09:43 AM, Xiangsong.Cui@huawei.com wrote: Hi Phil, I'm more confused now, You said "Defining "path capacity" on a lower level is a daunting task ......", and "Anyway, I believe that it is out of scope of the IPPM WG". I agree this is a diffucult task, but let's take a look at the table of content of RFC5136, which reads: 2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7 2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7 2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7 2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8 2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8 2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8 In these sections, many formula are specified, such as C(P,T,I) = min {1..n} {C(Ln,T,I)} I think this RFC did specify the link capacity and path capacity (without consideration on the middle-boxes), and my questions come from these sections. I am sorry I don't know well the history of this RFC, but I noticed you are the author of this document, so could you please tell me more information, e.g. the WG discussion? Thanks and Best Regards Xiangsong ------------------------------------------------------------------------------ Hi Xiangsong: The rfc is actually about IP capacity, not about path capacity per se. The whole idea behind the rfc was to explore what many of the "bandwidth" measurement tools were trying to measure. We settled on IP capacity because that is what a user sees; i.e. what he can send and have correctly received from point A to point B at layer 3. This includes all the impairments from, say, a wireless link which has variable capacity and variable quality, or from an intermediate node (router, switch, security device, take your pick) which has its backplane overloaded. In your example, you are right, the rate is 2Gb/s because that is the rate of the correctly received IP bit stream. Defining "path capacity" on a lower level is a daunting task because of the very large variety of middleboxes that exist (not just L2/L3 transport elements, but also NATs, load balancers, security devices, etc etc), many of which can have peculiar behaviors, not to mention the wide variety of link types that exist and do not have a fixed capacity. Anyway, I believe that it is out of scope of the IPPM WG (Henk, Matt, correct me if I am wrong). Regards, Phil Chimento Aug 9, 2010 09:27:19 PM, Xiangsong.Cui@huawei.com wrote: Hi Phil, Thank you for your quick feedback! I do agree your statement about IP capacity, but I think that is a higher level concept, here I just want to talk about Path Capacity. You said "The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity.", my questions are: Does the notion of "middle-box" capacity is included in the definition of Path Capacity? Should it be or not? Additionally, I want to clarify my example, I also talked about IP capacity. A------link1------Router------link2------B Node A sends IP packets to B at the rate of 5G bps, and all the packets are transferred by the router. The router forwards the packets, but the rate exceeds its capacity, so unfortunately bit error happens in 60% packets, and what more unfortunately is, the error bit is in IP header checksum. Node B receives packets from the router, it detects the IP header checksum errors, so the accepted IP flow rate is 2G bps (the capacity of the neckbottle, the router). How should we say the capacity of the path between A and B? I guess the capacity of the path is 2G bps, the invalid IP bandwidth is not our expected IP capacity (neither the link nor the path), right? Thanks and regards Xiangsong ----- Original Message ----- From: To: Cc: Sent: Monday, August 09, 2010 8:26 PM Subject: Re: [ippm] Question/comment on RFC5136 Remember, what we are talking about here is the IP capacity, not raw link capacity. So the definition includes the number of IP layer bits that can be transmitted by the source and received by the destination. Lots of things make this capacity smaller than the nominal link capacity measured at the physical layer. Some things that can reduce the IP layer capacity include: node backplane capcity, NIC implementation, queueing structure, buffer management, etc. etc. The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity. Regards, Phil Chimento Aug 9, 2010 12:00:47 AM, Xiangsong.Cui@huawei.com wrote: Hi folks, I'm reading RFC5136 "Defining Network Capacity", and I have some question/comment on it. In section 2.1, the definition of link and path, it reads: We then define a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and destination D reside at N1 and Nn+1, respectively. I'm a bit confused by this definition, it seems the middle-boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the path between N1 and Nn+1, is this right? it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box should be a part of the path? Well, if the middle-boxes were part of the path, how about the "path capacity"? In section 2.3.3, it specifies, C(P,T,I) = min {1..n} {C(Ln,T,I)} I think this should be updated, as C(P,T,I) = min ( X, Y) X = min {2..n} {C(Nn,T,I)} Y = min {1..n} {C(Ln,T,I)} Of course, we should additionally define the capacity of node (transmitting/receiving/forwarding aspect), I think that is necessary. And there are also some other text need modification, such as IP-type-P Available Path Capacity. For example, in the path between node A and B as follows, A------link1------Router------link2------B For some certain packet/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of the router is 2G bps, how much is the capacity of the path between A and B? I believe the capacity is 2G bps (the neckbottle is the middle-box), but not 3G bps (as definition of RFC5136). Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft, to update this RFC. Any thought? Regards, Xiangsong _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm -------------------------------------------------------------------------------- > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From Xiangsong.Cui@huawei.com Wed Aug 11 01:22:45 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946873A6A48 for ; Wed, 11 Aug 2010 01:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=1.622, BAYES_00=-2.599] 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 b3kWiVERDuOX for ; Wed, 11 Aug 2010 01:22:44 -0700 (PDT) Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9E4DE3A6804 for ; Wed, 11 Aug 2010 01:22:43 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6Z00JH9B8IIA@szxga05-in.huawei.com> for ippm@ietf.org; Wed, 11 Aug 2010 16:21:54 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L6Z009F8B8GMG@szxga05-in.huawei.com> for ippm@ietf.org; Wed, 11 Aug 2010 16:21:54 +0800 (CST) Date: Wed, 11 Aug 2010 16:21:52 +0800 From: Xiangsong Cui To: pfc@ieee.org, ippm@ietf.org Message-id: <014a01cb392e$4170c720$80106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1951144877.1668412.1281449182600.JavaMail.root@vms170003.mailsrvcs.net> <008501cb38f5$71a5b7e0$80106f0a@china.huawei.com> Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 08:22:45 -0000 Hi Phil, and all, I found some answer for my quesions now, I think this issue worth some discussion. And, I have began the update draft, wish your feedback, would anybody like to co-author this document? The draft (begin part) looks like: Internet Engineering Task Force X. Cui, Ed. Internet-Draft Huawei Updates: 5136 (if approved) August 11, 2010 Intended status: Informational Expires: February 12, 2011 Update RFC5136: Path and Capacity draft-cui-ippm-path-capacity-00 Abstract RFC5136 defines network capacity and introduces definition of link, path, IP-type-P Link Capacity, IP-type-P Path Capacity, and IP-type-P Available Path Capacity. But some notions in this document are not fully precise and confusing. This document provides some clarification and update on RFC5136, especially on the definition of Path and Path Capacity. One important modification on RFC5136 is that the in-path-nodes are considered in the definition of path and path capacity. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 12, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Network Capacity is an improtant metric for internet and many documents have provided many definitions, measurement metholds, calculation formulas. One example is RFC5136, which specifies Link Capacity and Path Capacity. This document is expected to provide complementarity for network capacity, especially for path capacity. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology This document uses the following terminology: o Node: Same as the definintion of node of RFC2460, an IP node is a device that implements IP protocol. In IP field, a node without special statement is IP node, refer to this definition. There is a definition of host in RFC2330, which is equal to the definition of node of RFC2460. o Non-IP node: In this document, a non-IP node is a entity that can transmit, receive or forward bit flow, but is not belong to the scope of IP node. The examples of non-IP node are ethernet switch and hub. o Host: Same as the definition of host of RFC2460, any node that is not a router. Note that in RFC2330 the notion of host includes router, in this document, host doesn't include router. o Link: As defined in RFC2330 and RFC2460, a link is a layer2-level connection between nodes. o Path: As defined in RFC2330, a path is a sequence of the form < N0, L1, N1, ..., Ln, Nn >, where n >= 0, each Ni is a node, each Li is a link between Ni-1 and Ni, each N1...Nn-1 is a router. A pair is termed a 'hop'. In an appropriate operational configuration, the links and routers in the path facilitate network-layer communication of packets from N0 to Nn. Note that path is a unidirectional concept. In section 2.1 of RFC5136, node, link and path are defined. In this document, the definition of node, link and path are updated, as specified in this section. 3. Discussion [Editor's note: This section may be removed by RFC-editor]. Based on the definition of link, link is a layer2-level connection between IP nodes. By this definition, neither the connection between ethernet switches nor the connection between IP node and ethernet switch is a true link, or in other words, those are not IP link. In the scenario of local area network, where host A and host B is connected by cable and an ethernet switch, it is need more study and dicussion whether the ethernet switch is a part of IP link. In section 2.1 of RFC5136, path is defined as "a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1)", which means the path is a set of links. But if we compare this definition with RFC2330, we can find that the routers in the path (i.e. between the source node and the destination node), are completely removed. Accordingly, in section 2.3.3 of RFC5136, the router capacity is not considered in the formula of IP-type-P Path Capacity. RFC5136 specifies IP-type-P Path Capacity as C(P,T,I) = min {1..n} {C(Ln,T,I)}, which need more discussion. This document suggests that the router capacity should be considered in IP-type-P Path Capacity. The proposed formula is: C(P,T,I) = min (C-router, C-link) C-router = min {2..n} {C(Nn,T,I)} C-link = min {1..n} {C(Ln,T,I)} For this proposal, we should additionally define "IP-type-P Router Capacity". Routers are the core entities in internet, we can not define internet's network capacity without mentioning router capacity. 4. IP-type-P Router Capacity TBD 5. IP-type-P Path Capacity TBD What do you think about this draft? Any commets are appreciated! Regards, Xiangsong ----- Original Message ----- From: "Xiangsong Cui" To: Cc: Sent: Wednesday, August 11, 2010 9:35 AM Subject: Re: [ippm] Question/comment on RFC5136 > Hi Phil, > > I know the precondition of IP-type-P, in my initial example, the first sentence is " For some certain packet/traffic,...", so we > are both talking about the capacity for IP-type-P and all we are discussing is about IP-type-P. I'm not discussing Layer 1 or > layer 2 either, I'm talking about path and path capacity (in the precondition of IP-type-P, not physical capacity but IP > capacity). > > My concerns are: > the middle-box should be included in the definition of path, > the IP-type-P IP capacity of the middle-box should be considered in IP-type-P Path Capacity. > > I believe IP-type-P Path Capacity is a very important metric, I like it, and just want to make it more accurate although that is a > hard job. > > Regards, > Xiangsong > > ----- Original Message ----- [snip] From vze275m9@verizon.net Wed Aug 11 06:23:37 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B113A6863 for ; Wed, 11 Aug 2010 06:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MIME_HTML_ONLY=1.457] 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 Kir8JIVe9cAL for ; Wed, 11 Aug 2010 06:23:36 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id E33DC3A6847 for ; Wed, 11 Aug 2010 06:23:35 -0700 (PDT) Received: from vms073.mailsrvcs.net ([unknown] [192.168.1.2]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6Z00G0FP7SK6U0@vms173017.mailsrvcs.net> for ippm@ietf.org; Wed, 11 Aug 2010 08:23:52 -0500 (CDT) Received: from 128.244.9.9 ([128.244.9.9]) by vms073.mailsrvcs.net (Verizon Webmail) with HTTP; Wed, 11 Aug 2010 08:23:52 -0500 (CDT) Date: Wed, 11 Aug 2010 08:23:52 -0500 (CDT) From: vze275m9@verizon.net To: Xiangsong.Cui@huawei.com Message-id: <24656454.944051.1281533032242.JavaMail.root@vms073.mailsrvcs.net> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Originating-IP: [128.244.9.9] Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pfc@ieee.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 13:23:37 -0000 Xiangsong:
We did not forget to include the node capacity. As I explain= ed, the node capacity and characteristics are implicitly included in the li= nk capacity (that is, any restrictions in the node's performance will impac= t its ability to transmit IP packets at a given rate. So, for example, if y= ou have a node with an outgoing link of 10 Gb/s and the node is only capabl= e of transmitting 3 Gb/s at a given time on that link, then that is the cap= acity of that link at that time (note that we have a time parameter associa= ted with each metric).
I understand that you would prefer to have this = made explicit. It is too bad that your comments did not come earlier, but I= see you have submitted your own draft.

Regards,
Phil Chimento<= br>
Aug 10, 2010 09:35:25 PM, Xiangsong.Cui@huawei.com wrote:
Hi Phil,

I= know the precondition of IP-type-P, in my initial example, the first sente= nce is " For some certain packet/traffic,...", so we are
both talking a= bout the capacity for IP-type-P and all we are discussing is about IP-type-= P. I'm not discussing Layer 1 or layer 2
either, I'm talking about path= and path capacity (in the precondition of IP-type-P, not physical capacity= but IP capacity).

My concerns are:
the middle-box should be incl= uded in the definition of path,
the IP-type-P IP capacity of the middle-= box should be considered in IP-type-P Path Capacity.

I believe IP-ty= pe-P Path Capacity is a very important metric, I like it, and just want to = make it more accurate although that is a
hard job.

Regards,
X= iangsong

----- Original Message -----
From:
To:
Cc:
Sent: Tuesda= y, August 10, 2010 10:06 PM
Subject: Re: [ippm] Question/comment on RFC5= 136


Xiangsong:
Please notice that these are "IP-type-P ...Cap= acity". The same physical/logical path can have different capacities depend= ing on the
type of IP packets sent, for example, packets with different= DSCP values may see different capacities (because of traffic class
def= initions in routers, for example). We were not trying to define this at Lay= er 1 or Layer 2. The formulas should all refer to IP
capacity of links = and paths, not to the physical capacity per se (which is an upper bound tha= t in practice is never reached).

Regards,
Phil Chimento

Au= g 10, 2010 09:09:43 AM, Xiangsong.Cui@huawei.com wrote:

Hi Phil,
I'm more confused now,
You said "Defining "path capacity" on a= lower level is a daunting task ......", and "Anyway, I believe that it is = out of scope of
the IPPM WG". I agree this is a diffucult task, but let= 's take a look at the table of content of RFC5136, which reads:

2.= 3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7
2.3.3. De= finition: IP-type-P Path Capacity . . . . . . . . . 7
2.3.4. Definitio= n: IP-type-P Link Usage . . . . . . . . . . . 7
2.3.5. Definition: IP-= type-P Link Utilization . . . . . . . . 8
2.3.6. Definition: IP-type-P= Available Link Capacity . . . . 8
2.3.7. Definition: IP-type-P Availa= ble Path Capacity . . . . 8

In these sections, many formula are sp= ecified, such as

C(P,T,I) =3D min {1..n} {C(Ln,T,I)}


= I think this RFC did specify the link capacity and path capacity (without c= onsideration on the middle-boxes), and my questions
come from these sec= tions.

I am sorry I don't know well the history of this RFC, but I= noticed you are the author of this document, so could you please tell
= me more information, e.g. the WG discussion?


Thanks and Best R= egards
Xiangsong


------------------------------------------= ------------------------------------

Hi Xiangsong:
The rfc i= s actually about IP capacity, not about path capacity per se. The whole ide= a behind the rfc was to explore what
many of the "bandwidth" measureme= nt tools were trying to measure. We settled on IP capacity because that is = what a user sees; i.e.
what he can send and have correctly received fr= om point A to point B at layer 3. This includes all the impairments from, s= ay, a
wireless link which
has variable capacity and variable quali= ty, or from an intermediate node (router, switch, security device, take you= r pick) which
has its backplane overloaded.
In your example, you a= re right, the rate is 2Gb/s because that is the rate of the correctly recei= ved IP bit stream.

Defining "path capacity" on a lower level is a = daunting task because of the very large variety of middleboxes that exist (= not just
L2/L3 transport elements, but also NATs, load balancers, secur= ity devices, etc etc), many of which can have peculiar behaviors, not
t= o mention the wide variety of link types that exist and do not have a fixed= capacity. Anyway, I believe that it is out of scope of
the IPPM WG (He= nk, Matt, correct me if I am wrong).
Regards,
Phil Chimento
Aug 9, 2010 09:27:19 PM, Xiangsong.Cui@huawei.com wrote:

Hi = Phil,

Thank you for your quick feedback!

I do agree y= our statement about IP capacity, but I think that is a higher level concept= , here I just want to talk about Path
Capacity.
You said "The= notion of "middle-box" capacity is, in effect, included in the definition = of IP capacity.", my questions are:
Does the notion of "middle-box" = capacity is included in the definition of Path Capacity? Should it be or no= t?


Additionally, I want to clarify my example, I also talked= about IP capacity.

A------link1------Router------link2------B
Node A sends IP packets to B at the rate of 5G bps, and all the p= ackets are transferred by the router.
The router forwards the packet= s, but the rate exceeds its capacity, so unfortunately bit error happens in= 60% packets, and what
more
unfortunately is, the error bit is i= n IP header checksum.
Node B receives packets from the router, it de= tects the IP header checksum errors, so the accepted IP flow rate is 2G bps= (the
capacity of the neckbottle, the router).

How should= we say the capacity of the path between A and B?
I guess the capaci= ty of the path is 2G bps, the invalid IP bandwidth is not our expected IP c= apacity (neither the link nor the
path), right?


Thank= s and regards
Xiangsong


----- Original Message ----- =
From:
To:
Cc:
Sent: Monday, August 09, 2010 8:= 26 PM
Subject: Re: [ippm] Question/comment on RFC5136


= Remember, what we are talking about here is the IP capacity, not raw link = capacity. So the definition includes the number of IP
layer bits tha= t can be transmitted by the source and received by the destination. Lots of= things make this capacity smaller than
the
nominal link capacit= y measured at the physical layer. Some things that can reduce the IP layer = capacity include: node backplane
capcity, NIC implementation, queuei= ng structure, buffer management, etc. etc. The notion of "middle-box" capac= ity is, in effect,
included in the definition of IP capacity.
Regards,
Phil Chimento

Aug 9, 2010 12:00:47 AM, Xian= gsong.Cui@huawei.com wrote:

Hi folks,

I'm reading RFC= 5136 "Defining Network Capacity", and I have some question/comment on it.

In section 2.1, the definition of link and path, it reads:
We then define a path P of length n as a series of
links (L= 1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ...,
Nn+1). = A source S and destination D reside at N1 and Nn+1,
respectively.
I'm a bit confused by this definition,
it seems the middle-= boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) i= n the path between N1 and Nn+1,
is
this right?
it is very= strange to me, because I remember we often mentioned "the middle-box in th= e path", does that means the middle-box
should
be a part of t= he path?


Well, if the middle-boxes were part of the path, ho= w about the "path capacity"?
In section 2.3.3, it specifies,

= C(P,T,I) =3D min {1..n} {C(Ln,T,I)}

I think this should be u= pdated, as

C(P,T,I) =3D min ( X, Y)
X =3D min {2..n} {C(N= n,T,I)}
Y =3D min {1..n} {C(Ln,T,I)}

Of course, we should= additionally define the capacity of node (transmitting/receiving/forwardin= g aspect), I think that is
necessary.
And there are also some= other text need modification, such as IP-type-P Available Path Capacity.

For example, in the path between node A and B as follows,
=
A------link1------Router------link2------B

For some cert= ain packet/traffic, if the capacity of link1 is 5G bps and the capacity of = link2 is 3G bps, while the capacity of
the
router is 2G bps, how= much is the capacity of the path between A and B? I believe the capacity i= s 2G bps (the neckbottle is the
middle-box), but not 3G bps (as defi= nition of RFC5136).


Since this is a very late comment (on a = frozen RFC document), if you agree these are serious issues, I would submit= a new draft,
to
update this RFC.

Any thought?
=

Regards,
Xiangsong

__________________________= _____________________
ippm mailing list
ippm@ietf.org
= https://www.ietf.org/mailman/listinfo/ippm




-------------= -------------------------------------------------------------------

=
> _______________________________________________
> ippm maili= ng list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo= /ippm
>

From acmorton@att.com Wed Aug 11 06:35:39 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB933A6863 for ; Wed, 11 Aug 2010 06:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.888 X-Spam-Level: X-Spam-Status: No, score=-104.888 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 7HVRTn-6gFiU for ; Wed, 11 Aug 2010 06:35:37 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 81B913A689B for ; Wed, 11 Aug 2010 06:35:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-7.tower-146.messagelabs.com!1281533771!18157355!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 31213 invoked from network); 11 Aug 2010 13:36:11 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Aug 2010 13:36:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7BDaQca008814 for ; Wed, 11 Aug 2010 09:36:27 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7BDaNds008753 for ; Wed, 11 Aug 2010 09:36:23 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o7BDa7cr025504 for ; Wed, 11 Aug 2010 09:36:07 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o7BDa2RG025362 for ; Wed, 11 Aug 2010 09:36:02 -0400 Message-Id: <201008111336.o7BDa2RG025362@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100811133601gw100s4psoe>; Wed, 11 Aug 2010 13:36:01 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Aug 2010 09:36:21 -0400 To: pfc@ieee.org, Xiangsong.Cui@huawei.com From: Al Morton In-Reply-To: <24656454.944051.1281533032242.JavaMail.root@vms073.mailsrv cs.net> References: <24656454.944051.1281533032242.JavaMail.root@vms073.mailsrvcs.net> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 13:35:39 -0000 Hi Phil,

Perhaps this issue can be fully addressed with a short note,
essentially your text below submitted as an Errata
to RFC 5136. 

I think the concepts below were clearly understood
by the working group when we were working on the draft,
and so a simple clarification should be sufficient now.

Al

At 09:23 AM 8/11/2010, vze275m9@verizon.net wrote:
Xiangsong:
We did not forget to include the node capacity. As I explained, the node capacity and characteristics are implicitly included in the link capacity (that is, any restrictions in the node's performance will impact its ability to transmit IP packets at a given rate. So, for example, if you have a node with an outgoing link of 10 Gb/s and the node is only capable of transmitting 3 Gb/s at a given time on that link, then that is the capacity of that link at that time (note that we have a time parameter associated with each metric).
I understand that you would prefer to have this made explicit. It is too bad that your comments did not come earlier, but I see you have submitted your own draft.

Regards,
Phil Chimento

Aug 10, 2010 09:35:25 PM, Xiangsong.Cui@huawei.com wrote:
Hi Phil,

I know the precondition of IP-type-P, in my initial example, the first sentence is " For some certain packet/traffic,...", so we are
both talking about the capacity for IP-type-P and all we are discussing is about IP-type-P. I'm not discussing Layer 1 or layer 2
either, I'm talking about path and path capacity (in the precondition of IP-type-P, not physical capacity but IP capacity).

My concerns are:
the middle-box should be included in the definition of path,
the IP-type-P IP capacity of the middle-box should be considered in IP-type-P Path Capacity.

I believe IP-type-P Path Capacity is a very important metric, I like it, and just want to make it more accurate although that is a
hard job.

Regards,
Xiangsong

----- Original Message -----
From:
To:
Cc:
Sent: Tuesday, August 10, 2010 10:06 PM
Subject: Re: [ippm] Question/comment on RFC5136


Xiangsong:
Please notice that these are "IP-type-P ...Capacity". The same physical/logical path can have different capacities depending on the
type of IP packets sent, for example, packets with different DSCP values may see different capacities (because of traffic class
definitions in routers, for example). We were not trying to define this at Layer 1 or Layer 2. The formulas should all refer to IP
capacity of links and paths, not to the physical capacity per se (which is an upper bound that in practice is never reached).

Regards,
Phil Chimento

Aug 10, 2010 09:09:43 AM, Xiangsong.Cui@huawei.com wrote:

Hi Phil,

I'm more confused now,
You said "Defining "path capacity" on a lower level is a daunting task ......", and "Anyway, I believe that it is out of scope of
the IPPM WG". I agree this is a diffucult task, but let's take a look at the table of content of RFC5136, which reads:

2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7
2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7
2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7
2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8
2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8
2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8

In these sections, many formula are specified, such as

C(P,T,I) = min {1..n} {C(Ln,T,I)}


I think this RFC did specify the link capacity and path capacity (without consideration on the middle-boxes), and my questions
come from these sections.

I am sorry I don't know well the history of this RFC, but I noticed you are the author of this document, so could you please tell
me more information, e.g. the WG discussion?


Thanks and Best Regards
Xiangsong


------------------------------------------------------------------------------

Hi Xiangsong:
The rfc is actually about IP capacity, not about path capacity per se. The whole idea behind the rfc was to explore what
many of the "bandwidth" measurement tools were trying to measure. We settled on IP capacity because that is what a user sees; i.e.
what he can send and have correctly received from point A to point B at layer 3. This includes all the impairments from, say, a
wireless link which
has variable capacity and variable quality, or from an intermediate node (router, switch, security device, take your pick) which
has its backplane overloaded.
In your example, you are right, the rate is 2Gb/s because that is the rate of the correctly received IP bit stream.

Defining "path capacity" on a lower level is a daunting task because of the very large variety of middleboxes that exist (not just
L2/L3 transport elements, but also NATs, load balancers, security devices, etc etc), many of which can have peculiar behaviors, not
to mention the wide variety of link types that exist and do not have a fixed capacity. Anyway, I believe that it is out of scope of
the IPPM WG (Henk, Matt, correct me if I am wrong).
Regards,
Phil Chimento

Aug 9, 2010 09:27:19 PM, Xiangsong.Cui@huawei.com wrote:

Hi Phil,

Thank you for your quick feedback!

I do agree your statement about IP capacity, but I think that is a higher level concept, here I just want to talk about Path
Capacity.
You said "The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity.", my questions are:
Does the notion of "middle-box" capacity is included in the definition of Path Capacity? Should it be or not?


Additionally, I want to clarify my example, I also talked about IP capacity.

A------link1------Router------link2------B

Node A sends IP packets to B at the rate of 5G bps, and all the packets are transferred by the router.
The router forwards the packets, but the rate exceeds its capacity, so unfortunately bit error happens in 60% packets, and what
more
unfortunately is, the error bit is in IP header checksum.
Node B receives packets from the router, it detects the IP header checksum errors, so the accepted IP flow rate is 2G bps (the
capacity of the neckbottle, the router).

How should we say the capacity of the path between A and B?
I guess the capacity of the path is 2G bps, the invalid IP bandwidth is not our expected IP capacity (neither the link nor the
path), right?


Thanks and regards
Xiangsong


----- Original Message -----
From:
To:
Cc:
Sent: Monday, August 09, 2010 8:26 PM
Subject: Re: [ippm] Question/comment on RFC5136


Remember, what we are talking about here is the IP capacity, not raw link capacity. So the definition includes the number of IP
layer bits that can be transmitted by the source and received by the destination. Lots of things make this capacity smaller than
the
nominal link capacity measured at the physical layer. Some things that can reduce the IP layer capacity include: node backplane
capcity, NIC implementation, queueing structure, buffer management, etc. etc. The notion of "middle-box" capacity is, in effect,
included in the definition of IP capacity.

Regards,
Phil Chimento

Aug 9, 2010 12:00:47 AM, Xiangsong.Cui@huawei.com wrote:

Hi folks,

I'm reading RFC5136 "Defining Network Capacity", and I have some question/comment on it.


In section 2.1, the definition of link and path, it reads:

We then define a path P of length n as a series of
links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ...,
Nn+1). A source S and destination D reside at N1 and Nn+1,
respectively.

I'm a bit confused by this definition,
it seems the middle-boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the path between N1 and Nn+1,
is
this right?
it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box
should
be a part of the path?


Well, if the middle-boxes were part of the path, how about the "path capacity"?
In section 2.3.3, it specifies,

C(P,T,I) = min {1..n} {C(Ln,T,I)}

I think this should be updated, as

C(P,T,I) = min ( X, Y)
X = min {2..n} {C(Nn,T,I)}
Y = min {1..n} {C(Ln,T,I)}

Of course, we should additionally define the capacity of node (transmitting/receiving/forwarding aspect), I think that is
necessary.
And there are also some other text need modification, such as IP-type-P Available Path Capacity.


For example, in the path between node A and B as follows,

A------link1------Router------link2------B

For some certain packet/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of
the
router is 2G bps, how much is the capacity of the path between A and B? I believe the capacity is 2G bps (the neckbottle is the
middle-box), but not 3G bps (as definition of RFC5136).


Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft,
to
update this RFC.

Any thought?


Regards,
Xiangsong

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm




--------------------------------------------------------------------------------


> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
From vze275m9@verizon.net Wed Aug 11 07:31:30 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0464C3A6980 for ; Wed, 11 Aug 2010 07:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 GrkJjry3wiZH for ; Wed, 11 Aug 2010 07:31:27 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 79B223A698A for ; Wed, 11 Aug 2010 07:31:27 -0700 (PDT) Received: from vms073.mailsrvcs.net ([unknown] [192.168.1.2]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6Z00L81SCO42W1@vms173003.mailsrvcs.net> for ippm@ietf.org; Wed, 11 Aug 2010 09:31:37 -0500 (CDT) Received: from 128.244.9.9 ([128.244.9.9]) by vms073.mailsrvcs.net (Verizon Webmail) with HTTP; Wed, 11 Aug 2010 09:31:36 -0500 (CDT) Date: Wed, 11 Aug 2010 09:31:36 -0500 (CDT) From: vze275m9@verizon.net To: acmorton@att.com Message-id: <32270797.944947.1281537096896.JavaMail.root@vms073.mailsrvcs.net> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7bit X-Originating-IP: [128.244.9.9] Cc: Xiangsong.Cui@huawei.com, ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pfc@ieee.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 14:31:30 -0000 Hi Al:
That's fine with me. Who would determine direction on this? Henk and Matt?
Regards,
Phil Chimento

Aug 11, 2010 09:36:22 AM, acmorton@att.com wrote:
Hi Phil,

Perhaps this issue can be fully addressed with a short note,
essentially your text below submitted as an Errata
to RFC 5136. 

I think the concepts below were clearly understood
by the working group when we were working on the draft,
and so a simple clarification should be sufficient now.

Al

At 09:23 AM 8/11/2010, vze275m9@verizon.net wrote:
Xiangsong:
We did not forget to include the node capacity. As I explained, the node capacity and characteristics are implicitly included in the link capacity (that is, any restrictions in the node's performance will impact its ability to transmit IP packets at a given rate. So, for example, if you have a node with an outgoing link of 10 Gb/s and the node is only capable of transmitting 3 Gb/s at a given time on that link, then that is the capacity of that link at that time (note that we have a time parameter associated with each metric).
I understand that you would prefer to have this made explicit. It is too bad that your comments did not come earlier, but I see you have submitted your own draft.

Regards,
Phil Chimento

Aug 10, 2010 09:35:25 PM, Xiangsong.Cui@huawei.com wrote:
Hi Phil,

I know the precondition of IP-type-P, in my initial example, the first sentence is " For some certain packet/traffic,...", so we are
both talking about the capacity for IP-type-P and all we are discussing is about IP-type-P. I'm not discussing Layer 1 or layer 2
either, I'm talking about path and path capacity (in the precondition of IP-type-P, not physical capacity but IP capacity).

My concerns are:
the middle-box should be included in the definition of path,
the IP-type-P IP capacity of the middle-box should be considered in IP-type-P Path Capacity.

I believe IP-type-P Path Capacity is a very important metric, I like it, and just want to make it more accurate although that is a
hard job.

Regards,
Xiangsong

----- Original Message -----
From:
To:
Cc:
Sent: Tuesday, August 10, 2010 10:06 PM
Subject: Re: [ippm] Question/comment on RFC5136


Xiangsong:
Please notice that these are "IP-type-P ...Capacity". The same physical/logical path can have different capacities depending on the
type of IP packets sent, for example, packets with different DSCP values may see different capacities (because of traffic class
definitions in routers, for example). We were not trying to define this at Layer 1 or Layer 2. The formulas should all refer to IP
capacity of links and paths, not to the physical capacity per se (which is an upper bound that in practice is never reached).

Regards,
Phil Chimento

Aug 10, 2010 09:09:43 AM, Xiangsong.Cui@huawei.com wrote:

Hi Phil,

I'm more confused now,
You said "Defining "path capacity" on a lower level is a daunting task ......", and "Anyway, I believe that it is out of scope of
the IPPM WG". I agree this is a diffucult task, but let's take a look at the table of content of RFC5136, which reads:

2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7
2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7
2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7
2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8
2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8
2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8

In these sections, many formula are specified, such as

C(P,T,I) = min {1..n} {C(Ln,T,I)}


I think this RFC did specify the link capacity and path capacity (without consideration on the middle-boxes), and my questions
come from these sections.

I am sorry I don't know well the history of this RFC, but I noticed you are the author of this document, so could you please tell
me more information, e.g. the WG discussion?


Thanks and Best Regards
Xiangsong


------------------------------------------------------------------------------

Hi Xiangsong:
The rfc is actually about IP capacity, not about path capacity per se. The whole idea behind the rfc was to explore what
many of the "bandwidth" measurement tools were trying to measure. We settled on IP capacity because that is what a user sees; i.e.
what he can send and have correctly received from point A to point B at layer 3. This includes all the impairments from, say, a
wireless link which
has variable capacity and variable quality, or from an intermediate node (router, switch, security device, take your pick) which
has its backplane overloaded.
In your example, you are right, the rate is 2Gb/s because that is the rate of the correctly received IP bit stream.

Defining "path capacity" on a lower level is a daunting task because of the very large variety of middleboxes that exist (not just
L2/L3 transport elements, but also NATs, load balancers, security devices, etc etc), many of which can have peculiar behaviors, not
to mention the wide variety of link types that exist and do not have a fixed capacity. Anyway, I believe that it is out of scope of
the IPPM WG (Henk, Matt, correct me if I am wrong).
Regards,
Phil Chimento

Aug 9, 2010 09:27:19 PM, Xiangsong.Cui@huawei.com wrote:

Hi Phil,

Thank you for your quick feedback!

I do agree your statement about IP capacity, but I think that is a higher level concept, here I just want to talk about Path
Capacity.
You said "The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity.", my questions are:
Does the notion of "middle-box" capacity is included in the definition of Path Capacity? Should it be or not?


Additionally, I want to clarify my example, I also talked about IP capacity.

A------link1------Router------link2------B

Node A sends IP packets to B at the rate of 5G bps, and all the packets are transferred by the router.
The router forwards the packets, but the rate exceeds its capacity, so unfortunately bit error happens in 60% packets, and what
more
unfortunately is, the error bit is in IP header checksum.
Node B receives packets from the router, it detects the IP header checksum errors, so the accepted IP flow rate is 2G bps (the
capacity of the neckbottle, the router).

How should we say the capacity of the path between A and B?
I guess the capacity of the path is 2G bps, the invalid IP bandwidth is not our expected IP capacity (neither the link nor the
path), right?


Thanks and regards
Xiangsong


----- Original Message -----
From:
To:
Cc:
Sent: Monday, August 09, 2010 8:26 PM
Subject: Re: [ippm] Question/comment on RFC5136


Remember, what we are talking about here is the IP capacity, not raw link capacity. So the definition includes the number of IP
layer bits that can be transmitted by the source and received by the destination. Lots of things make this capacity smaller than
the
nominal link capacity measured at the physical layer. Some things that can reduce the IP layer capacity include: node backplane
capcity, NIC implementation, queueing structure, buffer management, etc. etc. The notion of "middle-box" capacity is, in effect,
included in the definition of IP capacity.

Regards,
Phil Chimento

Aug 9, 2010 12:00:47 AM, Xiangsong.Cui@huawei.com wrote:

Hi folks,

I'm reading RFC5136 "Defining Network Capacity", and I have some question/comment on it.


In section 2.1, the definition of link and path, it reads:

We then define a path P of length n as a series of
links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ...,
Nn+1). A source S and destination D reside at N1 and Nn+1,
respectively.

I'm a bit confused by this definition,
it seems the middle-boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the path between N1 and Nn+1,
is
this right?
it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box
should
be a part of the path?


Well, if the middle-boxes were part of the path, how about the "path capacity"?
In section 2.3.3, it specifies,

C(P,T,I) = min {1..n} {C(Ln,T,I)}

I think this should be updated, as

C(P,T,I) = min ( X, Y)
X = min {2..n} {C(Nn,T,I)}
Y = min {1..n} {C(Ln,T,I)}

Of course, we should additionally define the capacity of node (transmitting/receiving/forwarding aspect), I think that is
necessary.
And there are also some other text need modification, such as IP-type-P Available Path Capacity.


For example, in the path between node A and B as follows,

A------link1------Router------link2------B

For some certain packet/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of
the
router is 2G bps, how much is the capacity of the path between A and B? I believe the capacity is 2G bps (the neckbottle is the
middle-box), but not 3G bps (as definition of RFC5136).


Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft,
to
update this RFC.

Any thought?


Regards,
Xiangsong

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm




--------------------------------------------------------------------------------


> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
From acmorton@att.com Wed Aug 11 07:40:14 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC09C3A68CB for ; Wed, 11 Aug 2010 07:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.849 X-Spam-Level: X-Spam-Status: No, score=-104.849 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 L5s-EcbCS57X for ; Wed, 11 Aug 2010 07:40:13 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id A66DC3A6944 for ; Wed, 11 Aug 2010 07:40:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1281537648!37598537!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 10336 invoked from network); 11 Aug 2010 14:40:48 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Aug 2010 14:40:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7BEf4UI032353 for ; Wed, 11 Aug 2010 10:41:04 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7BEf0kS032288 for ; Wed, 11 Aug 2010 10:41:00 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o7BEeiX3012874 for ; Wed, 11 Aug 2010 10:40:44 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o7BEecTh012668 for ; Wed, 11 Aug 2010 10:40:38 -0400 Message-Id: <201008111440.o7BEecTh012668@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100811144037gw100s4pt5e>; Wed, 11 Aug 2010 14:40:37 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Aug 2010 10:40:58 -0400 To: pfc@ieee.org From: Al Morton In-Reply-To: <32270797.944947.1281537096896.JavaMail.root@vms073.mailsrv cs.net> References: <32270797.944947.1281537096896.JavaMail.root@vms073.mailsrvcs.net> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Cc: Xiangsong.Cui@huawei.com, ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 14:40:14 -0000 At 10:31 AM 8/11/2010, vze275m9@verizon.net wrote:
Hi Al:
That's fine with me. Who would determine direction on this? Henk and Matt?

Ultimately, I think an Errata makes sense here whether there's
a new draft or not.

IIRC, the Errata must be approved by some combination
of authors and chairs, but anyone can submit Errata using the on-line
system. That would get the process rolling.

Al

Regards,
Phil Chimento

Aug 11, 2010 09:36:22 AM, acmorton@att.com wrote:
Hi Phil,

Perhaps this issue can be fully addressed with a short note,
essentially your text below submitted as an Errata
to RFC 5136. 

I think the concepts below were clearly understood
by the working group when we were working on the draft,
and so a simple clarification should be sufficient now.

Al

At 09:23 AM 8/11/2010, vze275m9@verizon.net wrote:
Xiangsong:
We did not forget to include the node capacity. As I explained, the node capacity and characteristics are implicitly included in the link capacity (that is, any restrictions in the node's performance will impact its ability to transmit IP packets at a given rate. So, for example, if you have a node with an outgoing link of 10 Gb/s and the node is only capable of transmitting 3 Gb/s at a given time on that link, then that is the capacity of that link at that time (note that we have a time parameter associated with each metric).
I understand that you would prefer to have this made explicit. It is too bad that your comments did not come earlier, but I see you have submitted your own draft.

Regards,
Phil Chimento
From wwwrun@rfc-editor.org Wed Aug 11 10:15:00 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6631E3A6A7A; Wed, 11 Aug 2010 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.014 X-Spam-Level: X-Spam-Status: No, score=-102.014 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 WJMYq0jz7fbJ; Wed, 11 Aug 2010 10:14:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id E8CE13A6986; Wed, 11 Aug 2010 10:14:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 27DB2E06B7; Wed, 11 Aug 2010 10:15:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100811171533.27DB2E06B7@rfc-editor.org> Date: Wed, 11 Aug 2010 10:15:33 -0700 (PDT) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 5938 on Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 17:15:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5938 Title: Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) Author: A. Morton, M. Chiba Status: Standards Track Stream: IETF Date: August 2010 Mailbox: acmorton@att.com, mchiba@cisco.com Pages: 17 Characters: 37539 Updates: RFC5357 I-D Tag: draft-ietf-ippm-twamp-session-cntrl-07.txt URL: http://www.rfc-editor.org/rfc/rfc5938.txt The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS TRACK] This document is a product of the IP Performance Metrics Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Xiangsong.Cui@huawei.com Wed Aug 11 19:04:40 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7BF3A68AE for ; Wed, 11 Aug 2010 19:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 qonP19E2jqVN for ; Wed, 11 Aug 2010 19:04:39 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3890B3A67A4 for ; Wed, 11 Aug 2010 19:04:39 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L70003FDOGHLE@szxga05-in.huawei.com> for ippm@ietf.org; Thu, 12 Aug 2010 10:05:05 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7000L9BOGE35@szxga05-in.huawei.com> for ippm@ietf.org; Thu, 12 Aug 2010 10:05:05 +0800 (CST) Date: Thu, 12 Aug 2010 10:05:02 +0800 From: Xiangsong Cui To: pfc@ieee.org Message-id: <003101cb39c2$c78e9500$80106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; format=flowed; charset=UTF-8; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <24656454.944051.1281533032242.JavaMail.root@vms073.mailsrvcs.net> Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 02:04:40 -0000 Hi Phil, and also to Al, I don't think things are so simple. Please see my comments inline. Regards, Xiangsong ----- Original Message ----- From: To: Cc: ; Sent: Wednesday, August 11, 2010 9:23 PM Subject: Re: Re: [ippm] Question/comment on RFC5136 Xiangsong: We did not forget to include the node capacity. As I explained, the node capacity and characteristics are implicitly included in the link capacity (that is, any restrictions in the node's performance will impact its ability to transmit IP packets at a given rate. So, for example, if you have a node with an outgoing link of 10 Gb/s and the node is only capable of transmitting 3 Gb/s at a given time on that link, then that is the capacity of that link at that time (note that we have a time parameter associated with each metric). Xiangsong=>We used to talk about path and path capacity, now we begin to discuss link capacity. I just want to mention another metric here, that is IP-type-P Link Usage. IMHO, link capacity does NOT depend on the IP nodes it connectes to (as link capacity is defined in RFC5136). What you said seems to me is the link usage, but not the link capacity. Because, the link capacity is "the maximum number of IP-layer bits that can be transmitted from the source S and correctly received by the destination D over the link L during the interval [T, T+I], divided by I". Notice the *MAX*, for a same link (between S and D), if you measure and get two values (e.g. 2G bps and 5G bps) in two cases (with different nodes), how can you say about the capacity value? It has two MAX numbers? and the two MAX values are NOT equal to each other? I can give another example here, if you get a high-class router (e.g. 1T bps capacity) from a vendor, and you test it in your lab but you connect it to a low-class router (e.g. 1G bps capacity). After the test, you announce that the capacity of the high-class router is 1G bps, yes, it the right value you got from your test. But, would the vendor agree this is the capacity of their device? I don't think they would agree, the value you announced, is the usage in your environment, but not the capacity, right? I agree that the link capacity is content (the packet go through the link) dependent, time depdent, duration dependent, but I do NOT think it was external-device dependent. If you still want to take the IP nodes as a factor of link capacity (I still think this is confusing), I suggest changing the formula C(L,T,I), at least should be modified to C(L,T,I,N1,N2), to present the capability of given link from N1 to N2, begin from time T, during period I, and in the precondition IP type P. I understand that you would prefer to have this made explicit. It is too bad that your comments did not come earlier, but I see you have submitted your own draft. Xiangsong=>Yes, I want to make it clear (as soon as possible, because I think the RFC is important and the clarification is also), and it is really too late :( But I havn't submitted my draft, what you saw is just a draft of the draft :), to formally and detailedly express my thought. Regards, Xiangsong Regards, Phil Chimento Aug 10, 2010 09:35:25 PM, Xiangsong.Cui@huawei.com wrote: Hi Phil, I know the precondition of IP-type-P, in my initial example, the first sentence is " For some certain packet/traffic,...", so we are both talking about the capacity for IP-type-P and all we are discussing is about IP-type-P. I'm not discussing Layer 1 or layer 2 either, I'm talking about path and path capacity (in the precondition of IP-type-P, not physical capacity but IP capacity). My concerns are: the middle-box should be included in the definition of path, the IP-type-P IP capacity of the middle-box should be considered in IP-type-P Path Capacity. I believe IP-type-P Path Capacity is a very important metric, I like it, and just want to make it more accurate although that is a hard job. Regards, Xiangsong ----- Original Message ----- From: To: Cc: Sent: Tuesday, August 10, 2010 10:06 PM Subject: Re: [ippm] Question/comment on RFC5136 Xiangsong: Please notice that these are "IP-type-P ...Capacity". The same physical/logical path can have different capacities depending on the type of IP packets sent, for example, packets with different DSCP values may see different capacities (because of traffic class definitions in routers, for example). We were not trying to define this at Layer 1 or Layer 2. The formulas should all refer to IP capacity of links and paths, not to the physical capacity per se (which is an upper bound that in practice is never reached). Regards, Phil Chimento Aug 10, 2010 09:09:43 AM, Xiangsong.Cui@huawei.com wrote: Hi Phil, I'm more confused now, You said "Defining "path capacity" on a lower level is a daunting task ......", and "Anyway, I believe that it is out of scope of the IPPM WG". I agree this is a diffucult task, but let's take a look at the table of content of RFC5136, which reads: 2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7 2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7 2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7 2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8 2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8 2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8 In these sections, many formula are specified, such as C(P,T,I) = min {1..n} {C(Ln,T,I)} I think this RFC did specify the link capacity and path capacity (without consideration on the middle-boxes), and my questions come from these sections. I am sorry I don't know well the history of this RFC, but I noticed you are the author of this document, so could you please tell me more information, e.g. the WG discussion? Thanks and Best Regards Xiangsong ------------------------------------------------------------------------------ Hi Xiangsong: The rfc is actually about IP capacity, not about path capacity per se. The whole idea behind the rfc was to explore what many of the "bandwidth" measurement tools were trying to measure. We settled on IP capacity because that is what a user sees; i.e. what he can send and have correctly received from point A to point B at layer 3. This includes all the impairments from, say, a wireless link which has variable capacity and variable quality, or from an intermediate node (router, switch, security device, take your pick) which has its backplane overloaded. In your example, you are right, the rate is 2Gb/s because that is the rate of the correctly received IP bit stream. Defining "path capacity" on a lower level is a daunting task because of the very large variety of middleboxes that exist (not just L2/L3 transport elements, but also NATs, load balancers, security devices, etc etc), many of which can have peculiar behaviors, not to mention the wide variety of link types that exist and do not have a fixed capacity. Anyway, I believe that it is out of scope of the IPPM WG (Henk, Matt, correct me if I am wrong). Regards, Phil Chimento Aug 9, 2010 09:27:19 PM, Xiangsong.Cui@huawei.com wrote: Hi Phil, Thank you for your quick feedback! I do agree your statement about IP capacity, but I think that is a higher level concept, here I just want to talk about Path Capacity. You said "The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity.", my questions are: Does the notion of "middle-box" capacity is included in the definition of Path Capacity? Should it be or not? Additionally, I want to clarify my example, I also talked about IP capacity. A------link1------Router------link2------B Node A sends IP packets to B at the rate of 5G bps, and all the packets are transferred by the router. The router forwards the packets, but the rate exceeds its capacity, so unfortunately bit error happens in 60% packets, and what more unfortunately is, the error bit is in IP header checksum. Node B receives packets from the router, it detects the IP header checksum errors, so the accepted IP flow rate is 2G bps (the capacity of the neckbottle, the router). How should we say the capacity of the path between A and B? I guess the capacity of the path is 2G bps, the invalid IP bandwidth is not our expected IP capacity (neither the link nor the path), right? Thanks and regards Xiangsong ----- Original Message ----- From: To: Cc: Sent: Monday, August 09, 2010 8:26 PM Subject: Re: [ippm] Question/comment on RFC5136 Remember, what we are talking about here is the IP capacity, not raw link capacity. So the definition includes the number of IP layer bits that can be transmitted by the source and received by the destination. Lots of things make this capacity smaller than the nominal link capacity measured at the physical layer. Some things that can reduce the IP layer capacity include: node backplane capcity, NIC implementation, queueing structure, buffer management, etc. etc. The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity. Regards, Phil Chimento Aug 9, 2010 12:00:47 AM, Xiangsong.Cui@huawei.com wrote: Hi folks, I'm reading RFC5136 "Defining Network Capacity", and I have some question/comment on it. In section 2.1, the definition of link and path, it reads: We then define a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and destination D reside at N1 and Nn+1, respectively. I'm a bit confused by this definition, it seems the middle-boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the path between N1 and Nn+1, is this right? it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box should be a part of the path? Well, if the middle-boxes were part of the path, how about the "path capacity"? In section 2.3.3, it specifies, C(P,T,I) = min {1..n} {C(Ln,T,I)} I think this should be updated, as C(P,T,I) = min ( X, Y) X = min {2..n} {C(Nn,T,I)} Y = min {1..n} {C(Ln,T,I)} Of course, we should additionally define the capacity of node (transmitting/receiving/forwarding aspect), I think that is necessary. And there are also some other text need modification, such as IP-type-P Available Path Capacity. For example, in the path between node A and B as follows, A------link1------Router------link2------B For some certain packet/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of the router is 2G bps, how much is the capacity of the path between A and B? I believe the capacity is 2G bps (the neckbottle is the middle-box), but not 3G bps (as definition of RFC5136). Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft, to update this RFC. Any thought? Regards, Xiangsong _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm -------------------------------------------------------------------------------- > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From Xiangsong.Cui@huawei.com Thu Aug 12 18:24:10 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5973A6A7A for ; Thu, 12 Aug 2010 18:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.219 X-Spam-Level: X-Spam-Status: No, score=0.219 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 viVQ6jJU8W0c for ; Thu, 12 Aug 2010 18:24:07 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 99C9C3A6958 for ; Thu, 12 Aug 2010 18:24:07 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7200CEXH8XWA@szxga01-in.huawei.com> for ippm@ietf.org; Fri, 13 Aug 2010 09:24:34 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7200BD5H8XKK@szxga01-in.huawei.com> for ippm@ietf.org; Fri, 13 Aug 2010 09:24:33 +0800 (CST) Date: Fri, 13 Aug 2010 09:24:32 +0800 From: Xiangsong Cui To: Joseph Ishac Message-id: <000901cb3a86$488efc30$80106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00a701cb3777$2cc70ef0$80106f0a@china.huawei.com> <20100812173013.GA29879@firebird1.grc.nasa.gov> Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 01:24:11 -0000 Hi Joseph, Thanks for your response! We come to link capacity again, I showed my option on this problem in the link: http://www.ietf.org/mail-archive/web/ippm/current/msg02417.html As to link and link capacity, I want to make sure: Is IP node is a part or a IP link? I guess not, because link is the layer2-level connection, it is the media, the facility, the layer2 protocol..., but does Not cover nodes, which is a layer3 concept. So C(L,T,I) is node-independent, right? If you insisit link capacity is node-dependent, I give my third example here. In the following scenario, where link1/link2/link3/link4 physical capacity is 1.x G bps, they all use the same link protocol, and we assume their "physical IP capacity" is 1G bps. Same way, the router IP capacity is 1G bps. host A------link1-------- ----------link2------ host B \ / Router / \ host C------link3-------- ----------link4------ host D Phase 1, only host A transmit packets (IP-type-P) to host B, other hosts don't transimit any packet. Base on RFC5136, the IP capacity of link1 and link2 is 1G bps for the certain time/period, the link usage is same. IP capacity of link3 and link4 is 0 bps and link usage is also same (althouth their physical IP capacity is 1G bps). As to IP-type-P Link Utilization, base on the definition of RFC5136, Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100% (1G bps/1G bps), this looks right, but how about link3 and link4? the IP-type-P Link Utilization of link3 is 0/0, what does this mean? (in my mind, when a link is idle, the link utilization is 0, but not 0/0) Well, phase 2, host C begin to transmit packets (IP-type-P) to host D (others keep unchanged, same networks, same nodes, same links....), also at the rate 1G bps. Unfortunately, router over-loads, but it still works fairly. so link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is the metric? Base on RFC5136, the IP capacity of link1 and link2 is 500M bps for the certain time/period, the link usage is same. IP capacity of link3 and link4 is 500M bps for the certain time/period and link usage is also same. As to IP-type-P Link Utilization, base on the definition of RFC5136, Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100% (500M bps/500M bps), this looks very strange, Link Utilization is unchaged, really? How about link3 and link4? the IP-type-P Link Utilization of link3 is 100% (500M / 500M)? Now, it is phase 3, host A stop transmitting packets, host C still transmitting as before. Base on RFC5136, the IP capacity of link1 and link2 is 0 G bps, the link usage is same. IP capacity of link3 and link4 is 1G bps and link usage is also same. How to calculate C(L,T,I) and Util(L,T,I) now? All of these, are more and more confusing..................................... Regards Xiangsong ----- Original Message ----- From: "Joseph Ishac" To: "Xiangsong Cui" Cc: Sent: Friday, August 13, 2010 1:30 AM Subject: Re: [ippm] Question/comment on RFC5136 > Just getting back from vacation so I'm slowly catching up here. I've > not parsed the whole thread, but have some thoughts on the initial > question and will throw that out here as I catch up. > >> For example, in the path between node A and B as follows, >> >> A------link1------Router------link2------B >> >> For some certain packet/traffic, if the capacity of link1 is 5G bps >> and the capacity of link2 is 3G bps, while the capacity of the router >> is 2G bps, how much is the capacity of the path between A and B? I >> believe the capacity is 2G bps (the neckbottle is the >> middle-box), but not 3G bps (as definition of RFC5136). > > Well, the RFC calls out a couple of things. The 5 Gbit/s and 3 Gbit/s > links would be "Nominal Physical Link Capacity" such that: > > NomCap(link1) = 5 Gbit/s > NomCap(link2) = 3 Gbit/s > > Now, the "IP-type-P Link Capacity" is what can be transmitted on a link > by link basis. So if A has no problem saturating the router then for > some given time, T, and interval, I: > > C(link1,T,I) ~= 5 Gbit/s > C(link2,T,I) ~= 2 Gbit/s > > The reason being that the Capacity at link 2 is driven by the ability to > transmit IP data from "Router" to "B". If "Router" has a limitation > here it impacts this value. > >> I think this should be updated, as >> >> C(P,T,I) = min ( X, Y) >> X = min {2..n} {C(Nn,T,I)} >> Y = min {1..n} {C(Ln,T,I)} > > The way I read the above is that value for Y is essentially the limit of > "Nominal Physical Link Capacity". The value of X is attempting to > factor in only *one* possible limiting factor to that, particularly a > node's forwarding and processing ability. > > Our original definition of C aims to capture the many factors that can > inhibit the ability to reach the "Nominal Physical Link Capacity" and as > such I believe is intended to be more robust than the case outlined > above. > > I will note that in practice, measuring all of this is VERY hard (and we > note this in the draft). However this document is not itself intended to > be a measuring technique, but instead, a conceptual analysis of what > should be counted. > > -Joseph From Ruediger.Geib@telekom.de Fri Aug 13 02:41:45 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22893A67FA for ; Fri, 13 Aug 2010 02:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 KjoHgvv3wfgx for ; Fri, 13 Aug 2010 02:41:45 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 86BA93A67F4 for ; Fri, 13 Aug 2010 02:41:44 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 13 Aug 2010 11:42:16 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 11:42:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Aug 2010 11:42:15 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5047ABFA2@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <4C31990B.6030104@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ippm-tcp-throughput-tm Thread-Index: AcscHOZrlhSrDhVEQHO03e5yr0wCogeqt8oQ References: <4C31990B.6030104@ripe.net> From: To: X-OriginalArrivalTime: 13 Aug 2010 09:42:16.0495 (UTC) FILETIME=[D0BC13F0:01CB3ACB] Cc: ippm@ietf.org Subject: [ippm] draft-ietf-ippm-tcp-throughput-tm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:41:46 -0000 Barry, the aspect was mentioned during the Maastricht meeting and by this mail = it goes to the list too: Is tcp-throughput-tm designed to be performed on dedidcated = infrastructure (like a leased line infrastructure) only, or is it = designed to operate on shared infrastructure (like VRF based L2 or L3 = VPNs)? This should be stated explicitely in the text. If tcp-throughput-tm is designed for shared infrastructure, any test = incurring load to a level that congestion in a providers network is a = likely outcome should be coordinated with that provider (or not be = performed at all). IETF likes to avoid numbering performance, but my = personal take is if a customer interface can transmit a load of more = than 10% of a single provider edge network internal interface bandwidth, = the provider may like to be informed about these load tests. As far as I = understand, most business customers hardly congest their own interfaces, = meaning that loads of a level of more than 90% of such an interface = shouldn't occur. Further, standard traffic has an address entropy = enabling load sharing within the providers network. We have experience = with a special customer whose traffic didn't meet the above provider = expectations while being of high bandwidth. We agreed that the customer = informs the NOC when planing to create traffic with the unusual patterns = mentioned above. I think that a company requesting a tcp-throughput-tm from someone may = be annoyed if the NOC of the povider gives the companie's network admin = a call inquiring what's going on there even before service started. Should the intention of the draft however be to induce congestion in a = provider network, please add a clear statement expressing that. Regards, Ruediger From vinayakh@gmail.com Fri Aug 13 02:54:24 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376DF3A697F for ; Fri, 13 Aug 2010 02:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 FF1ZZ+IMvZyr for ; Fri, 13 Aug 2010 02:54:22 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 4C9A33A68F1 for ; Fri, 13 Aug 2010 02:54:22 -0700 (PDT) Received: by qwc9 with SMTP id 9so2836913qwc.31 for ; Fri, 13 Aug 2010 02:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=FiUOGcOj8rTwflgMZI1wl2H1D5DFSX1SuPGCPbagNUI=; b=NogiFUUPLD3v2O4rFudOtIcjzS3459YPN+cOyjqxqjogdWgGyN5qOvjUakFxoca9Jw meXaI0IDS4DVI/BaZmJjbdscOpaBTsQS8jLJPdSehurDl4cJVIsBEmp/6RUNDALYtJ5G u8D7NXgNT3+SaClRBesucEP7T87KaUmfu2k3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qSY5zxVKxIbzN/nYRqWNPeU0LTqTumONOVQUPClQ1DehReL3TpVvDwwq73OW88OSyi Tcf9d0IpvdyRDVdiJ/Rv75/q0/5FQweGmxOjQuvHptIAPzpTZRtCMGRFc0IlX+T4dHUc kxOY11JBlmxmaVBPWDDLdFOKjB4QCR6yMsEo4= MIME-Version: 1.0 Received: by 10.220.179.7 with SMTP id bo7mr484044vcb.2.1281693298827; Fri, 13 Aug 2010 02:54:58 -0700 (PDT) Received: by 10.220.193.141 with HTTP; Fri, 13 Aug 2010 02:54:58 -0700 (PDT) Date: Fri, 13 Aug 2010 15:24:58 +0530 Message-ID: From: Vinayak Hegde To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [ippm] CFP - IEEE Comm. Magazine feature topic on "Recent Advances in IETF Standards" X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:54:24 -0000 ================================================================== Call For Papers - IEEE Communications Magazine Feature Topic on "Recent Advances in IETF Standards" ================================================================== The mission of the Internet engineering Task Force (IETF) is to "make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet". This is a continuous process driving and driven by the rapid evolution of the Internet. Protocols and other technical standards developed by the IETF are fundamental building blocks of the networked society. This feature topic will give an overview of recent achievements in creating standards that soon will have an impact on design, use and management of the Internet. We welcome tutorial style papers that describe new IETF standards as well as research papers presenting results that had an impact on the standardization process or that investigate the expected impact of recent standards. All submissions should be written to be understandable and appealing to a general audience. Areas of Interest ================= Areas of interest include standards track work that has been completed recently or will be completed soon from all areas of the IETF including but not limited to - Emergency service - Location based services - Internationalization - Peer-to-peer communication - Network address translation - Congestion control - IP6 transition - Mobility and mobility management - Secure DNS - Routing security - Locator/Identifier Separation - MPLS Transport Profile - Better-than-nothing security - Network configuration with XML - Internet metrics and measurement Schedule ======== Full paper submission: October 1, 2010 Author notifications: December 17, 2010 Manuscripts in final form: January 27, 2011 Publication date: April 2011 Submission Instructions ======================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the field. Authors must follow the IEEE Communications Magazine's guidelines for preparation of the manuscript. Complete guidelines for prospective authors can be found at http://www.comsoc.org/livepubs/ci1/info/sub_guidelines.html. All articles to be considered for publication must be submitted through the IEEE Manuscript Central (http://commag-ieee.manuscriptcentral.com). Guest Editors ============= Juergen Quittek, NEC Europe Ltd., quittek@neclab.eu Henning Schulzrinne, Columbia University, hgs@cs.columbia.edu Joe Touch, Postel Center, USC/ISI, touch@isi.edu From eelco.bottenheft@tele2.com Fri Aug 13 03:05:12 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1053C3A698F for ; Fri, 13 Aug 2010 03:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 p9cNhDMmT-Ph for ; Fri, 13 Aug 2010 03:05:09 -0700 (PDT) Received: from gw1-in.tele2.se (gw1-in.tele2.se [193.12.60.45]) by core3.amsl.com (Postfix) with ESMTP id 7CDB43A6982 for ; Fri, 13 Aug 2010 03:05:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,362,1278280800"; d="scan'208";a="21979576" Received: from unknown (HELO T2eiffel.t2srv.corp.tele2.com) ([172.16.241.7]) by gw1-out.tele2.se with ESMTP; 13 Aug 2010 12:05:44 +0200 Auto-Submitted: auto-generated From: Eelco Bottenheft To: ippm@ietf.org Message-ID: Date: Fri, 13 Aug 2010 12:05:43 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [ippm] Eelco Bottenheft is out of the office. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 10:05:12 -0000 I will be out of the office starting 12/08/2010 and will not return until 16/08/2010. During this period I will not read my email. I will respond to your mail when I return. For urgent matters please contact my manager Joop Grewer. regards Eelco Bottenheft From root@core3.amsl.com Fri Aug 13 10:15:05 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 18F1C3A6A29; Fri, 13 Aug 2010 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100813171503.18F1C3A6A29@core3.amsl.com> Date: Fri, 13 Aug 2010 10:15:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 17:15:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : TCP Throughput Testing Methodology Author(s) : B. Constantine, et al. Filename : draft-ietf-ippm-tcp-throughput-tm-05.txt Pages : 20 Date : 2010-08-13 This memo describes a methodology for measuring sustained TCP throughput performance in an end-to-end managed network environment. This memo is intended to provide a practical approach to help users validate the TCP layer performance of a managed network, which should provide a better indication of end-user application level experience. In the methodology, various TCP and network parameters are identified that should be tested as part of the network verification at the TCP layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-tcp-throughput-tm-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-13101314.I-D@ietf.org> --NextPart-- From Barry.Constantine@jdsu.com Fri Aug 13 13:41:13 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7175E3A6852 for ; Fri, 13 Aug 2010 13:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XCid-C+bqAxL for ; Fri, 13 Aug 2010 13:41:12 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with SMTP id 370F53A65A5 for ; Fri, 13 Aug 2010 13:41:11 -0700 (PDT) Received: from source ([209.36.247.245]) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTGWuDIp0m2fD5E9E+HyHjOuocR94+lBA@postini.com; Fri, 13 Aug 2010 13:41:49 PDT Received: from milexhtca1.ds.jdsu.net ([10.75.2.121]) by Outbound2.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 13:36:30 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca1.ds.jdsu.net ([::1]) with mapi; Fri, 13 Aug 2010 13:36:29 -0700 From: Barry Constantine To: "ippm@ietf.org" Date: Fri, 13 Aug 2010 13:36:27 -0700 Thread-Topic: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-05.txt Thread-Index: Acs7Cy6eDrj1QVFqRWKEnj2LOLF/dAAG9JYg Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B9B46B10@MILEXCH1.ds.jdsu.net> References: <20100813171503.18F1C3A6A29@core3.amsl.com> In-Reply-To: <20100813171503.18F1C3A6A29@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2010 20:36:30.0006 (UTC) FILETIME=[35A68560:01CB3B27] Subject: Re: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 20:41:13 -0000 Hello All, I was not able to attend the Maastricht session, but listened to the audio = stream and jabbered. There was also some very good comments made through some emails right after= ward. The summary of revisions present in the version -05 are: - Clearly defined the configurable TCP and network parameters that are =20 the core target of this methodology - Bi-directional (in addition to uni-directional) testing is discussed - Specified how multiple retransmitted bytes are to be computed in the=20 TCP Efficiency metric - Discussed the implications of using dedicated test equipment versus=20 standard computers to compute the TCP Efficiency metric (detecting=20 retransmissions) - Added the concept of a normalized TCP Transfer Time ratio (Actual /=20 Ideal) - Expanded upon the relationship of TCP Transfer Time and TCP Efficiency - Generalized the Layer 2/3 "pre-test" techniques to satisfy concerns of=20 the reference to RFC2544 Thanks, Barry -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Int= ernet-Drafts@ietf.org Sent: Friday, August 13, 2010 1:15 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of th= e IETF. Title : TCP Throughput Testing Methodology Author(s) : B. Constantine, et al. Filename : draft-ietf-ippm-tcp-throughput-tm-05.txt Pages : 20 Date : 2010-08-13 This memo describes a methodology for measuring sustained TCP=20 throughput performance in an end-to-end managed network environment. =20 This memo is intended to provide a practical approach to help users=20 validate the TCP layer performance of a managed network, which should=20 provide a better indication of end-user application level experience. =20 In the methodology, various TCP and network parameters are identified=20 that should be tested as part of the network verification at the TCP=20 layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-05.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From root@core3.amsl.com Sat Aug 14 12:30:06 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B09C83A6884; Sat, 14 Aug 2010 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100814193003.B09C83A6884@core3.amsl.com> Date: Sat, 14 Aug 2010 12:30:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-reflect-octets-08.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2010 19:30:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : TWAMP Reflect Octets and Symmetrical Size Features Author(s) : A. Morton, L. Ciavattone Filename : draft-ietf-ippm-twamp-reflect-octets-08.txt Pages : 20 Date : 2010-08-14 This memo describes two closely-related features for the core specification of TWAMP - the Two-Way Active Measurement Protocol: an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-reflect-octets-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-twamp-reflect-octets-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-14122135.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Aug 14 12:30:08 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B7BDD3A6943; Sat, 14 Aug 2010 12:30:06 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100814193007.B7BDD3A6943@core3.amsl.com> Date: Sat, 14 Aug 2010 12:30:06 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-spatial-composition-16.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2010 19:30:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Spatial Composition of Metrics Author(s) : A. Morton, E. Stephan Filename : draft-ietf-ippm-spatial-composition-16.txt Pages : 30 Date : 2010-08-14 This memo utilizes IP Performance Metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-spatial-composition-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-spatial-composition-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-14122202.I-D@ietf.org> --NextPart-- From gln@pura.gm Mon Aug 16 08:42:50 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A4A3A6781 for ; Mon, 16 Aug 2010 08:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 fWeTb0m+wscm for ; Mon, 16 Aug 2010 08:42:50 -0700 (PDT) Received: from serv01.siteground246.com (ns1.siteground246.com [75.125.62.11]) by core3.amsl.com (Postfix) with ESMTP id F056A3A63C9 for ; Mon, 16 Aug 2010 08:42:49 -0700 (PDT) Received: from [212.60.65.174] (port=23215 helo=LAT2006) by serv01.siteground246.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ol1qK-0008CK-9s; Mon, 16 Aug 2010 10:43:24 -0500 From: "Gabriel Latjor Ndow" To: References: In-Reply-To: Date: Mon, 16 Aug 2010 15:43:13 -0000 Message-ID: <001101cb3d59$c0e04ce0$42a0e6a0$@gm> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs8rGqP52rjw+qYRyCQIc7KULh/zgArQAJw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - serv01.siteground246.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - pura.gm Cc: gln@pura.gm, md@gambian.com Subject: Re: [ippm] ippm Digest, Vol 75, Issue 11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 15:42:51 -0000 Please change my e-mail address on this mailing list from gln@pura.gm to: md@gambian.com Thank you kindly, Gabriel Ndow -----Original Message----- From: ippm-request@ietf.org [mailto:ippm-request@ietf.org] Sent: Sunday, August 15, 2010 7:00 PM To: ippm@ietf.org Subject: ippm Digest, Vol 75, Issue 11 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ippm Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send ippm mailing list submissions to ippm@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ippm or, via email, send a message with subject or body 'help' to ippm-request@ietf.org You can reach the person managing the list at ippm-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ippm digest..." Today's Topics: 1. I-D Action:draft-ietf-ippm-twamp-reflect-octets-08.txt (Internet-Drafts@ietf.org) 2. I-D Action:draft-ietf-ippm-spatial-composition-16.txt (Internet-Drafts@ietf.org) ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Aug 2010 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-reflect-octets-08.txt To: i-d-announce@ietf.org Cc: ippm@ietf.org Message-ID: <20100814193003.B09C83A6884@core3.amsl.com> Content-Type: text/plain; charset="us-ascii" ------------------------------ Message: 2 Date: Sat, 14 Aug 2010 12:30:06 -0700 (PDT) From: Internet-Drafts@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-spatial-composition-16.txt To: i-d-announce@ietf.org Cc: ippm@ietf.org Message-ID: <20100814193007.B7BDD3A6943@core3.amsl.com> Content-Type: text/plain; charset="us-ascii" ------------------------------ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm End of ippm Digest, Vol 75, Issue 11 ************************************ From root@core3.amsl.com Tue Aug 17 06:00:01 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CF6773A696D; Tue, 17 Aug 2010 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100817130001.CF6773A696D@core3.amsl.com> Date: Tue, 17 Aug 2010 06:00:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-reflect-octets-09.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : TWAMP Reflect Octets and Symmetrical Size Features Author(s) : A. Morton, L. Ciavattone Filename : draft-ietf-ippm-twamp-reflect-octets-09.txt Pages : 20 Date : 2010-08-17 This memo describes two closely-related features for the core specification of TWAMP - the Two-Way Active Measurement Protocol: an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-reflect-octets-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-twamp-reflect-octets-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-17054837.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Tue Aug 17 06:12:48 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFE83A699C; Tue, 17 Aug 2010 06:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 gCToTjT11MrM; Tue, 17 Aug 2010 06:12:47 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6645A3A6969; Tue, 17 Aug 2010 06:12:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100817131247.13538.11055.idtracker@localhost> Date: Tue, 17 Aug 2010 06:12:47 -0700 Cc: ippm@ietf.org Subject: [ippm] Second Last Call: (Spatial Composition of Metrics) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:12:48 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Spatial Composition of Metrics' as a Proposed Standard This specification has normative references to two Informational RFCs: * "Framework for IP Performance Metrics", RFC 2330 * "Framework for Metric Composition", RFC 5835 These downrefs describe the frameworks for IP performance metrics and their composition, and are therefore required background reading in order to implement this Proposed Standard. Comments on whether these downrefs are appropriate for a standards track publications are requested. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-08-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ippm-spatial-composition/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-spatial-composition/ No IPR declarations were found that appear related to this I-D. From iesg-secretary@ietf.org Tue Aug 17 08:07:06 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E763C3A687B; Tue, 17 Aug 2010 08:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, 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 L7opMZmoNmcg; Tue, 17 Aug 2010 08:07:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726363A6A7A; Tue, 17 Aug 2010 08:07:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100817150704.18028.74789.idtracker@localhost> Date: Tue, 17 Aug 2010 08:07:04 -0700 Cc: Internet Architecture Board , ippm chair , ippm mailing list , RFC Editor Subject: [ippm] Protocol Action: 'TWAMP Reflect Octets and Symmetrical Size Features' to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:07:06 -0000 The IESG has approved the following document: - 'TWAMP Reflect Octets and Symmetrical Size Features' as a Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-reflect-octets/ Technical Summary The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes two closely-related features for TWAMP: an optional capability where the responder host returns some of the command octets or padding octets to the controller, and an optional sender packet format that ensures equal test packet sizes are used in both directions. Working Group Summary The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noticing. Personnel Henk Uijterwaal (henk@ripe.net) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From wwwrun@rfc-editor.org Thu Aug 19 08:12:13 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3C83A6893 for ; Thu, 19 Aug 2010 08:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ESTPl5inRbIS for ; Thu, 19 Aug 2010 08:12:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id B2C673A6888 for ; Thu, 19 Aug 2010 08:12:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E8835E0692; Thu, 19 Aug 2010 08:12:46 -0700 (PDT) To: acmorton@att.com, mchiba@cisco.com, ietfdbh@comcast.net, lars.eggert@nokia.com, henk@ripe.net, matt@internet2.edu From: RFC Errata System Message-Id: <20100819151246.E8835E0692@rfc-editor.org> Date: Thu, 19 Aug 2010 08:12:46 -0700 (PDT) Cc: ah@TR-Sys.de, rfc-editor@rfc-editor.org, ippm@ietf.org Subject: [ippm] [Editorial Errata Reported] RFC5938 (2478) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 15:12:13 -0000 The following errata report has been submitted for RFC5938, "Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5938&eid=2478 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 3.2 and 3.4 Original Text ------------- a) [[ second-to-last para of Section 3.2: ]] The Server MUST respond with one or more Start-N-Ack messages (which SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL | have the format defined in the next session. ^^ b) [[ last para of Section 3.4: ]] The Server MUST respond with one or more Stop-N-Ack messages (which SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL | have the format defined in the next session. ^^ Corrected Text -------------- a) The Server MUST respond with one or more Start-N-Ack messages (which SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL | have the format defined in the next section. ^^ b) The Server MUST respond with one or more Stop-N-Ack messages (which SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL | have the format defined in the next section. ^^ Notes ----- Rationale: potentially confusing typo (iterated)! Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5938 (draft-ietf-ippm-twamp-session-cntrl-07) -------------------------------------- Title : Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) Publication Date : August 2010 Author(s) : A. Morton, M. Chiba Category : PROPOSED STANDARD Source : IP Performance Metrics Area : Transport Stream : IETF Verifying Party : IESG From acmorton@att.com Thu Aug 19 08:33:26 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6001E3A6956 for ; Thu, 19 Aug 2010 08:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.584 X-Spam-Level: X-Spam-Status: No, score=-105.584 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 5Cwzx6mpGXso for ; Thu, 19 Aug 2010 08:33:23 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 8DEA43A69C5 for ; Thu, 19 Aug 2010 08:33:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-161.messagelabs.com!1282232024!12484925!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 20254 invoked from network); 19 Aug 2010 15:33:45 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Aug 2010 15:33:45 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7JFXxXk012050 for ; Thu, 19 Aug 2010 11:34:00 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7JFXtAM011936 for ; Thu, 19 Aug 2010 11:33:55 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o7JFXdXU013595 for ; Thu, 19 Aug 2010 11:33:39 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o7JFXYYs013442 for ; Thu, 19 Aug 2010 11:33:34 -0400 Message-Id: <201008191533.o7JFXYYs013442@alpd052.aldc.att.com> Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100819153332gw100s4pn7e>; Thu, 19 Aug 2010 15:33:33 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Aug 2010 11:33:55 -0400 To: RFC Errata System , mchiba@cisco.com, ietfdbh@comcast.net, lars.eggert@nokia.com, henk@ripe.net, matt@internet2.edu From: Al Morton In-Reply-To: <20100819151246.E8835E0692@rfc-editor.org> References: <20100819151246.E8835E0692@rfc-editor.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ah@TR-Sys.de, rfc-editor@rfc-editor.org, ippm@ietf.org Subject: Re: [ippm] [Editorial Errata Reported] RFC5938 (2478) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 15:33:26 -0000 Alfred is right again, Al At 11:12 AM 8/19/2010, RFC Errata System wrote: >The following errata report has been submitted for RFC5938, >"Individual Session Control Feature for the Two-Way Active >Measurement Protocol (TWAMP)". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=5938&eid=2478 > >-------------------------------------- >Type: Editorial >Reported by: Alfred Hoenes > >Section: 3.2 and 3.4 > >Original Text >------------- >a) [[ second-to-last para of Section 3.2: ]] > > The Server MUST respond with one or more Start-N-Ack messages (which > SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL >| have the format defined in the next session. > ^^ > >b) [[ last para of Section 3.4: ]] > > The Server MUST respond with one or more Stop-N-Ack messages (which > SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL >| have the format defined in the next session. > ^^ > >Corrected Text >-------------- >a) > > The Server MUST respond with one or more Start-N-Ack messages (which > SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL >| have the format defined in the next section. > ^^ > >b) > > The Server MUST respond with one or more Stop-N-Ack messages (which > SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL >| have the format defined in the next section. > ^^ > >Notes >----- >Rationale: potentially confusing typo (iterated)! > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC5938 (draft-ietf-ippm-twamp-session-cntrl-07) >-------------------------------------- >Title : Individual Session Control Feature for the >Two-Way Active Measurement Protocol (TWAMP) >Publication Date : August 2010 >Author(s) : A. Morton, M. Chiba >Category : PROPOSED STANDARD >Source : IP Performance Metrics >Area : Transport >Stream : IETF >Verifying Party : IESG From mchiba@cisco.com Thu Aug 19 09:36:28 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00193A6A4C for ; Thu, 19 Aug 2010 09:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 UDNYQT0Kn+Jq for ; Thu, 19 Aug 2010 09:36:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9F4C63A6A48 for ; Thu, 19 Aug 2010 09:36:24 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE76bEyrRN+J/2dsb2JhbACgUHGIJJpAnAOFNwSEM4grh1Y X-IronPort-AV: E=Sophos;i="4.56,234,1280707200"; d="scan'208";a="242539411" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Aug 2010 16:36:59 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7JGaxY6001355; Thu, 19 Aug 2010 16:36:59 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 09:36:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Aug 2010 09:36:57 -0700 Message-ID: In-Reply-To: <201008191533.o7JFXYlA013447@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Editorial Errata Reported] RFC5938 (2478) Thread-Index: Acs/s+vw603uisgUQh+q07uxNHDq6QAB5Nnw References: <20100819151246.E8835E0692@rfc-editor.org> <201008191533.o7JFXYlA013447@alpd052.aldc.att.com> From: "Murtaza Chiba (mchiba)" To: "Al Morton" , "RFC Errata System" , , , , X-OriginalArrivalTime: 19 Aug 2010 16:36:59.0415 (UTC) FILETIME=[BE96DA70:01CB3FBC] Cc: ah@TR-Sys.de, rfc-editor@rfc-editor.org, ippm@ietf.org Subject: Re: [ippm] [Editorial Errata Reported] RFC5938 (2478) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:36:28 -0000 Agreed, so what is the procedure now? Thanks, -murtaza -----Original Message----- From: Al Morton [mailto:acmorton@att.com]=20 Sent: Thursday, August 19, 2010 8:34 AM To: RFC Errata System; Murtaza Chiba (mchiba); ietfdbh@comcast.net; lars.eggert@nokia.com; henk@ripe.net; matt@internet2.edu Cc: ah@TR-Sys.de; ippm@ietf.org; rfc-editor@rfc-editor.org Subject: Re: [Editorial Errata Reported] RFC5938 (2478) Alfred is right again, Al At 11:12 AM 8/19/2010, RFC Errata System wrote: >The following errata report has been submitted for RFC5938, >"Individual Session Control Feature for the Two-Way Active=20 >Measurement Protocol (TWAMP)". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D5938&eid=3D2478 > >-------------------------------------- >Type: Editorial >Reported by: Alfred Hoenes > >Section: 3.2 and 3.4 > >Original Text >------------- >a) [[ second-to-last para of Section 3.2: ]] > > The Server MUST respond with one or more Start-N-Ack messages (which > SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL >| have the format defined in the next session. > ^^ > >b) [[ last para of Section 3.4: ]] > > The Server MUST respond with one or more Stop-N-Ack messages (which > SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL >| have the format defined in the next session. > ^^ > >Corrected Text >-------------- >a) > > The Server MUST respond with one or more Start-N-Ack messages (which > SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL >| have the format defined in the next section. > ^^ > >b) > > The Server MUST respond with one or more Stop-N-Ack messages (which > SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL >| have the format defined in the next section. > ^^ > >Notes >----- >Rationale: potentially confusing typo (iterated)! > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC5938 (draft-ietf-ippm-twamp-session-cntrl-07) >-------------------------------------- >Title : Individual Session Control Feature for the=20 >Two-Way Active Measurement Protocol (TWAMP) >Publication Date : August 2010 >Author(s) : A. Morton, M. Chiba >Category : PROPOSED STANDARD >Source : IP Performance Metrics >Area : Transport >Stream : IETF >Verifying Party : IESG From acmorton@att.com Thu Aug 19 10:41:19 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236333A65A6 for ; Thu, 19 Aug 2010 10:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.592 X-Spam-Level: X-Spam-Status: No, score=-105.592 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 nbWXYScMp-rO for ; Thu, 19 Aug 2010 10:41:18 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id F341C3A67FD for ; Thu, 19 Aug 2010 10:41:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1282239705!22545091!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 25931 invoked from network); 19 Aug 2010 17:41:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Aug 2010 17:41:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7JHfG2q017201 for ; Thu, 19 Aug 2010 13:41:16 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7JHf9qw017046 for ; Thu, 19 Aug 2010 13:41:09 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o7JHfbgp022524 for ; Thu, 19 Aug 2010 12:41:38 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o7JHfX0N022367 for ; Thu, 19 Aug 2010 12:41:33 -0500 Message-Id: <201008191741.o7JHfX0N022367@klpd017.kcdc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100819174132gw100s4po2e>; Thu, 19 Aug 2010 17:41:32 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Aug 2010 13:41:54 -0400 To: "Murtaza Chiba (mchiba)" , "RFC Errata System" , , , , From: Al Morton In-Reply-To: References: <20100819151246.E8835E0692@rfc-editor.org> <201008191533.o7JFXYlA013447@alpd052.aldc.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ah@TR-Sys.de, rfc-editor@rfc-editor.org, ippm@ietf.org Subject: Re: [ippm] [Editorial Errata Reported] RFC5938 (2478) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:41:19 -0000 IIRC, there needs to be approval at some level higher than "Author", then the Errata is posted. At 12:36 PM 8/19/2010, Murtaza Chiba (mchiba) wrote: >Agreed, so what is the procedure now? > >Thanks, >-murtaza > >-----Original Message----- >From: Al Morton [mailto:acmorton@att.com] >Sent: Thursday, August 19, 2010 8:34 AM >To: RFC Errata System; Murtaza Chiba (mchiba); ietfdbh@comcast.net; >lars.eggert@nokia.com; henk@ripe.net; matt@internet2.edu >Cc: ah@TR-Sys.de; ippm@ietf.org; rfc-editor@rfc-editor.org >Subject: Re: [Editorial Errata Reported] RFC5938 (2478) > >Alfred is right again, >Al ... From A.Hoenes@TR-Sys.de Thu Aug 19 12:38:04 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D9D3A6A3C for ; Thu, 19 Aug 2010 12:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.149 X-Spam-Level: X-Spam-Status: No, score=-97.149 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 NLP4XQNYmnan for ; Thu, 19 Aug 2010 12:38:02 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 5ACBF3A6A06 for ; Thu, 19 Aug 2010 12:37:44 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA259666495; Thu, 19 Aug 2010 21:34:55 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA24263; Thu, 19 Aug 2010 21:34:52 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201008191934.VAA24263@TR-Sys.de> To: acmorton@att.com Date: Thu, 19 Aug 2010 21:34:51 +0200 (MESZ) In-Reply-To: <201008191741.o7JHfXI4022368@klpd017.kcdc.att.com> from Al Morton at Aug "19, " 2010 "01:41:54" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 19 Aug 2010 13:01:05 -0700 Cc: ippm@ietf.org, henk@ripe.net, matt@internet2.edu, ietfdbh@comcast.net, rfc-editor@rfc-editor.org Subject: Re: [ippm] [Editorial Errata Reported] RFC5938 (2478) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:38:04 -0000 > IIRC, there needs to be approval at some level > higher than "Author", then the Errata is posted. > > At 12:36 PM 8/19/2010, Murtaza Chiba (mchiba) wrote: >> Agreed, so what is the procedure now? >> >> Thanks, >> -murtaza Based on the judgement of the authors, the WG (if necessary), and his own, the responsible AD will have to make the decision on whether the EID shold change status to "Verified" or "Rejected" or "Keep for Update", and enter it into the RFC Errata system; he is the IESG "verifier" for such and has write aceess to the Errata system. The outcome (status change) will be announced by another auto-generated email to the same distribution list. That's it. Plese feel free to follow the links at the bottom of the Errata portal page at , below the headline "More Information", if you are interested in details. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From lars.eggert@nokia.com Fri Aug 20 00:29:33 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF313A69D6 for ; Fri, 20 Aug 2010 00:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.103 X-Spam-Level: X-Spam-Status: No, score=-104.103 tagged_above=-999 required=5 tests=[AWL=-1.504, BAYES_00=-2.599, 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 6wXKemC1nemu for ; Fri, 20 Aug 2010 00:29:32 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 0E6973A67A4 for ; Fri, 20 Aug 2010 00:29:31 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7K7Q5IZ023789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 10:26:05 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-9--960497037; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201008191533.o7JFXYxD013449@alpd052.aldc.att.com> Date: Fri, 20 Aug 2010 10:29:40 +0300 Message-Id: References: <20100819151246.E8835E0692@rfc-editor.org> <201008191533.o7JFXYxD013449@alpd052.aldc.att.com> To: Al Morton X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Cc: "ah@TR-Sys.de" , "ippm@ietf.org" , "henk@ripe.net" , "matt@internet2.edu" , "ietfdbh@comcast.net" , RFC Errata System Subject: Re: [ippm] [Editorial Errata Reported] RFC5938 (2478) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 07:29:33 -0000 --Apple-Mail-9--960497037 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks for reviewing! I marked the errata as verified. On 2010-8-19, at 18:33, Al Morton wrote: > Alfred is right again, > Al > > At 11:12 AM 8/19/2010, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5938, >> "Individual Session Control Feature for the Two-Way Active >> Measurement Protocol (TWAMP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5938&eid=2478 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Alfred Hoenes >> >> Section: 3.2 and 3.4 >> >> Original Text >> ------------- >> a) [[ second-to-last para of Section 3.2: ]] >> >> The Server MUST respond with one or more Start-N-Ack messages (which >> SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL >> | have the format defined in the next session. >> ^^ >> >> b) [[ last para of Section 3.4: ]] >> >> The Server MUST respond with one or more Stop-N-Ack messages (which >> SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL >> | have the format defined in the next session. >> ^^ >> >> Corrected Text >> -------------- >> a) >> >> The Server MUST respond with one or more Start-N-Ack messages (which >> SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL >> | have the format defined in the next section. >> ^^ >> >> b) >> >> The Server MUST respond with one or more Stop-N-Ack messages (which >> SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL >> | have the format defined in the next section. >> ^^ >> >> Notes >> ----- >> Rationale: potentially confusing typo (iterated)! >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5938 (draft-ietf-ippm-twamp-session-cntrl-07) >> -------------------------------------- >> Title : Individual Session Control Feature for the >> Two-Way Active Measurement Protocol (TWAMP) >> Publication Date : August 2010 >> Author(s) : A. Morton, M. Chiba >> Category : PROPOSED STANDARD >> Source : IP Performance Metrics >> Area : Transport >> Stream : IETF >> Verifying Party : IESG > --Apple-Mail-9--960497037 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyMDA3 Mjk0MVowIwYJKoZIhvcNAQkEMRYEFI8dzRcPy4QIwjLTy8QSTJaavQ+TMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAJhd5Q29JDlHc/pxeSuh4NGs2XmmbLGYbQvXcarn08ubgXrSnCSg r3EnVQloJsy0Wf3fs5QE7fwUcD3/MVu+eZzU7ttzmxXnXe/AhvYwUwt0rLJQLLMeaeYvM/1WFbol b1tNK8y950iGsCUnCFMHeAmEJba/+Pae67u7UuEJORn8cTKzVIKlmpa7/PMEbAjflC/xKvuY0AGp tzlQi4GPpSU0TN5KCZk5udYEmec6kiO1hcYWjVeO2tey8ONZpnAEZg4sQRcfEiD8RJei670NzyTG gt5zvwr3eJcpudN2TkbsIh2UhllvBV7Km+LM/TG1hXYEhDDMC8RxVLk/n+5rcawAAAAAAAA= --Apple-Mail-9--960497037-- From Barry.Constantine@jdsu.com Fri Aug 20 05:23:39 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C05D3A68F0 for ; Fri, 20 Aug 2010 05:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.94 X-Spam-Level: X-Spam-Status: No, score=-4.94 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] 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 P1I8sT0grZT1 for ; Fri, 20 Aug 2010 05:23:38 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with SMTP id D9D843A681F for ; Fri, 20 Aug 2010 05:23:37 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTG5z6qebx8xj6Jrgnmy5WXEDl7TmMGK4@postini.com; Fri, 20 Aug 2010 05:24:12 PDT Received: from milexhtca1.ds.jdsu.net ([10.75.2.121]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 05:23:52 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca1.ds.jdsu.net ([::1]) with mapi; Fri, 20 Aug 2010 05:23:50 -0700 From: Barry Constantine To: "Ruediger.Geib@telekom.de" Date: Fri, 20 Aug 2010 05:23:48 -0700 Thread-Topic: draft-ietf-ippm-tcp-throughput-tm Thread-Index: AcscHOZrlhSrDhVEQHO03e5yr0wCogeqt8oQAAOg4kA= Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B9C7805A@MILEXCH1.ds.jdsu.net> References: <4C31990B.6030104@ripe.net> <151C164FE2E066418D8D44D0801543A5047ABFA2@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <151C164FE2E066418D8D44D0801543A5047ABFA2@S4DE8PSAAQA.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Aug 2010 12:23:52.0328 (UTC) FILETIME=[8CCB0880:01CB4062] Cc: "ippm@ietf.org" Subject: Re: [ippm] draft-ietf-ippm-tcp-throughput-tm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 12:23:39 -0000 Hello Reudiger, Thank you for reviewing the draft again. This is a good point and item for= clarification. The draft was born with the primary intention of being conducted by network= providers as another level of turn-up testing prior to end business custom= er hand-off. Also this test could be used as a troubleshooting mechanism b= y the provider when the end-customer issues complaints concerning performan= ce. I have personally seen manual TCP testing conducted by network providers fo= r both reasons listed above. The manual nature of these tests and the netw= ork provider technician's inexperience with TCP testing, often leads to var= iable and non-conclusive results. Enterprise customers are using tools such as "Iperf", "ttcp", etc. and are = running throughput tests to verify the SLA that they purchased from the pro= vider. The enterprise customer challenges the provider's SLA and in most c= ases, the provider can only defend the SLA with Layer 2/3 test data. I believe the majority of use cases will be over Ethernet / IP managed netw= orks and not leased line interface but this will vary. When I have been in= volved in these sort of tests (either Layer 2/3 packet stress tests or TCP)= , the network provider coordinates these tests either before the service is= activated or during "off" hours with the end-customer. And of course, the= se tests are controlled to be within the SLA purchased by the end customer.= =20 Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Sent: Friday, August 13, 2010 5:42 AM To: Barry Constantine Cc: ippm@ietf.org Subject: draft-ietf-ippm-tcp-throughput-tm Barry, the aspect was mentioned during the Maastricht meeting and by this mail it = goes to the list too: Is tcp-throughput-tm designed to be performed on dedidcated infrastructure = (like a leased line infrastructure) only, or is it designed to operate on s= hared infrastructure (like VRF based L2 or L3 VPNs)? This should be stated = explicitely in the text. If tcp-throughput-tm is designed for shared infrastructure, any test incurr= ing load to a level that congestion in a providers network is a likely outc= ome should be coordinated with that provider (or not be performed at all). = IETF likes to avoid numbering performance, but my personal take is if a cus= tomer interface can transmit a load of more than 10% of a single provider e= dge network internal interface bandwidth, the provider may like to be infor= med about these load tests. As far as I understand, most business customers= hardly congest their own interfaces, meaning that loads of a level of more= than 90% of such an interface shouldn't occur. Further, standard traffic h= as an address entropy enabling load sharing within the providers network. W= e have experience with a special customer whose traffic didn't meet the abo= ve provider expectations while being of high bandwidth. We agreed that the = customer informs the NOC when planing to create traffic with the unusual pa= tterns mentioned above. I think that a company requesting a tcp-throughput-tm from someone may be a= nnoyed if the NOC of the povider gives the companie's network admin a call = inquiring what's going on there even before service started. Should the intention of the draft however be to induce congestion in a prov= ider network, please add a clear statement expressing that. Regards, Ruediger From Ruediger.Geib@telekom.de Mon Aug 23 00:29:24 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D133A67CC for ; Mon, 23 Aug 2010 00:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 Ri3G5+loeEdr for ; Mon, 23 Aug 2010 00:29:22 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 3A2F33A6820 for ; Mon, 23 Aug 2010 00:29:21 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 23 Aug 2010 09:29:49 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 09:29:50 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 23 Aug 2010 09:29:49 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5048BC446@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38B9C7805A@MILEXCH1.ds.jdsu.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ippm-tcp-throughput-tm thread-index: AcscHOZrlhSrDhVEQHO03e5yr0wCogeqt8oQAAOg4kAB7wKosA== References: <4C31990B.6030104@ripe.net> <151C164FE2E066418D8D44D0801543A5047ABFA2@S4DE8PSAAQA.mitte.t-com.de> <94DEE80C63F7D34F9DC9FE69E39436BE38B9C7805A@MILEXCH1.ds.jdsu.net> From: To: X-OriginalArrivalTime: 23 Aug 2010 07:29:50.0467 (UTC) FILETIME=[F8A9ED30:01CB4294] Cc: ippm@ietf.org Subject: Re: [ippm] draft-ietf-ippm-tcp-throughput-tm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 07:29:24 -0000 Hello Barry,=20 > Thank you for reviewing the draft again. This is a good=20 > point and item for clarification. > The draft was born with the primary intention of being=20 > conducted by network providers as another level of turn-up=20 > testing prior to end business customer hand-off. Also this=20 > test could be used as a troubleshooting mechanism by the=20 > provider when the end-customer issues complaints concerning=20 > performance. That's useful. The concern I expressed is about provider=20 external testing on high speed interfaces only. I've heard of boxes promising to measure Y.1731 performance to=20 compliance with SLAs. If I got that right, a vendor suggested=20 to fill any spare capacity by dummy traffic just to make=20 sure the contractually agreed throughput is available all=20 the time. While that is within SLA and to some extent technically feasible,=20 it is not desireable. That's why I'd like to have some hints at=20 the right place in the TCP TM draft helping to avoid not really=20 useful scenarios. [snip] Regards, Ruediger -----Original Message----- From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Sent: Friday, August 13, 2010 5:42 AM To: Barry Constantine Cc: ippm@ietf.org Subject: draft-ietf-ippm-tcp-throughput-tm Barry, the aspect was mentioned during the Maastricht meeting and by this mail = it goes to the list too: Is tcp-throughput-tm designed to be performed on dedidcated = infrastructure (like a leased line infrastructure) only, or is it = designed to operate on shared infrastructure (like VRF based L2 or L3 = VPNs)? This should be stated explicitely in the text. If tcp-throughput-tm is designed for shared infrastructure, any test = incurring load to a level that congestion in a providers network is a = likely outcome should be coordinated with that provider (or not be = performed at all). IETF likes to avoid numbering performance, but my = personal take is if a customer interface can transmit a load of more = than 10% of a single provider edge network internal interface bandwidth, = the provider may like to be informed about these load tests. As far as I = understand, most business customers hardly congest their own interfaces, = meaning that loads of a level of more than 90% of such an interface = shouldn't occur. Further, standard traffic has an address entropy = enabling load sharing within the providers network. We have experience = with a special customer whose traffic didn't meet the above provider = expectations while being of high bandwidth. We agreed that the customer = informs the NOC when planing to create traffic with the unusual patterns = mentioned above. I think that a company requesting a tcp-throughput-tm from someone may = be annoyed if the NOC of the povider gives the companie's network admin = a call inquiring what's going on there even before service started. Should the intention of the draft however be to induce congestion in a = provider network, please add a clear statement expressing that. Regards, Ruediger From henk@ripe.net Tue Aug 24 04:40:05 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573603A683A; Tue, 24 Aug 2010 04:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, 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 VQwkqc4JbJgF; Tue, 24 Aug 2010 04:40:03 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 485673A6809; Tue, 24 Aug 2010 04:40:03 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Onrrh-00024P-Fh; Tue, 24 Aug 2010 13:40:35 +0200 Received: from [193.0.21.124] (helo=geir.lan) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Onrrh-00026X-4e; Tue, 24 Aug 2010 13:40:29 +0200 Message-ID: <4C73AFAC.3050506@ripe.net> Date: Tue, 24 Aug 2010 13:40:28 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: The IESG References: <20100817131247.13538.11055.idtracker@localhost> In-Reply-To: <20100817131247.13538.11055.idtracker@localhost> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d53ba37ef5d4288bb36b092e407bf9551c X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d53ba37ef5d4288bb36b092e407bf9551c Cc: IETF-Announce , ippm@ietf.org Subject: Re: [ippm] Second Last Call: (Spatial Composition of Metrics) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 11:40:05 -0000 On 17/08/2010 15:12, The IESG wrote: > > The IESG has received a request from the IP Performance Metrics WG (ippm) > to consider the following document: > - 'Spatial Composition of Metrics' > as a Proposed Standard > > This specification has normative references to two Informational RFCs: > > * "Framework for IP Performance Metrics", RFC 2330 > * "Framework for Metric Composition", RFC 5835 > > These downrefs describe the frameworks for IP performance metrics and > their composition, and are therefore required background reading in order to > implement this Proposed Standard. Comments on whether these downrefs > are appropriate for a standards track publications are requested. Yes, I think it is appropriate. We wrote the framework documents to provide a common framework for IPPM metrics and to avoid that each document describing a metric has to repeat everything that is said in the framework documents. However, at the time of publication of 2330 and 5835, framework documents were classified as informational. Thus, the downref cannot be avoided. On a more general note: I think this situation will occur in every case where there is a framework document plus standards built on the framework, so a more general solution might be in order. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Tue Aug 24 05:24:50 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B9B3A6876; Tue, 24 Aug 2010 05:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.601 X-Spam-Level: X-Spam-Status: No, score=-105.601 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 7adcBT-ZpvsU; Tue, 24 Aug 2010 05:24:49 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 435C03A67C0; Tue, 24 Aug 2010 05:24:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-167.messagelabs.com!1282652720!18105579!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 25309 invoked from network); 24 Aug 2010 12:25:21 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Aug 2010 12:25:21 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7OCPatW014028; Tue, 24 Aug 2010 08:25:36 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7OCPXYc014004; Tue, 24 Aug 2010 08:25:33 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o7OCPHEb031288; Tue, 24 Aug 2010 08:25:17 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o7OCPDTD031225; Tue, 24 Aug 2010 08:25:13 -0400 Message-Id: <201008241225.o7OCPDTD031225@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100824122513gw100s4p3ee>; Tue, 24 Aug 2010 12:25:13 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Aug 2010 08:25:34 -0400 To: Henk Uijterwaal , The IESG From: Al Morton In-Reply-To: <4C73AFAC.3050506@ripe.net> References: <20100817131247.13538.11055.idtracker@localhost> <4C73AFAC.3050506@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ippm@ietf.org Subject: Re: [ippm] Second Last Call: (Spatial Composition of Metrics) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 12:24:50 -0000 At 07:40 AM 8/24/2010, Henk Uijterwaal wrote: >...On a more general note: I think this situation will occur in every >case where there is a framework document plus standards built on >the framework, so a more general solution might be in order. I agree, and observed the same in my exchange with Dan. "Framework" Status, or a Reference track is now needed (and wasn't needed in the past when there was a single reference section and no Down-Refs). Al From Ruediger.Geib@telekom.de Tue Aug 24 23:45:55 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924333A67F7 for ; Tue, 24 Aug 2010 23:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 4WutABE+BCuV for ; Tue, 24 Aug 2010 23:45:54 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 54E883A6407 for ; Tue, 24 Aug 2010 23:45:54 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 25 Aug 2010 08:46:20 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 08:46:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Aug 2010 08:46:16 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A50490E31E@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <4C516B9A.1080502@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WG interest in Multicast performance monitoring drafts thread-index: AcsvFKZffATBuM9qTeO/Nu7VmeY58wVCv7cA References: <9FCB2ACF14591E4DAF4180D4010E3618A777ECCD07@GRFMBX702BA020.griffon.local><9FCB2ACF14591E4DAF4180D4010E3618A7786D7685@GRFMBX702BA020.griffon.local><4C4FF248.1020109@ripe.net> <4C516B9A.1080502@ripe.net> From: To: , X-OriginalArrivalTime: 25 Aug 2010 06:46:19.0765 (UTC) FILETIME=[3963EA50:01CB4421] Cc: matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] WG interest in Multicast performance monitoring drafts X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 06:45:55 -0000 Henk,=20 I just had a look at > > = http://tools.ietf.org/html/draft-liu-mboned-multicast-realstream-monitor-= 02 The draft proposes to apply Y.1731 methodology to monitor multicast = groups. While the loss measurement is active/passive, the delay = measurement is clearly active. I'd suggest the authors to read RFC5644. = I didn't compare details but would expect the following: - differences in packet loss measurement between draft-liu and RFC5644. - no serious difference in delay measurement methodology between = draft-liu=20 and RFC5644 (meaning that the draft-liu delay measurement method is=20 identical with or a subset of RFC5644).=20 Regards Ruediger From henk@ripe.net Wed Aug 25 02:25:52 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0393A685E for ; Wed, 25 Aug 2010 02:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.929 X-Spam-Level: X-Spam-Status: No, score=-102.929 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, 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 vAJ7NSe82vMf for ; Wed, 25 Aug 2010 02:25:51 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id ABB6B3A681D for ; Wed, 25 Aug 2010 02:25:50 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OoCFM-0001kL-Sb for ippm@ietf.org; Wed, 25 Aug 2010 11:26:23 +0200 Received: from [193.0.21.124] (helo=guest-113.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OoCFL-0003F9-1Z for ippm@ietf.org; Wed, 25 Aug 2010 11:26:16 +0200 Message-ID: <4C74E1B6.8020501@ripe.net> Date: Wed, 25 Aug 2010 11:26:14 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: ippm@ietf.org References: <32270797.944947.1281537096896.JavaMail.root@vms073.mailsrvcs.net> <201008111440.o7BEecTh012668@alpd052.aldc.att.com> In-Reply-To: <201008111440.o7BEecTh012668@alpd052.aldc.att.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d59ffc8d4a08806380a7879d8f5357d4b1 X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d59ffc8d4a08806380a7879d8f5357d4b1 Subject: Re: [ippm] Question/comment on RFC5136 (Process) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 09:25:52 -0000 All, Catching up after 3 weeks of vacation... >> That's fine with me. Who would determine direction on this? Henk and Matt? > > Ultimately, I think an Errata makes sense here whether there's > a new draft or not. If I understand the discussion correctly, then I think a note to clarify this is in order. > IIRC, the Errata must be approved by some combination > of authors and chairs, but anyone can submit Errata using the on-line > system. That would get the process rolling. That is correct. I suggest that the original poster (i.e. Xiangsong) submits the errate. The authors and chairs can verify this. If the issue can be explained as in section 3 of the draft from Xiangsong, then I don't think that a new RFC is needed. If not, the WG can pick up the draft as a work item, with the goal of replacing 5136. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From henk@ripe.net Wed Aug 25 02:31:42 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2303A696E for ; Wed, 25 Aug 2010 02:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, 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 Qknr0k4O8nlO for ; Wed, 25 Aug 2010 02:31:33 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 17D513A681D for ; Wed, 25 Aug 2010 02:31:29 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OoCKo-0000vh-7i for ippm@ietf.org; Wed, 25 Aug 2010 11:32:00 +0200 Received: from [193.0.21.124] (helo=guest-113.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OoCKn-0003YL-AH for ippm@ietf.org; Wed, 25 Aug 2010 11:31:53 +0200 Message-ID: <4C74E309.50909@ripe.net> Date: Wed, 25 Aug 2010 11:31:53 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: ippm@ietf.org References: <1951144877.1668412.1281449182600.JavaMail.root@vms170003.mailsrvcs.net> <008501cb38f5$71a5b7e0$80106f0a@china.huawei.com> <014a01cb392e$4170c720$80106f0a@china.huawei.com> In-Reply-To: <014a01cb392e$4170c720$80106f0a@china.huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5f0ac2c55cf86faa514f83ae25b26f6dc X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5f0ac2c55cf86faa514f83ae25b26f6dc Subject: Re: [ippm] Question/comment on RFC5136 (Content) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 09:31:43 -0000 Hi all, Speaking as a reader of the draft > 3. Discussion [...] > RFC5136 specifies IP-type-P Path Capacity as > > C(P,T,I) = min {1..n} {C(Ln,T,I)}, > > which need more discussion. This document suggests that > the router capacity should be considered in IP-type-P Path > Capacity. The proposed formula is: > > C(P,T,I) = min (C-router, C-link) > C-router = min {2..n} {C(Nn,T,I)} > C-link = min {1..n} {C(Ln,T,I)} I don't quite understand C-router. In the most extreme case (2 computers connected by a piece of wire), there is no router and the Path Capacity is: C(P,T,I) = C(L1, T, I) In the old formula, or in other words, the capacity of the the cable. In the new one, this would become: C(P,T,I) = min (C-router, C-link) C-router = min {0..0} {C(Nn,T,I)} C-link = min {1..1} {C(Ln,T,I)} = C(L0,T,I). And more general: C(P,T,I) = min (C-router, C-link) C-router = min {0..n} {C(Nn,T,I)} C-link = min {1..n} {C(Ln,T,I)} Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From vze275m9@verizon.net Wed Aug 25 17:31:40 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF1B3A68CC for ; Wed, 25 Aug 2010 17:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6] 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 0+2+8DQRqsiw for ; Wed, 25 Aug 2010 17:31:39 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id E96333A689B for ; Wed, 25 Aug 2010 17:31:38 -0700 (PDT) Received: from [10.0.1.3] ([unknown] [151.200.124.171]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L7Q00FCXHGRK414@vms173003.mailsrvcs.net> for ippm@ietf.org; Wed, 25 Aug 2010 19:31:55 -0500 (CDT) MIME-version: 1.0 (Apple Message framework v1081) Content-type: text/plain; charset=us-ascii From: Philip Chimento X-Priority: 3 In-reply-to: <000901cb3a86$488efc30$80106f0a@china.huawei.com> Date: Wed, 25 Aug 2010 20:31:35 -0400 Content-transfer-encoding: quoted-printable Message-id: References: <00a701cb3777$2cc70ef0$80106f0a@china.huawei.com> <20100812173013.GA29879@firebird1.grc.nasa.gov> <000901cb3a86$488efc30$80106f0a@china.huawei.com> To: Xiangsong Cui X-Mailer: Apple Mail (2.1081) Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Philip Chimento List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 00:31:40 -0000 XIangsong:=20 I have been busy and have not been able to respond quickly over the past = week or so.=20 The origin of RFC 5136 was to try to make precise what was being and = should be measured by the many tools that attempt to determine the = "bandwidth" of a source-to-destination path at a given time. We spoke at = the time of having another informational RFC discussing the current = state of "bandwidth" measurement tools, but it was decided not to pursue = it. This RFC was not intended to be an element-by-element model of the = network. The whole point was to capture what was meant by "bandwidth". I disagree with your statement that C(L,T,I) is node independent (in the = context of this RFC). Take the instance of, say, a firewall, in the path = between two routers. Suppose that the firewall is only capable of a = throughput of 10 Mb/s but is connected to the routers by 100 Mb/s = Ethernet links. We can say that the IP Type P Capacity is 10 Mb/s for = the "link" (which is really a path) between the two routers. You could = include the firewall if you wanted to, in which case the IP Type P = Capacity would be 10 Mb/s for both links, but there wouldn't really be = any point.=20 Going on to your third example below:=20 - Phase 1: You are right, in this case, the IP Type P Capacity reaches = the Nominal Link Capacity of both Link 1 and Link 2. The IP Type P = Capacity of links 3 and 4 is 0. If the IP Type P Capacity is 0, then the = utilization also has to be 0. I believe that this is consistent with = normal engineering usage.=20 - Phase 2: You postulate that the router is able to share its backplane = capacity fairly. Then if the router is designed so that it shares = exactly fairly among all active links, then the IP Type P Capacity of = links 1,2,3 and 4 is 500 Mb/s, because that is the highest rate at which = bits can be (correctly) delivered. Suppose that nodes B and D transmit = in the reverse direction (to A and C, respectively) and that the = backplane capacity of the router is 1 Gb/s total (both directions). Then = the IP Type P Capacity is only 250 Mb/s for links 1,2,3,4.=20 - Phase 3: This is exactly the same as Phase 1, just exchanging link and = node labels.=20 The reason that things are defined this way is that this is what you = would see if you were to probe this network with a "bandwidth" = measurement tool.=20 A router with more links and a given backplane design could give you = more quirky behavior depending on internal congestion patterns or hot = spots in the switching fabric. For the purposes of the RFC, it doesn't = matter whether a node's design, or fast fading of a wireless link is = limiting the capacity, it only matters that the capacity is limited. = That is why we do not separate links and nodes as separate entities. = Given real node behavior, you can't assign a single node capacity = (especially to routers and switches) because it depends on the design of = the node and what other traffic is present at a given time.=20 At this point, my opinion is that we do not need a new draft or RFC; I = would be happy to add the above explanations (or some variant) as a = correction/update to the RFC, but I defer to Henk, Matt and the opinion = of the workgroup. =20 =20 Regards,=20 Phil Chimento=20 pfc@ieee.org On Aug 12, 2010, at 9:24 PM, Xiangsong Cui wrote: > Hi Joseph, >=20 > Thanks for your response! >=20 > We come to link capacity again, I showed my option on this problem in = the link: > http://www.ietf.org/mail-archive/web/ippm/current/msg02417.html >=20 > As to link and link capacity, I want to make sure: >=20 > Is IP node is a part or a IP link? I guess not, because link is the = layer2-level connection, it is the media, the facility, the layer2 = protocol..., but does Not cover nodes, which is a layer3 concept. >=20 > So C(L,T,I) is node-independent, right? >=20 >=20 > If you insisit link capacity is node-dependent, I give my third = example here. >=20 > In the following scenario, where link1/link2/link3/link4 physical = capacity is 1.x G bps, they all use the same link protocol, and we = assume their "physical IP capacity" is 1G bps. Same way, the router IP = capacity is 1G bps. >=20 > host A------link1-------- ----------link2------ host B > \ / > Router > / \ > host C------link3-------- ----------link4------ host D >=20 >=20 > Phase 1, only host A transmit packets (IP-type-P) to host B, other = hosts don't transimit any packet. > Base on RFC5136, the IP capacity of link1 and link2 is 1G bps for the = certain time/period, the link usage is same. IP capacity of link3 and = link4 is 0 bps and link usage is also same (althouth their physical IP = capacity is 1G bps). As to IP-type-P Link Utilization, base on the = definition of RFC5136, Util(L,T,I) =3D ( Used(L,T,I) / C(L,T,I) ), so we = can get: IP-type-P Link Utilization of link1 is 100% (1G bps/1G bps), = this looks right, but how about link3 and link4? the IP-type-P Link = Utilization of link3 is 0/0, what does this mean? (in my mind, when a = link is idle, the link utilization is 0, but not 0/0) >=20 > Well, phase 2, host C begin to transmit packets (IP-type-P) to host D = (others keep unchanged, same networks, same nodes, same links....), also = at the rate 1G bps. > Unfortunately, router over-loads, but it still works fairly. so = link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is the = metric? Base on RFC5136, the IP capacity of link1 and link2 is 500M bps = for the certain time/period, the link usage is same. IP capacity of = link3 and link4 is 500M bps for the certain time/period and link usage = is also same. As to IP-type-P Link Utilization, base on the definition = of RFC5136, Util(L,T,I) =3D ( Used(L,T,I) / C(L,T,I) ), so we can get: = IP-type-P Link Utilization of link1 is 100% (500M bps/500M bps), this = looks very strange, Link Utilization is unchaged, really? How about = link3 and link4? the IP-type-P Link Utilization of link3 is 100% (500M / = 500M)? >=20 > Now, it is phase 3, host A stop transmitting packets, host C still = transmitting as before. > Base on RFC5136, the IP capacity of link1 and link2 is 0 G bps, the = link usage is same. IP capacity of link3 and link4 is 1G bps and link = usage is also same. > How to calculate C(L,T,I) and Util(L,T,I) now? >=20 > All of these, are more and more = confusing..................................... >=20 > Regards > Xiangsong >=20 >=20 > ----- Original Message ----- From: "Joseph Ishac" > To: "Xiangsong Cui" > Cc: > Sent: Friday, August 13, 2010 1:30 AM > Subject: Re: [ippm] Question/comment on RFC5136 >=20 >=20 >> Just getting back from vacation so I'm slowly catching up here. I've >> not parsed the whole thread, but have some thoughts on the initial >> question and will throw that out here as I catch up. >>=20 >>> For example, in the path between node A and B as follows, >>>=20 >>> A------link1------Router------link2------B >>>=20 >>> For some certain packet/traffic, if the capacity of link1 is 5G bps >>> and the capacity of link2 is 3G bps, while the capacity of the = router >>> is 2G bps, how much is the capacity of the path between A and B? I >>> believe the capacity is 2G bps (the neckbottle is the >>> middle-box), but not 3G bps (as definition of RFC5136). >>=20 >> Well, the RFC calls out a couple of things. The 5 Gbit/s and 3 = Gbit/s >> links would be "Nominal Physical Link Capacity" such that: >>=20 >> NomCap(link1) =3D 5 Gbit/s >> NomCap(link2) =3D 3 Gbit/s >>=20 >> Now, the "IP-type-P Link Capacity" is what can be transmitted on a = link >> by link basis. So if A has no problem saturating the router then for >> some given time, T, and interval, I: >>=20 >> C(link1,T,I) ~=3D 5 Gbit/s >> C(link2,T,I) ~=3D 2 Gbit/s >>=20 >> The reason being that the Capacity at link 2 is driven by the ability = to >> transmit IP data from "Router" to "B". If "Router" has a limitation >> here it impacts this value. >>=20 >>> I think this should be updated, as >>>=20 >>> C(P,T,I) =3D min ( X, Y) >>> X =3D min {2..n} {C(Nn,T,I)} >>> Y =3D min {1..n} {C(Ln,T,I)} >>=20 >> The way I read the above is that value for Y is essentially the limit = of >> "Nominal Physical Link Capacity". The value of X is attempting to >> factor in only *one* possible limiting factor to that, particularly a >> node's forwarding and processing ability. >>=20 >> Our original definition of C aims to capture the many factors that = can >> inhibit the ability to reach the "Nominal Physical Link Capacity" and = as >> such I believe is intended to be more robust than the case outlined >> above. >>=20 >> I will note that in practice, measuring all of this is VERY hard (and = we >> note this in the draft). However this document is not itself = intended to >> be a measuring technique, but instead, a conceptual analysis of what >> should be counted. >>=20 >> -Joseph=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Wed Aug 25 18:32:54 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7903A68D0 for ; Wed, 25 Aug 2010 18:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.215 X-Spam-Level: X-Spam-Status: No, score=0.215 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1] 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 UlxFdawghHCM for ; Wed, 25 Aug 2010 18:32:48 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id D07663A6A94 for ; Wed, 25 Aug 2010 18:32:39 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7Q00277KAV43@szxga01-in.huawei.com> for ippm@ietf.org; Thu, 26 Aug 2010 09:32:56 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7Q000CTKAVFM@szxga01-in.huawei.com> for ippm@ietf.org; Thu, 26 Aug 2010 09:32:55 +0800 (CST) Date: Thu, 26 Aug 2010 09:32:54 +0800 From: Xiangsong Cui In-reply-to: To: 'Philip Chimento' Message-id: <003001cb44be$9b6dcb10$d2496130$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: ActEticL6+5gOxdIS12pECvALzBEMQAAtZiQ References: <00a701cb3777$2cc70ef0$80106f0a@china.huawei.com> <20100812173013.GA29879@firebird1.grc.nasa.gov> <000901cb3a86$488efc30$80106f0a@china.huawei.com> Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 01:32:54 -0000 Hi Phil, I believe our discussion becomes more and more focused, please see my comments inline. > -----Original Message----- > From: Philip Chimento [mailto:vze275m9@verizon.net] > Sent: Thursday, August 26, 2010 8:32 AM > To: Xiangsong Cui > Cc: Joseph Ishac; ippm@ietf.org > Subject: Re: [ippm] Question/comment on RFC5136 > > XIangsong: > I have been busy and have not been able to respond quickly over the past week > or so. > > The origin of RFC 5136 was to try to make precise what was being and should > be measured by the many tools that attempt to determine the "bandwidth" of > a source-to-destination path at a given time. Agree, we did talk about source-to-destination path. We spoke at the time of having > another informational RFC discussing the current state of "bandwidth" > measurement tools, but it was decided not to pursue it. This RFC was not > intended to be an element-by-element model of the network. The whole point > was to capture what was meant by "bandwidth". I don't understand what "element-by-element model" means, The path definition of "a path P of length n as a series of links" is element-by-element? The path capacity C(P,T,I) = min {1..n} {C(Ln,T,I)} is element-by-element? > > I disagree with your statement that C(L,T,I) is node independent (in the context > of this RFC). Take the instance of, say, a firewall, in the path between two > routers. Suppose that the firewall is only capable of a throughput of 10 Mb/s > but is connected to the routers by 100 Mb/s Ethernet links. We can say that the > IP Type P Capacity is 10 Mb/s for the "link" (which is really a path) between the > two routers. Good instance. Do you mean Router1--------connection1-----firewall-----connection2-----router2? My first question, How many links are there in this network? My answer is TWO, one is between router 1 and firewall (i.e., connection1), the other is between firewall and router2 (i.e., connection2). There is a path between router 1 and router 2, but, router1 and router2 IS NOT CONNECTED BY ONE LINK. PS, imho, In the internet, there are only IP node and non-IP node, and, IP node consists of host and router. All firewall, application-layer-gateway are routers, although they have more functionalities. You could include the firewall if you wanted to, in which case the > IP Type P Capacity would be 10 Mb/s for both links, but there wouldn't really be > any point. No, I would like to say, in this case, Link1 capacity is 100Mbps, link2 capacity is 100Mbps, path capacity is 10M bps. > > Going on to your third example below: > > - Phase 1: You are right, in this case, the IP Type P Capacity reaches the > Nominal Link Capacity of both Link 1 and Link 2. The IP Type P Capacity of links 3 > and 4 is 0. If the IP Type P Capacity is 0, then the utilization also has to be 0. I > believe that this is consistent with normal engineering usage. This seems very strange to me, Link capacity is defined as "the maximum number of IP-layer bits that can be transmitted" If the capacity is 0, do you mean the max number of bits can be transmitted in this link is 0? If the link can only transmit 0 bit, is it an active link or unavailable link? > > - Phase 2: You postulate that the router is able to share its backplane capacity > fairly. Yes, because all the traffic are type P packets. Then if the router is designed so that it shares exactly fairly among all > active links, then the IP Type P Capacity of links 1,2,3 and 4 is 500 Mb/s, > because that is the highest rate at which bits can be (correctly) delivered. But my question here is the link utilization, does it change from phase 1? > Suppose that nodes B and D transmit in the reverse direction (to A and C, > respectively) and that the backplane capacity of the router is 1 Gb/s total (both > directions). Then the IP Type P Capacity is only 250 Mb/s for links 1,2,3,4. > > - Phase 3: This is exactly the same as Phase 1, just exchanging link and node > labels. > > The reason that things are defined this way is that this is what you would see if > you were to probe this network with a "bandwidth" measurement tool. No problem here, but when we get a final result, how to say that? Can we classify the reason to some one factor? I mean if the result is affected by multiple *parallel* factors, can we speak the result is only affected by one factor A, and other factors are sub-factor of factor A? This RFC is not about probe, but describes the principle and arithmetic, imho. > > A router with more links and a given backplane design could give you more > quirky behavior depending on internal congestion patterns or hot spots in the > switching fabric. For the purposes of the RFC, it doesn't matter whether a > node's design, or fast fading of a wireless link is limiting the capacity, it only > matters that the capacity is limited. That is why we do not separate links and > nodes as separate entities. Given real node behavior, you can't assign a single > node capacity (especially to routers and switches) I have to say, we should do right actions firstly, if action A is right, but difficult to do, while action B is easy to do, can we choose B? we should do the right job, but not the easy job, right? because it depends on the > design of the node and what other traffic is present at a given time. Yes, I agree this, and I think this may also be wrote in RFC documents, if needed. > > At this point, my opinion is that we do not need a new draft or RFC; I would be > happy to add the above explanations (or some variant) as a correction/update > to the RFC, I think we need a bulk modification. but I defer to Henk, Matt and the opinion of the workgroup. Me too. Best regards Xiangsong > > Regards, > Phil Chimento > pfc@ieee.org > > > > On Aug 12, 2010, at 9:24 PM, Xiangsong Cui wrote: > > > Hi Joseph, > > > > Thanks for your response! > > > > We come to link capacity again, I showed my option on this problem in the > link: > > http://www.ietf.org/mail-archive/web/ippm/current/msg02417.html > > > > As to link and link capacity, I want to make sure: > > > > Is IP node is a part or a IP link? I guess not, because link is the layer2-level > connection, it is the media, the facility, the layer2 protocol..., but does Not > cover nodes, which is a layer3 concept. > > > > So C(L,T,I) is node-independent, right? > > > > > > If you insisit link capacity is node-dependent, I give my third example here. > > > > In the following scenario, where link1/link2/link3/link4 physical capacity is 1.x > G bps, they all use the same link protocol, and we assume their "physical IP > capacity" is 1G bps. Same way, the router IP capacity is 1G bps. > > > > host A------link1-------- ----------link2------ host B > > \ / > > Router > > / \ > > host C------link3-------- ----------link4------ host D > > > > > > Phase 1, only host A transmit packets (IP-type-P) to host B, other hosts don't > transimit any packet. > > Base on RFC5136, the IP capacity of link1 and link2 is 1G bps for the certain > time/period, the link usage is same. IP capacity of link3 and link4 is 0 bps and > link usage is also same (althouth their physical IP capacity is 1G bps). As to > IP-type-P Link Utilization, base on the definition of RFC5136, Util(L,T,I) = > ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100% > (1G bps/1G bps), this looks right, but how about link3 and link4? the IP-type-P > Link Utilization of link3 is 0/0, what does this mean? (in my mind, when a link is > idle, the link utilization is 0, but not 0/0) > > > > Well, phase 2, host C begin to transmit packets (IP-type-P) to host D (others > keep unchanged, same networks, same nodes, same links....), also at the rate > 1G bps. > > Unfortunately, router over-loads, but it still works fairly. so > link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is the metric? Base > on RFC5136, the IP capacity of link1 and link2 is 500M bps for the certain > time/period, the link usage is same. IP capacity of link3 and link4 is 500M bps > for the certain time/period and link usage is also same. As to IP-type-P Link > Utilization, base on the definition of RFC5136, Util(L,T,I) = ( Used(L,T,I) / > C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100% (500M > bps/500M bps), this looks very strange, Link Utilization is unchaged, really? > How about link3 and link4? the IP-type-P Link Utilization of link3 is 100% (500M > / 500M)? > > > > Now, it is phase 3, host A stop transmitting packets, host C still transmitting > as before. > > Base on RFC5136, the IP capacity of link1 and link2 is 0 G bps, the link usage is > same. IP capacity of link3 and link4 is 1G bps and link usage is also same. > > How to calculate C(L,T,I) and Util(L,T,I) now? > > > > All of these, are more and more confusing..................................... > > > > Regards > > Xiangsong > > > > > > ----- Original Message ----- From: "Joseph Ishac" > > To: "Xiangsong Cui" > > Cc: > > Sent: Friday, August 13, 2010 1:30 AM > > Subject: Re: [ippm] Question/comment on RFC5136 > > > > > >> Just getting back from vacation so I'm slowly catching up here. I've > >> not parsed the whole thread, but have some thoughts on the initial > >> question and will throw that out here as I catch up. > >> > >>> For example, in the path between node A and B as follows, > >>> > >>> A------link1------Router------link2------B > >>> > >>> For some certain packet/traffic, if the capacity of link1 is 5G bps > >>> and the capacity of link2 is 3G bps, while the capacity of the router > >>> is 2G bps, how much is the capacity of the path between A and B? I > >>> believe the capacity is 2G bps (the neckbottle is the > >>> middle-box), but not 3G bps (as definition of RFC5136). > >> > >> Well, the RFC calls out a couple of things. The 5 Gbit/s and 3 Gbit/s > >> links would be "Nominal Physical Link Capacity" such that: > >> > >> NomCap(link1) = 5 Gbit/s > >> NomCap(link2) = 3 Gbit/s > >> > >> Now, the "IP-type-P Link Capacity" is what can be transmitted on a link > >> by link basis. So if A has no problem saturating the router then for > >> some given time, T, and interval, I: > >> > >> C(link1,T,I) ~= 5 Gbit/s > >> C(link2,T,I) ~= 2 Gbit/s > >> > >> The reason being that the Capacity at link 2 is driven by the ability to > >> transmit IP data from "Router" to "B". If "Router" has a limitation > >> here it impacts this value. > >> > >>> I think this should be updated, as > >>> > >>> C(P,T,I) = min ( X, Y) > >>> X = min {2..n} {C(Nn,T,I)} > >>> Y = min {1..n} {C(Ln,T,I)} > >> > >> The way I read the above is that value for Y is essentially the limit of > >> "Nominal Physical Link Capacity". The value of X is attempting to > >> factor in only *one* possible limiting factor to that, particularly a > >> node's forwarding and processing ability. > >> > >> Our original definition of C aims to capture the many factors that can > >> inhibit the ability to reach the "Nominal Physical Link Capacity" and as > >> such I believe is intended to be more robust than the case outlined > >> above. > >> > >> I will note that in practice, measuring all of this is VERY hard (and we > >> note this in the draft). However this document is not itself intended to > >> be a measuring technique, but instead, a conceptual analysis of what > >> should be counted. > >> > >> -Joseph > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm From henk@ripe.net Fri Aug 27 02:12:58 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358153A68FC for ; Fri, 27 Aug 2010 02:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.83 X-Spam-Level: X-Spam-Status: No, score=-101.83 tagged_above=-999 required=5 tests=[AWL=-1.393, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 rVNz0XEHV7PB for ; Fri, 27 Aug 2010 02:12:57 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 8C3C73A6A4F for ; Fri, 27 Aug 2010 02:12:56 -0700 (PDT) Received: from ayeaye.ipv6.ripe.net ([2001:610:240:23::c100:1705] helo=ayeaye.ripe.net) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Oouzs-0006BG-SH; Fri, 27 Aug 2010 11:13:22 +0200 Received: from [193.0.21.124] (helo=guest-113.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Oouzs-0003RK-NI; Fri, 27 Aug 2010 11:13:16 +0200 Message-ID: <4C7781AC.6090602@ripe.net> Date: Fri, 27 Aug 2010 11:13:16 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Xiangsong Cui References: <00a701cb3777$2cc70ef0$80106f0a@china.huawei.com> <20100812173013.GA29879@firebird1.grc.nasa.gov> <000901cb3a86$488efc30$80106f0a@china.huawei.com> <003001cb44be$9b6dcb10$d2496130$%cui@huawei.com> In-Reply-To: <003001cb44be$9b6dcb10$d2496130$%cui@huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d579128a6f26cd061079bb24507c8d1788 X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d579128a6f26cd061079bb24507c8d1788 Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 09:12:58 -0000 IPPM group, You have probably seen the discussion on RFC 5136. The state of the discussion is now: Phil: >> At this point, my opinion is that we do not need a new draft or RFC; I >> would be happy to add the above explanations (or some variant) as a >> correction/update to the RFC, Xiangsong: > I think we need a bulk modification. Both: > but I defer to Henk, Matt and the opinion of the workgroup. I'd appreciate it if people who have been following this discussion, voiced their opinion about this. A 1 line comment ("note" or "new RFC") is already helpful. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Fri Aug 27 06:28:01 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB53C3A6969 for ; Fri, 27 Aug 2010 06:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.777 X-Spam-Level: X-Spam-Status: No, score=-104.777 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 twnivE0WLs3P for ; Fri, 27 Aug 2010 06:28:00 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 926543A6955 for ; Fri, 27 Aug 2010 06:28:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-167.messagelabs.com!1282915711!21242782!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 32418 invoked from network); 27 Aug 2010 13:28:31 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Aug 2010 13:28:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7RDS0KI026153 for ; Fri, 27 Aug 2010 09:28:01 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7RDRu9O026073 for ; Fri, 27 Aug 2010 09:27:56 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o7RDSPBT011803 for ; Fri, 27 Aug 2010 08:28:25 -0500 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o7RDSMp0011746 for ; Fri, 27 Aug 2010 08:28:23 -0500 Message-Id: <201008271328.o7RDSMp0011746@klpd017.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-145-106.vpn.mwst.att.com[135.70.145.106](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100827132822gw100s4pece>; Fri, 27 Aug 2010 13:28:22 +0000 X-Originating-IP: [135.70.145.106] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 Aug 2010 09:28:42 -0400 To: Henk Uijterwaal , ippm@ietf.org From: Al Morton In-Reply-To: <4C7781AC.6090602@ripe.net> References: <00a701cb3777$2cc70ef0$80106f0a@china.huawei.com> <20100812173013.GA29879@firebird1.grc.nasa.gov> <000901cb3a86$488efc30$80106f0a@china.huawei.com> <003001cb44be$9b6dcb10$d2496130$%cui@huawei.com> <4C7781AC.6090602@ripe.net> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 13:28:02 -0000 At 05:13 AM 8/27/2010, Henk Uijterwaal wrote:
...I'd appreciate it if people who have been following this discussion,
voiced their opinion about this.  A 1 line comment ("note" or "new RFC")
is already helpful.

Henk

I've briefly contributed to this discussion and followed
the exchange since then.  IPPM has spent the overwhelming
majority of its effort on defining metrics that are also measurable.
If Black-Box Nodes were to be measured in isolation, they must be
connected to measurement devices by something - interfaces and
the media between them. A glance at any of BMWG's methodologies
confirms this reality. http://datatracker.ietf.org/wg/bmwg/

Looking at one of the fundamental journal articles for this topic:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2468
"Bandwidth estimation: metrics, measurement techniques, and tools",
R.Prasad, et al.

Section II immediately sorts through the terminology needed and
sets the definitions for the work that follows:
"In the following discussion we distinguish between
links at the data link layer (“layer-2”) and links at the IP
layer (“layer-3”). We call the former segments and the
latter hops. A segment normally corresponds to a physical
point-to-point link, a virtual circuit, or to a shared
access local area network (e.g., an Ethernet collision
domain, or an FDDI ring). In contrast, a hop may consist
of a sequence of one or more segments, connected
through switches, bridges, or other layer-2 devices. "
IMO, we need a note to capture similar assumptions for RFC 5136 terminology.

Al

From vze275m9@verizon.net Fri Aug 27 07:37:45 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA523A687D for ; Fri, 27 Aug 2010 07:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, J_CHICKENPOX_41=0.6, MIME_HTML_ONLY=1.457] 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 nCpZkHjlIF7U for ; Fri, 27 Aug 2010 07:37:43 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 43C213A6809 for ; Fri, 27 Aug 2010 07:37:43 -0700 (PDT) Received: from vms184.mailsrvcs.net ([unknown] [192.168.1.2]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L7T007AIFBE98J8@vms173005.mailsrvcs.net> for ippm@ietf.org; Fri, 27 Aug 2010 09:38:03 -0500 (CDT) Received: from 128.244.9.9 ([128.244.9.9]) by vms184.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 27 Aug 2010 09:38:02 -0500 (CDT) Date: Fri, 27 Aug 2010 09:38:02 -0500 (CDT) From: vze275m9@verizon.net To: Xiangsong.Cui@huawei.com Message-id: <346546944.2082711.1282919882410.JavaMail.root@vms184.mailsrvcs.net> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Originating-IP: [128.244.9.9] Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pfc@ieee.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 14:37:45 -0000 A few more comments on Xiangsong's last e-mail:

1) "element-by-elem= ent" means that you want to characterize each network element individually.= Joseph and I have both explained why we think this does not help the defin= ition of capacity in this case.
2) A router would look at the firewall = example as 1 hop (not two links, the firewall is invisible to the router). = While you COULD look at it your way, it doesn't bring any additional insigh= t to the achievable capacity between these two nodes, which for whatever re= ason remains limited to 10 Mb/s. 
3) Yes, at that time, the maximu= m number of IP bits that can be transmitted on that path is 0. When you sta= rt sending another stream and the router re-allocates resources, the capaci= ty changes.
4) No, under the conditions postulated, the link utilizatio= n does not change. When the router is dividing the entire capacity evenly b= etween two streams and there is no capacity left, then the utilization is 1= 00%.
5) I don't understand your comments about factors.
6) However = to reply to the next comment, we were not lazy in not including a node capa= city definition, and it wasn't because it was too hard. It was because it d= idn't make sense to do so.

Regarding Al Morton's proposal, I am fine= with that.

Thanks.
Regards,
Phil Chimento

Aug 25, 2= 010 09:33:13 PM, Xiangsong.Cui@huawei.com wrote:
Hi Phil,

I believe our dis= cussion becomes more and more focused, please see my
comments inline.


> -----Original Message-----
> From: Philip Chimento = [mailto:vze275m9@verizon.net]
> Sent: Thursday, August 26, 2010 8:32 = AM
> To: Xiangsong Cui
> Cc: Joseph Ishac; ippm@ietf.org
>= ; Subject: Re: [ippm] Question/comment on RFC5136
>
> XIangson= g:
> I have been busy and have not been able to respond quickly over = the past
week
> or so.
>
> The origin of RFC 5136 was= to try to make precise what was being and
should
> be measured by= the many tools that attempt to determine the "bandwidth" of
> a sour= ce-to-destination path at a given time.

Agree, we did talk about sou= rce-to-destination path.

We spoke at the time of having
> ano= ther informational RFC discussing the current state of "bandwidth"
> = measurement tools, but it was decided not to pursue it. This RFC was not> intended to be an element-by-element model of the network. The whole = point
> was to capture what was meant by "bandwidth".

I don't = understand what "element-by-element model" means,
The path definition of= "a path P of length n as a series of links" is
element-by-element?
T= he path capacity C(P,T,I) =3D min {1..n} {C(Ln,T,I)} is element-by-element?=

>
> I disagree with your statement that C(L,T,I) is node = independent (in the
context
> of this RFC). Take the instance of, = say, a firewall, in the path between
two
> routers. Suppose that t= he firewall is only capable of a throughput of 10
Mb/s
> but is c= onnected to the routers by 100 Mb/s Ethernet links. We can say
that the<= br>> IP Type P Capacity is 10 Mb/s for the "link" (which is really a pat= h)
between the
> two routers.

Good instance. Do you mean
Router1--------connection1-----firewall-----connection2-----router2?<= br>
My first question, How many links are there in this network?
My a= nswer is TWO, one is between router 1 and firewall (i.e., connection1), the other is between firewall and router2 (i.e., connection2).
There is= a path between router 1 and router 2,
but, router1 and router2 IS NOT = CONNECTED BY ONE LINK.

PS, imho,
In the internet, there are only = IP node and non-IP node, and, IP node
consists of host and router.
Al= l firewall, application-layer-gateway are routers, although they have more<= br>functionalities.


You could include the firewall if you wanted= to, in which case the
> IP Type P Capacity would be 10 Mb/s for both= links, but there wouldn't
really be
> any point.

No, I wou= ld like to say, in this case,
Link1 capacity is 100Mbps, link2 capacity = is 100Mbps, path capacity is 10M
bps.

>
> Going on to y= our third example below:
>
> - Phase 1: You are right, in this= case, the IP Type P Capacity reaches the
> Nominal Link Capacity of = both Link 1 and Link 2. The IP Type P Capacity of
links 3
> and 4 = is 0. If the IP Type P Capacity is 0, then the utilization also has
to b= e 0. I
> believe that this is consistent with normal engineering usag= e.

This seems very strange to me,
Link capacity is defined as "th= e maximum number of IP-layer bits that can be
transmitted"
If the cap= acity is 0, do you mean the max number of bits can be transmitted
in thi= s link is 0?
If the link can only transmit 0 bit, is it an active link o= r unavailable
link?

>
> - Phase 2: You postulate that t= he router is able to share its backplane
capacity
> fairly.
Yes, because all the traffic are type P packets.

Then if the route= r is designed so that it shares exactly fairly among all
> active lin= ks, then the IP Type P Capacity of links 1,2,3 and 4 is 500
Mb/s,
>= ; because that is the highest rate at which bits can be (correctly)
deli= vered.

But my question here is the link utilization, does it change = from phase 1?

> Suppose that nodes B and D transmit in the revers= e direction (to A and C,
> respectively) and that the backplane capac= ity of the router is 1 Gb/s
total (both
> directions). Then the IP= Type P Capacity is only 250 Mb/s for links
1,2,3,4.
>
> - = Phase 3: This is exactly the same as Phase 1, just exchanging link and
n= ode
> labels.
>
> The reason that things are defined thi= s way is that this is what you would
see if
> you were to probe th= is network with a "bandwidth" measurement tool.

No problem here, but= when we get a final result, how to say that?
Can we classify the reason= to some one factor?
I mean if the result is affected by multiple *paral= lel* factors,
can we speak the result is only affected by one factor A,= and other factors
are sub-factor of factor A?
This RFC is not about = probe, but describes the principle and arithmetic,
imho.

> > A router with more links and a given backplane design could give you = more
> quirky behavior depending on internal congestion patterns or h= ot spots in
the
> switching fabric. For the purposes of the RFC, i= t doesn't matter whether a
> node's design, or fast fading of a wirel= ess link is limiting the capacity,
it only
> matters that the capa= city is limited. That is why we do not separate links
and
> nodes = as separate entities. Given real node behavior, you can't assign a
singl= e
> node capacity (especially to routers and switches)

I have= to say, we should do right actions firstly,
if action A is right, but = difficult to do, while action B is easy to do, can
we choose B?
we sh= ould do the right job, but not the easy job, right?

because it depen= ds on the
> design of the node and what other traffic is present at a= given time.

Yes, I agree this, and I think this may also be wrote i= n RFC documents, if
needed.

>
> At this point, my opini= on is that we do not need a new draft or RFC; I
would be
> happy t= o add the above explanations (or some variant) as a
correction/update> to the RFC,

I think we need a bulk modification.


= but I defer to Henk, Matt and the opinion of the workgroup.

Me too.<= br>
Best regards
Xiangsong


>
> Regards,
> = Phil Chimento
> pfc@ieee.org
>
>
>
> On Au= g 12, 2010, at 9:24 PM, Xiangsong Cui wrote:
>
> > Hi Josep= h,
> >
> > Thanks for your response!
> >
>= > We come to link capacity again, I showed my option on this problem in=
the
> link:
> > http://www.ietf.org/mail-archive/web/ipp= m/current/msg02417.html
> >
> > As to link and link capac= ity, I want to make sure:
> >
> > Is IP node is a part or= a IP link? I guess not, because link is the
layer2-level
> conne= ction, it is the media, the facility, the layer2 protocol..., but
does N= ot
> cover nodes, which is a layer3 concept.
> >
> >= ; So C(L,T,I) is node-independent, right?
> >
> >
>= > If you insisit link capacity is node-dependent, I give my third examp= le
here.
> >
> > In the following scenario, where link= 1/link2/link3/link4 physical
capacity is 1.x
> G bps, they all use= the same link protocol, and we assume their "physical
IP
> capaci= ty" is 1G bps. Same way, the router IP capacity is 1G bps.
> >
= > > host A------link1-------- ----------link2------ hos= t B
> > \ /
>= ; > Router
> > = / \
> > host C------link3--= ------ ----------link4------ host D
> >
> >=
> > Phase 1, only host A transmit packets (IP-type-P) to host B, = other hosts
don't
> transimit any packet.
> > Base on RFC= 5136, the IP capacity of link1 and link2 is 1G bps for the
certain
&g= t; time/period, the link usage is same. IP capacity of link3 and link4 is 0=
bps and
> link usage is also same (althouth their physical IP cap= acity is 1G bps).
As to
> IP-type-P Link Utilization, base on the = definition of RFC5136, Util(L,T,I)
=3D
> ( Used(L,T,I) / C(L,T,I) = ), so we can get: IP-type-P Link Utilization of
link1 is 100%
> (1= G bps/1G bps), this looks right, but how about link3 and link4? the
IP-t= ype-P
> Link Utilization of link3 is 0/0, what does this mean? (in my= mind, when a
link is
> idle, the link utilization is 0, but not 0= /0)
> >
> > Well, phase 2, host C begin to transmit packe= ts (IP-type-P) to host D
(others
> keep unchanged, same networks, = same nodes, same links....), also at the
rate
> 1G bps.
> &g= t; Unfortunately, router over-loads, but it still works fairly. so
> = link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is the
met= ric? Base
> on RFC5136, the IP capacity of link1 and link2 is 500M bp= s for the
certain
> time/period, the link usage is same. IP capac= ity of link3 and link4 is
500M bps
> for the certain time/period a= nd link usage is also same. As to IP-type-P
Link
> Utilization, ba= se on the definition of RFC5136, Util(L,T,I) =3D (
Used(L,T,I) /
>= C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100%
= (500M
> bps/500M bps), this looks very strange, Link Utilization is u= nchaged,
really?
> How about link3 and link4? the IP-type-P Link U= tilization of link3 is 100%
(500M
> / 500M)?
> >
> = > Now, it is phase 3, host A stop transmitting packets, host C still
= transmitting
> as before.
> > Base on RFC5136, the IP capaci= ty of link1 and link2 is 0 G bps, the link
usage is
> same. IP cap= acity of link3 and link4 is 1G bps and link usage is also
same.
> = > How to calculate C(L,T,I) and Util(L,T,I) now?
> >
> &g= t; All of these, are more and more
confusing............................= .........
> >
> > Regards
> > Xiangsong
> = >
> >
> > ----- Original Message ----- From: "Joseph I= shac"
> > To: "Xiangsong Cui"
> > Cc:
> > Sent: Friday, August= 13, 2010 1:30 AM
> > Subject: Re: [ippm] Question/comment on RFC5= 136
> >
> >
> >> Just getting back from vacat= ion so I'm slowly catching up here. I've
> >> not parsed the w= hole thread, but have some thoughts on the initial
> >> questio= n and will throw that out here as I catch up.
> >>
> >= >> For example, in the path between node A and B as follows,
> = >>>
> >>> A------link1------Router------link2------= B
> >>>
> >>> For some certain packet/traffic= , if the capacity of link1 is 5G bps
> >>> and the capacity = of link2 is 3G bps, while the capacity of the router
> >>> i= s 2G bps, how much is the capacity of the path between A and B? I
> &= gt;>> believe the capacity is 2G bps (the neckbottle is the
> &= gt;>> middle-box), but not 3G bps (as definition of RFC5136).
>= >>
> >> Well, the RFC calls out a couple of things. The= 5 Gbit/s and 3 Gbit/s
> >> links would be "Nominal Physical Li= nk Capacity" such that:
> >>
> >> NomCap(link1) =3D= 5 Gbit/s
> >> NomCap(link2) =3D 3 Gbit/s
> >>
&= gt; >> Now, the "IP-type-P Link Capacity" is what can be transmitted = on a link
> >> by link basis. So if A has no problem saturatin= g the router then for
> >> some given time, T, and interval, I:=
> >>
> >> C(link1,T,I) ~=3D 5 Gbit/s
> >&= gt; C(link2,T,I) ~=3D 2 Gbit/s
> >>
> >> The reason= being that the Capacity at link 2 is driven by the ability
to
> &= gt;> transmit IP data from "Router" to "B". If "Router" has a limitatio= n
> >> here it impacts this value.
> >>
> >= ;>> I think this should be updated, as
> >>>
> &= gt;>> C(P,T,I) =3D min ( X, Y)
> >>> X =3D min {2..n} = {C(Nn,T,I)}
> >>> Y =3D min {1..n} {C(Ln,T,I)}
> >&= gt;
> >> The way I read the above is that value for Y is essent= ially the limit
of
> >> "Nominal Physical Link Capacity". T= he value of X is attempting to
> >> factor in only *one* possib= le limiting factor to that, particularly a
> >> node's forwardi= ng and processing ability.
> >>
> >> Our original d= efinition of C aims to capture the many factors that can
> >> i= nhibit the ability to reach the "Nominal Physical Link Capacity" and
as<= br>> >> such I believe is intended to be more robust than the case= outlined
> >> above.
> >>
> >> I will = note that in practice, measuring all of this is VERY hard (and
we
>= ; >> note this in the draft). However this document is not itself in= tended
to
> >> be a measuring technique, but instead, a conc= eptual analysis of what
> >> should be counted.
> >>= ;
> >> -Joseph
> >
> > ______________________= _________________________
> > ippm mailing list
> > ippm@= ietf.org
> > https://www.ietf.org/mailman/listinfo/ippm

From Xiangsong.Cui@huawei.com Fri Aug 27 17:31:33 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2B53A65A6 for ; Fri, 27 Aug 2010 17:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1] 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 dEYNZ6LYDdsT for ; Fri, 27 Aug 2010 17:31:30 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 64A223A6358 for ; Fri, 27 Aug 2010 17:31:28 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7U00BDC6T1HN@szxga04-in.huawei.com> for ippm@ietf.org; Sat, 28 Aug 2010 08:31:50 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7U0044J6T068@szxga04-in.huawei.com> for ippm@ietf.org; Sat, 28 Aug 2010 08:31:49 +0800 (CST) Date: Sat, 28 Aug 2010 08:31:49 +0800 From: Xiangsong Cui In-reply-to: <346546944.2082711.1282919882410.JavaMail.root@vms184.mailsrvcs.net> To: pfc@ieee.org Message-id: <004101cb4648$6782dc10$36889430$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mSdWsPaDG5hncOMrL7GjSA)" Content-language: zh-cn Thread-index: ActF9XrQ8BWF8jfbRNCMEYvzCAbACwAUZwzA References: <346546944.2082711.1282919882410.JavaMail.root@vms184.mailsrvcs.net> Cc: ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 00:31:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_mSdWsPaDG5hncOMrL7GjSA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Just a quick response. Your statements seems to me that link is an end-to-end concept, but not a hop-by-hop concept, so the firewall is just a hop of the link but does not split the path (i.e., between the source and the destination) to two links. This is really different from my thought. PS, nobody says routers should be visible to the source, we all know the source transmits packet to the destination but not to the on-way routers. I would like to wait the decision of working group now. Thanks and best regards Xiangsong From: vze275m9@verizon.net [mailto:vze275m9@verizon.net] Sent: Friday, August 27, 2010 10:38 PM To: Xiangsong.Cui@huawei.com Cc: pfc@ieee.org; jishac@nasa.gov; ippm@ietf.org Subject: Re: RE: [ippm] Question/comment on RFC5136 A few more comments on Xiangsong's last e-mail: 1) "element-by-element" means that you want to characterize each network element individually. Joseph and I have both explained why we think this does not help the definition of capacity in this case. 2) A router would look at the firewall example as 1 hop (not two links, the firewall is invisible to the router). While you COULD look at it your way, it doesn't bring any additional insight to the achievable capacity between these two nodes, which for whatever reason remains limited to 10 Mb/s. 3) Yes, at that time, the maximum number of IP bits that can be transmitted on that path is 0. When you start sending another stream and the router re-allocates resources, the capacity changes. 4) No, under the conditions postulated, the link utilization does not change. When the router is dividing the entire capacity evenly between two streams and there is no capacity left, then the utilization is 100%. 5) I don't understand your comments about factors. 6) However to reply to the next comment, we were not lazy in not including a node capacity definition, and it wasn't because it was too hard. It was because it didn't make sense to do so. Regarding Al Morton's proposal, I am fine with that. Thanks. Regards, Phil Chimento Aug 25, 2010 09:33:13 PM, Xiangsong.Cui@huawei.com wrote: Hi Phil, I believe our discussion becomes more and more focused, please see my comments inline. > -----Original Message----- > From: Philip Chimento [mailto:vze275m9@verizon.net] > Sent: Thursday, August 26, 2010 8:32 AM > To: Xiangsong Cui > Cc: Joseph Ishac; ippm@ietf.org > Subject: Re: [ippm] Question/comment on RFC5136 > > XIangsong: > I have been busy and have not been able to respond quickly over the past week > or so. > > The origin of RFC 5136 was to try to make precise what was being and should > be measured by the many tools that attempt to determine the "bandwidth" of > a source-to-destination path at a given time. Agree, we did talk about source-to-destination path. We spoke at the time of having > another informational RFC discussing the current state of "bandwidth" > measurement tools, but it was decided not to pursue it. This RFC was not > intended to be an element-by-element model of the network. The whole point > was to capture what was meant by "bandwidth". I don't understand what "element-by-element model" means, The path definition of "a path P of length n as a series of links" is element-by-element? The path capacity C(P,T,I) = min {1..n} {C(Ln,T,I)} is element-by-element? > > I disagree with your statement that C(L,T,I) is node independent (in the context > of this RFC). Take the instance of, say, a firewall, in the path between two > routers. Suppose that the firewall is only capable of a throughput of 10 Mb/s > but is connected to the routers by 100 Mb/s Ethernet links. We can say that the > IP Type P Capacity is 10 Mb/s for the "link" (which is really a path) between the > two routers. Good instance. Do you mean Router1--------connection1-----firewall-----connection2-----router2? My first question, How many links are there in this network? My answer is TWO, one is between router 1 and firewall (i.e., connection1), the other is between firewall and router2 (i.e., connection2). There is a path between router 1 and router 2, but, router1 and router2 IS NOT CONNECTED BY ONE LINK. PS, imho, In the internet, there are only IP node and non-IP node, and, IP node consists of host and router. All firewall, application-layer-gateway are routers, although they have more functionalities. You could include the firewall if you wanted to, in which case the > IP Type P Capacity would be 10 Mb/s for both links, but there wouldn't really be > any point. No, I would like to say, in this case, Link1 capacity is 100Mbps, link2 capacity is 100Mbps, path capacity is 10M bps. > > Going on to your third example below: > > - Phase 1: You are right, in this case, the IP Type P Capacity reaches the > Nominal Link Capacity of both Link 1 and Link 2. The IP Type P Capacity of links 3 > and 4 is 0. If the IP Type P Capacity is 0, then the utilization also has to be 0. I > believe that this is consistent with normal engineering usage. This seems very strange to me, Link capacity is defined as "the maximum number of IP-layer bits that can be transmitted" If the capacity is 0, do you mean the max number of bits can be transmitted in this link is 0? If the link can only transmit 0 bit, is it an active link or unavailable link? > > - Phase 2: You postulate that the router is able to share its backplane capacity > fairly. Yes, because all the traffic are type P packets. Then if the router is designed so that it shares exactly fairly among all > active links, then the IP Type P Capacity of links 1,2,3 and 4 is 500 Mb/s, > because that is the highest rate at which bits can be (correctly) delivered. But my question here is the link utilization, does it change from phase 1? > Suppose that nodes B and D transmit in the reverse direction (to A and C, > respectively) and that the backplane capacity of the router is 1 Gb/s total (both > directions). Then the IP Type P Capacity is only 250 Mb/s for links 1,2,3,4. > > - Phase 3: This is exactly the same as Phase 1, just exchanging link and node > labels. > > The reason that things are defined this way is that this is what you would see if > you were to probe this network with a "bandwidth" measurement tool. No problem here, but when we get a final result, how to say that? Can we classify the reason to some one factor? I mean if the result is affected by multiple *parallel* factors, can we speak the result is only affected by one factor A, and other factors are sub-factor of factor A? This RFC is not about probe, but describes the principle and arithmetic, imho. > > A router with more links and a given backplane design could give you more > quirky behavior depending on internal congestion patterns or hot spots in the > switching fabric. For the purposes of the RFC, it doesn't matter whether a > node's design, or fast fading of a wireless link is limiting the capacity, it only > matters that the capacity is limited. That is why we do not separate links and > nodes as separate entities. Given real node behavior, you can't assign a single > node capacity (especially to routers and switches) I have to say, we should do right actions firstly, if action A is right, but difficult to do, while action B is easy to do, can we choose B? we should do the right job, but not the easy job, right? because it depends on the > design of the node and what other traffic is present at a given time. Yes, I agree this, and I think this may also be wrote in RFC documents, if needed. > > At this point, my opinion is that we do not need a new draft or RFC; I would be > happy to add the above explanations (or some variant) as a correction/update > to the RFC, I think we need a bulk modification. but I defer to Henk, Matt and the opinion of the workgroup. Me too. Best regards Xiangsong > > Regards, > Phil Chimento > pfc@ieee.org > > > > On Aug 12, 2010, at 9:24 PM, Xiangsong Cui wrote: > > > Hi Joseph, > > > > Thanks for your response! > > > > We come to link capacity again, I showed my option on this problem in the > link: > > http://www.ietf.org/mail-archive/web/ippm/current/msg02417.html > > > > As to link and link capacity, I want to make sure: > > > > Is IP node is a part or a IP link? I guess not, because link is the layer2-level > connection, it is the media, the facility, the layer2 protocol..., but does Not > cover nodes, which is a layer3 concept. > > > > So C(L,T,I) is node-independent, right? > > > > > > If you insisit link capacity is node-dependent, I give my third example here. > > > > In the following scenario, where link1/link2/link3/link4 physical capacity is 1.x > G bps, they all use the same link protocol, and we assume their "physical IP > capacity" is 1G bps. Same way, the router IP capacity is 1G bps. > > > > host A------link1-------- ----------link2------ host B > > \ / > > Router > > / \ > > host C------link3-------- ----------link4------ host D > > > > > > Phase 1, only host A transmit packets (IP-type-P) to host B, other hosts don't > transimit any packet. > > Base on RFC5136, the IP capacity of link1 and link2 is 1G bps for the certain > time/period, the link usage is same. IP capacity of link3 and link4 is 0 bps and > link usage is also same (althouth their physical IP capacity is 1G bps). As to > IP-type-P Link Utilization, base on the definition of RFC5136, Util(L,T,I) = > ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100% > (1G bps/1G bps), this looks right, but how about link3 and link4? the IP-type-P > Link Utilization of link3 is 0/0, what does this mean? (in my mind, when a link is > idle, the link utilization is 0, but not 0/0) > > > > Well, phase 2, host C begin to transmit packets (IP-type-P) to host D (others > keep unchanged, same networks, same nodes, same links....), also at the rate > 1G bps. > > Unfortunately, router over-loads, but it still works fairly. so > link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is the metric? Base > on RFC5136, the IP capacity of link1 and link2 is 500M bps for the certain > time/period, the link usage is same. IP capacity of link3 and link4 is 500M bps > for the certain time/period and link usage is also same. As to IP-type-P Link > Utilization, base on the definition of RFC5136, Util(L,T,I) = ( Used(L,T,I) / > C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100% (500M > bps/500M bps), this looks very strange, Link Utilization is unchaged, really? > How about link3 and link4? the IP-type-P Link Utilization of link3 is 100% (500M > / 500M)? > > > > Now, it is phase 3, host A stop transmitting packets, host C still transmitting > as before. > > Base on RFC5136, the IP capacity of link1 and link2 is 0 G bps, the link usage is > same. IP capacity of link3 and link4 is 1G bps and link usage is also same. > > How to calculate C(L,T,I) and Util(L,T,I) now? > > > > All of these, are more and more confusing..................................... > > > > Regards > > Xiangsong > > > > > > ----- Original Message ----- From: "Joseph Ishac" > > To: "Xiangsong Cui" > > Cc: > > Sent: Friday, August 13, 2010 1:30 AM > > Subject: Re: [ippm] Question/comment on RFC5136 > > > > > >> Just getting back from vacation so I'm slowly catching up here. I've > >> not parsed the whole thread, but have some thoughts on the initial > >> question and will throw that out here as I catch up. > >> > >>> For example, in the path between node A and B as follows, > >>> > >>> A------link1------Router------link2------B > >>> > >>> For some certain packet/traffic, if the capacity of link1 is 5G bps > >>> and the capacity of link2 is 3G bps, while the capacity of the router > >>> is 2G bps, how much is the capacity of the path between A and B? I > >>> believe the capacity is 2G bps (the neckbottle is the > >>> middle-box), but not 3G bps (as definition of RFC5136). > >> > >> Well, the RFC calls out a couple of things. The 5 Gbit/s and 3 Gbit/s > >> links would be "Nominal Physical Link Capacity" such that: > >> > >> NomCap(link1) = 5 Gbit/s > >> NomCap(link2) = 3 Gbit/s > >> > >> Now, the "IP-type-P Link Capacity" is what can be transmitted on a link > >> by link basis. So if A has no problem saturating the router then for > >> some given time, T, and interval, I: > >> > >> C(link1,T,I) ~= 5 Gbit/s > >> C(link2,T,I) ~= 2 Gbit/s > >> > >> The reason being that the Capacity at link 2 is driven by the ability to > >> transmit IP data from "Router" to "B". If "Router" has a limitation > >> here it impacts this value. > >> > >>> I think this should be updated, as > >>> > >>> C(P,T,I) = min ( X, Y) > >>> X = min {2..n} {C(Nn,T,I)} > >>> Y = min {1..n} {C(Ln,T,I)} > >> > >> The way I read the above is that value for Y is essentially the limit of > >> "Nominal Physical Link Capacity". The value of X is attempting to > >> factor in only *one* possible limiting factor to that, particularly a > >> node's forwarding and processing ability. > >> > >> Our original definition of C aims to capture the many factors that can > >> inhibit the ability to reach the "Nominal Physical Link Capacity" and as > >> such I believe is intended to be more robust than the case outlined > >> above. > >> > >> I will note that in practice, measuring all of this is VERY hard (and we > >> note this in the draft). However this document is not itself intended to > >> be a measuring technique, but instead, a conceptual analysis of what > >> should be counted. > >> > >> -Joseph > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm --Boundary_(ID_mSdWsPaDG5hncOMrL7GjSA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Just a quick response.

 

Your statements seems to me that link is an end-to-end = concept, but not a hop-by-hop concept, so the firewall is just a hop of the link = but does not split the path (i.e., between the source and the destination) to two = links. This is really different from my thought.

 

PS, nobody says routers should be visible to the source, = we all know the source transmits packet to the destination but not to the = on-way routers.

 

 

I would like to wait the decision of working group = now.

 

Thanks and best regards

Xiangsong

 

 

 

From: vze275m9@verizon.net [mailto:vze275m9@verizon.net]
Sent: Friday, August 27, 2010 10:38 PM
To: Xiangsong.Cui@huawei.com
Cc: pfc@ieee.org; jishac@nasa.gov; ippm@ietf.org
Subject: Re: RE: [ippm] Question/comment on = RFC5136

 

A few more comments on = Xiangsong's last e-mail:

1) "element-by-element" means that you want to characterize = each network element individually. Joseph and I have both explained why we = think this does not help the definition of capacity in this case.
2) A router would look at the firewall example as 1 hop (not two links, = the firewall is invisible to the router). While you COULD look at it your = way, it doesn't bring any additional insight to the achievable capacity between = these two nodes, which for whatever reason remains limited to 10 Mb/s.  =
3) Yes, at that time, the maximum number of IP bits that can be = transmitted on that path is 0. When you start sending another stream and the router re-allocates resources, the capacity changes.
4) No, under the conditions postulated, the link utilization does not = change. When the router is dividing the entire capacity evenly between two = streams and there is no capacity left, then the utilization is 100%.
5) I don't understand your comments about factors.
6) However to reply to the next comment, we were not lazy in not = including a node capacity definition, and it wasn't because it was too hard. It was = because it didn't make sense to do so.

Regarding Al Morton's proposal, I am fine with that.

Thanks.
Regards,
Phil Chimento

Aug 25, 2010 09:33:13 PM, Xiangsong.Cui@huawei.com = wrote:

Hi Phil,

I believe our discussion becomes more and more focused, please see = my
comments inline.



> -----Original Message-----
> From: Philip Chimento [mailto:vze275m9@verizon.net]
> Sent: Thursday, August 26, 2010 8:32 AM
> To: Xiangsong Cui
> Cc: Joseph Ishac; ippm@ietf.org
> Subject: Re: [ippm] Question/comment on RFC5136
>
> XIangsong:
> I have been busy and have not been able to respond quickly over the = past
week
> or so.
>
> The origin of RFC 5136 was to try to make precise what was being = and
should
> be measured by the many tools that attempt to determine the "bandwidth" of
> a source-to-destination path at a given time.

Agree, we did talk about source-to-destination path.

We spoke at the time of having
> another informational RFC discussing the current state of "bandwidth"
> measurement tools, but it was decided not to pursue it. This RFC = was not
> intended to be an element-by-element model of the network. The = whole point
> was to capture what was meant by "bandwidth".

I don't understand what "element-by-element model" means,
The path definition of "a path P of length n as a series of = links" is
element-by-element?
The path capacity C(P,T,I) =3D min {1..n} {C(Ln,T,I)} is = element-by-element?

>
> I disagree with your statement that C(L,T,I) is node independent = (in the
context
> of this RFC). Take the instance of, say, a firewall, in the path = between
two
> routers. Suppose that the firewall is only capable of a throughput = of 10
Mb/s
> but is connected to the routers by 100 Mb/s Ethernet links. We can = say
that the
> IP Type P Capacity is 10 Mb/s for the "link" (which is = really a path)
between the
> two routers.

Good instance. Do you mean

Router1--------connection1-----firewall-----connection2-----router2?

My first question, How many links are there in this network?
My answer is TWO, one is between router 1 and firewall (i.e., = connection1),
the other is between firewall and router2 (i.e., connection2).
There is a path between router 1 and router 2,
but, router1 and router2 IS NOT CONNECTED BY ONE LINK.

PS, imho,
In the internet, there are only IP node and non-IP node, and, IP = node
consists of host and router.
All firewall, application-layer-gateway are routers, although they have = more
functionalities.


You could include the firewall if you wanted to, in which case the
> IP Type P Capacity would be 10 Mb/s for both links, but there = wouldn't
really be
> any point.

No, I would like to say, in this case,
Link1 capacity is 100Mbps, link2 capacity is 100Mbps, path capacity is = 10M
bps.

>
> Going on to your third example below:
>
> - Phase 1: You are right, in this case, the IP Type P Capacity = reaches the
> Nominal Link Capacity of both Link 1 and Link 2. The IP Type P = Capacity of
links 3
> and 4 is 0. If the IP Type P Capacity is 0, then the utilization = also has
to be 0. I
> believe that this is consistent with normal engineering usage.

This seems very strange to me,
Link capacity is defined as "the maximum number of IP-layer bits = that can be
transmitted"
If the capacity is 0, do you mean the max number of bits can be = transmitted
in this link is 0?
If the link can only transmit 0 bit, is it an active link or = unavailable
link?

>
> - Phase 2: You postulate that the router is able to share its = backplane
capacity
> fairly.

Yes, because all the traffic are type P packets.

Then if the router is designed so that it shares exactly fairly among = all
> active links, then the IP Type P Capacity of links 1,2,3 and 4 is = 500
Mb/s,
> because that is the highest rate at which bits can be = (correctly)
delivered.

But my question here is the link utilization, does it change from phase = 1?

> Suppose that nodes B and D transmit in the reverse direction (to A = and C,
> respectively) and that the backplane capacity of the router is 1 = Gb/s
total (both
> directions). Then the IP Type P Capacity is only 250 Mb/s for = links
1,2,3,4.
>
> - Phase 3: This is exactly the same as Phase 1, just exchanging = link and
node
> labels.
>
> The reason that things are defined this way is that this is what = you would
see if
> you were to probe this network with a "bandwidth" = measurement tool.

No problem here, but when we get a final result, how to say that?
Can we classify the reason to some one factor?
I mean if the result is affected by multiple *parallel* factors,
can we speak the result is only affected by one factor A, and other = factors
are sub-factor of factor A?
This RFC is not about probe, but describes the principle and = arithmetic,
imho.

>
> A router with more links and a given backplane design could give = you more
> quirky behavior depending on internal congestion patterns or hot = spots in
the
> switching fabric. For the purposes of the RFC, it doesn't matter = whether a
> node's design, or fast fading of a wireless link is limiting the = capacity,
it only
> matters that the capacity is limited. That is why we do not = separate links
and
> nodes as separate entities. Given real node behavior, you can't = assign a
single
> node capacity (especially to routers and switches)

I have to say, we should do right actions firstly,
if action A is right, but difficult to do, while action B is easy to do, = can
we choose B?
we should do the right job, but not the easy job, right?

because it depends on the
> design of the node and what other traffic is present at a given = time.

Yes, I agree this, and I think this may also be wrote in RFC documents, = if
needed.

>
> At this point, my opinion is that we do not need a new draft or = RFC; I
would be
> happy to add the above explanations (or some variant) as a
correction/update
> to the RFC,

I think we need a bulk modification.


but I defer to Henk, Matt and the opinion of the workgroup.

Me too.

Best regards
Xiangsong


>
> Regards,
> Phil Chimento
> pfc@ieee.org
>
>
>
> On Aug 12, 2010, at 9:24 PM, Xiangsong Cui wrote:
>
> > Hi Joseph,
> >
> > Thanks for your response!
> >
> > We come to link capacity again, I showed my option on this = problem in
the
> link:
> > = http://www.ietf.org/mail-archive/web/ippm/current/msg02417.html
> >
> > As to link and link capacity, I want to make sure:
> >
> > Is IP node is a part or a IP link? I guess not, because link = is the
layer2-level
> connection, it is the media, the facility, the layer2 protocol..., = but
does Not
> cover nodes, which is a layer3 concept.
> >
> > So C(L,T,I) is node-independent, right?
> >
> >
> > If you insisit link capacity is node-dependent, I give my = third example
here.
> >
> > In the following scenario, where link1/link2/link3/link4 = physical
capacity is 1.x
> G bps, they all use the same link protocol, and we assume their "physical
IP
> capacity" is 1G bps. Same way, the router IP capacity is 1G = bps.
> >
> > host A------link1-------- ----------link2------ host B
> > \ /
> > Router
> > / \
> > host C------link3-------- ----------link4------ host D
> >
> >
> > Phase 1, only host A transmit packets (IP-type-P) to host B, = other hosts
don't
> transimit any packet.
> > Base on RFC5136, the IP capacity of link1 and link2 is 1G bps = for the
certain
> time/period, the link usage is same. IP capacity of link3 and link4 = is 0
bps and
> link usage is also same (althouth their physical IP capacity is 1G = bps).
As to
> IP-type-P Link Utilization, base on the definition of RFC5136, = Util(L,T,I)
=3D
> ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link = Utilization of
link1 is 100%
> (1G bps/1G bps), this looks right, but how about link3 and link4? = the
IP-type-P
> Link Utilization of link3 is 0/0, what does this mean? (in my mind, = when a
link is
> idle, the link utilization is 0, but not 0/0)
> >
> > Well, phase 2, host C begin to transmit packets (IP-type-P) to = host D
(others
> keep unchanged, same networks, same nodes, same links....), also at = the
rate
> 1G bps.
> > Unfortunately, router over-loads, but it still works fairly. = so
> link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is = the
metric? Base
> on RFC5136, the IP capacity of link1 and link2 is 500M bps for = the
certain
> time/period, the link usage is same. IP capacity of link3 and link4 = is
500M bps
> for the certain time/period and link usage is also same. As to = IP-type-P
Link
> Utilization, base on the definition of RFC5136, Util(L,T,I) =3D = (
Used(L,T,I) /
> C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is = 100%
(500M
> bps/500M bps), this looks very strange, Link Utilization is = unchaged,
really?
> How about link3 and link4? the IP-type-P Link Utilization of link3 = is 100%
(500M
> / 500M)?
> >
> > Now, it is phase 3, host A stop transmitting packets, host C = still
transmitting
> as before.
> > Base on RFC5136, the IP capacity of link1 and link2 is 0 G = bps, the link
usage is
> same. IP capacity of link3 and link4 is 1G bps and link usage is = also
same.
> > How to calculate C(L,T,I) and Util(L,T,I) now?
> >
> > All of these, are more and more
confusing.....................................
> >
> > Regards
> > Xiangsong
> >
> >
> > ----- Original Message ----- From: "Joseph Ishac" =
> > To: "Xiangsong Cui"
> > Cc:
> > Sent: Friday, August 13, 2010 1:30 AM
> > Subject: Re: [ippm] Question/comment on RFC5136
> >
> >
> >> Just getting back from vacation so I'm slowly catching up = here. I've
> >> not parsed the whole thread, but have some thoughts on the initial
> >> question and will throw that out here as I catch up.
> >>
> >>> For example, in the path between node A and B as = follows,
> >>>
> >>> A------link1------Router------link2------B
> >>>
> >>> For some certain packet/traffic, if the capacity of = link1 is 5G bps
> >>> and the capacity of link2 is 3G bps, while the = capacity of the router
> >>> is 2G bps, how much is the capacity of the path = between A and B? I
> >>> believe the capacity is 2G bps (the neckbottle is = the
> >>> middle-box), but not 3G bps (as definition of = RFC5136).
> >>
> >> Well, the RFC calls out a couple of things. The 5 Gbit/s = and 3 Gbit/s
> >> links would be "Nominal Physical Link Capacity" = such that:
> >>
> >> NomCap(link1) =3D 5 Gbit/s
> >> NomCap(link2) =3D 3 Gbit/s
> >>
> >> Now, the "IP-type-P Link Capacity" is what can = be transmitted on a link
> >> by link basis. So if A has no problem saturating the = router then for
> >> some given time, T, and interval, I:
> >>
> >> C(link1,T,I) ~=3D 5 Gbit/s
> >> C(link2,T,I) ~=3D 2 Gbit/s
> >>
> >> The reason being that the Capacity at link 2 is driven by = the ability
to
> >> transmit IP data from "Router" to "B". = If "Router" has a limitation
> >> here it impacts this value.
> >>
> >>> I think this should be updated, as
> >>>
> >>> C(P,T,I) =3D min ( X, Y)
> >>> X =3D min {2..n} {C(Nn,T,I)}
> >>> Y =3D min {1..n} {C(Ln,T,I)}
> >>
> >> The way I read the above is that value for Y is = essentially the limit
of
> >> "Nominal Physical Link Capacity". The value of X = is attempting to
> >> factor in only *one* possible limiting factor to that, particularly a
> >> node's forwarding and processing ability.
> >>
> >> Our original definition of C aims to capture the many = factors that can
> >> inhibit the ability to reach the "Nominal Physical = Link Capacity" and
as
> >> such I believe is intended to be more robust than the case outlined
> >> above.
> >>
> >> I will note that in practice, measuring all of this is = VERY hard (and
we
> >> note this in the draft). However this document is not = itself intended
to
> >> be a measuring technique, but instead, a conceptual = analysis of what
> >> should be counted.
> >>
> >> -Joseph
> >
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> > https://www.ietf.org/mailman/listinfo/ippm


--Boundary_(ID_mSdWsPaDG5hncOMrL7GjSA)-- From Xiangsong.Cui@huawei.com Fri Aug 27 17:39:31 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F673A65A5 for ; Fri, 27 Aug 2010 17:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 885qhih3fRGs for ; Fri, 27 Aug 2010 17:39:25 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B91FD3A6358 for ; Fri, 27 Aug 2010 17:39:24 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7U0071K76AET@szxga05-in.huawei.com> for ippm@ietf.org; Sat, 28 Aug 2010 08:39:46 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7U00K7N768JT@szxga05-in.huawei.com> for ippm@ietf.org; Sat, 28 Aug 2010 08:39:46 +0800 (CST) Date: Sat, 28 Aug 2010 08:39:44 +0800 From: Xiangsong Cui In-reply-to: <201008271328.o7RDSMp0011746@klpd017.kcdc.att.com> To: 'Al Morton' , 'Henk Uijterwaal' , ippm@ietf.org Message-id: <004901cb4649$832f6770$898e3650$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Cy/HcbAqKU4udVngVU+rdg)" Content-language: zh-cn Thread-index: ActF68LqpxodMkncTWCycvGQ/ow8/AAXXDqg References: <00a701cb3777$2cc70ef0$80106f0a@china.huawei.com> <20100812173013.GA29879@firebird1.grc.nasa.gov> <000901cb3a86$488efc30$80106f0a@china.huawei.com> <003001cb44be$9b6dcb10$d2496130$%cui@huawei.com> <4C7781AC.6090602@ripe.net> <201008271328.o7RDSMp0011746@klpd017.kcdc.att.com> Subject: Re: [ippm] Question/comment on RFC5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 00:39:31 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Cy/HcbAqKU4udVngVU+rdg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I'm OK to link and link capacity, my concerns are path and path capacity. Section II immediately sorts through the terminology needed and sets the definitions for the work that follows: "In the following discussion we distinguish between links at the data link layer ("layer-2") and links at the IP layer ("layer-3"). We call the former segments and the latter hops. A segment normally corresponds to a physical point-to-point link, a virtual circuit, or to a shared access local area network (e.g., an Ethernet collision domain, or an FDDI ring). In contrast, a hop may consist of a sequence of one or more segments, connected through switches, bridges, or other layer-2 devices. " all of this describes link, without mention of path. Xiangsong From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton Sent: Friday, August 27, 2010 9:29 PM To: Henk Uijterwaal; ippm@ietf.org Subject: Re: [ippm] Question/comment on RFC5136 At 05:13 AM 8/27/2010, Henk Uijterwaal wrote: ...I'd appreciate it if people who have been following this discussion, voiced their opinion about this. A 1 line comment ("note" or "new RFC") is already helpful. Henk I've briefly contributed to this discussion and followed the exchange since then. IPPM has spent the overwhelming majority of its effort on defining metrics that are also measurable. If Black-Box Nodes were to be measured in isolation, they must be connected to measurement devices by something - interfaces and the media between them. A glance at any of BMWG's methodologies confirms this reality. http://datatracker.ietf.org/wg/bmwg/ Looking at one of the fundamental journal articles for this topic: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2468 "Bandwidth estimation: metrics, measurement techniques, and tools", R.Prasad, et al. Section II immediately sorts through the terminology needed and sets the definitions for the work that follows: "In the following discussion we distinguish between links at the data link layer ("layer-2") and links at the IP layer ("layer-3"). We call the former segments and the latter hops. A segment normally corresponds to a physical point-to-point link, a virtual circuit, or to a shared access local area network (e.g., an Ethernet collision domain, or an FDDI ring). In contrast, a hop may consist of a sequence of one or more segments, connected through switches, bridges, or other layer-2 devices. " IMO, we need a note to capture similar assumptions for RFC 5136 terminology. Al --Boundary_(ID_Cy/HcbAqKU4udVngVU+rdg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I’m OK to link and link capacity, my concerns are path and path capacity.

 

Section II immediately sorts through the terminology needed and
sets the definitions for the work that follows:

"In the following discussion we distinguish between

links at the data link layer (“layer-2”) and links at the IP

layer (“layer-3”). We call the former segments and the

latter hops. A segment normally corresponds to a physical

point-to-point link, a virtual circuit, or to a shared

access local area network (e.g., an Ethernet collision

domain, or an FDDI ring). In contrast, a hop may consist

of a sequence of one or more segments, connected

through switches, bridges, or other layer-2 devices. "

 

all of this describes link, without mention of path.

 

Xiangsong

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton
Sent: Friday, August 27, 2010 9:29 PM
To: Henk Uijterwaal; ippm@ietf.org
Subject: Re: [ippm] Question/comment on RFC5136

 

At 05:13 AM 8/27/2010, Henk Uijterwaal wrote:

...I'd appreciate it if people who have been following this discussion,
voiced their opinion about this.  A 1 line comment ("note" or "new RFC")
is already helpful.

Henk


I've briefly contributed to this discussion and followed
the exchange since then.  IPPM has spent the overwhelming
majority of its effort on defining metrics that are also measurable.
If Black-Box Nodes were to be measured in isolation, they must be
connected to measurement devices by something - interfaces and
the media between them. A glance at any of BMWG's methodologies
confirms this reality. http://datatracker.ietf.org/wg/bmwg/

Looking at one of the fundamental journal articles for this topic:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2468
"Bandwidth estimation: metrics, measurement techniques, and tools",
R.Prasad, et al.

Section II immediately sorts through the terminology needed and
sets the definitions for the work that follows:

"In the following discussion we distinguish between

links at the data link layer (“layer-2”) and links at the IP

layer (“layer-3”). We call the former segments and the

latter hops. A segment normally corresponds to a physical

point-to-point link, a virtual circuit, or to a shared

access local area network (e.g., an Ethernet collision

domain, or an FDDI ring). In contrast, a hop may consist

of a sequence of one or more segments, connected

through switches, bridges, or other layer-2 devices. "

IMO, we need a note to capture similar assumptions for RFC 5136 terminology.

Al

--Boundary_(ID_Cy/HcbAqKU4udVngVU+rdg)-- From Barry.Constantine@jdsu.com Sat Aug 28 07:11:31 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0F03A68E9 for ; Sat, 28 Aug 2010 07:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.658 X-Spam-Level: X-Spam-Status: No, score=-4.658 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 VZ3Rn1n-Pe42 for ; Sat, 28 Aug 2010 07:11:30 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with SMTP id C505C3A6862 for ; Sat, 28 Aug 2010 07:11:29 -0700 (PDT) Received: from source ([209.36.247.245]) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTHkZMZDzDkt5QAVxaMPvnNrnOe+na8j5@postini.com; Sat, 28 Aug 2010 07:12:02 PDT Received: from milexhtca1.ds.jdsu.net ([10.75.2.121]) by Outbound2.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Aug 2010 07:02:28 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca1.ds.jdsu.net ([::1]) with mapi; Sat, 28 Aug 2010 07:02:28 -0700 From: Barry Constantine To: "ippm@ietf.org" Date: Sat, 28 Aug 2010 07:02:27 -0700 Thread-Topic: Idnits Tool - -- "disclaimer for pre-RFC5378 work" Thread-Index: ActGuaXb4iWPt2cuToy2t/4y13RA/A== Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCB@MILEXCH1.ds.jdsu.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCBMILEXCH1dsjds_" MIME-Version: 1.0 X-OriginalArrivalTime: 28 Aug 2010 14:02:28.0710 (UTC) FILETIME=[A6894860:01CB46B9] Subject: [ippm] Idnits Tool - -- "disclaimer for pre-RFC5378 work" X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 14:11:31 -0000 --_000_94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCBMILEXCH1dsjds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, My first experience with the Idnits tool and 2 hours later, I am down to on= e warning message that I cannot figure out: -- The document has a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. Does it really need the disclaimer? I searched through my document for RFC5378 (5378, disclaimer keywords) and = cannot find this reference and I am banging my head against the wall. And I used draft-ietf-ippm-twamp-reflect-octets-09.txt document as a refere= nce for the boilerplate introductory material. Can anyone tell me if I am missing something obvious? Thanks, Barry Principal Member of Technical Staff JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research One Milestone Center Court Germantown, MD 20876 (W) 240-404-2227 (C) 301-325-7069 --_000_94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCBMILEXCH1dsjds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

My first experience with the Idnits tool and 2 hours lat= er, I am down to one warning message that I cannot figure out:

 

-- The document has a disclaimer for pre-RFC5378 work, b= ut was first

     submitted on or after 10 Novemb= er 2008.  Does it really need the

     disclaimer?

 

I searched through my document for RFC5378 (5378, discla= imer keywords) and cannot find this reference and I am banging my head against t= he wall.

 

And I used draft-ietf-ippm-twamp-reflect-octets-09.txt document as a reference for the boilerplate introductory material.

 

Can anyone tell me if I am missing something obvious?

 

Thanks,

Barry

 

Principal Member of Technical Staff

 

JDSU Communication Test (formerly Acterna)

Emerging Markets and Technology Research         =

One Milestone Center Court         = ;            &n= bsp;       

Germantown, MD 20876   &nbs= p;            &= nbsp;           &nbs= p;           

(W) 240-404-2227          &nb= sp;            =             &nb= sp;           

(C) 301-325-7069

 

--_000_94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCBMILEXCH1dsjds_-- From acmorton@att.com Sat Aug 28 07:19:31 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F00E3A68F9 for ; Sat, 28 Aug 2010 07:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.536 X-Spam-Level: X-Spam-Status: No, score=-103.536 tagged_above=-999 required=5 tests=[AWL=-1.612, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 EsWmozIPscJB for ; Sat, 28 Aug 2010 07:19:30 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 8292D3A6869 for ; Sat, 28 Aug 2010 07:19:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-15.tower-161.messagelabs.com!1283005200!29074696!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 6538 invoked from network); 28 Aug 2010 14:20:01 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Aug 2010 14:20:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7SEKHec013323 for ; Sat, 28 Aug 2010 10:20:17 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7SEKBZV013280 for ; Sat, 28 Aug 2010 10:20:11 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o7SEJtfm031506 for ; Sat, 28 Aug 2010 10:19:55 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o7SEJlrw031442 for ; Sat, 28 Aug 2010 10:19:48 -0400 Message-Id: <201008281419.o7SEJlrw031442@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-128-178.vpn.mwst.att.com[135.70.128.178](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100828141947gw100s4pfne>; Sat, 28 Aug 2010 14:19:47 +0000 X-Originating-IP: [135.70.128.178] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 28 Aug 2010 10:20:07 -0400 To: Barry Constantine , "ippm@ietf.org" From: Al Morton In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCB@MILEXCH1.ds.jds u.net> References: <94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCB@MILEXCH1.ds.jdsu.net> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [ippm] Idnits Tool - -- "disclaimer for pre-RFC5378 work" X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 14:19:31 -0000 At 10:02 AM 8/28/2010, Barry Constantine wrote:
...
Can anyone tell me if I am missing something obvious?

Try matching the boilerplate of
http://tools.ietf.org/id/draft-morton-ippm-rfc4148-obsolete-01.txt

which is new and does not have the pre-nov2008 disclaimer,
Al


From Barry.Constantine@jdsu.com Sat Aug 28 07:49:21 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD383A68F3 for ; Sat, 28 Aug 2010 07:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 A0Fx0e8DDo0e for ; Sat, 28 Aug 2010 07:49:20 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with SMTP id 07E933A67CC for ; Sat, 28 Aug 2010 07:49:19 -0700 (PDT) Received: from source ([209.36.247.245]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTHkiD/gjmzYUnPsF59X29ACy8bFnoO+7@postini.com; Sat, 28 Aug 2010 07:49:52 PDT Received: from milexhtca1.ds.jdsu.net ([10.75.2.121]) by Outbound2.jdsu.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Aug 2010 07:46:43 -0700 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca1.ds.jdsu.net ([::1]) with mapi; Sat, 28 Aug 2010 07:46:43 -0700 From: Barry Constantine To: Al Morton , "ippm@ietf.org" Date: Sat, 28 Aug 2010 07:46:41 -0700 Thread-Topic: [ippm] Idnits Tool - -- "disclaimer for pre-RFC5378 work" Thread-Index: ActGvB6yWHenXvNiRdiBl33yayot8wAA6Jkw Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCE@MILEXCH1.ds.jdsu.net> References: <94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCB@MILEXCH1.ds.jdsu.net> <201008281419.o7SEJlrw031442@alpd052.aldc.att.com> In-Reply-To: <201008281419.o7SEJlrw031442@alpd052.aldc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCEMILEXCH1dsjds_" MIME-Version: 1.0 X-OriginalArrivalTime: 28 Aug 2010 14:46:43.0781 (UTC) FILETIME=[D514F750:01CB46BF] Subject: Re: [ippm] Idnits Tool - -- "disclaimer for pre-RFC5378 work" X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 14:49:21 -0000 --_000_94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCEMILEXCH1dsjds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Al, That worked!! Thanks a bunch, Barry ________________________________ From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al = Morton Sent: Saturday, August 28, 2010 10:20 AM To: Barry Constantine; ippm@ietf.org Subject: Re: [ippm] Idnits Tool - -- "disclaimer for pre-RFC5378 work" At 10:02 AM 8/28/2010, Barry Constantine wrote: ... Can anyone tell me if I am missing something obvious? Try matching the boilerplate of http://tools.ietf.org/id/draft-morton-ippm-rfc4148-obsolete-01.txt which is new and does not have the pre-nov2008 disclaimer, Al --_000_94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCEMILEXCH1dsjds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Al,

 

That worked!!=

 

Thanks a bunch,

Barry=

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton
Sent: Saturday, August 28, 2= 010 10:20 AM
To: Barry Constantine; ippm@ietf.org
Subject: Re: [ippm] Idnits T= ool - -- "disclaimer for pre-RFC5378 work"

 

At 10:02 AM 8/28/2010, Barry Constantine wrote:

...
Can anyone tell me if I am missing something obvious?<= o:p>


Try matching the boilerplate of
http://tools.ietf.org/id/draft-morton-ippm-rfc4148-obsolet= e-01.txt

which is new and does not have the pre-nov2008 disclaimer,
Al

--_000_94DEE80C63F7D34F9DC9FE69E39436BE38B9DE4CCEMILEXCH1dsjds_-- From root@core3.amsl.com Mon Aug 30 05:00:02 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9BC8D3A69BA; Mon, 30 Aug 2010 05:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100830120002.9BC8D3A69BA@core3.amsl.com> Date: Mon, 30 Aug 2010 05:00:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 12:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : TCP Throughput Testing Methodology Author(s) : B. Constantine, et al. Filename : draft-ietf-ippm-tcp-throughput-tm-06.txt Pages : 20 Date : 2010-08-30 This memo describes a methodology for measuring sustained TCP throughput performance in an end-to-end managed network environment. This memo is intended to provide a practical approach to help users validate the TCP layer performance of a managed network, which should provide a better indication of end-user application level experience. In the methodology, various TCP and network parameters are identified that should be tested as part of the network verification at the TCP layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-tcp-throughput-tm-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-30044517.I-D@ietf.org> --NextPart-- From henk@ripe.net Tue Aug 31 01:23:03 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C443A6783 for ; Tue, 31 Aug 2010 01:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, 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 2c0tlRVYciIn for ; Tue, 31 Aug 2010 01:23:02 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 950A73A696D for ; Tue, 31 Aug 2010 01:23:01 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OqM7q-0008Nh-Ao for ippm@ietf.org; Tue, 31 Aug 2010 10:23:32 +0200 Received: from [193.0.21.124] (helo=geir.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OqM7p-0005dh-VW for ippm@ietf.org; Tue, 31 Aug 2010 10:23:26 +0200 Message-ID: <4C7CBBFD.1030402@ripe.net> Date: Tue, 31 Aug 2010 10:23:25 +0200 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5302b73a739b015a0679f67d934a88704 X-RIPE-Spam-Level: -- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5302b73a739b015a0679f67d934a88704 Subject: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 08:23:03 -0000 IPPM Group, This is a Working Group Last Call for the draft: TCP Throughput Testing Methodology draft-ietf-ippm-tcp-throughput-tm-06.txt This version of the draft addresses all issues brought up on the list and at the Maastricht meeting. It also fixes a number of ID-nits. The authors believe that no further work on the draft is needed. Note that there are a few spelling mistakes in the draft, these will be fixed when including any other LC comments. Please review the draft and raise any issues by Monday, September 20, 9:00 UTC. An URL for the draft is: http://www.ietf.org/id/draft-ietf-ippm-tcp-throughput-tm-06.txt Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From Ruediger.Geib@telekom.de Tue Aug 31 02:50:22 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E988E3A63D3 for ; Tue, 31 Aug 2010 02:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 rGs21vZqiH1b for ; Tue, 31 Aug 2010 02:50:21 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 6DA453A6A36 for ; Tue, 31 Aug 2010 02:50:09 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 31 Aug 2010 11:50:33 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Aug 2010 11:50:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Aug 2010 11:50:31 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5049C88F8@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <4C7CBBFD.1030402@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt thread-index: ActI5hDf36OqIEzkTBesOmMMqCSfmwABnUUg References: <4C7CBBFD.1030402@ripe.net> From: To: X-OriginalArrivalTime: 31 Aug 2010 09:50:33.0032 (UTC) FILETIME=[F4211C80:01CB48F1] Cc: ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 09:50:23 -0000 Henk, If time allows, I'll send more comments. If not, here's my view: Change the document title to "Framework for a TCP Throughput Testing Methodology" Arguments: The document as is does not contain any Type P Specification. See = definitions in "2.2 Metrics for TCP Throughput Tests" The document only gives guidance on how to measure RTT, bandwidth and = some auiliary=20 parameters as RTT jitter (it does not specify how to measure these or = refer to=20 specifications of related measurements). I don't recall having seen = references to=20 prior related work of IPPM (last read version was draft -05).=20 All in all, I doubt that two implementors are able to measure compatible = metrics=20 based on the documents definitions as they are by now. Even if it is = only=20 "Informational" I'd prefer classification as a "framework". Many or most = other=20 informational documents produced by IPPM contain Type P specifications = as soon as=20 metrics are to be established. Regards, Ruediger -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of = Henk Uijterwaal Sent: Tuesday, August 31, 2010 10:23 AM To: IETF IPPM WG Subject: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt IPPM Group, This is a Working Group Last Call for the draft: TCP Throughput Testing Methodology draft-ietf-ippm-tcp-throughput-tm-06.txt This version of the draft addresses all issues brought up on the list = and at the Maastricht meeting. It also fixes a number of ID-nits. The = authors believe that no further work on the draft is needed. Note that there = are a few spelling mistakes in the draft, these will be fixed when including any other LC comments. Please review the draft and raise any issues by Monday, September 20, 9:00 UTC. An URL for the draft is: http://www.ietf.org/id/draft-ietf-ippm-tcp-throughput-tm-06.txt Matt & Henk --=20 -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- I confirm today what I denied yesterday. Anonymous = Politician. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From eelco.bottenheft@tele2.com Tue Aug 31 13:04:16 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4D33A6ABE for ; Tue, 31 Aug 2010 13:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 zv8xCWlyctUs for ; Tue, 31 Aug 2010 13:04:15 -0700 (PDT) Received: from gw1-in.tele2.se (gw1-in.tele2.se [193.12.60.45]) by core3.amsl.com (Postfix) with ESMTP id AD6673A6ABC for ; Tue, 31 Aug 2010 13:04:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,300,1280700000"; d="scan'208";a="23897548" Received: from unknown (HELO T2eiffel.t2srv.corp.tele2.com) ([172.16.241.7]) by gw1-out.tele2.se with ESMTP; 31 Aug 2010 22:04:43 +0200 Auto-Submitted: auto-generated From: Eelco Bottenheft To: ippm@ietf.org Message-ID: Date: Tue, 31 Aug 2010 22:04:43 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [ippm] Eelco Bottenheft is out of the office. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 20:04:16 -0000 I will be out of the office starting 31/08/2010 and will not return until 01/09/2010. During this period I will not read my email. I will respond to your mail when I return. regards Eelco Bottenheft