From tiziano.ionta@telecomitalia.it Tue Mar 8 00:04:26 2011 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 A5F083A68EA for ; Tue, 8 Mar 2011 00:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 lZp0bojgQVfF for ; Tue, 8 Mar 2011 00:04:25 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 6044D3A68AB for ; Tue, 8 Mar 2011 00:04:25 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 8 Mar 2011 09:05:37 +0100 Received: from GRFMBX702BA020.griffon.local ([10.188.101.12]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Tue, 8 Mar 2011 09:05:37 +0100 From: Ionta Tiziano To: IETF IPPM WG Importance: high X-Priority: 1 Date: Tue, 8 Mar 2011 09:05:36 +0100 Thread-Topic: [ippm] draft-morton-ippm-rt-loss as a WG document Thread-Index: AcvB922kBGUUn3MWTqiWoQcRKXXO3Qbb+QXQ Message-ID: <885CC0380486234DBF486FA72FE9BE3BA52450E3BB@GRFMBX702BA020.griffon.local> References: <4D47DA81.9020404@ripe.net> In-Reply-To: <4D47DA81.9020404@ripe.net> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Henk Uijterwaal' , "ippm@ietf.org" Subject: [ippm] R: draft-morton-ippm-rt-loss as a WG document 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, 08 Mar 2011 08:04:26 -0000 Even for me it makes sense to adopt this document as a WG document. Best regards. Tiziano Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From steve.baillargeon@ericsson.com Tue Mar 8 04:47:33 2011 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 8C1253A67A4 for ; Tue, 8 Mar 2011 04:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 ekU-xsIeNA1q for ; Tue, 8 Mar 2011 04:47:32 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id A538B3A63D2 for ; Tue, 8 Mar 2011 04:47:32 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p28Cmkss001605 for ; Tue, 8 Mar 2011 06:48:47 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 8 Mar 2011 07:48:40 -0500 From: Steve Baillargeon To: "ippm@ietf.org" Date: Tue, 8 Mar 2011 07:48:38 -0500 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets-01 Thread-Index: AcvdjyV04svmnWrbQ9eviS9V3pd0ug== Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0966BDB15B@EUSAACMS0701.eamcs.ericsson.se> 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_4383945B8C24AA4FBC33555BB7B829EF0966BDB15BEUSAACMS0701e_" MIME-Version: 1.0 Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets-01 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, 08 Mar 2011 12:47:33 -0000 --_000_4383945B8C24AA4FBC33555BB7B829EF0966BDB15BEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi IPPM Draft 01 has been posted and the following revisions have been incorporated= : 1. Replaced TLC by TSC across the entire document 2. Updated the Abstract 3. Simplified and improved the Introduction (section 1) 4. Updated the Scope and Purpose (section 2) with the new TWAMP mode 5. Updated the TWAMP Control Extensions (section 5) with the new TWAMP mode 6. Completely removed sub-section 5.1, 5.2 and 5.3 7. Updated and simplified the Sender Behavior (section 6.1) and Session-Sen= der Packet Format (section 6.1.2) based on the TWAMP mode and flag bits 8. Updated and simplified the Reflector Behavior (section 6.2) based on the= TWAMP mode and flag bits and added consideration for duplicate packets 9. Updated the security considerations (section 7) 10. Added new section 8 for IANA Considerations for Valued-Added Octets Ver= sion 1 mode 11. Updated the informative reference for Y.1540 Regards Steve Baillargeon --_000_4383945B8C24AA4FBC33555BB7B829EF0966BDB15BEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi IPPM
 
Draft 01 has been posted and the following revisions have been incorpo= rated:
 
1. Replaced TLC by TSC across the entire document
2. Updated the Abstract
3. Simplified and improved the Introduction (section 1)
4. Updated the Scope and Purpose (section 2) with the new TWAMP mode
5. Updated the TWAMP Control Extensions (section 5) with the new TWAMP= mode
6. Completely removed sub-section 5.1, 5.2 and 5.3
7. Updated and simplified the Sender Behavior (section 6.1) and Sessio= n-Sender Packet Format (section 6.1.2) based on the TWAMP mode and flag bit= s
8. Updated and simplified the Reflector Behavior (section 6.2) based o= n the TWAMP mode and flag bits and added consideration for duplicate packet= s
9. Updated the security considerations (section 7)
10. Added new section 8 for IANA Considerations for Valued-Added Octet= s Version 1 mode
11. Updated the informative reference for Y.1540
 
 
Regards
Steve Baillargeon
 
 
 
 
 --_000_4383945B8C24AA4FBC33555BB7B829EF0966BDB15BEUSAACMS0701e_-- From henk@uijterwaal.nl Fri Mar 11 05:04:57 2011 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 5F9CC3A6952 for ; Fri, 11 Mar 2011 05:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Ahi3jxxkf2c2 for ; Fri, 11 Mar 2011 05:04:56 -0800 (PST) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by core3.amsl.com (Postfix) with ESMTP id 1945E3A6BE5 for ; Fri, 11 Mar 2011 05:04:55 -0800 (PST) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id p2BD6Ct3061206 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2011 14:06:13 +0100 (CET) (envelope-from henk@uijterwaal.nl) Message-ID: <4D7A05EF.4070301@uijterwaal.nl> Date: Fri, 11 Mar 2011 12:22:23 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Matthew J Zekauskas , IETF IPPM WG References: <47B13C3F.1060305@ripe.net> In-Reply-To: <47B13C3F.1060305@ripe.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Fri, 11 Mar 2011 05:14:30 -0800 Subject: [ippm] New email address 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, 11 Mar 2011 13:04:57 -0000 Hi Matt and the rest of the group, Please start using my new email address: henk@uijterwaal.nl. 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 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From Internet-Drafts@ietf.org Mon Mar 14 14:15:04 2011 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 0011A3A6AA5; Mon, 14 Mar 2011 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 fIv+Bn9SgOad; Mon, 14 Mar 2011 14:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382643A6BB2; Mon, 14 Mar 2011 14:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314211502.16840.17694.idtracker@localhost> Date: Mon, 14 Mar 2011 14:15:02 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-reporting-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, 14 Mar 2011 21:15:04 -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 : Reporting IP Performance Metrics to Users Author(s) : S. Shalunov, M. Swany Filename : draft-ietf-ippm-reporting-06.txt Pages : 42 Date : 2011-03-14 The aim of this document is to define a small set of metrics that are robust, easy to understand, orthogonal, relevant, and easy to compute. The IPPM WG has defined a large number of richly parameterized metrics because network measurement has many purposes. Often, the ultimate purpose is to report a concise set of metrics describing a network's current state to an end user. It is for this purpose that the present set of metrics is defined, and the document is principally concerned with "short-term" reporting considerations (a few seconds or minutes as opposed to days, months or years.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-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-reporting-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14140639.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 15:15:06 2011 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 9BC6D3A6F55; Mon, 14 Mar 2011 15:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 kP6Dm5wFIi6D; Mon, 14 Mar 2011 15:15:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1120A3A6E2D; Mon, 14 Mar 2011 15:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314221503.9641.44794.idtracker@localhost> Date: Mon, 14 Mar 2011 15:15:03 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-metrictest-02.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, 14 Mar 2011 22:15:06 -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 : IPPM standard advancement testing Author(s) : R. Geib, et al. Filename : draft-ietf-ippm-metrictest-02.txt Pages : 39 Date : 2011-03-14 This document specifies tests to determine if multiple independent instantiations of a performance metric RFC have implemented the specifications in the same way. This is the performance metric equivalent of interoperability, required to advance RFCs along the standards track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using state of the art statistical methods. The goal is an evaluation of the metric RFC itself, whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF standards track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrictest-02.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-metrictest-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14151350.I-D@ietf.org> --NextPart-- From henk.uijterwaal@gmail.com Tue Mar 15 08:50:00 2011 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 90C983A6E11 for ; Tue, 15 Mar 2011 08:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 yNQZ-PoqDcfu for ; Tue, 15 Mar 2011 08:49:59 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 7E4613A6D0F for ; Tue, 15 Mar 2011 08:49:59 -0700 (PDT) Received: by pve39 with SMTP id 39so177127pve.31 for ; Tue, 15 Mar 2011 08:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Nya+umiKEDxlvpSWghwjI1bpP1xQJPRpkysopi+7Xsk=; b=on8sz1j1k2pp4pCxr5aiNXSNQkbVNPd2YxBL5oqPExbZSpjrHz/HDouCb5MRsCkGel LmHEorijrNzgl6uUKMWnzukJ6Y+K5/UQtjAbR9t9w4OlvQ840n1sipQGoMKg7vTmOhKF Aify7h7YsiDEcVPcUXwziaxDeC9riuHfJg6k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=UkHfWzGHL+5qhdSW4w4YfjUYfhBbYEADIjsarbqELHecYVon26cUkgs9zpDQJl5jD0 m5Vajjv8T2L6tOSbu1QNT02AZ1A9qC3CSE8JhSIhavom79yFoJyZOQrjSiuhzVRo/MvK w6Jblb0Sw224d1tMuD2xreaL7AleRVi1Ymnho= Received: by 10.142.135.21 with SMTP id i21mr11831716wfd.418.1300204284635; Tue, 15 Mar 2011 08:51:24 -0700 (PDT) Received: from geir.local ([130.129.254.2]) by mx.google.com with ESMTPS id o11sm7207616wfa.12.2011.03.15.08.51.23 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 08:51:24 -0700 (PDT) Message-ID: <4D7F8AFA.7030405@gmail.com> Date: Tue, 15 Mar 2011 16:51:22 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ippm] Agenda For Prague 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, 15 Mar 2011 15:50:00 -0000 IPPM Group, Please find below the first draft agenda for Prague. Comments are welcome. If you are presenting, please send me a copy of your slides before the meeting. Try to focus on issues that need discussion, rather than reviews of things presented before. Also, make sure that there is sufficient time left for discussion in your slot. Henk - - - - AGENDA IPPM Meeting @ IETF80 ============================ Thursday, 17:40-19:40. Draft 1. 15/3/2011 0. 5' Administrativia (Minutes, Scribe, Blue Sheet, Note Well, ...) 1. 5' Status of drafts not discussed today Ongoing work ============ 2. 10' Metrics on the standard track (Ruediger, Al) draft-ietf-ippm-metricstest-02 3. 10' Round Trip Loss (Al) draft-ietf-ippm-rt-loss-00 4. 10' Loss Episode Metrics (Al) draft-ietf-ippm-loss-episode-metrics-01 Possible new work ================= 5. 20' TWAMP Value-Added Octets (Steve Baillargeon/Andreas Johnsson) draft-baillargeon-ippm-twamp-value-added-octets-01 6. 20' OWAMP Issues/Yaakov Stein 7. 20' RFC5136 issues (Xiangsong Cui) draft-cui-ippm-rfc5136bis-00 8. AOB -- ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From steve.baillargeon@ericsson.com Mon Mar 21 05:37:20 2011 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 09A0028C12E for ; Mon, 21 Mar 2011 05:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, 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 NOoSpG79GEW0 for ; Mon, 21 Mar 2011 05:37:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 075BD28C12C for ; Mon, 21 Mar 2011 05:37:18 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2LCcgVb011052; Mon, 21 Mar 2011 07:38:50 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.192]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 21 Mar 2011 08:38:47 -0400 From: Steve Baillargeon To: Al Morton Date: Mon, 21 Mar 2011 08:38:46 -0400 Thread-Topic: [ippm] Feedback on Round-Trip Loss Thread-Index: AcvnxOveDjziin/6Qh6Yy8eMPijx5A== Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0969CCF2FE@EUSAACMS0701.eamcs.ericsson.se> 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_4383945B8C24AA4FBC33555BB7B829EF0969CCF2FEEUSAACMS0701e_" MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: [ippm] Feedback on Round-Trip Loss 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, 21 Mar 2011 12:37:20 -0000 --_000_4383945B8C24AA4FBC33555BB7B829EF0969CCF2FEEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Al I have two suggestions/comments about draft-ietf-ippm-rt-loss-00 draft. 1) In my opinion, the information from section 7 and section 8 is applicabl= e for all metrics measured with a "reflected measurement architecture" like= TWAMP. Is it possible to move the text from section 7 and section 8 in the TWAMP R= FC? This will avoid the need to repeat the same considerations and limitations = in different documents. For instance, you could move the text and associated structure from section= 8 into the security considerations of RFC 5357 and make a reference to it = in the Round-trip Loss. You could also move the text from section 7 into a new section in RFC 5357 = entitled "Reporting Considerations". 2) I think it is a good time to clarify the terminology or naming conventio= n associated with the Scr->Dst path and Dst->Scr path. You are also using r= eturn path to identify the Dst->Scr path. We prefer to use the terms forwar= d and reverse paths as described in draft-baillargeon-ippm-twamp-value-adde= d-octets. I am open to suggestions as long as we try to be consistent. Regards Steve Baillargeon --_000_4383945B8C24AA4FBC33555BB7B829EF0969CCF2FEEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Al
I have two suggestions/comments about draft-ietf-ippm-rt-loss-00 draft= .
 
1) In my opinion, the information from section 7 and section 8 is appl= icable for all metrics measured with a "reflected measurement architec= ture" like TWAMP.
Is it possible to move the text from section 7 and section 8 in the TW= AMP RFC?
This will avoid the need to repeat the same considerations and limitat= ions in different documents.
For instance, you could move the text and associated structure from se= ction 8 into the security considerations of RFC 5357 and make a reference t= o it in the Round-trip Loss.
You could also move the text from section 7 into a new section in RFC = 5357 entitled "Reporting Considerations".
 
2) I think it is a good time to clarify the terminology or naming conv= ention associated with the Scr->Dst path and Dst->Scr path. You are a= lso using return path to identify the Dst->Scr path. We prefer to use th= e terms forward and reverse paths as described in draft-baillargeon-ippm-twamp-value-added-octets. I am open to suggestion= s as long as we try to be consistent.
 
Regards
Steve Baillargeon
 
 
 
 
 
 --_000_4383945B8C24AA4FBC33555BB7B829EF0969CCF2FEEUSAACMS0701e_-- From matt@internet2.edu Mon Mar 28 04:10:20 2011 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 3DF033A67AB for ; Mon, 28 Mar 2011 04:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, 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 EAjhg0HTi3nz for ; Mon, 28 Mar 2011 04:10:19 -0700 (PDT) Received: from int-mailstore01.merit.edu (int-mailstore01.merit.edu [207.75.116.232]) by core3.amsl.com (Postfix) with ESMTP id 50F543A6452 for ; Mon, 28 Mar 2011 04:10:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-mailstore01.merit.edu (Postfix) with ESMTP id 8CBC33057380; Mon, 28 Mar 2011 07:11:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at int-mailstore01.merit.edu Received: from int-mailstore01.merit.edu ([127.0.0.1]) by localhost (int-mailstore01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRpHCpbrUbnD; Mon, 28 Mar 2011 07:11:54 -0400 (EDT) Received: from dhcp-473f.meeting.ietf.org (dhcp-473f.meeting.ietf.org [130.129.71.63]) by int-mailstore01.merit.edu (Postfix) with ESMTPSA id 2249B305733E; Mon, 28 Mar 2011 07:11:54 -0400 (EDT) Message-ID: <4D906CF2.3010007@internet2.edu> Date: Mon, 28 Mar 2011 07:11:46 -0400 From: Matthew J Zekauskas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ippm@ietf.org References: <4D7F8AFA.7030405@gmail.com> In-Reply-To: <4D7F8AFA.7030405@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Matt Zekauskas Subject: [ippm] Presenters, please send slides (Re: Agenda For Prague) 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, 28 Mar 2011 11:10:20 -0000 Please send slides in advance if you will be using them to both Henk and myself (note Henk's new address). A slightly revised agenda is appended. Comments always welcome. --Matt On 3/15/11 11:51 AM, Henk Uijterwaal wrote: > > If you are presenting, please send me a copy of your slides before the > meeting. Try to focus on issues that need discussion, rather than > reviews of things presented before. Also, make sure that there is > sufficient time left for discussion in your slot. -=-=-=- AGENDA IPPM Meeting @ IETF80 ============================ Thursday, 17:40-19:40. Draft 3. 27/3/2011 0. 5' Administrativia (Minutes, Scribe, Blue Sheet, Note Well, ...) 1. 5' Status of drafts not discussed today Ongoing work ============ 2. 20' Metrics on the standards track (Ruediger, Al) 2a. 10' IPPM standard advancement testing draft-ietf-ippm-metrictest-02 2b 10' Test Plan and Results for Advancing RFC 2679 on the Standards Track draft-morton-ippm-testplan-rfc2679-00 3. 10' Round Trip Loss (Al) draft-ietf-ippm-rt-loss-00 4. 10' Loss Episode Metrics (Al) draft-ietf-ippm-loss-episode-metrics-01 Possible new work ================= 5. 20' TWAMP Value-Added Octets (Steve Baillargeon/Andreas Johnsson) draft-baillargeon-ippm-twamp-value-added-octets-01 6. 20' OWAMP and TWAMP Measurement Issues/Topics (Al, for Yaakov and Al) 7. 20' RFC5136 issues (Xiangsong Cui) draft-cui-ippm-rfc5136bis-00 8. AOB From acmorton@att.com Mon Mar 28 08:59:42 2011 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 73D693A6A59 for ; Mon, 28 Mar 2011 08:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.938 X-Spam-Level: X-Spam-Status: No, score=-104.938 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 neLGCVmXjSdt for ; Mon, 28 Mar 2011 08:59:41 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 6713B3A6A2F for ; Mon, 28 Mar 2011 08:59:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1301328078!8220623!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 20617 invoked from network); 28 Mar 2011 16:01:18 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Mar 2011 16:01:18 -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 p2SG1fkN021895 for ; Mon, 28 Mar 2011 12:01:41 -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 p2SG1aX3021778 for ; Mon, 28 Mar 2011 12:01:36 -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 p2SG1Bm3003956 for ; Mon, 28 Mar 2011 12:01:11 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2SG13pe003411 for ; Mon, 28 Mar 2011 12:01:04 -0400 Message-Id: <201103281601.p2SG13pe003411@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-211-237.vpn.east.att.com[135.70.211.237](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110328160102gw100e4laqe>; Mon, 28 Mar 2011 16:01:03 +0000 X-Originating-IP: [135.70.211.237] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 12:01:36 -0400 To: Steve Baillargeon From: Al Morton In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0969CCF2FE@EUSAACMS0701.ea mcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0969CCF2FE@EUSAACMS0701.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Cc: "ippm@ietf.org" Subject: Re: [ippm] Feedback on Round-Trip Loss 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, 28 Mar 2011 15:59:42 -0000 Hi Steve,

Thanks for your comments.
Belated replies in-line,
Al

At 08:38 AM 3/21/2011, Steve Baillargeon wrote:

Hi Al
I have two suggestions/comments about draft-ietf-ippm-rt-loss-00 draft.
 
1) In my opinion, the information from section 7 and section 8 is applicable for all metrics measured with a "reflected measurement architecture" like TWAMP.
Is it possible to move the text from section 7 and section 8 in the TWAMP RFC?
This will avoid the need to repeat the same considerations and limitations in different documents.

There's no need to repeat the text while there is a reference mechanism
that works, and with HTML draft presentation IETF's references are
better than most (even at the Internet-Draft stage of development).

Also, there are several forms of TWAMP-like measurements, so these
considerations are by no means TWAMP-unique. Of course, section 8
is the Security Considerations, and therefore required to appear
in this draft.

For instance, you could move the text and associated structure from section 8 into the security considerations of RFC 5357 and make a reference to it in the Round-trip Loss.
You could also move the text from section 7 into a new section in RFC 5357 entitled "Reporting Considerations".

We have effectively covered method and reporting topics with the
metrics RFCs in the past, and that organization still makes sense to me.

 
2) I think it is a good time to clarify the terminology or naming convention associated with the Scr->Dst path and Dst->Scr path. You are also using return path to identify the Dst->Scr path. We prefer to use the terms forward and reverse paths as described in draft-baillargeon-ippm-twamp-value-added-octets. I am open to suggestions as long as we try to be consistent.

We need to be consistent with the existing RFCs, such as
RFC 2681, the Round Trip Delay metric, which says in Section 1.1:

   The measurement of round-trip delay instead of one-way delay has
   several weaknesses, summarized here:

   +  The Internet path from a source to a destination may differ from
      the path from the destination back to the source ("asymmetric
      paths"), such that different sequences of routers are used for the
      forward and reverse paths.  Therefore round-trip measurements
      actually measure the performance of two distinct paths together.

Src and Dst are used heavily throughout RFC 2681, but "return" is only used
once (to refer to a "return packet").

I'll do an intelligent  "1,$ s/return/reverse/g",
and six instances will change in -01.






From henk@uijterwaal.nl Wed Mar 30 01:06:26 2011 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 17F343A6B23; Wed, 30 Mar 2011 01:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 FRt39tfhN3JB; Wed, 30 Mar 2011 01:06:25 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by core3.amsl.com (Postfix) with ESMTP id D3D563A6B0E; Wed, 30 Mar 2011 01:06:24 -0700 (PDT) Received: from dhcp-1653.meeting.ietf.org (dhcp-1653.meeting.ietf.org [130.129.22.83]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id p2U882Zm024977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 30 Mar 2011 10:08:02 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4D92E4E1.7000308@uijterwaal.nl> Date: Wed, 30 Mar 2011 10:08:01 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Henk Uijterwaal References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> In-Reply-To: <4D677893.2050200@ripe.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: tcpm@ietf.org, IETF IPPM WG 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: Wed, 30 Mar 2011 08:06:26 -0000 On 25/02/2011 10:38, Henk Uijterwaal wrote: > IPPM WG, > > This is a Working Group Last Call for the draft: > > TCP Throughput Testing Methodology > draft-ietf-ippm-tcp-throughput-tm-12.txt No issues were raised and the WGLC is closed. We'll move the draft forward in the next week or so. Henk > > The -07 version of this document has been submitted to IESG last October. Since > then, there have been several reviews and a lot of text has been changed. > Before proceeding, we think it is good that the WG looks at this document again. > The TCPM WG is cc'd as some members of this group have been > involved in the reviews. > > Please review the draft and raise any issues by Monday, March 28, 2011, 8:00 > UTC. An URL for the draft is: > > http://www.ietf.org/id/draft-ietf-ippm-tcp-throughput-tm-12.txt > > (The date is intentional, if there are issues that require face-2-face > discussion, we can do this in Prague). > > Matt & Henk > > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From jishac@nasa.gov Wed Mar 30 13:31:14 2011 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 958F43A69AB for ; Wed, 30 Mar 2011 13:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 smcCFITDyZpL for ; Wed, 30 Mar 2011 13:31:13 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id B29B63A68F4 for ; Wed, 30 Mar 2011 13:31:12 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id BA38C182198 for ; Wed, 30 Mar 2011 15:32:50 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt03.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id p2UKWoLj027836 for ; Wed, 30 Mar 2011 15:32:50 -0500 Received: from mail-yx0-f172.google.com (209.85.213.172) by smtp01.ndc.nasa.gov (198.117.1.160) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 30 Mar 2011 15:32:50 -0500 Received: by yxk30 with SMTP id 30so771713yxk.31 for ; Wed, 30 Mar 2011 13:32:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.133.4 with SMTP id f4mr1561403ict.167.1301517169338; Wed, 30 Mar 2011 13:32:49 -0700 (PDT) Received: by 10.231.205.206 with HTTP; Wed, 30 Mar 2011 13:32:49 -0700 (PDT) Date: Wed, 30 Mar 2011 16:32:49 -0400 Message-ID: From: Joseph Ishac To: IETF IPPM WG Content-Type: multipart/alternative; boundary="90e6ba6e85328c2824049fb914ba" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-30_09:2011-03-30, 2011-03-30, 1970-01-01 signatures=0 Cc: "Chimento, Philip F." Subject: [ippm] Impact of hosts on network capacity and RFC 5136 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, 30 Mar 2011 20:31:14 -0000 --90e6ba6e85328c2824049fb914ba Content-Type: text/plain; charset="ISO-8859-1" Folks, There has been some recent debate regarding RFC 5136. Specifically if the impact of network hosts are accounted for in the definitions of network capacity. Phil and I have been discussing this off-list and by phone. We believe that the following paragraphs from the RFC clearly highlight our intent to indeed capture such effects as they all relate to the role of endpoints as only a portion in determining the capacity of any "link". End of Section 1: Aside from questions of coding efficiency, there are issues of how > access to the channel is controlled, which also may affect the > capacity. For example, a multiple-access medium with collision > detection, avoidance, and recovery mechanisms has a varying capacity > from the point of view of the users. This varying capacity depends > upon the total number of users contending for the medium, how busy > the users are, and bounds resulting from the mechanisms themselves. > RF channels may also vary in capacity, depending on range, > environmental conditions, mobility, shadowing, etc. The important points to derive from this discussion are these: First, > capacity is only meaningful when defined relative to a given protocol > layer in the network. It is meaningless to speak of "link" capacity > without qualifying exactly what is meant. Second, capacity is not > necessarily fixed, and consequently, a single measure of capacity at > any layer may in fact provide a skewed picture (either optimistic or > pessimistic) of what is actually available. Section 2.3.1.2 The definitions in this document refer to "Type P" packets to > designate a particular type of flow or sets of flows. As defined in > RFC 2330, Section 13, "Type P" is a placeholder for what may be an > explicit specification of the packet flows referenced by the metric, > or it may be a very loose specification encompassing aggregates. We > use the "Type P" designation in these definitions in order to > emphasize two things: First, that the value of the capacity > measurement depends on the types of flows referenced in the > definition. This is because networks may treat packets differently > (in terms of queuing and scheduling) based on their markings and > classification. Networks may also arbitrarily decide to flow-balance > based on the packet type or flow type and thereby affect capacity > measurements. Second, the measurement of capacity depends not only > on the type of the reference packets, but also on the types of the > packets in the "population" with which the flows of interest share > the links in the path. Section 2.3.2. Definition: IP-type-P Link Capacity As mentioned earlier, this definition is affected by many factors > that may change over time. *For example, a device's ability to > process and forward IP packets for a particular link may have varying > effect on capacity*, depending on the amount or type of traffic being > processed. To summarize RFC 5136, we define nodes as hosts, routers, Ethernet switches, or any other device and a link as a connection between two of these network devices or nodes. 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. Furthermore, we define a link L as a special case where the path length is one. Meaning: - The definition of nodes have been extended from RFC 2330 to include any devices which can impact IP datagrams - A link is a connection between two network devices or nodes - The definition of a Path (P) is a sequence of (n+1) nodes and (n) links for which a Source resides at N(1) and a Destination at N(n+1) - The definition of a Link (L) is the case where n=1 above. Thus it includes two devices and one link Thus, the usage of a link L in this document refers to two nodes and the link between those devices and not simply the link between the nodes. When we later define the capacity of L, it incorporates the complexities of both the devices and the link between them and does not simply mean the "capacity of the physical (virtual) link" that exists between those two nodes. Thanks! -Joseph and Phil --90e6ba6e85328c2824049fb914ba Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Folks,

There has been some recent debate regarding RFC 5136. =A0Spec= ifically if the impact of network hosts are accounted for in the definition= s of network capacity.

Phil and I have been discussing this off-list= and by phone. We believe that the following paragraphs from the RFC clearl= y highlight our intent to indeed capture such effects as they all relate to= the role of endpoints as only a portion in determining the capacity of any= "link".

End of Section 1:

=A0 Aside from questions of coding efficiency, there are issues of how
= =A0 access to the channel is controlled, which also may affect the
=A0= capacity. =A0For example, a multiple-access medium with collision
=A0 = detection, avoidance, and recovery mechanisms has a varying capacity
=A0 from the point of view of the users. =A0This varying capacity depends<= br> =A0 upon the total number of users contending for the medium, how busy<= br> =A0 the users are, and bounds resulting from the mechanisms themselves.=
=A0 RF channels may also vary in capacity, depending on range,
=A0 env= ironmental conditions, mobility, shadowing, etc.

=A0 The important points to derive from this discussion are these: First,<= br> =A0 capacity is only meaningful when defined relative to a given protoc= ol
=A0 layer in the network. =A0It is meaningless to speak of "lin= k" capacity
=A0 without qualifying exactly what is meant. =A0Second, capacity is not =A0 necessarily fixed, and consequently, a single measure of capacity at=
=A0 any layer may in fact provide a skewed picture (either optimistic = or
=A0 pessimistic) of what is actually available.
Section 2.= 3.1.2

=A0 The definitions in this document refer to "Type P" packets t= o
=A0 designate a particular type of flow or sets of flows. =A0As defin= ed in
=A0 RFC 2330, Section 13, "Type P" is a placeholder for= what may be an
=A0 explicit specification of the packet flows referenced by the metric, =A0 or it may be a very loose specification encompassing aggregates. =A0= We
=A0 use the "Type P" designation in these definitions in o= rder to
=A0 emphasize two things: First, that the value of the capacity
=A0 me= asurement depends on the types of flows referenced in the
=A0 definitio= n. =A0This is because networks may treat packets differently
=A0 (in te= rms of queuing and scheduling) based on their markings and
=A0 classification. =A0Networks may also arbitrarily decide to flow-balanc= e
=A0 based on the packet type or flow type and thereby affect capacity=
=A0 measurements. =A0Second, the measurement of capacity depends not o= nly
=A0 on the type of the reference packets, but also on the types of the
= =A0 packets in the "population" with which the flows of interest= share
=A0 the links in the path.

Section 2.3.2. =A0Def= inition: IP-type-P Link Capacity

=A0 As mentioned earlier, this definition is affected by many factors
= =A0 that may change over time. =A0For example, a device's ability to=
=A0 process and forward IP packets for a particular link may have vary= ing
=A0 effect on capacity, depending on the amount or type of traffic bei= ng
=A0 processed.


T= o summarize RFC 5136, we define nodes as hosts, routers, Ethernet switches,= or any other=A0device and a=A0link as a connection between two of these ne= twork=A0devices or nodes. =A0We then define a path P of length n as a serie= s of=A0links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ...,= =A0Nn+1). =A0A source S and destination D reside at N1 and Nn+1,=A0respecti= vely. =A0Furthermore, we define a link L as a special case=A0where the path= length is one.

Meaning:
  • The definition of node= s have been extended from RFC 2330 to include=A0any devices which can impac= t IP datagrams
  • A link is a connection between two network devices o= r nodes
  • The definition of a Path (P) is a sequence of (n+1) nodes and (n) links= =A0for which a Source resides at N(1) and a Destination at N(n+1)
  • T= he definition of a Link (L) is the case where n=3D1 above. =A0Thus it=A0inc= ludes two devices and one link
Thus, the usage of a link L in this document refers to two = nodes and the=A0link between those devices and not simply the link between = the nodes.=A0When we later define the capacity of L, it incorporates the co= mplexities=A0of both the devices and the link between them and does not sim= ply mean=A0the "capacity of the physical (virtual) link" that exi= sts between those two nodes.

Thanks!

-Joseph and Phil
--90e6ba6e85328c2824049fb914ba-- From steve.baillargeon@ericsson.com Wed Mar 30 23:47:47 2011 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 175D028C24D for ; Wed, 30 Mar 2011 23:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=1.000, 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 zHe2gEqma7rF for ; Wed, 30 Mar 2011 23:47:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 67CDF28C251 for ; Wed, 30 Mar 2011 23:47:45 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2V6nOQa024524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Mar 2011 01:49:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 31 Mar 2011 02:49:23 -0400 From: Steve Baillargeon To: Joseph Ishac , IETF IPPM WG Date: Thu, 31 Mar 2011 02:49:21 -0400 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: AcvvGajh5+kInOZpST6+Lv3qimySUgAVUDgQ Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B348@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: 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_4383945B8C24AA4FBC33555BB7B829EF0DEC28B348EUSAACMS0701e_" MIME-Version: 1.0 Cc: "Chimento, Philip F." Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 06:47:47 -0000 --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC28B348EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joseph I agree. In my opinion, the current definitions in RFC5136 are covering all cases. I don't see the need to breakdown the network entities further. All operators that I know refers to link and link capacity as you have defi= ned them. -Steve ________________________________ From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Jos= eph Ishac Sent: March-30-11 4:33 PM To: IETF IPPM WG Cc: Chimento, Philip F. Subject: [ippm] Impact of hosts on network capacity and RFC 5136 Folks, There has been some recent debate regarding RFC 5136. Specifically if the = impact of network hosts are accounted for in the definitions of network cap= acity. Phil and I have been discussing this off-list and by phone. We believe that= the following paragraphs from the RFC clearly highlight our intent to inde= ed capture such effects as they all relate to the role of endpoints as only= a portion in determining the capacity of any "link". End of Section 1: Aside from questions of coding efficiency, there are issues of how access to the channel is controlled, which also may affect the capacity. For example, a multiple-access medium with collision detection, avoidance, and recovery mechanisms has a varying capacity from the point of view of the users. This varying capacity depends upon the total number of users contending for the medium, how busy the users are, and bounds resulting from the mechanisms themselves. RF channels may also vary in capacity, depending on range, environmental conditions, mobility, shadowing, etc. The important points to derive from this discussion are these: First, capacity is only meaningful when defined relative to a given protocol layer in the network. It is meaningless to speak of "link" capacity without qualifying exactly what is meant. Second, capacity is not necessarily fixed, and consequently, a single measure of capacity at any layer may in fact provide a skewed picture (either optimistic or pessimistic) of what is actually available. Section 2.3.1.2 The definitions in this document refer to "Type P" packets to designate a particular type of flow or sets of flows. As defined in RFC 2330, Section 13, "Type P" is a placeholder for what may be an explicit specification of the packet flows referenced by the metric, or it may be a very loose specification encompassing aggregates. We use the "Type P" designation in these definitions in order to emphasize two things: First, that the value of the capacity measurement depends on the types of flows referenced in the definition. This is because networks may treat packets differently (in terms of queuing and scheduling) based on their markings and classification. Networks may also arbitrarily decide to flow-balance based on the packet type or flow type and thereby affect capacity measurements. Second, the measurement of capacity depends not only on the type of the reference packets, but also on the types of the packets in the "population" with which the flows of interest share the links in the path. Section 2.3.2. Definition: IP-type-P Link Capacity As mentioned earlier, this definition is affected by many factors that may change over time. For example, a device's ability to process and forward IP packets for a particular link may have varying effect on capacity, depending on the amount or type of traffic being processed. To summarize RFC 5136, we define nodes as hosts, routers, Ethernet switches= , or any other device and a link as a connection between two of these netwo= rk devices or nodes. We then define a path P of length n as a series of li= nks (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. Furtherm= ore, we define a link L as a special case where the path length is one. Meaning: * The definition of nodes have been extended from RFC 2330 to include an= y devices which can impact IP datagrams * A link is a connection between two network devices or nodes * The definition of a Path (P) is a sequence of (n+1) nodes and (n) link= s for which a Source resides at N(1) and a Destination at N(n+1) * The definition of a Link (L) is the case where n=3D1 above. Thus it i= ncludes two devices and one link Thus, the usage of a link L in this document refers to two nodes and the li= nk between those devices and not simply the link between the nodes. When we= later define the capacity of L, it incorporates the complexities of both t= he devices and the link between them and does not simply mean the "capacity= of the physical (virtual) link" that exists between those two nodes. Thanks! -Joseph and Phil --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC28B348EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Joseph
I agree.
In my opinion, the current definitions in RFC= 5136=20 are covering all cases.
I don't see the need to breakdown the=20 network entities=20 further.
All operators that I know refers to link and lin= k=20 capacity as you have defined them.
 
-Steve
 
 
From:=20 ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Jo= seph=20 Ishac
Sent: March-30-11 4:33 PM
To: IETF IPPM=20 WG
Cc: Chimento, Philip F.
Subject: [ippm] Impact of ho= sts=20 on network capacity and RFC 5136

Folks,

There has been some recent debate regarding RFC 51= 36.=20  Specifically if the impact of network hosts are accounted for in the= =20 definitions of network capacity.

Phil and I have been discussing thi= s=20 off-list and by phone. We believe that the following paragraphs from the RF= C=20 clearly highlight our intent to indeed capture such effects as they all rel= ate=20 to the role of endpoints as only a portion in determining the capacity of a= ny=20 "link".

End of Section 1:

 =20 Aside from questions of coding efficiency, there are issues of how
&nb= sp;=20 access to the channel is controlled, which also may affect the
 = =20 capacity.  For example, a multiple-access medium with collision
&= nbsp;=20 detection, avoidance, and recovery mechanisms has a varying capacity
&= nbsp;=20 from the point of view of the users.  This varying capacity=20 depends
  upon the total number of users contending for the mediu= m,=20 how busy
  the users are, and bounds resulting from the mechanism= s=20 themselves.
  RF channels may also vary in capacity, depending on= =20 range,
  environmental conditions, mobility, shadowing,=20 etc.

 =20 The important points to derive from this discussion are these:=20 First,
  capacity is only meaningful when defined relative to a g= iven=20 protocol
  layer in the network.  It is meaningless to speak= of=20 "link" capacity
  without qualifying exactly what is meant.=20  Second, capacity is not
  necessarily fixed, and consequent= ly, a=20 single measure of capacity at
  any layer may in fact provide a s= kewed=20 picture (either optimistic or
  pessimistic) of what is actually= =20 available.

Section 2.3.1.2

 =20 The definitions in this document refer to "Type P" packets to
 =20 designate a particular type of flow or sets of flows.  As defined=20 in
  RFC 2330, Section 13, "Type P" is a placeholder for what may= be=20 an
  explicit specification of the packet flows referenced by the= =20 metric,
  or it may be a very loose specification encompassing=20 aggregates.  We
  use the "Type P" designation in these=20 definitions in order to
  emphasize two things: First, that the v= alue=20 of the capacity
  measurement depends on the types of flows refer= enced=20 in the
  definition.  This is because networks may treat pac= kets=20 differently
  (in terms of queuing and scheduling) based on their= =20 markings and
  classification.  Networks may also arbitraril= y=20 decide to flow-balance
  based on the packet type or flow type an= d=20 thereby affect capacity
  measurements.  Second, the measure= ment=20 of capacity depends not only
  on the type of the reference packe= ts,=20 but also on the types of the
  packets in the "population" with w= hich=20 the flows of interest share
  the links in the=20 path.

Section 2.3.2.  Definition: IP-type-P Link=20 Capacity

 =20 As mentioned earlier, this definition is affected by many factors
&nbs= p;=20 that may change over time.  For example, a device's ability=20 to
  process and forward IP packets for a particular link may hav= e=20 varying
  effect on capacity, depending on the amount or type= of=20 traffic being
  processed.


To summarize RFC 5136, we define nodes as hosts, routers, Ethernet=20 switches, or any other device and a link as a connection between = two=20 of these network devices or nodes.  We then define a path P of le= ngth=20 n as a series of links (L1, L2, ..., Ln) connecting a sequence of node= s=20 (N1, N2, ..., Nn+1).  A source S and destination D reside at N1 a= nd=20 Nn+1, respectively.  Furthermore, we define a link L as a special= =20 case where the path length is one.

Meaning:
  • The definition of nodes have been extended from RFC 2330 to=20 include any devices which can impact IP datagrams
  • A link is a connection between two network devices or nodes=20
  • The definition of a Path (P) is a sequence of (n+1) nodes and (n)=20 links for which a Source resides at N(1) and a Destination at N(n+1)
  • The definition of a Link (L) is the case where n=3D1 above.  Thu= s=20 it includes two devices and one link
Thus, the usage of a link L in this document refers to two nodes and=20 the link between those devices and not simply the link between the=20 nodes. When we later define the capacity of L, it incorporates the=20 complexities of both the devices and the link between them and does no= t=20 simply mean the "capacity of the physical (virtual) link" that exists= =20 between those two nodes.

Thanks!

-Joseph and Phil
--_000_4383945B8C24AA4FBC33555BB7B829EF0DEC28B348EUSAACMS0701e_-- From Xiangsong.Cui@huawei.com Thu Mar 31 00:18:57 2011 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 EB20328C21E for ; Thu, 31 Mar 2011 00:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] 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 i72t-jOGGXlx for ; Thu, 31 Mar 2011 00:18:56 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D120828C21D for ; Thu, 31 Mar 2011 00:18:56 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW00BQ5V2BK5@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 02:20:36 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW00ME5V2AVV@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 02:20:35 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [130.129.16.72]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 15:20:33 +0800 Date: Thu, 31 Mar 2011 15:20:33 +0800 From: Xiangsong Cui In-reply-to: To: Joseph Ishac 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_em9Vo4S7EQ/gS+r5puaWsA)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: Cc: "Chimento, Philip F." , IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 07:18:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_em9Vo4S7EQ/gS+r5puaWsA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Dear Joseph and Phil=2C Thanks for your clarification=2C and here I would like to have an E-mail = dicssion with you=2E Please see my comments below=2E ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C 2011 =C9=CF= =CE=E74=3A33 =D6=F7=CC=E2=3A =5Bippm=5D Impact of hosts on network capacity and RFC 51= 36 =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChimento=40jhua= pl=2Eedu=3E =3E Folks=2C =3E = =3E There has been some recent debate regarding RFC 5136=2E = =3E Specifically if the =3E impact of network hosts are accounted for in the definitions of = =3E networkcapacity=2E =3E = =3E Phil and I have been discussing this off-list and by phone=2E We = =3E believe that =3E the following paragraphs from the RFC clearly highlight our intent = =3E to indeed =3E capture such effects as they all relate to the role of endpoints = =3E as only a =3E portion in determining the capacity of any =22link=22=2E =3E = =3E End of Section 1=3A =3E = =3E Aside from questions of coding efficiency=2C there are issues of how= =3E =3E access to the channel is controlled=2C which also may affect th= e =3E =3E capacity=2E For example=2C a multiple-access medium with colli= sion =3E =3E detection=2C avoidance=2C and recovery mechanisms has a varying= = =3E capacity=3E from the point of view of the users=2E This varying = =3E capacity depends =3E =3E upon the total number of users contending for the medium=2C how= busy =3E =3E the users are=2C and bounds resulting from the mechanisms = =3E themselves=2E=3E RF channels may also vary in capacity=2C depending= on = =3E range=2C=3E environmental conditions=2C mobility=2C shadowing=2C et= c=2E I do agree this paragraph=2C there is no problem=2E =3E = =3E = =3E The important points to derive from this discussion are these=3A = =3E First=2C=3E capacity is only meaningful when defined relative to a = =3E given protocol =3E =3E layer in the network=2E It is meaningless to speak of =22link=22= = =3E capacity=3E without qualifying exactly what is meant=2E Second=2C = =3E capacity is not =3E =3E necessarily fixed=2C and consequently=2C a single measure of = =3E capacity at =3E =3E any layer may in fact provide a skewed picture (either = =3E optimistic or =3E =3E pessimistic) of what is actually available=2E I almost agree this paragraph=2C and I just want to focus on =22IP-layer=22= here=2E =3E = =3E = =3E Section 2=2E3=2E1=2E2 =3E = =3E The definitions in this document refer to =22Type P=22 packets to =3E =3E designate a particular type of flow or sets of flows=2E As = =3E defined in =3E =3E RFC 2330=2C Section 13=2C =22Type P=22 is a placeholder for wha= t may = =3E be an =3E =3E explicit specification of the packet flows referenced by the = =3E metric=2C=3E or it may be a very loose specification encompassing = =3E aggregates=2E We =3E =3E use the =22Type P=22 designation in these definitions in order = to =3E =3E emphasize two things=3A First=2C that the value of the capacity= =3E =3E measurement depends on the types of flows referenced in the =3E =3E definition=2E This is because networks may treat packets = =3E differently=3E (in terms of queuing and scheduling) based on their = =3E markings and =3E =3E classification=2E Networks may also arbitrarily decide to flow= - =3E balance=3E based on the packet type or flow type and thereby = =3E affect capacity =3E =3E measurements=2E Second=2C the measurement of capacity depends = not = =3E only=3E on the type of the reference packets=2C but also on the = =3E types of the =3E =3E packets in the =22population=22 with which the flows of interes= t share =3E =3E the links in the path=2E =3E = I have no problem with =22Type-P packet=22=2E What is more=2C I think above statement has no relation to our debate=2E =3E = =3E Section 2=2E3=2E2=2E Definition=3A IP-type-P Link Capacity =3E = =3E As mentioned earlier=2C this definition is affected by many factors =3E =3E that may change over time=2E *For example=2C a device=27s abil= ity to =3E =3E process and forward IP packets for a particular link may have = =3E varying=3E effect on capacity*=2C depending on the amount or type o= f = =3E traffic being =3E =3E processed=2E =3E = Yes=2C I get your point here=2E However=2C that is exactly my concern=2E You mean you combined (or say enbeded) nodes inside link=2C right=3F I just don=27think this is appropriate=2E =3E = =3E = =3E To summarize RFC 5136=2C we define nodes as hosts=2C routers=2C Ether= net = =3E switches=2Cor any other device and a link as a connection between = =3E two of these =3E network devices or nodes=2E We then define a path P of length n as = =3E a series =3E of links (L1=2C L2=2C =2E=2E=2E=2C Ln) connecting a sequence of nodes= (N1=2C N2=2C =3E =2E=2E=2E=2C Nn+1)=2E A source S and destination D reside at N1 and =3E Nn+1=2C respectively=2E Furthermore=2C we define a link L as a speci= al = =3E case where =3E the path length is one=2E =3E = =3E Meaning=3A =3E = =3E - The definition of nodes have been extended from RFC 2330 to = =3E include any =3E devices which can impact IP datagrams =3E - A link is a connection between two network devices or nodes Do you mean the =22link=22 is exactly the connection between nodes=3F Or you mean the link is the =22combination=22 of =22the connection betwee= n nodes=22 + =22the nodes themselves=22=3F =3E - The definition of a Path (P) is a sequence of (n+1) nodes and (n)= =3E links for which a Source resides at N(1) and a Destination at = =3E N(n+1) - The definition of a Link (L) is the case where n=3D1 = =3E above=2E Thus =3E it includes two devices and one link =3E = =3E Thus=2C the usage of a link L in this document refers to two nodes an= d =3E the link between those devices and not simply the link between the =3E nodes=2E = Let me try to understand your words=2C there are three =22link=22 in this= sentence=2E =22LINK L=22=2C yes=2C I get it=2E There are also =3Cand the =22link=22 between those devices=3E =26 =3Cnot = simply the =22link=22 between the nodes=3E=2C I=27m fully confused now=2C= do you mean =22link L=22 is NOT a link=3F I don=27t think people would u= nderstand this well=2E When we later define the capacity of L=2C it incorporates the So you are speaking =22the capacity of L=22 is NOT =22the capacity of a l= ink=22=2C but capacity of something else=2C right=3F Then=2C what is its = meaning for people who are only familiar with normal =22link=22=2C =22nod= e=22 and =22path=22 concept=3F By the way=2C could you please answer my questions in my presentation sli= des=3F In slide 7=2C ! Link1 capacity (IP layer)=2C 0=2E99 M or 990 M=3F = ! Link1 utilization (IP layer)=2C 0=2E1=25 or 100=25=3F = ! Link2 capacity (IP layer)=2C 0=2E99 M or 99 M=3F = ! Link2 utilization (IP layer)=2C 1=25 or 100=25=3F = ! Path (Src to Dst) capacity (IP layer)=3F = ! Available path capacity (IP layer)=3F = Thanks and best regards=2C Xiangsong =3E complexities of both the devices and the link between them and = =3E does not =3E simply mean the =22capacity of the physical (virtual) link=22 that ex= ists =3E between those two nodes=2E =3E = =3E Thanks! =3E = =3E -Joseph and Phil =3E --Boundary_(ID_em9Vo4S7EQ/gS+r5puaWsA) 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_em9Vo4S7EQ/gS+r5puaWsA)-- From Xiangsong.Cui@huawei.com Thu Mar 31 00:20:36 2011 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 8E8DA28C1EC for ; Thu, 31 Mar 2011 00:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] 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 Tmcfh1Uuua05 for ; Thu, 31 Mar 2011 00:20:35 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6D3663A6A46 for ; Thu, 31 Mar 2011 00:20:35 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW00BVLV52K5@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 02:22:14 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW00MJCV51VV@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 02:22:14 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [130.129.16.72]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 15:22:12 +0800 Date: Thu, 31 Mar 2011 15:22:12 +0800 From: Xiangsong Cui In-reply-to: To: Joseph Ishac 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_NaY59SJ9en1NNMPStrLipQ)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: Cc: "Chimento, Philip F." , IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 07:20:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NaY59SJ9en1NNMPStrLipQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline The presentation slides is http=3A//www=2Eietf=2Eorg/proceedings/80/slide= s/ippm-4=2Epdf=2E Best Regards Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C 2011 =C9=CF= =CE=E74=3A33 =D6=F7=CC=E2=3A =5Bippm=5D Impact of hosts on network capacity and RFC 51= 36 =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChimento=40jhua= pl=2Eedu=3E =3E Folks=2C =3E = =3E There has been some recent debate regarding RFC 5136=2E = =3E Specifically if the =3E impact of network hosts are accounted for in the definitions of = =3E networkcapacity=2E =3E = =3E Phil and I have been discussing this off-list and by phone=2E We = =3E believe that =3E the following paragraphs from the RFC clearly highlight our intent = =3E to indeed =3E capture such effects as they all relate to the role of endpoints = =3E as only a =3E portion in determining the capacity of any =22link=22=2E =3E = =3E End of Section 1=3A =3E = =3E Aside from questions of coding efficiency=2C there are issues of how= =3E =3E access to the channel is controlled=2C which also may affect th= e =3E =3E capacity=2E For example=2C a multiple-access medium with colli= sion =3E =3E detection=2C avoidance=2C and recovery mechanisms has a varying= = =3E capacity=3E from the point of view of the users=2E This varying = =3E capacity depends =3E =3E upon the total number of users contending for the medium=2C how= busy =3E =3E the users are=2C and bounds resulting from the mechanisms = =3E themselves=2E=3E RF channels may also vary in capacity=2C depending= on = =3E range=2C=3E environmental conditions=2C mobility=2C shadowing=2C et= c=2E =3E = =3E = =3E The important points to derive from this discussion are these=3A = =3E First=2C=3E capacity is only meaningful when defined relative to a = =3E given protocol =3E =3E layer in the network=2E It is meaningless to speak of =22link=22= = =3E capacity=3E without qualifying exactly what is meant=2E Second=2C = =3E capacity is not =3E =3E necessarily fixed=2C and consequently=2C a single measure of = =3E capacity at =3E =3E any layer may in fact provide a skewed picture (either = =3E optimistic or =3E =3E pessimistic) of what is actually available=2E =3E = =3E = =3E Section 2=2E3=2E1=2E2 =3E = =3E The definitions in this document refer to =22Type P=22 packets to =3E =3E designate a particular type of flow or sets of flows=2E As = =3E defined in =3E =3E RFC 2330=2C Section 13=2C =22Type P=22 is a placeholder for wha= t may = =3E be an =3E =3E explicit specification of the packet flows referenced by the = =3E metric=2C=3E or it may be a very loose specification encompassing = =3E aggregates=2E We =3E =3E use the =22Type P=22 designation in these definitions in order = to =3E =3E emphasize two things=3A First=2C that the value of the capacity= =3E =3E measurement depends on the types of flows referenced in the =3E =3E definition=2E This is because networks may treat packets = =3E differently=3E (in terms of queuing and scheduling) based on their = =3E markings and =3E =3E classification=2E Networks may also arbitrarily decide to flow= - =3E balance=3E based on the packet type or flow type and thereby = =3E affect capacity =3E =3E measurements=2E Second=2C the measurement of capacity depends = not = =3E only=3E on the type of the reference packets=2C but also on the = =3E types of the =3E =3E packets in the =22population=22 with which the flows of interes= t share =3E =3E the links in the path=2E =3E = =3E = =3E Section 2=2E3=2E2=2E Definition=3A IP-type-P Link Capacity =3E = =3E As mentioned earlier=2C this definition is affected by many factors =3E =3E that may change over time=2E *For example=2C a device=27s abil= ity to =3E =3E process and forward IP packets for a particular link may have = =3E varying=3E effect on capacity*=2C depending on the amount or type o= f = =3E traffic being =3E =3E processed=2E =3E = =3E = =3E = =3E To summarize RFC 5136=2C we define nodes as hosts=2C routers=2C Ether= net = =3E switches=2Cor any other device and a link as a connection between = =3E two of these =3E network devices or nodes=2E We then define a path P of length n as = =3E a series =3E of links (L1=2C L2=2C =2E=2E=2E=2C Ln) connecting a sequence of nodes= (N1=2C N2=2C =3E =2E=2E=2E=2C Nn+1)=2E A source S and destination D reside at N1 and =3E Nn+1=2C respectively=2E Furthermore=2C we define a link L as a speci= al = =3E case where =3E the path length is one=2E =3E = =3E Meaning=3A =3E = =3E - The definition of nodes have been extended from RFC 2330 to = =3E include any =3E devices which can impact IP datagrams =3E - A link is a connection between two network devices or nodes =3E - The definition of a Path (P) is a sequence of (n+1) nodes and (n)= =3E links for which a Source resides at N(1) and a Destination at = =3E N(n+1) - The definition of a Link (L) is the case where n=3D1 = =3E above=2E Thus =3E it includes two devices and one link =3E = =3E Thus=2C the usage of a link L in this document refers to two nodes an= d =3E the link between those devices and not simply the link between the =3E nodes=2E When we later define the capacity of L=2C it incorporates th= e =3E complexities of both the devices and the link between them and = =3E does not =3E simply mean the =22capacity of the physical (virtual) link=22 that ex= ists =3E between those two nodes=2E =3E = =3E Thanks! =3E = =3E -Joseph and Phil =3E --Boundary_(ID_NaY59SJ9en1NNMPStrLipQ) 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_NaY59SJ9en1NNMPStrLipQ)-- From steve.baillargeon@ericsson.com Thu Mar 31 01:34:36 2011 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 51A1828C0E1 for ; Thu, 31 Mar 2011 01:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[AWL=-1.904, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_82=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 keeojVQQmaYs for ; Thu, 31 Mar 2011 01:34:35 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 0F84A3A6AFA for ; Thu, 31 Mar 2011 01:34:34 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2V8ZVbB016515; Thu, 31 Mar 2011 03:35:32 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 31 Mar 2011 04:35:26 -0400 From: Steve Baillargeon To: Xiangsong Cui , Joseph Ishac Date: Thu, 31 Mar 2011 04:35:23 -0400 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: AcvvdF/HHx0f9cJhSkW6PjVtHJS43AABZ0OQ Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B359@EUSAACMS0701.eamcs.ericsson.se> References: 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Chimento, Philip F." , IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 08:34:36 -0000 SW4gbXkgYm9vaywgdGhpcyBpcyBhIHNwZWNpYWwgY2FzZS4gSSBiZWxpZXZlIGluIG1vc3QgY2Fz ZXMsIHRoZSBJUC10eXBlLVAgbGluayBjYXBhY2l0eSBpcyB0aGUgIklQLWxheWVyIGxpbmsgc3Bl ZWQiLg0KVGhlIGRlZmluaXRpb24gb2YgdGhlIElQLXR5cGUtUCBsaW5rIGNhcGFjaXR5IGluIFJG QzUxMzYgYWxyZWFkeSBpbmRpY2F0ZXMgb3IgaW1wbGllcyB0aGUgbGluayBjYXBhY2l0eSBjYW4g YmUgc21hbGxlciB0aGFuIHRoZSAibGluayBzcGVlZCIuIA0KSXQgaXMgdXAgdG8gdGhlIGltcGxl bWVudGVyIHRvIGNob29zZSBob3cgdG8gcmVwb3J0IHRoZSBsaW5rIGNhcGFjaXR5IGFzIHRoZXkg c2VlIGZpdCBiYXNlZCBvbiB0aGVpciBpbXBsZW1lbnRhdGlvbiBvciBlbnZpcm9ubWVudCAoZS5n IGVmZmVjdGl2ZSBsaW5rIGNhcGFjaXR5KS4gDQpEbyB3ZSBuZWVkIHRvIGFkZCBhIG5ldyBkZWZp bml0aW9uIGNhbGxlZCBJUC1UeXBlLVAgbGluayBzcGVlZD8gSSBkb24ndCBiZWxpZXZlIHNvLg0K DQotU3RldmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwcG0tYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFhp YW5nc29uZyBDdWkNClNlbnQ6IE1hcmNoLTMxLTExIDM6MjIgQU0NClRvOiBKb3NlcGggSXNoYWMN CkNjOiBDaGltZW50bywgUGhpbGlwIEYuOyBJRVRGIElQUE0gV0cNClN1YmplY3Q6IFJlOiBbaXBw bV0gSW1wYWN0IG9mIGhvc3RzIG9uIG5ldHdvcmsgY2FwYWNpdHkgYW5kIFJGQyA1MTM2DQoNClRo ZSBwcmVzZW50YXRpb24gc2xpZGVzIGlzIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv ODAvc2xpZGVzL2lwcG0tNC5wZGYuDQoNCkJlc3QgUmVnYXJkcw0KWGlhbmdzb25nDQoNCi0tLS0t INSt08q8/iAtLS0tLQ0Kt6K8/sjLOiBKb3NlcGggSXNoYWMgPGppc2hhY0BuYXNhLmdvdj4NCsjV xto6INDHxtrLxCwgyP3UwiAzMcjVLCAyMDExIMnPzuc0OjMzDQrW98ziOiBbaXBwbV0gSW1wYWN0 IG9mIGhvc3RzIG9uIG5ldHdvcmsgY2FwYWNpdHkgYW5kIFJGQyA1MTM2DQrK1bz+yMs6IElFVEYg SVBQTSBXRyA8aXBwbUBpZXRmLm9yZz4NCrOty806ICJDaGltZW50bywgUGhpbGlwIEYuIiA8UGhp bGlwLkNoaW1lbnRvQGpodWFwbC5lZHU+DQoNCj4gRm9sa3MsDQo+IA0KPiBUaGVyZSBoYXMgYmVl biBzb21lIHJlY2VudCBkZWJhdGUgcmVnYXJkaW5nIFJGQyA1MTM2LiAgDQo+IFNwZWNpZmljYWxs eSBpZiB0aGUNCj4gaW1wYWN0IG9mIG5ldHdvcmsgaG9zdHMgYXJlIGFjY291bnRlZCBmb3IgaW4g dGhlIGRlZmluaXRpb25zIG9mIA0KPiBuZXR3b3JrY2FwYWNpdHkuDQo+IA0KPiBQaGlsIGFuZCBJ IGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMgb2ZmLWxpc3QgYW5kIGJ5IHBob25lLiBXZSBiZWxp ZXZlIA0KPiB0aGF0IHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBocyBmcm9tIHRoZSBSRkMgY2xlYXJs eSBoaWdobGlnaHQgb3VyIA0KPiBpbnRlbnQgdG8gaW5kZWVkIGNhcHR1cmUgc3VjaCBlZmZlY3Rz IGFzIHRoZXkgYWxsIHJlbGF0ZSB0byB0aGUgcm9sZSANCj4gb2YgZW5kcG9pbnRzIGFzIG9ubHkg YSBwb3J0aW9uIGluIGRldGVybWluaW5nIHRoZSBjYXBhY2l0eSBvZiBhbnkgDQo+ICJsaW5rIi4N Cj4gDQo+IEVuZCBvZiBTZWN0aW9uIDE6DQo+IA0KPiAgQXNpZGUgZnJvbSBxdWVzdGlvbnMgb2Yg Y29kaW5nIGVmZmljaWVuY3ksIHRoZXJlIGFyZSBpc3N1ZXMgb2YgaG93DQo+ID4gICBhY2Nlc3Mg dG8gdGhlIGNoYW5uZWwgaXMgY29udHJvbGxlZCwgd2hpY2ggYWxzbyBtYXkgYWZmZWN0IHRoZQ0K PiA+ICAgY2FwYWNpdHkuICBGb3IgZXhhbXBsZSwgYSBtdWx0aXBsZS1hY2Nlc3MgbWVkaXVtIHdp dGggY29sbGlzaW9uDQo+ID4gICBkZXRlY3Rpb24sIGF2b2lkYW5jZSwgYW5kIHJlY292ZXJ5IG1l Y2hhbmlzbXMgaGFzIGEgdmFyeWluZw0KPiBjYXBhY2l0eT4gICBmcm9tIHRoZSBwb2ludCBvZiB2 aWV3IG9mIHRoZSB1c2Vycy4gIFRoaXMgdmFyeWluZw0KPiBjYXBhY2l0eSBkZXBlbmRzDQo+ID4g ICB1cG9uIHRoZSB0b3RhbCBudW1iZXIgb2YgdXNlcnMgY29udGVuZGluZyBmb3IgdGhlIG1lZGl1 bSwgaG93IGJ1c3kNCj4gPiAgIHRoZSB1c2VycyBhcmUsIGFuZCBib3VuZHMgcmVzdWx0aW5nIGZy b20gdGhlIG1lY2hhbmlzbXMNCj4gdGhlbXNlbHZlcy4+ICAgUkYgY2hhbm5lbHMgbWF5IGFsc28g dmFyeSBpbiBjYXBhY2l0eSwgZGVwZW5kaW5nIG9uIA0KPiByYW5nZSw+ICAgZW52aXJvbm1lbnRh bCBjb25kaXRpb25zLCBtb2JpbGl0eSwgc2hhZG93aW5nLCBldGMuDQo+IA0KPiANCj4gIFRoZSBp bXBvcnRhbnQgcG9pbnRzIHRvIGRlcml2ZSBmcm9tIHRoaXMgZGlzY3Vzc2lvbiBhcmUgdGhlc2U6 IA0KPiBGaXJzdCw+ICAgY2FwYWNpdHkgaXMgb25seSBtZWFuaW5nZnVsIHdoZW4gZGVmaW5lZCBy ZWxhdGl2ZSB0byBhIA0KPiBnaXZlbiBwcm90b2NvbA0KPiA+ICAgbGF5ZXIgaW4gdGhlIG5ldHdv cmsuICBJdCBpcyBtZWFuaW5nbGVzcyB0byBzcGVhayBvZiAibGluayIgDQo+IGNhcGFjaXR5PiAg IHdpdGhvdXQgcXVhbGlmeWluZyBleGFjdGx5IHdoYXQgaXMgbWVhbnQuICBTZWNvbmQsDQo+IGNh cGFjaXR5IGlzIG5vdA0KPiA+ICAgbmVjZXNzYXJpbHkgZml4ZWQsIGFuZCBjb25zZXF1ZW50bHks IGEgc2luZ2xlIG1lYXN1cmUgb2YNCj4gY2FwYWNpdHkgYXQNCj4gPiAgIGFueSBsYXllciBtYXkg aW4gZmFjdCBwcm92aWRlIGEgc2tld2VkIHBpY3R1cmUgKGVpdGhlcg0KPiBvcHRpbWlzdGljIG9y DQo+ID4gICBwZXNzaW1pc3RpYykgb2Ygd2hhdCBpcyBhY3R1YWxseSBhdmFpbGFibGUuDQo+IA0K PiANCj4gU2VjdGlvbiAyLjMuMS4yDQo+IA0KPiAgVGhlIGRlZmluaXRpb25zIGluIHRoaXMgZG9j dW1lbnQgcmVmZXIgdG8gIlR5cGUgUCIgcGFja2V0cyB0bw0KPiA+ICAgZGVzaWduYXRlIGEgcGFy dGljdWxhciB0eXBlIG9mIGZsb3cgb3Igc2V0cyBvZiBmbG93cy4gIEFzDQo+IGRlZmluZWQgaW4N Cj4gPiAgIFJGQyAyMzMwLCBTZWN0aW9uIDEzLCAiVHlwZSBQIiBpcyBhIHBsYWNlaG9sZGVyIGZv ciB3aGF0IG1heQ0KPiBiZSBhbg0KPiA+ICAgZXhwbGljaXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUg cGFja2V0IGZsb3dzIHJlZmVyZW5jZWQgYnkgdGhlDQo+IG1ldHJpYyw+ICAgb3IgaXQgbWF5IGJl IGEgdmVyeSBsb29zZSBzcGVjaWZpY2F0aW9uIGVuY29tcGFzc2luZyANCj4gYWdncmVnYXRlcy4g IFdlDQo+ID4gICB1c2UgdGhlICJUeXBlIFAiIGRlc2lnbmF0aW9uIGluIHRoZXNlIGRlZmluaXRp b25zIGluIG9yZGVyIHRvDQo+ID4gICBlbXBoYXNpemUgdHdvIHRoaW5nczogRmlyc3QsIHRoYXQg dGhlIHZhbHVlIG9mIHRoZSBjYXBhY2l0eQ0KPiA+ICAgbWVhc3VyZW1lbnQgZGVwZW5kcyBvbiB0 aGUgdHlwZXMgb2YgZmxvd3MgcmVmZXJlbmNlZCBpbiB0aGUNCj4gPiAgIGRlZmluaXRpb24uICBU aGlzIGlzIGJlY2F1c2UgbmV0d29ya3MgbWF5IHRyZWF0IHBhY2tldHMNCj4gZGlmZmVyZW50bHk+ ICAgKGluIHRlcm1zIG9mIHF1ZXVpbmcgYW5kIHNjaGVkdWxpbmcpIGJhc2VkIG9uIHRoZWlyDQo+ IG1hcmtpbmdzIGFuZA0KPiA+ICAgY2xhc3NpZmljYXRpb24uICBOZXR3b3JrcyBtYXkgYWxzbyBh cmJpdHJhcmlseSBkZWNpZGUgdG8gZmxvdy0NCj4gYmFsYW5jZT4gICBiYXNlZCBvbiB0aGUgcGFj a2V0IHR5cGUgb3IgZmxvdyB0eXBlIGFuZCB0aGVyZWJ5DQo+IGFmZmVjdCBjYXBhY2l0eQ0KPiA+ ICAgbWVhc3VyZW1lbnRzLiAgU2Vjb25kLCB0aGUgbWVhc3VyZW1lbnQgb2YgY2FwYWNpdHkgZGVw ZW5kcyBub3QNCj4gb25seT4gICBvbiB0aGUgdHlwZSBvZiB0aGUgcmVmZXJlbmNlIHBhY2tldHMs IGJ1dCBhbHNvIG9uIHRoZQ0KPiB0eXBlcyBvZiB0aGUNCj4gPiAgIHBhY2tldHMgaW4gdGhlICJw b3B1bGF0aW9uIiB3aXRoIHdoaWNoIHRoZSBmbG93cyBvZiBpbnRlcmVzdCBzaGFyZQ0KPiA+ICAg dGhlIGxpbmtzIGluIHRoZSBwYXRoLg0KPiANCj4gDQo+IFNlY3Rpb24gMi4zLjIuICBEZWZpbml0 aW9uOiBJUC10eXBlLVAgTGluayBDYXBhY2l0eQ0KPiANCj4gIEFzIG1lbnRpb25lZCBlYXJsaWVy LCB0aGlzIGRlZmluaXRpb24gaXMgYWZmZWN0ZWQgYnkgbWFueSBmYWN0b3JzDQo+ID4gICB0aGF0 IG1heSBjaGFuZ2Ugb3ZlciB0aW1lLiAgKkZvciBleGFtcGxlLCBhIGRldmljZSdzIGFiaWxpdHkg dG8NCj4gPiAgIHByb2Nlc3MgYW5kIGZvcndhcmQgSVAgcGFja2V0cyBmb3IgYSBwYXJ0aWN1bGFy IGxpbmsgbWF5IGhhdmUNCj4gdmFyeWluZz4gICBlZmZlY3Qgb24gY2FwYWNpdHkqLCBkZXBlbmRp bmcgb24gdGhlIGFtb3VudCBvciB0eXBlIG9mDQo+IHRyYWZmaWMgYmVpbmcNCj4gPiAgIHByb2Nl c3NlZC4NCj4gDQo+IA0KPiANCj4gVG8gc3VtbWFyaXplIFJGQyA1MTM2LCB3ZSBkZWZpbmUgbm9k ZXMgYXMgaG9zdHMsIHJvdXRlcnMsIEV0aGVybmV0IA0KPiBzd2l0Y2hlcyxvciBhbnkgb3RoZXIg ZGV2aWNlIGFuZCBhIGxpbmsgYXMgYSBjb25uZWN0aW9uIGJldHdlZW4gdHdvIG9mIA0KPiB0aGVz ZSBuZXR3b3JrIGRldmljZXMgb3Igbm9kZXMuICBXZSB0aGVuIGRlZmluZSBhIHBhdGggUCBvZiBs ZW5ndGggbiANCj4gYXMgYSBzZXJpZXMgb2YgbGlua3MgKEwxLCBMMiwgLi4uLCBMbikgY29ubmVj dGluZyBhIHNlcXVlbmNlIG9mIG5vZGVzIA0KPiAoTjEsIE4yLCAuLi4sIE5uKzEpLiAgQSBzb3Vy Y2UgUyBhbmQgZGVzdGluYXRpb24gRCByZXNpZGUgYXQgTjEgYW5kDQo+IE5uKzEsIHJlc3BlY3Rp dmVseS4gIEZ1cnRoZXJtb3JlLCB3ZSBkZWZpbmUgYSBsaW5rIEwgYXMgYSBzcGVjaWFsDQo+IGNh c2Ugd2hlcmUNCj4gdGhlIHBhdGggbGVuZ3RoIGlzIG9uZS4NCj4gDQo+IE1lYW5pbmc6DQo+IA0K PiAgIC0gVGhlIGRlZmluaXRpb24gb2Ygbm9kZXMgaGF2ZSBiZWVuIGV4dGVuZGVkIGZyb20gUkZD IDIzMzAgdG8gDQo+IGluY2x1ZGUgYW55DQo+ICAgZGV2aWNlcyB3aGljaCBjYW4gaW1wYWN0IElQ IGRhdGFncmFtcw0KPiAgIC0gQSBsaW5rIGlzIGEgY29ubmVjdGlvbiBiZXR3ZWVuIHR3byBuZXR3 b3JrIGRldmljZXMgb3Igbm9kZXMNCj4gICAtIFRoZSBkZWZpbml0aW9uIG9mIGEgUGF0aCAoUCkg aXMgYSBzZXF1ZW5jZSBvZiAobisxKSBub2RlcyBhbmQgKG4pDQo+ICAgbGlua3MgZm9yIHdoaWNo IGEgU291cmNlIHJlc2lkZXMgYXQgTigxKSBhbmQgYSBEZXN0aW5hdGlvbiBhdCANCj4gTihuKzEp ICAgLSBUaGUgZGVmaW5pdGlvbiBvZiBhIExpbmsgKEwpIGlzIHRoZSBjYXNlIHdoZXJlIG49MSAN Cj4gYWJvdmUuICBUaHVzDQo+ICAgaXQgaW5jbHVkZXMgdHdvIGRldmljZXMgYW5kIG9uZSBsaW5r DQo+IA0KPiBUaHVzLCB0aGUgdXNhZ2Ugb2YgYSBsaW5rIEwgaW4gdGhpcyBkb2N1bWVudCByZWZl cnMgdG8gdHdvIG5vZGVzIGFuZCANCj4gdGhlIGxpbmsgYmV0d2VlbiB0aG9zZSBkZXZpY2VzIGFu ZCBub3Qgc2ltcGx5IHRoZSBsaW5rIGJldHdlZW4gdGhlIA0KPiBub2Rlcy4gV2hlbiB3ZSBsYXRl ciBkZWZpbmUgdGhlIGNhcGFjaXR5IG9mIEwsIGl0IGluY29ycG9yYXRlcyB0aGUgDQo+IGNvbXBs ZXhpdGllcyBvZiBib3RoIHRoZSBkZXZpY2VzIGFuZCB0aGUgbGluayBiZXR3ZWVuIHRoZW0gYW5k IGRvZXMgDQo+IG5vdCBzaW1wbHkgbWVhbiB0aGUgImNhcGFjaXR5IG9mIHRoZSBwaHlzaWNhbCAo dmlydHVhbCkgbGluayIgdGhhdCANCj4gZXhpc3RzIGJldHdlZW4gdGhvc2UgdHdvIG5vZGVzLg0K PiANCj4gVGhhbmtzIQ0KPiANCj4gLUpvc2VwaCBhbmQgUGhpbA0KPiANCg== From Xiangsong.Cui@huawei.com Thu Mar 31 01:37:54 2011 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 5C0C33A6C1D for ; Thu, 31 Mar 2011 01:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=1.845, 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 9s-JspPvajUl for ; Thu, 31 Mar 2011 01:37:52 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id BF05E3A6B14 for ; Thu, 31 Mar 2011 01:37:52 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW00BKDYPVK5@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 03:39:31 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW008DWYPS9H@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 03:39:31 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [130.129.16.72]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 16:39:28 +0800 Date: Thu, 31 Mar 2011 16:39:28 +0800 From: Xiangsong Cui In-reply-to: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B348@EUSAACMS0701.eamcs.ericsson.se> To: Steve Baillargeon 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_o0FpiElJ+S7i+FACmzh4dw)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B348@EUSAACMS0701.eamcs.ericsson.se> Cc: "Chimento, Philip F." , IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 08:37:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_o0FpiElJ+S7i+FACmzh4dw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi Steve, > All operators that I know refers to link and link capacity as you > have defined them. I'm not sure, but could you please give me some examples? What I know is, for example, the information theory, http://en.wikipedia.org/wiki/Information_theory, which takes the reference model of <"Transmitter" + "Channel" + Receiver">. Do you mean guys usually take transmitter and receiver as part of channel? Or you mean the maximum performance value of the channel is transmitter-dependent? Best regards, Xiangsong > > -Steve > > > ________________________________ > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On > Behalf Of Joseph Ishac > Sent: March-30-11 4:33 PM > To: IETF IPPM WG > Cc: Chimento, Philip F. > Subject: [ippm] Impact of hosts on network capacity and RFC 5136 > > Folks, > > There has been some recent debate regarding RFC 5136. > Specifically if the impact of network hosts are accounted for in > the definitions of network capacity. > > Phil and I have been discussing this off-list and by phone. We > believe that the following paragraphs from the RFC clearly > highlight our intent to indeed capture such effects as they all > relate to the role of endpoints as only a portion in determining > the capacity of any "link". > > End of Section 1: > > Aside from questions of coding efficiency, there are issues of how > access to the channel is controlled, which also may affect the > capacity. For example, a multiple-access medium with collision > detection, avoidance, and recovery mechanisms has a varying capacity > from the point of view of the users. This varying capacity depends > upon the total number of users contending for the medium, how busy > the users are, and bounds resulting from the mechanisms themselves. > RF channels may also vary in capacity, depending on range, > environmental conditions, mobility, shadowing, etc. > > The important points to derive from this discussion are these: > First, capacity is only meaningful when defined relative to a > given protocol > layer in the network. It is meaningless to speak of "link" capacity > without qualifying exactly what is meant. Second, capacity is not > necessarily fixed, and consequently, a single measure of > capacity at > any layer may in fact provide a skewed picture (either > optimistic or > pessimistic) of what is actually available. > > Section 2.3.1.2 > > The definitions in this document refer to "Type P" packets to > designate a particular type of flow or sets of flows. As > defined in > RFC 2330, Section 13, "Type P" is a placeholder for what may be an > explicit specification of the packet flows referenced by the metric, > or it may be a very loose specification encompassing aggregates. > We > use the "Type P" designation in these definitions in order to > emphasize two things: First, that the value of the capacity > measurement depends on the types of flows referenced in the > definition. This is because networks may treat packets differently > (in terms of queuing and scheduling) based on their markings and > classification. Networks may also arbitrarily decide to flow- > balance based on the packet type or flow type and thereby affect > capacity measurements. Second, the measurement of capacity > depends not only > on the type of the reference packets, but also on the types of the > packets in the "population" with which the flows of interest share > the links in the path. > > Section 2.3.2. Definition: IP-type-P Link Capacity > > As mentioned earlier, this definition is affected by many factors > that may change over time. For example, a device's ability to > process and forward IP packets for a particular link may have > varying effect on capacity, depending on the amount or type of > traffic being > processed. > > > To summarize RFC 5136, we define nodes as hosts, routers, Ethernet > switches, or any other device and a link as a connection between > two of these network devices or nodes. 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. Furthermore, we define a > link L as a special case where the path length is one. > > Meaning: > > * The definition of nodes have been extended from RFC 2330 to > include any devices which can impact IP datagrams > * A link is a connection between two network devices or nodes > * The definition of a Path (P) is a sequence of (n+1) nodes and > (n) links for which a Source resides at N(1) and a Destination at > N(n+1) * The definition of a Link (L) is the case where n=1 > above. Thus it includes two devices and one link > > Thus, the usage of a link L in this document refers to two nodes > and the link between those devices and not simply the link between > the nodes. When we later define the capacity of L, it incorporates > the complexities of both the devices and the link between them and > does not simply mean the "capacity of the physical (virtual) link" > that exists between those two nodes. > > Thanks! > > -Joseph and Phil > --Boundary_(ID_o0FpiElJ+S7i+FACmzh4dw) 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_o0FpiElJ+S7i+FACmzh4dw)-- From Xiangsong.Cui@huawei.com Thu Mar 31 01:48:32 2011 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 C2C613A6B00 for ; Thu, 31 Mar 2011 01:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.325 X-Spam-Level: X-Spam-Status: No, score=0.325 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] 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 x7VCERdVAkbe for ; Thu, 31 Mar 2011 01:48:31 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A6B843A6B2B for ; Thu, 31 Mar 2011 01:48:31 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW00BKCZ7NK5@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 03:50:11 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW0087RZ7K9H@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 03:50:11 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [130.129.16.72]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 16:50:08 +0800 Date: Thu, 31 Mar 2011 16:50:08 +0800 From: Xiangsong Cui In-reply-to: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B359@EUSAACMS0701.eamcs.ericsson.se> To: Steve Baillargeon 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_Mk2d6XEeEczcjbzB0MxpcA)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B359@EUSAACMS0701.eamcs.ericsson.se> Cc: "Chimento, Philip F." , IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 08:48:32 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Mk2d6XEeEczcjbzB0MxpcA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline =3E In my book=2C this is a special case=2E = could you please explain why this is a special case=3F because there is a router in the network=3F or because the =22capacity of the router=22 is less than =22the capacity = of the links=22 if it is the latter=2C then there is a different capacity of the link in = your mind=2C right=3F Best regards=2C Xiangosng I believe in most cases=2C the = =3E IP-type-P link capacity is the =22IP-layer link speed=22=2E =3E The definition of the IP-type-P link capacity in RFC5136 already = =3E indicates or implies the link capacity can be smaller than the = =3E =22link speed=22=2E = =3E It is up to the implementer to choose how to report the link = =3E capacity as they see fit based on their implementation or = =3E environment (e=2Eg effective link capacity)=2E = =3E Do we need to add a new definition called IP-Type-P link speed=3F I = =3E don=27t believe so=2E =3E = =3E -Steve =3E = =3E -----Original Message----- =3E From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf=2Eo= rg=5D On = =3E Behalf Of Xiangsong Cui =3E Sent=3A March-31-11 3=3A22 AM =3E To=3A Joseph Ishac =3E Cc=3A Chimento=2C Philip F=2E=3B IETF IPPM WG =3E Subject=3A Re=3A =5Bippm=5D Impact of hosts on network capacity and R= FC 5136 =3E = =3E The presentation slides is = =3E http=3A//www=2Eietf=2Eorg/proceedings/80/slides/ippm-4=2Epdf=2E =3E = =3E Best Regards =3E Xiangsong =3E = =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C 2011 =C9= =CF=CE=E74=3A33 =3E =D6=F7=CC=E2=3A =5Bippm=5D Impact of hosts on network capacity and RF= C 5136 =3E =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChimento=40= jhuapl=2Eedu=3E =3E = =3E =3E Folks=2C =3E =3E = =3E =3E There has been some recent debate regarding RFC 5136=2E = =3E =3E Specifically if the =3E =3E impact of network hosts are accounted for in the definitions of = =3E =3E networkcapacity=2E =3E =3E = =3E =3E Phil and I have been discussing this off-list and by phone=2E We = =3E believe = =3E =3E that the following paragraphs from the RFC clearly highlight our = =3E =3E intent to indeed capture such effects as they all relate to the = =3E role = =3E =3E of endpoints as only a portion in determining the capacity of = =3E any = =3E =3E =22link=22=2E =3E =3E = =3E =3E End of Section 1=3A =3E =3E = =3E =3E Aside from questions of coding efficiency=2C there are issues of= how =3E =3E =3E access to the channel is controlled=2C which also may affec= t the =3E =3E =3E capacity=2E For example=2C a multiple-access medium with c= ollision =3E =3E =3E detection=2C avoidance=2C and recovery mechanisms has a var= ying =3E =3E capacity=3E from the point of view of the users=2E This varyin= g =3E =3E capacity depends =3E =3E =3E upon the total number of users contending for the medium=2C= = =3E how busy =3E =3E =3E the users are=2C and bounds resulting from the mechanisms =3E =3E themselves=2E=3E RF channels may also vary in capacity=2C depen= ding = =3E on = =3E =3E range=2C=3E environmental conditions=2C mobility=2C shadowing=2C= etc=2E =3E =3E = =3E =3E = =3E =3E The important points to derive from this discussion are these=3A= = =3E =3E First=2C=3E capacity is only meaningful when defined relative t= o a = =3E =3E given protocol =3E =3E =3E layer in the network=2E It is meaningless to speak of =22l= ink=22 = =3E =3E capacity=3E without qualifying exactly what is meant=2E Second= =2C =3E =3E capacity is not =3E =3E =3E necessarily fixed=2C and consequently=2C a single measure o= f =3E =3E capacity at =3E =3E =3E any layer may in fact provide a skewed picture (either =3E =3E optimistic or =3E =3E =3E pessimistic) of what is actually available=2E =3E =3E = =3E =3E = =3E =3E Section 2=2E3=2E1=2E2 =3E =3E = =3E =3E The definitions in this document refer to =22Type P=22 packets t= o =3E =3E =3E designate a particular type of flow or sets of flows=2E As= =3E =3E defined in =3E =3E =3E RFC 2330=2C Section 13=2C =22Type P=22 is a placeholder for= what may =3E =3E be an =3E =3E =3E explicit specification of the packet flows referenced by th= e =3E =3E metric=2C=3E or it may be a very loose specification encompassi= ng = =3E =3E aggregates=2E We =3E =3E =3E use the =22Type P=22 designation in these definitions in or= der to =3E =3E =3E emphasize two things=3A First=2C that the value of the capa= city =3E =3E =3E measurement depends on the types of flows referenced in the= =3E =3E =3E definition=2E This is because networks may treat packets =3E =3E differently=3E (in terms of queuing and scheduling) based on th= eir =3E =3E markings and =3E =3E =3E classification=2E Networks may also arbitrarily decide to = =3E flow- =3E =3E balance=3E based on the packet type or flow type and thereby =3E =3E affect capacity =3E =3E =3E measurements=2E Second=2C the measurement of capacity depe= nds not =3E =3E only=3E on the type of the reference packets=2C but also on the= =3E =3E types of the =3E =3E =3E packets in the =22population=22 with which the flows of int= erest = =3E share=3E =3E the links in the path=2E =3E =3E = =3E =3E = =3E =3E Section 2=2E3=2E2=2E Definition=3A IP-type-P Link Capacity =3E =3E = =3E =3E As mentioned earlier=2C this definition is affected by many fact= ors =3E =3E =3E that may change over time=2E *For example=2C a device=27s = ability to =3E =3E =3E process and forward IP packets for a particular link may ha= ve =3E =3E varying=3E effect on capacity*=2C depending on the amount or ty= pe of =3E =3E traffic being =3E =3E =3E processed=2E =3E =3E = =3E =3E = =3E =3E = =3E =3E To summarize RFC 5136=2C we define nodes as hosts=2C routers=2C = =3E Ethernet = =3E =3E switches=2Cor any other device and a link as a connection between= = =3E two of = =3E =3E these network devices or nodes=2E We then define a path P of = =3E length n = =3E =3E as a series of links (L1=2C L2=2C =2E=2E=2E=2C Ln) connecting a s= equence of = =3E nodes = =3E =3E (N1=2C N2=2C =2E=2E=2E=2C Nn+1)=2E A source S and destination D = reside at N1 and =3E =3E Nn+1=2C respectively=2E Furthermore=2C we define a link L as a s= pecial =3E =3E case where =3E =3E the path length is one=2E =3E =3E = =3E =3E Meaning=3A =3E =3E = =3E =3E - The definition of nodes have been extended from RFC 2330 to = =3E =3E include any =3E =3E devices which can impact IP datagrams =3E =3E - A link is a connection between two network devices or nodes =3E =3E - The definition of a Path (P) is a sequence of (n+1) nodes = =3E and (n) =3E =3E links for which a Source resides at N(1) and a Destination at = =3E =3E N(n+1) - The definition of a Link (L) is the case where n=3D1 = =3E =3E above=2E Thus =3E =3E it includes two devices and one link =3E =3E = =3E =3E Thus=2C the usage of a link L in this document refers to two node= s = =3E and = =3E =3E the link between those devices and not simply the link between = =3E the = =3E =3E nodes=2E When we later define the capacity of L=2C it incorporate= s = =3E the = =3E =3E complexities of both the devices and the link between them and = =3E does = =3E =3E not simply mean the =22capacity of the physical (virtual) link=22= = =3E that = =3E =3E exists between those two nodes=2E =3E =3E = =3E =3E Thanks! =3E =3E = =3E =3E -Joseph and Phil =3E =3E = =3E --Boundary_(ID_Mk2d6XEeEczcjbzB0MxpcA) 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_Mk2d6XEeEczcjbzB0MxpcA)-- From matt@internet2.edu Thu Mar 31 01:55:15 2011 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 0CDF828C0DC for ; Thu, 31 Mar 2011 01:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, 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 jnWTSrdwIN7j for ; Thu, 31 Mar 2011 01:55:14 -0700 (PDT) Received: from int-mailstore01.merit.edu (int-mailstore01.merit.edu [207.75.116.232]) by core3.amsl.com (Postfix) with ESMTP id 2480E28C1CF for ; Thu, 31 Mar 2011 01:55:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-mailstore01.merit.edu (Postfix) with ESMTP id 5B9B9305736A for ; Thu, 31 Mar 2011 04:56:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at int-mailstore01.merit.edu Received: from int-mailstore01.merit.edu ([127.0.0.1]) by localhost (int-mailstore01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tuat2eG8EGYF for ; Thu, 31 Mar 2011 04:56:49 -0400 (EDT) Received: from dhcp-431d.meeting.ietf.org (dhcp-431d.meeting.ietf.org [130.129.67.29]) by int-mailstore01.merit.edu (Postfix) with ESMTPSA id A7F03305734F for ; Thu, 31 Mar 2011 04:56:49 -0400 (EDT) Message-ID: <4D9441D0.5010200@internet2.edu> Date: Thu, 31 Mar 2011 04:56:48 -0400 From: Matthew J Zekauskas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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 Subject: [ippm] Remote Participation Details for IPPM at IETF 80 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, 31 Mar 2011 08:55:15 -0000 If you plan to join remotely, we start this afternoon (Thursday 31-Mar-2011) 1740 in Prague (which is GMT+2 or for me EDT+6). Assuming the Audio stream is working, please join it: All the latest versions of the slides received will be posted here by meeting time: Jabber info: , we'll be in ippm@jabber.ietf.org (We will monitor jabber; however, do not expect that the session will be completely scribed there!) IETF remote participation page: --Matt From andreas.a.johnsson@ericsson.com Thu Mar 31 02:16:24 2011 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 C281128C0DF for ; Thu, 31 Mar 2011 02:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_82=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 OiKT3aqqbR7k for ; Thu, 31 Mar 2011 02:16:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C1FBF3A6919 for ; Thu, 31 Mar 2011 02:16:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-37-4d9446c973b5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 07.5D.21265.9C6449D4; Thu, 31 Mar 2011 11:18:01 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.133]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 31 Mar 2011 11:18:01 +0200 From: Andreas Johnsson A To: IETF IPPM WG Date: Thu, 31 Mar 2011 11:17:58 +0200 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: AcvvgKjlV7Cr49p0RSqJ7VpQTrk/vAAATqjg Message-ID: <3B05069A569E6F4AB6397B968734EBEA0820B4297E@ESESSCMS0363.eemea.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B359@EUSAACMS0701.eamcs.ericsson.se> 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 09:16:24 -0000 U2luY2UgSSdtIG9uZSBvZiB0aGUgYXV0aG9ycyBvZiB0aGUgY2FwYWNpdHkgbWV0cmljIHBhcnRz IG9mIFkuMTU0MCB0aGF0IFhpYW5nc29uZyBhcmUgcmVmZXJyaW5nIHRvIGluIGhpcyBzbGlkZSBz ZXQsIEkgdGhpbmsgSSBzaG91bGQgc3RpY2sgbXkgaGVhZCBpbnRvIHRoaXMgZGViYXRlLg0KDQpJ biBteSB2aWV3LCBldmVyeXRoaW5nIHNlZW0gdG8gYm9pbCBkb3duIHRvIHdoZXRoZXIgd2UgYXNz dW1lIHRoYXQgdGhlIGRlZmluaXRpb24gb2YgYSBsaW5rIGluIFJGQzUxMzYgZW5jb21wYXNzIHRo ZSBpbnRlcmNvbm5lY3RlZCBob3N0cyAob3IgcGFydHMgb2YgdGhlbSkgb3Igbm90LiBYaWFuZ3Nv bmcgYmVsaWV2ZSB0aGF0IHRoZSBob3N0cyBhcmUgbm90IGluaGVyZW50bHkgcGFydCBvZiB0aGUg bGluayBjb25jZXB0IHdoaWxlIHRoZSBhdXRob3JzIG9mIHRoZSBSRkMgZG8uIFJpZ2h0PyBJIHRo aW5rIHdlIG5lZWQgdG8gY2xhcmlmeSAoc2luY2UgaXQgb2J2aW91c2x5IGlzIG5vdCBjbGVhcikg dGhpcyB2ZXJ5IGJhc2ljIHRoaW5nIG9uIHRvZGF5J3MgbWVldGluZy4gDQoNCkJlc3QgcmVnYXJk cywNCkFuZHJlYXMNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBwbS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgWGlhbmdzb25nIEN1aQ0KU2VudDogZGVuIDMxIG1hcnMgMjAxMSAxMDo1MA0KVG86IFN0ZXZl IEJhaWxsYXJnZW9uDQpDYzogQ2hpbWVudG8sIFBoaWxpcCBGLjsgSUVURiBJUFBNIFdHDQpTdWJq ZWN0OiBSZTogW2lwcG1dIEltcGFjdCBvZiBob3N0cyBvbiBuZXR3b3JrIGNhcGFjaXR5IGFuZCBS RkMgNTEzNg0KDQoNCj4gSW4gbXkgYm9vaywgdGhpcyBpcyBhIHNwZWNpYWwgY2FzZS4gDQoNCmNv dWxkIHlvdSBwbGVhc2UgZXhwbGFpbiB3aHkgdGhpcyBpcyBhIHNwZWNpYWwgY2FzZT8NCmJlY2F1 c2UgdGhlcmUgaXMgYSByb3V0ZXIgaW4gdGhlIG5ldHdvcms/DQpvciBiZWNhdXNlIHRoZSAiY2Fw YWNpdHkgb2YgdGhlIHJvdXRlciIgaXMgbGVzcyB0aGFuICJ0aGUgY2FwYWNpdHkgb2YgdGhlIGxp bmtzIg0KaWYgaXQgaXMgdGhlIGxhdHRlciwgdGhlbiB0aGVyZSBpcyBhIGRpZmZlcmVudCBjYXBh Y2l0eSBvZiB0aGUgbGluayBpbiB5b3VyIG1pbmQsIHJpZ2h0Pw0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFuZ29zbmcNCg0KSSBiZWxpZXZlIGluIG1vc3QgY2FzZXMsIHRoZSANCj4gSVAtdHlwZS1QIGxp bmsgY2FwYWNpdHkgaXMgdGhlICJJUC1sYXllciBsaW5rIHNwZWVkIi4NCj4gVGhlIGRlZmluaXRp b24gb2YgdGhlIElQLXR5cGUtUCBsaW5rIGNhcGFjaXR5IGluIFJGQzUxMzYgYWxyZWFkeSANCj4g aW5kaWNhdGVzIG9yIGltcGxpZXMgdGhlIGxpbmsgY2FwYWNpdHkgY2FuIGJlIHNtYWxsZXIgdGhh biB0aGUgImxpbmsgDQo+IHNwZWVkIi4NCj4gSXQgaXMgdXAgdG8gdGhlIGltcGxlbWVudGVyIHRv IGNob29zZSBob3cgdG8gcmVwb3J0IHRoZSBsaW5rIGNhcGFjaXR5IA0KPiBhcyB0aGV5IHNlZSBm aXQgYmFzZWQgb24gdGhlaXIgaW1wbGVtZW50YXRpb24gb3IgZW52aXJvbm1lbnQgKGUuZyANCj4g ZWZmZWN0aXZlIGxpbmsgY2FwYWNpdHkpLg0KPiBEbyB3ZSBuZWVkIHRvIGFkZCBhIG5ldyBkZWZp bml0aW9uIGNhbGxlZCBJUC1UeXBlLVAgbGluayBzcGVlZD8gSSANCj4gZG9uJ3QgYmVsaWV2ZSBz by4NCj4gDQo+IC1TdGV2ZQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogaXBwbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgDQo+IE9mIFhpYW5nc29uZyBDdWkNCj4gU2VudDogTWFyY2gtMzEtMTEgMzoyMiBB TQ0KPiBUbzogSm9zZXBoIElzaGFjDQo+IENjOiBDaGltZW50bywgUGhpbGlwIEYuOyBJRVRGIElQ UE0gV0cNCj4gU3ViamVjdDogUmU6IFtpcHBtXSBJbXBhY3Qgb2YgaG9zdHMgb24gbmV0d29yayBj YXBhY2l0eSBhbmQgUkZDIDUxMzYNCj4gDQo+IFRoZSBwcmVzZW50YXRpb24gc2xpZGVzIGlzDQo+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODAvc2xpZGVzL2lwcG0tNC5wZGYuDQo+ IA0KPiBCZXN0IFJlZ2FyZHMNCj4gWGlhbmdzb25nDQo+IA0KPiAtLS0tLSDUrdPKvP4gLS0tLS0N Cj4gt6K8/sjLOiBKb3NlcGggSXNoYWMgPGppc2hhY0BuYXNhLmdvdj4NCj4gyNXG2jog0MfG2svE LCDI/dTCIDMxyNUsIDIwMTEgyc/O5zQ6MzMNCj4g1vfM4jogW2lwcG1dIEltcGFjdCBvZiBob3N0 cyBvbiBuZXR3b3JrIGNhcGFjaXR5IGFuZCBSRkMgNTEzNg0KPiDK1bz+yMs6IElFVEYgSVBQTSBX RyA8aXBwbUBpZXRmLm9yZz4NCj4gs63LzTogIkNoaW1lbnRvLCBQaGlsaXAgRi4iIDxQaGlsaXAu Q2hpbWVudG9Aamh1YXBsLmVkdT4NCj4gDQo+ID4gRm9sa3MsDQo+ID4gDQo+ID4gVGhlcmUgaGFz IGJlZW4gc29tZSByZWNlbnQgZGViYXRlIHJlZ2FyZGluZyBSRkMgNTEzNi4gIA0KPiA+IFNwZWNp ZmljYWxseSBpZiB0aGUNCj4gPiBpbXBhY3Qgb2YgbmV0d29yayBob3N0cyBhcmUgYWNjb3VudGVk IGZvciBpbiB0aGUgZGVmaW5pdGlvbnMgb2YgDQo+ID4gbmV0d29ya2NhcGFjaXR5Lg0KPiA+IA0K PiA+IFBoaWwgYW5kIEkgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgdGhpcyBvZmYtbGlzdCBhbmQgYnkg cGhvbmUuIFdlDQo+IGJlbGlldmUNCj4gPiB0aGF0IHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBocyBm cm9tIHRoZSBSRkMgY2xlYXJseSBoaWdobGlnaHQgb3VyIA0KPiA+IGludGVudCB0byBpbmRlZWQg Y2FwdHVyZSBzdWNoIGVmZmVjdHMgYXMgdGhleSBhbGwgcmVsYXRlIHRvIHRoZQ0KPiByb2xlDQo+ ID4gb2YgZW5kcG9pbnRzIGFzIG9ubHkgYSBwb3J0aW9uIGluIGRldGVybWluaW5nIHRoZSBjYXBh Y2l0eSBvZg0KPiBhbnkNCj4gPiAibGluayIuDQo+ID4gDQo+ID4gRW5kIG9mIFNlY3Rpb24gMToN Cj4gPiANCj4gPiAgQXNpZGUgZnJvbSBxdWVzdGlvbnMgb2YgY29kaW5nIGVmZmljaWVuY3ksIHRo ZXJlIGFyZSBpc3N1ZXMgb2YgaG93DQo+ID4gPiAgIGFjY2VzcyB0byB0aGUgY2hhbm5lbCBpcyBj b250cm9sbGVkLCB3aGljaCBhbHNvIG1heSBhZmZlY3QgdGhlDQo+ID4gPiAgIGNhcGFjaXR5LiAg Rm9yIGV4YW1wbGUsIGEgbXVsdGlwbGUtYWNjZXNzIG1lZGl1bSB3aXRoIGNvbGxpc2lvbg0KPiA+ ID4gICBkZXRlY3Rpb24sIGF2b2lkYW5jZSwgYW5kIHJlY292ZXJ5IG1lY2hhbmlzbXMgaGFzIGEg dmFyeWluZw0KPiA+IGNhcGFjaXR5PiAgIGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHVz ZXJzLiAgVGhpcyB2YXJ5aW5nDQo+ID4gY2FwYWNpdHkgZGVwZW5kcw0KPiA+ID4gICB1cG9uIHRo ZSB0b3RhbCBudW1iZXIgb2YgdXNlcnMgY29udGVuZGluZyBmb3IgdGhlIG1lZGl1bSwNCj4gaG93 IGJ1c3kNCj4gPiA+ICAgdGhlIHVzZXJzIGFyZSwgYW5kIGJvdW5kcyByZXN1bHRpbmcgZnJvbSB0 aGUgbWVjaGFuaXNtcw0KPiA+IHRoZW1zZWx2ZXMuPiAgIFJGIGNoYW5uZWxzIG1heSBhbHNvIHZh cnkgaW4gY2FwYWNpdHksIGRlcGVuZGluZyANCj4gb24NCj4gPiByYW5nZSw+ICAgZW52aXJvbm1l bnRhbCBjb25kaXRpb25zLCBtb2JpbGl0eSwgc2hhZG93aW5nLCBldGMuDQo+ID4gDQo+ID4gDQo+ ID4gIFRoZSBpbXBvcnRhbnQgcG9pbnRzIHRvIGRlcml2ZSBmcm9tIHRoaXMgZGlzY3Vzc2lvbiBh cmUgdGhlc2U6IA0KPiA+IEZpcnN0LD4gICBjYXBhY2l0eSBpcyBvbmx5IG1lYW5pbmdmdWwgd2hl biBkZWZpbmVkIHJlbGF0aXZlIHRvIGEgDQo+ID4gZ2l2ZW4gcHJvdG9jb2wNCj4gPiA+ICAgbGF5 ZXIgaW4gdGhlIG5ldHdvcmsuICBJdCBpcyBtZWFuaW5nbGVzcyB0byBzcGVhayBvZiAibGluayIg DQo+ID4gY2FwYWNpdHk+ICAgd2l0aG91dCBxdWFsaWZ5aW5nIGV4YWN0bHkgd2hhdCBpcyBtZWFu dC4gIFNlY29uZCwNCj4gPiBjYXBhY2l0eSBpcyBub3QNCj4gPiA+ICAgbmVjZXNzYXJpbHkgZml4 ZWQsIGFuZCBjb25zZXF1ZW50bHksIGEgc2luZ2xlIG1lYXN1cmUgb2YNCj4gPiBjYXBhY2l0eSBh dA0KPiA+ID4gICBhbnkgbGF5ZXIgbWF5IGluIGZhY3QgcHJvdmlkZSBhIHNrZXdlZCBwaWN0dXJl IChlaXRoZXINCj4gPiBvcHRpbWlzdGljIG9yDQo+ID4gPiAgIHBlc3NpbWlzdGljKSBvZiB3aGF0 IGlzIGFjdHVhbGx5IGF2YWlsYWJsZS4NCj4gPiANCj4gPiANCj4gPiBTZWN0aW9uIDIuMy4xLjIN Cj4gPiANCj4gPiAgVGhlIGRlZmluaXRpb25zIGluIHRoaXMgZG9jdW1lbnQgcmVmZXIgdG8gIlR5 cGUgUCIgcGFja2V0cyB0bw0KPiA+ID4gICBkZXNpZ25hdGUgYSBwYXJ0aWN1bGFyIHR5cGUgb2Yg ZmxvdyBvciBzZXRzIG9mIGZsb3dzLiAgQXMNCj4gPiBkZWZpbmVkIGluDQo+ID4gPiAgIFJGQyAy MzMwLCBTZWN0aW9uIDEzLCAiVHlwZSBQIiBpcyBhIHBsYWNlaG9sZGVyIGZvciB3aGF0IG1heQ0K PiA+IGJlIGFuDQo+ID4gPiAgIGV4cGxpY2l0IHNwZWNpZmljYXRpb24gb2YgdGhlIHBhY2tldCBm bG93cyByZWZlcmVuY2VkIGJ5IHRoZQ0KPiA+IG1ldHJpYyw+ICAgb3IgaXQgbWF5IGJlIGEgdmVy eSBsb29zZSBzcGVjaWZpY2F0aW9uIGVuY29tcGFzc2luZyANCj4gPiBhZ2dyZWdhdGVzLiAgV2UN Cj4gPiA+ICAgdXNlIHRoZSAiVHlwZSBQIiBkZXNpZ25hdGlvbiBpbiB0aGVzZSBkZWZpbml0aW9u cyBpbiBvcmRlciB0bw0KPiA+ID4gICBlbXBoYXNpemUgdHdvIHRoaW5nczogRmlyc3QsIHRoYXQg dGhlIHZhbHVlIG9mIHRoZSBjYXBhY2l0eQ0KPiA+ID4gICBtZWFzdXJlbWVudCBkZXBlbmRzIG9u IHRoZSB0eXBlcyBvZiBmbG93cyByZWZlcmVuY2VkIGluIHRoZQ0KPiA+ID4gICBkZWZpbml0aW9u LiAgVGhpcyBpcyBiZWNhdXNlIG5ldHdvcmtzIG1heSB0cmVhdCBwYWNrZXRzDQo+ID4gZGlmZmVy ZW50bHk+ICAgKGluIHRlcm1zIG9mIHF1ZXVpbmcgYW5kIHNjaGVkdWxpbmcpIGJhc2VkIG9uIHRo ZWlyDQo+ID4gbWFya2luZ3MgYW5kDQo+ID4gPiAgIGNsYXNzaWZpY2F0aW9uLiAgTmV0d29ya3Mg bWF5IGFsc28gYXJiaXRyYXJpbHkgZGVjaWRlIHRvDQo+IGZsb3ctDQo+ID4gYmFsYW5jZT4gICBi YXNlZCBvbiB0aGUgcGFja2V0IHR5cGUgb3IgZmxvdyB0eXBlIGFuZCB0aGVyZWJ5DQo+ID4gYWZm ZWN0IGNhcGFjaXR5DQo+ID4gPiAgIG1lYXN1cmVtZW50cy4gIFNlY29uZCwgdGhlIG1lYXN1cmVt ZW50IG9mIGNhcGFjaXR5IGRlcGVuZHMgbm90DQo+ID4gb25seT4gICBvbiB0aGUgdHlwZSBvZiB0 aGUgcmVmZXJlbmNlIHBhY2tldHMsIGJ1dCBhbHNvIG9uIHRoZQ0KPiA+IHR5cGVzIG9mIHRoZQ0K PiA+ID4gICBwYWNrZXRzIGluIHRoZSAicG9wdWxhdGlvbiIgd2l0aCB3aGljaCB0aGUgZmxvd3Mg b2YgaW50ZXJlc3QNCj4gc2hhcmU+ID4gICB0aGUgbGlua3MgaW4gdGhlIHBhdGguDQo+ID4gDQo+ ID4gDQo+ID4gU2VjdGlvbiAyLjMuMi4gIERlZmluaXRpb246IElQLXR5cGUtUCBMaW5rIENhcGFj aXR5DQo+ID4gDQo+ID4gIEFzIG1lbnRpb25lZCBlYXJsaWVyLCB0aGlzIGRlZmluaXRpb24gaXMg YWZmZWN0ZWQgYnkgbWFueSBmYWN0b3JzDQo+ID4gPiAgIHRoYXQgbWF5IGNoYW5nZSBvdmVyIHRp bWUuICAqRm9yIGV4YW1wbGUsIGEgZGV2aWNlJ3MgYWJpbGl0eSB0bw0KPiA+ID4gICBwcm9jZXNz IGFuZCBmb3J3YXJkIElQIHBhY2tldHMgZm9yIGEgcGFydGljdWxhciBsaW5rIG1heSBoYXZlDQo+ ID4gdmFyeWluZz4gICBlZmZlY3Qgb24gY2FwYWNpdHkqLCBkZXBlbmRpbmcgb24gdGhlIGFtb3Vu dCBvciB0eXBlIG9mDQo+ID4gdHJhZmZpYyBiZWluZw0KPiA+ID4gICBwcm9jZXNzZWQuDQo+ID4g DQo+ID4gDQo+ID4gDQo+ID4gVG8gc3VtbWFyaXplIFJGQyA1MTM2LCB3ZSBkZWZpbmUgbm9kZXMg YXMgaG9zdHMsIHJvdXRlcnMsDQo+IEV0aGVybmV0DQo+ID4gc3dpdGNoZXMsb3IgYW55IG90aGVy IGRldmljZSBhbmQgYSBsaW5rIGFzIGEgY29ubmVjdGlvbiBiZXR3ZWVuDQo+IHR3byBvZg0KPiA+ IHRoZXNlIG5ldHdvcmsgZGV2aWNlcyBvciBub2Rlcy4gIFdlIHRoZW4gZGVmaW5lIGEgcGF0aCBQ IG9mDQo+IGxlbmd0aCBuDQo+ID4gYXMgYSBzZXJpZXMgb2YgbGlua3MgKEwxLCBMMiwgLi4uLCBM bikgY29ubmVjdGluZyBhIHNlcXVlbmNlIG9mDQo+IG5vZGVzDQo+ID4gKE4xLCBOMiwgLi4uLCBO bisxKS4gIEEgc291cmNlIFMgYW5kIGRlc3RpbmF0aW9uIEQgcmVzaWRlIGF0IE4xIGFuZA0KPiA+ IE5uKzEsIHJlc3BlY3RpdmVseS4gIEZ1cnRoZXJtb3JlLCB3ZSBkZWZpbmUgYSBsaW5rIEwgYXMg YSBzcGVjaWFsDQo+ID4gY2FzZSB3aGVyZQ0KPiA+IHRoZSBwYXRoIGxlbmd0aCBpcyBvbmUuDQo+ ID4gDQo+ID4gTWVhbmluZzoNCj4gPiANCj4gPiAgIC0gVGhlIGRlZmluaXRpb24gb2Ygbm9kZXMg aGF2ZSBiZWVuIGV4dGVuZGVkIGZyb20gUkZDIDIzMzAgdG8gDQo+ID4gaW5jbHVkZSBhbnkNCj4g PiAgIGRldmljZXMgd2hpY2ggY2FuIGltcGFjdCBJUCBkYXRhZ3JhbXMNCj4gPiAgIC0gQSBsaW5r IGlzIGEgY29ubmVjdGlvbiBiZXR3ZWVuIHR3byBuZXR3b3JrIGRldmljZXMgb3Igbm9kZXMNCj4g PiAgIC0gVGhlIGRlZmluaXRpb24gb2YgYSBQYXRoIChQKSBpcyBhIHNlcXVlbmNlIG9mIChuKzEp IG5vZGVzDQo+IGFuZCAobikNCj4gPiAgIGxpbmtzIGZvciB3aGljaCBhIFNvdXJjZSByZXNpZGVz IGF0IE4oMSkgYW5kIGEgRGVzdGluYXRpb24gYXQgDQo+ID4gTihuKzEpICAgLSBUaGUgZGVmaW5p dGlvbiBvZiBhIExpbmsgKEwpIGlzIHRoZSBjYXNlIHdoZXJlIG49MSANCj4gPiBhYm92ZS4gIFRo dXMNCj4gPiAgIGl0IGluY2x1ZGVzIHR3byBkZXZpY2VzIGFuZCBvbmUgbGluaw0KPiA+IA0KPiA+ IFRodXMsIHRoZSB1c2FnZSBvZiBhIGxpbmsgTCBpbiB0aGlzIGRvY3VtZW50IHJlZmVycyB0byB0 d28gbm9kZXMNCj4gYW5kDQo+ID4gdGhlIGxpbmsgYmV0d2VlbiB0aG9zZSBkZXZpY2VzIGFuZCBu b3Qgc2ltcGx5IHRoZSBsaW5rIGJldHdlZW4NCj4gdGhlDQo+ID4gbm9kZXMuIFdoZW4gd2UgbGF0 ZXIgZGVmaW5lIHRoZSBjYXBhY2l0eSBvZiBMLCBpdCBpbmNvcnBvcmF0ZXMNCj4gdGhlDQo+ID4g Y29tcGxleGl0aWVzIG9mIGJvdGggdGhlIGRldmljZXMgYW5kIHRoZSBsaW5rIGJldHdlZW4gdGhl bSBhbmQNCj4gZG9lcw0KPiA+IG5vdCBzaW1wbHkgbWVhbiB0aGUgImNhcGFjaXR5IG9mIHRoZSBw aHlzaWNhbCAodmlydHVhbCkgbGluayIgDQo+IHRoYXQNCj4gPiBleGlzdHMgYmV0d2VlbiB0aG9z ZSB0d28gbm9kZXMuDQo+ID4gDQo+ID4gVGhhbmtzIQ0KPiA+IA0KPiA+IC1Kb3NlcGggYW5kIFBo aWwNCj4gPiANCj4gDQo= From Xiangsong.Cui@huawei.com Thu Mar 31 02:34:37 2011 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 50A5C3A680E for ; Thu, 31 Mar 2011 02:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.441 X-Spam-Level: X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] 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 rMpP10Ow5ANN for ; Thu, 31 Mar 2011 02:34:36 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 2B86B3A694C for ; Thu, 31 Mar 2011 02:34:20 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00BIO1BZK5@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 04:35:59 -0500 (CDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX008481BX9H@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 04:35:59 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [130.129.16.72]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 17:35:47 +0800 Date: Thu, 31 Mar 2011 17:35:47 +0800 From: Xiangsong Cui In-reply-to: <3B05069A569E6F4AB6397B968734EBEA0820B4297E@ESESSCMS0363.eemea.ericsson.se> To: Andreas Johnsson A 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_oqQyYRULTtly1lnfYNIZ5Q)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B359@EUSAACMS0701.eamcs.ericsson.se> <3B05069A569E6F4AB6397B968734EBEA0820B4297E@ESESSCMS0363.eemea.ericsson.se> Cc: IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 09:34:37 -0000 This is a multi-part message in MIME format. --Boundary_(ID_oqQyYRULTtly1lnfYNIZ5Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline =3E = =3E In my view=2C everything seem to boil down to whether we assume that = =3E the definition of a link in RFC5136 encompass the interconnected = =3E hosts (or parts of them) or not=2E Xiangsong believe that the hosts = =3E are not inherently part of the link concept while the authors of = =3E the RFC do=2E Right=3F = Exactly! At least on my side=2E This is the essential issue=2C I think=2E I think we need to clarify (since it obviously = =3E is not clear) this very basic thing on today=27s meeting=2E = And yes=2C this is a very basic issue=2C so I propose to re-write this do= cument=2E Best regards=2C Xiangsong =3E = =3E Best regards=2C =3E Andreas =3E = =3E = =3E -----Original Message----- =3E From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf=2Eo= rg=5D On = =3E Behalf Of Xiangsong Cui =3E Sent=3A den 31 mars 2011 10=3A50 =3E To=3A Steve Baillargeon =3E Cc=3A Chimento=2C Philip F=2E=3B IETF IPPM WG =3E Subject=3A Re=3A =5Bippm=5D Impact of hosts on network capacity and R= FC 5136 =3E = =3E = =3E =3E In my book=2C this is a special case=2E = =3E = =3E could you please explain why this is a special case=3F =3E because there is a router in the network=3F =3E or because the =22capacity of the router=22 is less than =22the capac= ity = =3E of the links=22 =3E if it is the latter=2C then there is a different capacity of the = =3E link in your mind=2C right=3F =3E = =3E Best regards=2C =3E Xiangosng =3E = =3E I believe in most cases=2C the = =3E =3E IP-type-P link capacity is the =22IP-layer link speed=22=2E =3E =3E The definition of the IP-type-P link capacity in RFC5136 already = =3E =3E indicates or implies the link capacity can be smaller than the = =3E =22link = =3E =3E speed=22=2E =3E =3E It is up to the implementer to choose how to report the link = =3E capacity = =3E =3E as they see fit based on their implementation or environment = =3E (e=2Eg = =3E =3E effective link capacity)=2E =3E =3E Do we need to add a new definition called IP-Type-P link speed=3F= = =3E I = =3E =3E don=27t believe so=2E =3E =3E = =3E =3E -Steve =3E =3E = =3E =3E -----Original Message----- =3E =3E From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf= =2Eorg=5D On = =3E Behalf = =3E =3E Of Xiangsong Cui =3E =3E Sent=3A March-31-11 3=3A22 AM =3E =3E To=3A Joseph Ishac =3E =3E Cc=3A Chimento=2C Philip F=2E=3B IETF IPPM WG =3E =3E Subject=3A Re=3A =5Bippm=5D Impact of hosts on network capacity a= nd RFC 5136 =3E =3E = =3E =3E The presentation slides is =3E =3E http=3A//www=2Eietf=2Eorg/proceedings/80/slides/ippm-4=2Epdf=2E =3E =3E = =3E =3E Best Regards =3E =3E Xiangsong =3E =3E = =3E =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =3E =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C 20= 11 =C9=CF=CE=E74=3A33 =3E =3E =D6=F7=CC=E2=3A =5Bippm=5D Impact of hosts on network capacity an= d RFC 5136 =3E =3E =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E =3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChiment= o=40jhuapl=2Eedu=3E =3E =3E = =3E =3E =3E Folks=2C =3E =3E =3E = =3E =3E =3E There has been some recent debate regarding RFC 5136=2E = =3E =3E =3E Specifically if the =3E =3E =3E impact of network hosts are accounted for in the definitions = =3E of = =3E =3E =3E networkcapacity=2E =3E =3E =3E = =3E =3E =3E Phil and I have been discussing this off-list and by phone=2E= We =3E =3E believe =3E =3E =3E that the following paragraphs from the RFC clearly highlight = =3E our = =3E =3E =3E intent to indeed capture such effects as they all relate to t= he =3E =3E role =3E =3E =3E of endpoints as only a portion in determining the capacity of= =3E =3E any =3E =3E =3E =22link=22=2E =3E =3E =3E = =3E =3E =3E End of Section 1=3A =3E =3E =3E = =3E =3E =3E Aside from questions of coding efficiency=2C there are issue= s = =3E of how =3E =3E =3E =3E access to the channel is controlled=2C which also may a= ffect the =3E =3E =3E =3E capacity=2E For example=2C a multiple-access medium wi= th = =3E collision=3E =3E =3E detection=2C avoidance=2C and recovery mechani= sms has = =3E a varying =3E =3E =3E capacity=3E from the point of view of the users=2E This va= rying =3E =3E =3E capacity depends =3E =3E =3E =3E upon the total number of users contending for the mediu= m=2C =3E =3E how busy =3E =3E =3E =3E the users are=2C and bounds resulting from the mechanis= ms =3E =3E =3E themselves=2E=3E RF channels may also vary in capacity=2C = =3E depending = =3E =3E on =3E =3E =3E range=2C=3E environmental conditions=2C mobility=2C shadowi= ng=2C etc=2E =3E =3E =3E = =3E =3E =3E = =3E =3E =3E The important points to derive from this discussion are = =3E these=3A = =3E =3E =3E First=2C=3E capacity is only meaningful when defined relati= ve to = =3E a = =3E =3E =3E given protocol =3E =3E =3E =3E layer in the network=2E It is meaningless to speak of = =3E =22link=22 = =3E =3E =3E capacity=3E without qualifying exactly what is meant=2E Se= cond=2C =3E =3E =3E capacity is not =3E =3E =3E =3E necessarily fixed=2C and consequently=2C a single measu= re of =3E =3E =3E capacity at =3E =3E =3E =3E any layer may in fact provide a skewed picture (either =3E =3E =3E optimistic or =3E =3E =3E =3E pessimistic) of what is actually available=2E =3E =3E =3E = =3E =3E =3E = =3E =3E =3E Section 2=2E3=2E1=2E2 =3E =3E =3E = =3E =3E =3E The definitions in this document refer to =22Type P=22 packe= ts to =3E =3E =3E =3E designate a particular type of flow or sets of flows=2E= As =3E =3E =3E defined in =3E =3E =3E =3E RFC 2330=2C Section 13=2C =22Type P=22 is a placeholder= for what may =3E =3E =3E be an =3E =3E =3E =3E explicit specification of the packet flows referenced b= y the =3E =3E =3E metric=2C=3E or it may be a very loose specification = =3E encompassing = =3E =3E =3E aggregates=2E We =3E =3E =3E =3E use the =22Type P=22 designation in these definitions i= n order to =3E =3E =3E =3E emphasize two things=3A First=2C that the value of the = capacity =3E =3E =3E =3E measurement depends on the types of flows referenced in= the =3E =3E =3E =3E definition=2E This is because networks may treat packe= ts =3E =3E =3E differently=3E (in terms of queuing and scheduling) based o= n their =3E =3E =3E markings and =3E =3E =3E =3E classification=2E Networks may also arbitrarily decide= to =3E =3E flow- =3E =3E =3E balance=3E based on the packet type or flow type and thereb= y =3E =3E =3E affect capacity =3E =3E =3E =3E measurements=2E Second=2C the measurement of capacity = depends not =3E =3E =3E only=3E on the type of the reference packets=2C but also on= the =3E =3E =3E types of the =3E =3E =3E =3E packets in the =22population=22 with which the flows of= interest =3E =3E share=3E =3E the links in the path=2E =3E =3E =3E = =3E =3E =3E = =3E =3E =3E Section 2=2E3=2E2=2E Definition=3A IP-type-P Link Capacity =3E =3E =3E = =3E =3E =3E As mentioned earlier=2C this definition is affected by many = factors =3E =3E =3E =3E that may change over time=2E *For example=2C a device=27= s = =3E ability to =3E =3E =3E =3E process and forward IP packets for a particular link ma= y have =3E =3E =3E varying=3E effect on capacity*=2C depending on the amount o= r = =3E type of =3E =3E =3E traffic being =3E =3E =3E =3E processed=2E =3E =3E =3E = =3E =3E =3E = =3E =3E =3E = =3E =3E =3E To summarize RFC 5136=2C we define nodes as hosts=2C routers=2C= =3E =3E Ethernet =3E =3E =3E switches=2Cor any other device and a link as a connection bet= ween =3E =3E two of =3E =3E =3E these network devices or nodes=2E We then define a path P of= =3E =3E length n =3E =3E =3E as a series of links (L1=2C L2=2C =2E=2E=2E=2C Ln) connecting= a sequence of =3E =3E nodes =3E =3E =3E (N1=2C N2=2C =2E=2E=2E=2C Nn+1)=2E A source S and destinatio= n D reside at = =3E N1 and =3E =3E =3E Nn+1=2C respectively=2E Furthermore=2C we define a link L as= a special =3E =3E =3E case where =3E =3E =3E the path length is one=2E =3E =3E =3E = =3E =3E =3E Meaning=3A =3E =3E =3E = =3E =3E =3E - The definition of nodes have been extended from RFC 2330 = =3E to = =3E =3E =3E include any =3E =3E =3E devices which can impact IP datagrams =3E =3E =3E - A link is a connection between two network devices or nod= es =3E =3E =3E - The definition of a Path (P) is a sequence of (n+1) nodes= =3E =3E and (n) =3E =3E =3E links for which a Source resides at N(1) and a Destination = =3E at = =3E =3E =3E N(n+1) - The definition of a Link (L) is the case where n=3D= 1 = =3E =3E =3E above=2E Thus =3E =3E =3E it includes two devices and one link =3E =3E =3E = =3E =3E =3E Thus=2C the usage of a link L in this document refers to two = nodes =3E =3E and =3E =3E =3E the link between those devices and not simply the link betwee= n =3E =3E the =3E =3E =3E nodes=2E When we later define the capacity of L=2C it incorpo= rates =3E =3E the =3E =3E =3E complexities of both the devices and the link between them an= d =3E =3E does =3E =3E =3E not simply mean the =22capacity of the physical (virtual) lin= k=22 = =3E =3E that =3E =3E =3E exists between those two nodes=2E =3E =3E =3E = =3E =3E =3E Thanks! =3E =3E =3E = =3E =3E =3E -Joseph and Phil =3E =3E =3E = =3E =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E ippm mailing list =3E ippm=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E --Boundary_(ID_oqQyYRULTtly1lnfYNIZ5Q) 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_oqQyYRULTtly1lnfYNIZ5Q)-- From steve.baillargeon@ericsson.com Thu Mar 31 02:54:03 2011 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 661AE3A6949 for ; Thu, 31 Mar 2011 02:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_82=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 idTxlj1oR6nG for ; Thu, 31 Mar 2011 02:54:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id EF6313A680E for ; Thu, 31 Mar 2011 02:54:01 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2V9tQSL017757; Thu, 31 Mar 2011 04:55:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 31 Mar 2011 05:55:21 -0400 From: Steve Baillargeon To: Xiangsong Cui , Andreas Johnsson A Date: Thu, 31 Mar 2011 05:55:17 -0400 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: Acvvh6vy0gNJpr3SQKmq+6pqtfenCgAAEYIw Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B35F@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B359@EUSAACMS0701.eamcs.ericsson.se> <3B05069A569E6F4AB6397B968734EBEA0820B4297E@ESESSCMS0363.eemea.ericsson.se> 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 09:54:03 -0000 SXQgaXMgdXAgZm9yIGRlYmF0ZS4NCg0KTXkgcG9pbnQgaXMgdGhlIGJhc2ljIGRlZmluaXRpb25z IG9mIGEgcGF0aCBhbmQgbGluayBzaG91bGQgYmUgY29uc2lzdGVudC4NCg0KSW4gbXkgYm9vaywg YSBwYXRoIGNhbiBiZSBtYWRlIG9mIG11bHRpcGxlIGxpbmtzIGFuZCBub2RlcyBhbmQgYSBsaW5r IGlzIHNpbXBseSBhIHN1YnNldCBvZiB0aGF0IGRlZmluaXRpb24uDQpUaGlzIGlzIGFscmVhZHkg aW5kaWNhdGVkIGluIHNlY3Rpb24gMi4xIG9mIHRoZSBSRkMgNTEzNi4NCg0KDQotU3RldmUNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwcG0tYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFhpYW5nc29uZyBDdWkN ClNlbnQ6IE1hcmNoLTMxLTExIDU6MzYgQU0NClRvOiBBbmRyZWFzIEpvaG5zc29uIEENCkNjOiBJ RVRGIElQUE0gV0cNClN1YmplY3Q6IFJlOiBbaXBwbV0gSW1wYWN0IG9mIGhvc3RzIG9uIG5ldHdv cmsgY2FwYWNpdHkgYW5kIFJGQyA1MTM2DQoNCj4gDQo+IEluIG15IHZpZXcsIGV2ZXJ5dGhpbmcg c2VlbSB0byBib2lsIGRvd24gdG8gd2hldGhlciB3ZSBhc3N1bWUgdGhhdCB0aGUgDQo+IGRlZmlu aXRpb24gb2YgYSBsaW5rIGluIFJGQzUxMzYgZW5jb21wYXNzIHRoZSBpbnRlcmNvbm5lY3RlZCBo b3N0cyAob3IgDQo+IHBhcnRzIG9mIHRoZW0pIG9yIG5vdC4gWGlhbmdzb25nIGJlbGlldmUgdGhh dCB0aGUgaG9zdHMgYXJlIG5vdCANCj4gaW5oZXJlbnRseSBwYXJ0IG9mIHRoZSBsaW5rIGNvbmNl cHQgd2hpbGUgdGhlIGF1dGhvcnMgb2YgdGhlIFJGQyBkby4gDQo+IFJpZ2h0Pw0KDQpFeGFjdGx5 ISBBdCBsZWFzdCBvbiBteSBzaWRlLg0KVGhpcyBpcyB0aGUgZXNzZW50aWFsIGlzc3VlLCBJIHRo aW5rLg0KDQpJIHRoaW5rIHdlIG5lZWQgdG8gY2xhcmlmeSAoc2luY2UgaXQgb2J2aW91c2x5IA0K PiBpcyBub3QgY2xlYXIpIHRoaXMgdmVyeSBiYXNpYyB0aGluZyBvbiB0b2RheSdzIG1lZXRpbmcu IA0KDQpBbmQgeWVzLCB0aGlzIGlzIGEgdmVyeSBiYXNpYyBpc3N1ZSwgc28gSSBwcm9wb3NlIHRv IHJlLXdyaXRlIHRoaXMgZG9jdW1lbnQuDQoNCkJlc3QgcmVnYXJkcywNClhpYW5nc29uZw0KDQoN Cj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gQW5kcmVhcw0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGlwcG0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwcG0t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPiBPZiBYaWFuZ3NvbmcgQ3VpDQo+IFNlbnQ6 IGRlbiAzMSBtYXJzIDIwMTEgMTA6NTANCj4gVG86IFN0ZXZlIEJhaWxsYXJnZW9uDQo+IENjOiBD aGltZW50bywgUGhpbGlwIEYuOyBJRVRGIElQUE0gV0cNCj4gU3ViamVjdDogUmU6IFtpcHBtXSBJ bXBhY3Qgb2YgaG9zdHMgb24gbmV0d29yayBjYXBhY2l0eSBhbmQgUkZDIDUxMzYNCj4gDQo+IA0K PiA+IEluIG15IGJvb2ssIHRoaXMgaXMgYSBzcGVjaWFsIGNhc2UuIA0KPiANCj4gY291bGQgeW91 IHBsZWFzZSBleHBsYWluIHdoeSB0aGlzIGlzIGEgc3BlY2lhbCBjYXNlPw0KPiBiZWNhdXNlIHRo ZXJlIGlzIGEgcm91dGVyIGluIHRoZSBuZXR3b3JrPw0KPiBvciBiZWNhdXNlIHRoZSAiY2FwYWNp dHkgb2YgdGhlIHJvdXRlciIgaXMgbGVzcyB0aGFuICJ0aGUgY2FwYWNpdHkgb2YgDQo+IHRoZSBs aW5rcyINCj4gaWYgaXQgaXMgdGhlIGxhdHRlciwgdGhlbiB0aGVyZSBpcyBhIGRpZmZlcmVudCBj YXBhY2l0eSBvZiB0aGUgbGluayBpbiANCj4geW91ciBtaW5kLCByaWdodD8NCj4gDQo+IEJlc3Qg cmVnYXJkcywNCj4gWGlhbmdvc25nDQo+IA0KPiBJIGJlbGlldmUgaW4gbW9zdCBjYXNlcywgdGhl DQo+ID4gSVAtdHlwZS1QIGxpbmsgY2FwYWNpdHkgaXMgdGhlICJJUC1sYXllciBsaW5rIHNwZWVk Ii4NCj4gPiBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgSVAtdHlwZS1QIGxpbmsgY2FwYWNpdHkgaW4g UkZDNTEzNiBhbHJlYWR5IA0KPiA+IGluZGljYXRlcyBvciBpbXBsaWVzIHRoZSBsaW5rIGNhcGFj aXR5IGNhbiBiZSBzbWFsbGVyIHRoYW4gdGhlDQo+ICJsaW5rDQo+ID4gc3BlZWQiLg0KPiA+IEl0 IGlzIHVwIHRvIHRoZSBpbXBsZW1lbnRlciB0byBjaG9vc2UgaG93IHRvIHJlcG9ydCB0aGUgbGlu aw0KPiBjYXBhY2l0eQ0KPiA+IGFzIHRoZXkgc2VlIGZpdCBiYXNlZCBvbiB0aGVpciBpbXBsZW1l bnRhdGlvbiBvciBlbnZpcm9ubWVudA0KPiAoZS5nDQo+ID4gZWZmZWN0aXZlIGxpbmsgY2FwYWNp dHkpLg0KPiA+IERvIHdlIG5lZWQgdG8gYWRkIGEgbmV3IGRlZmluaXRpb24gY2FsbGVkIElQLVR5 cGUtUCBsaW5rIHNwZWVkPyANCj4gSQ0KPiA+IGRvbid0IGJlbGlldmUgc28uDQo+ID4gDQo+ID4g LVN0ZXZlDQo+ID4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBp cHBtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ IEJlaGFsZg0KPiA+IE9mIFhpYW5nc29uZyBDdWkNCj4gPiBTZW50OiBNYXJjaC0zMS0xMSAzOjIy IEFNDQo+ID4gVG86IEpvc2VwaCBJc2hhYw0KPiA+IENjOiBDaGltZW50bywgUGhpbGlwIEYuOyBJ RVRGIElQUE0gV0cNCj4gPiBTdWJqZWN0OiBSZTogW2lwcG1dIEltcGFjdCBvZiBob3N0cyBvbiBu ZXR3b3JrIGNhcGFjaXR5IGFuZCBSRkMgNTEzNg0KPiA+IA0KPiA+IFRoZSBwcmVzZW50YXRpb24g c2xpZGVzIGlzDQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MC9zbGlkZXMv aXBwbS00LnBkZi4NCj4gPiANCj4gPiBCZXN0IFJlZ2FyZHMNCj4gPiBYaWFuZ3NvbmcNCj4gPiAN Cj4gPiAtLS0tLSDUrdPKvP4gLS0tLS0NCj4gPiC3orz+yMs6IEpvc2VwaCBJc2hhYyA8amlzaGFj QG5hc2EuZ292Pg0KPiA+IMjVxto6INDHxtrLxCwgyP3UwiAzMcjVLCAyMDExIMnPzuc0OjMzDQo+ ID4g1vfM4jogW2lwcG1dIEltcGFjdCBvZiBob3N0cyBvbiBuZXR3b3JrIGNhcGFjaXR5IGFuZCBS RkMgNTEzNg0KPiA+IMrVvP7IyzogSUVURiBJUFBNIFdHIDxpcHBtQGlldGYub3JnPg0KPiA+ILOt y806ICJDaGltZW50bywgUGhpbGlwIEYuIiA8UGhpbGlwLkNoaW1lbnRvQGpodWFwbC5lZHU+DQo+ ID4gDQo+ID4gPiBGb2xrcywNCj4gPiA+IA0KPiA+ID4gVGhlcmUgaGFzIGJlZW4gc29tZSByZWNl bnQgZGViYXRlIHJlZ2FyZGluZyBSRkMgNTEzNi4gIA0KPiA+ID4gU3BlY2lmaWNhbGx5IGlmIHRo ZQ0KPiA+ID4gaW1wYWN0IG9mIG5ldHdvcmsgaG9zdHMgYXJlIGFjY291bnRlZCBmb3IgaW4gdGhl IGRlZmluaXRpb25zDQo+IG9mDQo+ID4gPiBuZXR3b3JrY2FwYWNpdHkuDQo+ID4gPiANCj4gPiA+ IFBoaWwgYW5kIEkgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgdGhpcyBvZmYtbGlzdCBhbmQgYnkgcGhv bmUuIFdlDQo+ID4gYmVsaWV2ZQ0KPiA+ID4gdGhhdCB0aGUgZm9sbG93aW5nIHBhcmFncmFwaHMg ZnJvbSB0aGUgUkZDIGNsZWFybHkgaGlnaGxpZ2h0DQo+IG91cg0KPiA+ID4gaW50ZW50IHRvIGlu ZGVlZCBjYXB0dXJlIHN1Y2ggZWZmZWN0cyBhcyB0aGV5IGFsbCByZWxhdGUgdG8gdGhlDQo+ID4g cm9sZQ0KPiA+ID4gb2YgZW5kcG9pbnRzIGFzIG9ubHkgYSBwb3J0aW9uIGluIGRldGVybWluaW5n IHRoZSBjYXBhY2l0eSBvZg0KPiA+IGFueQ0KPiA+ID4gImxpbmsiLg0KPiA+ID4gDQo+ID4gPiBF bmQgb2YgU2VjdGlvbiAxOg0KPiA+ID4gDQo+ID4gPiAgQXNpZGUgZnJvbSBxdWVzdGlvbnMgb2Yg Y29kaW5nIGVmZmljaWVuY3ksIHRoZXJlIGFyZSBpc3N1ZXMNCj4gb2YgaG93DQo+ID4gPiA+ICAg YWNjZXNzIHRvIHRoZSBjaGFubmVsIGlzIGNvbnRyb2xsZWQsIHdoaWNoIGFsc28gbWF5IGFmZmVj dCB0aGUNCj4gPiA+ID4gICBjYXBhY2l0eS4gIEZvciBleGFtcGxlLCBhIG11bHRpcGxlLWFjY2Vz cyBtZWRpdW0gd2l0aA0KPiBjb2xsaXNpb24+ID4gPiAgIGRldGVjdGlvbiwgYXZvaWRhbmNlLCBh bmQgcmVjb3ZlcnkgbWVjaGFuaXNtcyBoYXMNCj4gYSB2YXJ5aW5nDQo+ID4gPiBjYXBhY2l0eT4g ICBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB1c2Vycy4gIFRoaXMgdmFyeWluZw0KPiA+ ID4gY2FwYWNpdHkgZGVwZW5kcw0KPiA+ID4gPiAgIHVwb24gdGhlIHRvdGFsIG51bWJlciBvZiB1 c2VycyBjb250ZW5kaW5nIGZvciB0aGUgbWVkaXVtLA0KPiA+IGhvdyBidXN5DQo+ID4gPiA+ICAg dGhlIHVzZXJzIGFyZSwgYW5kIGJvdW5kcyByZXN1bHRpbmcgZnJvbSB0aGUgbWVjaGFuaXNtcw0K PiA+ID4gdGhlbXNlbHZlcy4+ICAgUkYgY2hhbm5lbHMgbWF5IGFsc28gdmFyeSBpbiBjYXBhY2l0 eSwgDQo+IGRlcGVuZGluZw0KPiA+IG9uDQo+ID4gPiByYW5nZSw+ICAgZW52aXJvbm1lbnRhbCBj b25kaXRpb25zLCBtb2JpbGl0eSwgc2hhZG93aW5nLCBldGMuDQo+ID4gPiANCj4gPiA+IA0KPiA+ ID4gIFRoZSBpbXBvcnRhbnQgcG9pbnRzIHRvIGRlcml2ZSBmcm9tIHRoaXMgZGlzY3Vzc2lvbiBh cmUNCj4gdGhlc2U6IA0KPiA+ID4gRmlyc3QsPiAgIGNhcGFjaXR5IGlzIG9ubHkgbWVhbmluZ2Z1 bCB3aGVuIGRlZmluZWQgcmVsYXRpdmUgdG8gDQo+IGENCj4gPiA+IGdpdmVuIHByb3RvY29sDQo+ ID4gPiA+ICAgbGF5ZXIgaW4gdGhlIG5ldHdvcmsuICBJdCBpcyBtZWFuaW5nbGVzcyB0byBzcGVh ayBvZg0KPiAibGluayIgDQo+ID4gPiBjYXBhY2l0eT4gICB3aXRob3V0IHF1YWxpZnlpbmcgZXhh Y3RseSB3aGF0IGlzIG1lYW50LiAgU2Vjb25kLA0KPiA+ID4gY2FwYWNpdHkgaXMgbm90DQo+ID4g PiA+ICAgbmVjZXNzYXJpbHkgZml4ZWQsIGFuZCBjb25zZXF1ZW50bHksIGEgc2luZ2xlIG1lYXN1 cmUgb2YNCj4gPiA+IGNhcGFjaXR5IGF0DQo+ID4gPiA+ICAgYW55IGxheWVyIG1heSBpbiBmYWN0 IHByb3ZpZGUgYSBza2V3ZWQgcGljdHVyZSAoZWl0aGVyDQo+ID4gPiBvcHRpbWlzdGljIG9yDQo+ ID4gPiA+ICAgcGVzc2ltaXN0aWMpIG9mIHdoYXQgaXMgYWN0dWFsbHkgYXZhaWxhYmxlLg0KPiA+ ID4gDQo+ID4gPiANCj4gPiA+IFNlY3Rpb24gMi4zLjEuMg0KPiA+ID4gDQo+ID4gPiAgVGhlIGRl ZmluaXRpb25zIGluIHRoaXMgZG9jdW1lbnQgcmVmZXIgdG8gIlR5cGUgUCIgcGFja2V0cyB0bw0K PiA+ID4gPiAgIGRlc2lnbmF0ZSBhIHBhcnRpY3VsYXIgdHlwZSBvZiBmbG93IG9yIHNldHMgb2Yg Zmxvd3MuICBBcw0KPiA+ID4gZGVmaW5lZCBpbg0KPiA+ID4gPiAgIFJGQyAyMzMwLCBTZWN0aW9u IDEzLCAiVHlwZSBQIiBpcyBhIHBsYWNlaG9sZGVyIGZvciB3aGF0IG1heQ0KPiA+ID4gYmUgYW4N Cj4gPiA+ID4gICBleHBsaWNpdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBwYWNrZXQgZmxvd3MgcmVm ZXJlbmNlZCBieSB0aGUNCj4gPiA+IG1ldHJpYyw+ICAgb3IgaXQgbWF5IGJlIGEgdmVyeSBsb29z ZSBzcGVjaWZpY2F0aW9uIA0KPiBlbmNvbXBhc3NpbmcNCj4gPiA+IGFnZ3JlZ2F0ZXMuICBXZQ0K PiA+ID4gPiAgIHVzZSB0aGUgIlR5cGUgUCIgZGVzaWduYXRpb24gaW4gdGhlc2UgZGVmaW5pdGlv bnMgaW4gb3JkZXIgdG8NCj4gPiA+ID4gICBlbXBoYXNpemUgdHdvIHRoaW5nczogRmlyc3QsIHRo YXQgdGhlIHZhbHVlIG9mIHRoZSBjYXBhY2l0eQ0KPiA+ID4gPiAgIG1lYXN1cmVtZW50IGRlcGVu ZHMgb24gdGhlIHR5cGVzIG9mIGZsb3dzIHJlZmVyZW5jZWQgaW4gdGhlDQo+ID4gPiA+ICAgZGVm aW5pdGlvbi4gIFRoaXMgaXMgYmVjYXVzZSBuZXR3b3JrcyBtYXkgdHJlYXQgcGFja2V0cw0KPiA+ ID4gZGlmZmVyZW50bHk+ICAgKGluIHRlcm1zIG9mIHF1ZXVpbmcgYW5kIHNjaGVkdWxpbmcpIGJh c2VkIG9uIHRoZWlyDQo+ID4gPiBtYXJraW5ncyBhbmQNCj4gPiA+ID4gICBjbGFzc2lmaWNhdGlv bi4gIE5ldHdvcmtzIG1heSBhbHNvIGFyYml0cmFyaWx5IGRlY2lkZSB0bw0KPiA+IGZsb3ctDQo+ ID4gPiBiYWxhbmNlPiAgIGJhc2VkIG9uIHRoZSBwYWNrZXQgdHlwZSBvciBmbG93IHR5cGUgYW5k IHRoZXJlYnkNCj4gPiA+IGFmZmVjdCBjYXBhY2l0eQ0KPiA+ID4gPiAgIG1lYXN1cmVtZW50cy4g IFNlY29uZCwgdGhlIG1lYXN1cmVtZW50IG9mIGNhcGFjaXR5IGRlcGVuZHMgbm90DQo+ID4gPiBv bmx5PiAgIG9uIHRoZSB0eXBlIG9mIHRoZSByZWZlcmVuY2UgcGFja2V0cywgYnV0IGFsc28gb24g dGhlDQo+ID4gPiB0eXBlcyBvZiB0aGUNCj4gPiA+ID4gICBwYWNrZXRzIGluIHRoZSAicG9wdWxh dGlvbiIgd2l0aCB3aGljaCB0aGUgZmxvd3Mgb2YgaW50ZXJlc3QNCj4gPiBzaGFyZT4gPiAgIHRo ZSBsaW5rcyBpbiB0aGUgcGF0aC4NCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBTZWN0aW9uIDIuMy4y LiAgRGVmaW5pdGlvbjogSVAtdHlwZS1QIExpbmsgQ2FwYWNpdHkNCj4gPiA+IA0KPiA+ID4gIEFz IG1lbnRpb25lZCBlYXJsaWVyLCB0aGlzIGRlZmluaXRpb24gaXMgYWZmZWN0ZWQgYnkgbWFueSBm YWN0b3JzDQo+ID4gPiA+ICAgdGhhdCBtYXkgY2hhbmdlIG92ZXIgdGltZS4gICpGb3IgZXhhbXBs ZSwgYSBkZXZpY2Uncw0KPiBhYmlsaXR5IHRvDQo+ID4gPiA+ICAgcHJvY2VzcyBhbmQgZm9yd2Fy ZCBJUCBwYWNrZXRzIGZvciBhIHBhcnRpY3VsYXIgbGluayBtYXkgaGF2ZQ0KPiA+ID4gdmFyeWlu Zz4gICBlZmZlY3Qgb24gY2FwYWNpdHkqLCBkZXBlbmRpbmcgb24gdGhlIGFtb3VudCBvcg0KPiB0 eXBlIG9mDQo+ID4gPiB0cmFmZmljIGJlaW5nDQo+ID4gPiA+ICAgcHJvY2Vzc2VkLg0KPiA+ID4g DQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gVG8gc3VtbWFyaXplIFJGQyA1MTM2LCB3ZSBkZWZpbmUg bm9kZXMgYXMgaG9zdHMsIHJvdXRlcnMsDQo+ID4gRXRoZXJuZXQNCj4gPiA+IHN3aXRjaGVzLG9y IGFueSBvdGhlciBkZXZpY2UgYW5kIGEgbGluayBhcyBhIGNvbm5lY3Rpb24gYmV0d2Vlbg0KPiA+ IHR3byBvZg0KPiA+ID4gdGhlc2UgbmV0d29yayBkZXZpY2VzIG9yIG5vZGVzLiAgV2UgdGhlbiBk ZWZpbmUgYSBwYXRoIFAgb2YNCj4gPiBsZW5ndGggbg0KPiA+ID4gYXMgYSBzZXJpZXMgb2YgbGlu a3MgKEwxLCBMMiwgLi4uLCBMbikgY29ubmVjdGluZyBhIHNlcXVlbmNlIG9mDQo+ID4gbm9kZXMN Cj4gPiA+IChOMSwgTjIsIC4uLiwgTm4rMSkuICBBIHNvdXJjZSBTIGFuZCBkZXN0aW5hdGlvbiBE IHJlc2lkZSBhdA0KPiBOMSBhbmQNCj4gPiA+IE5uKzEsIHJlc3BlY3RpdmVseS4gIEZ1cnRoZXJt b3JlLCB3ZSBkZWZpbmUgYSBsaW5rIEwgYXMgYSBzcGVjaWFsDQo+ID4gPiBjYXNlIHdoZXJlDQo+ ID4gPiB0aGUgcGF0aCBsZW5ndGggaXMgb25lLg0KPiA+ID4gDQo+ID4gPiBNZWFuaW5nOg0KPiA+ ID4gDQo+ID4gPiAgIC0gVGhlIGRlZmluaXRpb24gb2Ygbm9kZXMgaGF2ZSBiZWVuIGV4dGVuZGVk IGZyb20gUkZDIDIzMzANCj4gdG8NCj4gPiA+IGluY2x1ZGUgYW55DQo+ID4gPiAgIGRldmljZXMg d2hpY2ggY2FuIGltcGFjdCBJUCBkYXRhZ3JhbXMNCj4gPiA+ICAgLSBBIGxpbmsgaXMgYSBjb25u ZWN0aW9uIGJldHdlZW4gdHdvIG5ldHdvcmsgZGV2aWNlcyBvciBub2Rlcw0KPiA+ID4gICAtIFRo ZSBkZWZpbml0aW9uIG9mIGEgUGF0aCAoUCkgaXMgYSBzZXF1ZW5jZSBvZiAobisxKSBub2Rlcw0K PiA+IGFuZCAobikNCj4gPiA+ICAgbGlua3MgZm9yIHdoaWNoIGEgU291cmNlIHJlc2lkZXMgYXQg TigxKSBhbmQgYSBEZXN0aW5hdGlvbg0KPiBhdA0KPiA+ID4gTihuKzEpICAgLSBUaGUgZGVmaW5p dGlvbiBvZiBhIExpbmsgKEwpIGlzIHRoZSBjYXNlIHdoZXJlIG49MSANCj4gPiA+IGFib3ZlLiAg VGh1cw0KPiA+ID4gICBpdCBpbmNsdWRlcyB0d28gZGV2aWNlcyBhbmQgb25lIGxpbmsNCj4gPiA+ IA0KPiA+ID4gVGh1cywgdGhlIHVzYWdlIG9mIGEgbGluayBMIGluIHRoaXMgZG9jdW1lbnQgcmVm ZXJzIHRvIHR3byBub2Rlcw0KPiA+IGFuZA0KPiA+ID4gdGhlIGxpbmsgYmV0d2VlbiB0aG9zZSBk ZXZpY2VzIGFuZCBub3Qgc2ltcGx5IHRoZSBsaW5rIGJldHdlZW4NCj4gPiB0aGUNCj4gPiA+IG5v ZGVzLiBXaGVuIHdlIGxhdGVyIGRlZmluZSB0aGUgY2FwYWNpdHkgb2YgTCwgaXQgaW5jb3Jwb3Jh dGVzDQo+ID4gdGhlDQo+ID4gPiBjb21wbGV4aXRpZXMgb2YgYm90aCB0aGUgZGV2aWNlcyBhbmQg dGhlIGxpbmsgYmV0d2VlbiB0aGVtIGFuZA0KPiA+IGRvZXMNCj4gPiA+IG5vdCBzaW1wbHkgbWVh biB0aGUgImNhcGFjaXR5IG9mIHRoZSBwaHlzaWNhbCAodmlydHVhbCkgbGluayIgDQo+ID4gdGhh dA0KPiA+ID4gZXhpc3RzIGJldHdlZW4gdGhvc2UgdHdvIG5vZGVzLg0KPiA+ID4gDQo+ID4gPiBU aGFua3MhDQo+ID4gPiANCj4gPiA+IC1Kb3NlcGggYW5kIFBoaWwNCj4gPiA+IA0KPiA+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpcHBtIG1h aWxpbmcgbGlzdA0KPiBpcHBtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBwbQ0KPiANCg== From Xiangsong.Cui@huawei.com Thu Mar 31 03:59:06 2011 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 BC6E128C101 for ; Thu, 31 Mar 2011 03:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] 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 PhmvAMaL1We4 for ; Thu, 31 Mar 2011 03:59:05 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 447EF28C0EB for ; Thu, 31 Mar 2011 03:59:05 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00BBG598K5@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 06:00:44 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00GOU596T6@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 06:00:44 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [88.208.109.142]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 19:00:42 +0800 Date: Thu, 31 Mar 2011 19:00:42 +0800 From: Xiangsong Cui In-reply-to: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B35F@EUSAACMS0701.eamcs.ericsson.se> To: Steve Baillargeon 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_A2g3bu4HWetak6WcW1cChg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28B359@EUSAACMS0701.eamcs.ericsson.se> <3B05069A569E6F4AB6397B968734EBEA0820B4297E@ESESSCMS0363.eemea.ericsson.se> <4383945B8C24AA4FBC33555BB7B829EF0DEC28B35F@EUSAACMS0701.eamcs.ericsson.se> Cc: IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 10:59:06 -0000 This is a multi-part message in MIME format. --Boundary_(ID_A2g3bu4HWetak6WcW1cChg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline =3E = =3E My point is the basic definitions of a path and link should be = =3E consistent=2E I didn=27t get your point clearly=2C do you mean the definitions of path = and link should be same or be compatible=3F =3E In my book=2C a path can be made of multiple links and nodes and a = Yes=2C this is the basic definition=2C also in my book and RFC2330=2C a p= ath is made of links and nodes=2C but RFC5136 says path is made of ONLY l= inks=2C and without explicit nodes=2E (nodes perhaps hide inside links=2E= ) = =3E link is simply a subset of that definition=2E I guess you are speaking subpath=2C which is indicated in section 5 of RF= C2330=2E Otherwise=2C you are speaking =22LINK=22 is a subset of =22link=22 and =22= node=22=2C I cann=27t tell the diference between =22LINK=22 and =22link=22= =2E Best regards=2C Xiangsong =3E This is already indicated in section 2=2E1 of the RFC 5136=2E =3E = =3E = =3E -Steve =3E = =3E -----Original Message----- =3E From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf=2Eo= rg=5D On = =3E Behalf Of Xiangsong Cui =3E Sent=3A March-31-11 5=3A36 AM =3E To=3A Andreas Johnsson A =3E Cc=3A IETF IPPM WG =3E Subject=3A Re=3A =5Bippm=5D Impact of hosts on network capacity and R= FC 5136 =3E = =3E =3E = =3E =3E In my view=2C everything seem to boil down to whether we assume = =3E that the = =3E =3E definition of a link in RFC5136 encompass the interconnected = =3E hosts (or = =3E =3E parts of them) or not=2E Xiangsong believe that the hosts are not= = =3E =3E inherently part of the link concept while the authors of the RFC = =3E do=2E = =3E =3E Right=3F =3E = =3E Exactly! At least on my side=2E =3E This is the essential issue=2C I think=2E =3E = =3E I think we need to clarify (since it obviously = =3E =3E is not clear) this very basic thing on today=27s meeting=2E = =3E = =3E And yes=2C this is a very basic issue=2C so I propose to re-write thi= s = =3E document=2E =3E Best regards=2C =3E Xiangsong =3E = =3E = =3E =3E = =3E =3E Best regards=2C =3E =3E Andreas =3E =3E = =3E =3E = =3E =3E -----Original Message----- =3E =3E From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf= =2Eorg=5D On = =3E Behalf = =3E =3E Of Xiangsong Cui =3E =3E Sent=3A den 31 mars 2011 10=3A50 =3E =3E To=3A Steve Baillargeon =3E =3E Cc=3A Chimento=2C Philip F=2E=3B IETF IPPM WG =3E =3E Subject=3A Re=3A =5Bippm=5D Impact of hosts on network capacity a= nd RFC 5136 =3E =3E = =3E =3E = =3E =3E =3E In my book=2C this is a special case=2E = =3E =3E = =3E =3E could you please explain why this is a special case=3F =3E =3E because there is a router in the network=3F =3E =3E or because the =22capacity of the router=22 is less than =22the = =3E capacity of = =3E =3E the links=22 =3E =3E if it is the latter=2C then there is a different capacity of the = =3E link in = =3E =3E your mind=2C right=3F =3E =3E = =3E =3E Best regards=2C =3E =3E Xiangosng =3E =3E = =3E =3E I believe in most cases=2C the =3E =3E =3E IP-type-P link capacity is the =22IP-layer link speed=22=2E =3E =3E =3E The definition of the IP-type-P link capacity in RFC5136 = =3E already = =3E =3E =3E indicates or implies the link capacity can be smaller than th= e =3E =3E =22link =3E =3E =3E speed=22=2E =3E =3E =3E It is up to the implementer to choose how to report the link =3E =3E capacity =3E =3E =3E as they see fit based on their implementation or environment =3E =3E (e=2Eg =3E =3E =3E effective link capacity)=2E =3E =3E =3E Do we need to add a new definition called IP-Type-P link = =3E speed=3F = =3E =3E I =3E =3E =3E don=27t believe so=2E =3E =3E =3E = =3E =3E =3E -Steve =3E =3E =3E = =3E =3E =3E -----Original Message----- =3E =3E =3E From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40= ietf=2Eorg=5D On =3E =3E Behalf =3E =3E =3E Of Xiangsong Cui =3E =3E =3E Sent=3A March-31-11 3=3A22 AM =3E =3E =3E To=3A Joseph Ishac =3E =3E =3E Cc=3A Chimento=2C Philip F=2E=3B IETF IPPM WG =3E =3E =3E Subject=3A Re=3A =5Bippm=5D Impact of hosts on network capaci= ty and = =3E RFC 5136 =3E =3E =3E = =3E =3E =3E The presentation slides is =3E =3E =3E http=3A//www=2Eietf=2Eorg/proceedings/80/slides/ippm-4=2Epdf=2E= =3E =3E =3E = =3E =3E =3E Best Regards =3E =3E =3E Xiangsong =3E =3E =3E = =3E =3E =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =3E =3E =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =3E =3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C= 2011 =C9=CF=CE=E74=3A33 =3E =3E =3E =D6=F7=CC=E2=3A =5Bippm=5D Impact of hosts on network capacit= y and RFC 5136 =3E =3E =3E =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E =3E =3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChi= mento=40jhuapl=2Eedu=3E =3E =3E =3E = =3E =3E =3E =3E Folks=2C =3E =3E =3E =3E = =3E =3E =3E =3E There has been some recent debate regarding RFC 5136=2E = =3E =3E =3E =3E Specifically if the =3E =3E =3E =3E impact of network hosts are accounted for in the definiti= ons =3E =3E of =3E =3E =3E =3E networkcapacity=2E =3E =3E =3E =3E = =3E =3E =3E =3E Phil and I have been discussing this off-list and by phon= e=2E We =3E =3E =3E believe =3E =3E =3E =3E that the following paragraphs from the RFC clearly highli= ght =3E =3E our =3E =3E =3E =3E intent to indeed capture such effects as they all relate = to the =3E =3E =3E role =3E =3E =3E =3E of endpoints as only a portion in determining the capacit= y of =3E =3E =3E any =3E =3E =3E =3E =22link=22=2E =3E =3E =3E =3E = =3E =3E =3E =3E End of Section 1=3A =3E =3E =3E =3E = =3E =3E =3E =3E Aside from questions of coding efficiency=2C there are i= ssues =3E =3E of how =3E =3E =3E =3E =3E access to the channel is controlled=2C which also m= ay = =3E affect the =3E =3E =3E =3E =3E capacity=2E For example=2C a multiple-access mediu= m with =3E =3E collision=3E =3E =3E detection=2C avoidance=2C and recovery mec= hanisms has =3E =3E a varying =3E =3E =3E =3E capacity=3E from the point of view of the users=2E Thi= s varying =3E =3E =3E =3E capacity depends =3E =3E =3E =3E =3E upon the total number of users contending for the m= edium=2C =3E =3E =3E how busy =3E =3E =3E =3E =3E the users are=2C and bounds resulting from the mech= anisms =3E =3E =3E =3E themselves=2E=3E RF channels may also vary in capacity=2C= = =3E =3E depending =3E =3E =3E on =3E =3E =3E =3E range=2C=3E environmental conditions=2C mobility=2C sha= dowing=2C etc=2E =3E =3E =3E =3E = =3E =3E =3E =3E = =3E =3E =3E =3E The important points to derive from this discussion are =3E =3E these=3A = =3E =3E =3E =3E First=2C=3E capacity is only meaningful when defined re= lative = =3E to = =3E =3E a =3E =3E =3E =3E given protocol =3E =3E =3E =3E =3E layer in the network=2E It is meaningless to speak= of =3E =3E =22link=22 = =3E =3E =3E =3E capacity=3E without qualifying exactly what is meant=2E= Second=2C =3E =3E =3E =3E capacity is not =3E =3E =3E =3E =3E necessarily fixed=2C and consequently=2C a single m= easure of =3E =3E =3E =3E capacity at =3E =3E =3E =3E =3E any layer may in fact provide a skewed picture (eit= her =3E =3E =3E =3E optimistic or =3E =3E =3E =3E =3E pessimistic) of what is actually available=2E =3E =3E =3E =3E = =3E =3E =3E =3E = =3E =3E =3E =3E Section 2=2E3=2E1=2E2 =3E =3E =3E =3E = =3E =3E =3E =3E The definitions in this document refer to =22Type P=22 p= ackets to =3E =3E =3E =3E =3E designate a particular type of flow or sets of flow= s=2E As =3E =3E =3E =3E defined in =3E =3E =3E =3E =3E RFC 2330=2C Section 13=2C =22Type P=22 is a placeho= lder for what may =3E =3E =3E =3E be an =3E =3E =3E =3E =3E explicit specification of the packet flows referenc= ed by the =3E =3E =3E =3E metric=2C=3E or it may be a very loose specification = =3E =3E encompassing =3E =3E =3E =3E aggregates=2E We =3E =3E =3E =3E =3E use the =22Type P=22 designation in these definitio= ns in = =3E order to =3E =3E =3E =3E =3E emphasize two things=3A First=2C that the value of = the capacity =3E =3E =3E =3E =3E measurement depends on the types of flows reference= d in the =3E =3E =3E =3E =3E definition=2E This is because networks may treat p= ackets =3E =3E =3E =3E differently=3E (in terms of queuing and scheduling) bas= ed on = =3E their=3E =3E =3E markings and =3E =3E =3E =3E =3E classification=2E Networks may also arbitrarily de= cide to =3E =3E =3E flow- =3E =3E =3E =3E balance=3E based on the packet type or flow type and th= ereby =3E =3E =3E =3E affect capacity =3E =3E =3E =3E =3E measurements=2E Second=2C the measurement of capac= ity = =3E depends not =3E =3E =3E =3E only=3E on the type of the reference packets=2C but als= o on the =3E =3E =3E =3E types of the =3E =3E =3E =3E =3E packets in the =22population=22 with which the flow= s of interest =3E =3E =3E share=3E =3E the links in the path=2E =3E =3E =3E =3E = =3E =3E =3E =3E = =3E =3E =3E =3E Section 2=2E3=2E2=2E Definition=3A IP-type-P Link Capaci= ty =3E =3E =3E =3E = =3E =3E =3E =3E As mentioned earlier=2C this definition is affected by m= any = =3E factors=3E =3E =3E =3E that may change over time=2E *For example=2C= a device=27s =3E =3E ability to =3E =3E =3E =3E =3E process and forward IP packets for a particular lin= k may = =3E have=3E =3E =3E varying=3E effect on capacity*=2C depending on the = amount or =3E =3E type of =3E =3E =3E =3E traffic being =3E =3E =3E =3E =3E processed=2E =3E =3E =3E =3E = =3E =3E =3E =3E = =3E =3E =3E =3E = =3E =3E =3E =3E To summarize RFC 5136=2C we define nodes as hosts=2C rout= ers=2C =3E =3E =3E Ethernet =3E =3E =3E =3E switches=2Cor any other device and a link as a connection= between =3E =3E =3E two of =3E =3E =3E =3E these network devices or nodes=2E We then define a path = P of =3E =3E =3E length n =3E =3E =3E =3E as a series of links (L1=2C L2=2C =2E=2E=2E=2C Ln) connec= ting a sequence of =3E =3E =3E nodes =3E =3E =3E =3E (N1=2C N2=2C =2E=2E=2E=2C Nn+1)=2E A source S and destin= ation D reside at =3E =3E N1 and =3E =3E =3E =3E Nn+1=2C respectively=2E Furthermore=2C we define a link = L as a = =3E special=3E =3E =3E case where =3E =3E =3E =3E the path length is one=2E =3E =3E =3E =3E = =3E =3E =3E =3E Meaning=3A =3E =3E =3E =3E = =3E =3E =3E =3E - The definition of nodes have been extended from RFC 2= 330 =3E =3E to =3E =3E =3E =3E include any =3E =3E =3E =3E devices which can impact IP datagrams =3E =3E =3E =3E - A link is a connection between two network devices or= nodes =3E =3E =3E =3E - The definition of a Path (P) is a sequence of (n+1) n= odes =3E =3E =3E and (n) =3E =3E =3E =3E links for which a Source resides at N(1) and a Destinat= ion =3E =3E at =3E =3E =3E =3E N(n+1) - The definition of a Link (L) is the case where= = =3E n=3D1 = =3E =3E =3E =3E above=2E Thus =3E =3E =3E =3E it includes two devices and one link =3E =3E =3E =3E = =3E =3E =3E =3E Thus=2C the usage of a link L in this document refers to = two nodes =3E =3E =3E and =3E =3E =3E =3E the link between those devices and not simply the link be= tween =3E =3E =3E the =3E =3E =3E =3E nodes=2E When we later define the capacity of L=2C it inc= orporates =3E =3E =3E the =3E =3E =3E =3E complexities of both the devices and the link between the= m and =3E =3E =3E does =3E =3E =3E =3E not simply mean the =22capacity of the physical (virtual)= = =3E link=22 = =3E =3E =3E that =3E =3E =3E =3E exists between those two nodes=2E =3E =3E =3E =3E = =3E =3E =3E =3E Thanks! =3E =3E =3E =3E = =3E =3E =3E =3E -Joseph and Phil =3E =3E =3E =3E = =3E =3E =3E = =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E ippm mailing list =3E =3E ippm=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E =3E = =3E --Boundary_(ID_A2g3bu4HWetak6WcW1cChg) 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_A2g3bu4HWetak6WcW1cChg)-- From philip.chimento@jhuapl.edu Thu Mar 31 06:43:33 2011 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 4D89D28C0F2 for ; Thu, 31 Mar 2011 06:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=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 1tQYBK518fcO for ; Thu, 31 Mar 2011 06:43:31 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) by core3.amsl.com (Postfix) with ESMTP id 15B493A687F for ; Thu, 31 Mar 2011 06:43:30 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.112781202; Thu, 31 Mar 2011 09:44:03 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 31 Mar 2011 09:44:23 -0400 From: "Chimento, Philip F." To: Xiangsong Cui , Joseph Ishac Date: Thu, 31 Mar 2011 09:44:20 -0400 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: AcvvdCaEvnj60sbnR0Sb1/yI66ianwANZXq5 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9B9FD7496E1PhilipChimentojhuapledu_" MIME-Version: 1.0 Cc: IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 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, 31 Mar 2011 13:43:33 -0000 --_000_C9B9FD7496E1PhilipChimentojhuapledu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Xiangsong: Please see my comments below. On 3/31/11 3:20 AM, "Xiangsong Cui" wrote: >> >> >> The important points to derive from this discussion are these: >> First,> capacity is only meaningful when defined relative to a >> given protocol >>> layer in the network. It is meaningless to speak of "link" >> capacity> without qualifying exactly what is meant. Second, >> capacity is not >>> necessarily fixed, and consequently, a single measure of >> capacity at >>> any layer may in fact provide a skewed picture (either >> optimistic or >>> pessimistic) of what is actually available. > > I almost agree this paragraph, and I just want to focus on "IP-layer" her= e. > I am not sure what you mean by =93almost agree=94. What part of it do you d= isagree with? >> >> >> Section 2.3.1.2 >> >> The definitions in this document refer to "Type P" packets to >>> designate a particular type of flow or sets of flows. As >> defined in >>> RFC 2330, Section 13, "Type P" is a placeholder for what may >> be an >>> explicit specification of the packet flows referenced by the >> metric,> or it may be a very loose specification encompassing >> aggregates. We >>> use the "Type P" designation in these definitions in order to >>> emphasize two things: First, that the value of the capacity >>> measurement depends on the types of flows referenced in the >>> definition. This is because networks may treat packets >> differently> (in terms of queuing and scheduling) based on their >> markings and >>> classification. Networks may also arbitrarily decide to flow- >> balance> based on the packet type or flow type and thereby >> affect capacity >>> measurements. Second, the measurement of capacity depends not >> only> on the type of the reference packets, but also on the >> types of the >>> packets in the "population" with which the flows of interest share >>> the links in the path. >> > > I have no problem with "Type-P packet". > What is more, I think above statement has no relation to our debate. > I think that perhaps you have missed the point of this paragraph: It is not= only the nodal capacity that has to be factored in. The capacity that any flow =93se= es=94 is also affected by how the node is configured to treat the packets. = In a time of no congestion, where the flow is low priority, say the capacit= y available to it is X. In a time of congestion, where there are higher pri= ority flows of capacity Z, the capacity available to the low priority flow = is X-Z, not X. >> >> Section 2.3.2. Definition: IP-type-P Link Capacity >> >> As mentioned earlier, this definition is affected by many factors >>> that may change over time. *For example, a device's ability to >>> process and forward IP packets for a particular link may have >> varying> effect on capacity*, depending on the amount or type of >> traffic being >>> processed. >> > > Yes, I get your point here. However, that is exactly my concern. > You mean you combined (or say enbeded) nodes inside link, right? > I just don'think this is appropriate. No. We are not saying that the nodes are embedded in the link. We are sayin= g that the endpoint is part of the link. > >> >> >> To summarize RFC 5136, we define nodes as hosts, routers, Ethernet >> switches,or any other device and a link as a connection between >> two of these >> network devices or nodes. 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. Furthermore, we define a link L as a special >> case where >> the path length is one. >> >> Meaning: >> >> - The definition of nodes have been extended from RFC 2330 to >> include any >> devices which can impact IP datagrams >> - A link is a connection between two network devices or nodes > > Do you mean the "link" is exactly the connection between nodes? > Or you mean the link is the "combination" of "the connection between node= s" + > "the nodes themselves"? > >> - The definition of a Path (P) is a sequence of (n+1) nodes and (n) >> links for which a Source resides at N(1) and a Destination at >> N(n+1) - The definition of a Link (L) is the case where n=3D1 >> above. Thus >> it includes two devices and one link >> >> Thus, the usage of a link L in this document refers to two nodes and >> the link between those devices and not simply the link between the >> nodes. > > Let me try to understand your words, there are three "link" in this sente= nce. > "LINK L", yes, I get it. > There are also & between the nodes>, I'm fully confused now, do you mean "link L" is NOT a > link? I don't think people would understand this well. > I can see how this sentence can be confusing and I can see how re-wording c= ould clear up the confusion. However, we do not need a new draft to do that= . > > When we later define the capacity of L, it incorporates the > > So you are speaking "the capacity of L" is NOT "the capacity of a link", = but > capacity of something else, right? Then, what is its meaning for people w= ho > are only familiar with normal "link", "node" and "path" concept? > We already say in the beginning of section 2.1 that we are modifying the de= finitions of Link and Path from what they were in RFC2330. You may not agre= e with how we have modified them, but we made it clear that we were changin= g the definitions. > By the way, could you please answer my questions in my presentation slide= s? > In slide 7, > > ! Link1 capacity (IP layer), 0.99 M or 990 M? Link 1 IP Layer capacity is 0.99Mb/s > ! Link1 utilization (IP layer), 0.1% or 100%? IP Layer Utilization is 100% > ! Link2 capacity (IP layer), 0.99 M or 99 M? Is the router only capable of forwarding 1Mb/s on link 2? The answer depends on that. > ! Link2 utilization (IP layer), 1% or 100%? > ! Path (Src to Dst) capacity (IP layer)? 0.99 > ! Available path capacity (IP layer)? 0 > It is clear that your view is that what we call Nominal Capacity is the sam= e as IP Layer capacity. We explicitly differentiate these two concepts. > Thanks and best regards, > Xiangsong > >> complexities of both the devices and the link between them and >> does not >> simply mean the "capacity of the physical (virtual) link" that exists >> between those two nodes. >> >> Thanks! >> >> -Joseph and Phil >> Regards, Phil Chimento JHU/APL 240-228-1743 443-778-1743 Philip.Chimento@jhuapl.edu -- --_000_C9B9FD7496E1PhilipChimentojhuapledu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: [ippm] Impact of hosts on network capacity and RFC 5136</ti= tle> </head> <body> <font face=3D"Lucida Bright"><span style=3D"font-size:9pt">Xiangsong: <br> <br> Please see my comments below. <br> <br> On 3/31/11 3:20 AM, "Xiangsong Cui" <<a href=3D"Xiangsong.Cui@= huawei.com">Xiangsong.Cui@huawei.com</a>> wrote:<br> <br> <font color=3D"#008000">>> <br> >> <br> >>  The important points to derive from this discussion are thes= e: <br> >> First,>   capacity is only meaningful when defined re= lative to a <br> >> given protocol<br> </font><font color=3D"#FF0000">>>>   layer in the networ= k.  It is meaningless to speak of "link" <br> </font><font color=3D"#008000">>> capacity>   without qu= alifying exactly what is meant.  Second, <br> >> capacity is not<br> </font><font color=3D"#FF0000">>>>   necessarily fixed, = and consequently, a single measure of <br> </font><font color=3D"#008000">>> capacity at<br> </font><font color=3D"#FF0000">>>>   any layer may in fa= ct provide a skewed picture (either <br> </font><font color=3D"#008000">>> optimistic or<br> </font><font color=3D"#FF0000">>>>   pessimistic) of wha= t is actually available.<br> </font><font color=3D"#0000FF">> <br> > I almost agree this paragraph, and I just want to focus on "IP-la= yer" here.<br> > <br> </font><font color=3D"#800080">I am not sure what you mean by =93almost agr= ee=94. What part of it do you disagree with? <br> </font><font color=3D"#008000">>> <br> >> <br> >> Section 2.3.1.2<br> >> <br> >>  The definitions in this document refer to "Type P"= packets to<br> </font><font color=3D"#FF0000">>>>   designate a particu= lar type of flow or sets of flows.  As <br> </font><font color=3D"#008000">>> defined in<br> </font><font color=3D"#FF0000">>>>   RFC 2330, Section 1= 3, "Type P" is a placeholder for what may <br> </font><font color=3D"#008000">>> be an<br> </font><font color=3D"#FF0000">>>>   explicit specificat= ion of the packet flows referenced by the <br> </font><font color=3D"#008000">>> metric,>   or it may b= e a very loose specification encompassing <br> >> aggregates.  We<br> </font><font color=3D"#FF0000">>>>   use the "Type = P" designation in these definitions in order to<br> >>>   emphasize two things: First, that the value of the= capacity<br> >>>   measurement depends on the types of flows referenc= ed in the<br> >>>   definition.  This is because networks may tre= at packets <br> </font><font color=3D"#008000">>> differently>   (in ter= ms of queuing and scheduling) based on their <br> >> markings and<br> </font><font color=3D"#FF0000">>>>   classification. &nb= sp;Networks may also arbitrarily decide to flow-<br> </font><font color=3D"#008000">>> balance>   based on th= e packet type or flow type and thereby <br> >> affect capacity<br> </font><font color=3D"#FF0000">>>>   measurements.  = ;Second, the measurement of capacity depends not <br> </font><font color=3D"#008000">>> only>   on the type of= the reference packets, but also on the <br> >> types of the<br> </font><font color=3D"#FF0000">>>>   packets in the &quo= t;population" with which the flows of interest share<br> >>>   the links in the path.<br> </font><font color=3D"#008000">>> <br> </font><font color=3D"#0000FF">> <br> > I have no problem with "Type-P packet".<br> > What is more, I think above statement has no relation to our debate.<b= r> > <br> </font><font color=3D"#800080">I think that perhaps you have missed the poi= nt of this paragraph: It is not only the<br> nodal capacity that has to be factored in. The capacity that any flow =93se= es=94 is also affected by <b>how the node is configured to treat the packet= s</b>. In a time of no congestion, where the flow is low priority, say the = capacity available to it is X. In a time of congestion, where there are hig= her priority flows of capacity Z, the capacity available to the low priorit= y flow is X-Z, not X. <br> </font><font color=3D"#008000">>> <br> >> Section 2.3.2.  Definition: IP-type-P Link Capacity<br> >> <br> >>  As mentioned earlier, this definition is affected by many fa= ctors<br> </font><font color=3D"#FF0000">>>>   that may change ove= r time.  *For example, a device's ability to<br> >>>   process and forward IP packets for a particular li= nk may have <br> </font><font color=3D"#008000">>> varying>   effect on c= apacity*, depending on the amount or type of <br> >> traffic being<br> </font><font color=3D"#FF0000">>>>   processed.<br> </font><font color=3D"#008000">>> <br> </font><font color=3D"#0000FF">> <br> > Yes, I get your point here. However, that is exactly my concern.<br> > You mean you combined (or say enbeded) nodes inside link, right?<br> > I just don'think this is appropriate.<br> <br> </font><font color=3D"#800080">No. We are not saying that the nodes are emb= edded in the link. We are saying that the endpoint is part of the link. <br= > </font><font color=3D"#0000FF">> <br> </font><font color=3D"#008000">>> <br> >> <br> >> To summarize RFC 5136, we define nodes as hosts, routers, Ethernet= <br> >> switches,or any other device and a link as a connection between <b= r> >> two of these<br> >> network devices or nodes.  We then define a path P of length = n as <br> >> a series<br> >> of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2,= <br> >> ..., Nn+1).  A source S and destination D reside at N1 an= d<br> >> Nn+1, respectively.  Furthermore, we define a link L as a= special <br> >> case where<br> >> the path length is one.<br> >> <br> >> Meaning:<br> >> <br> >>   - The definition of nodes have been extended from RFC = 2330 to <br> >> include any<br> >>   devices which can impact IP datagrams<br> >>   - A link is a connection between two network devices o= r nodes<br> </font><font color=3D"#0000FF">> <br> > Do you mean the "link" is exactly the connection between nod= es?<br> > Or you mean the link is the "combination" of "the conne= ction between nodes" + <br> > "the nodes themselves"?<br> > <br> </font><font color=3D"#008000">>>   - The definition of a P= ath (P) is a sequence of (n+1) nodes and (n)<br> >>   links for which a Source resides at N(1) and a Destina= tion at <br> >> N(n+1)   - The definition of a Link (L) is the case = where n=3D1 <br> >> above.  Thus<br> >>   it includes two devices and one link<br> >> <br> >> Thus, the usage of a link L in this document refers to two nodes a= nd<br> >> the link between those devices and not simply the link between the= <br> >> nodes. <br> </font><font color=3D"#0000FF">> <br> > Let me try to understand your words, there are three "link" = in this sentence.<br> > "LINK L", yes, I get it.<br> > There are also <and the "link" between those devices> = & <not simply the "link" <br> > between the nodes>, I'm fully confused now, do you mean "link = L" is NOT a <br> > link? I don't think people would understand this well.<br> > <br> </font><font color=3D"#800080">I can see how this sentence can be confusing= and I can see how re-wording could clear up the confusion. However, we do = not need a new draft to do that. <br> </font><font color=3D"#0000FF">> <br> > When we later define the capacity of L, it incorporates the<br> > <br> > So you are speaking "the capacity of L" is NOT "the cap= acity of a link", but <br> > capacity of something else, right? Then, what is its meaning for peopl= e who <br> > are only familiar with normal "link", "node" and &= quot;path" concept?<br> > <br> </font><font color=3D"#800080">We already say in the beginning of section 2= .1 that we are modifying the definitions of Link and Path from what they we= re in RFC2330. You may not agree with how we have modified them, but we mad= e it clear that we were changing the definitions. <br> </font><font color=3D"#0000FF"><br> > By the way, could you please answer my questions in my presentation sl= ides?<br> > In slide 7,<br> > <br> > ! Link1 capacity (IP layer), 0.99 M or 990 M?<br> </font><font color=3D"#800080">Link 1 IP  Layer capacity is 0.99Mb/s <= br> </font><font color=3D"#0000FF">> ! Link1 utilization (IP layer), 0.1% or= 100%? <br> </font><font color=3D"#800080">IP Layer Utilization is 100%</font><font col= or=3D"#0000FF"> <br> > ! Link2 capacity (IP layer), 0.99 M or 99 M?  <br> </font><font color=3D"#800080">Is the router only capable of forwarding 1Mb= /s on link 2?  <br> The answer depends on that. </font><font color=3D"#0000FF">   <br= > > ! Link2 utilization (IP layer), 1% or 100%?     &n= bsp;<br> > ! Path (Src to Dst) capacity (IP layer)? <br> </font><font color=3D"#800080">0.99</font><font color=3D"#0000FF">  &n= bsp;    <br> > ! Available path capacity (IP layer)?  <br> </font><font color=3D"#800080">0</font><font color=3D"#0000FF">   = ;   <br> > <br> </font><font color=3D"#800080">It is clear that your view is that what we c= all Nominal Capacity is the same as IP Layer capacity. We explicitly differ= entiate these two concepts. <br> </font><font color=3D"#0000FF"><br> > Thanks and best regards,<br> > Xiangsong<br> > <br> </font><font color=3D"#008000">>> complexities of both the devices an= d the link between them and <br> >> does not<br> >> simply mean the "capacity of the physical (virtual) link"= ; that exists<br> >> between those two nodes.<br> >> <br> >> Thanks!<br> >> <br> >> -Joseph and Phil<br> >> <br> </font><br> Regards, <br> Phil Chimento<br> <br> JHU/APL<br> 240-228-1743<br> 443-778-1743<br> <a href=3D"Philip.Chimento@jhuapl.edu">Philip.Chimento@jhuapl.edu</a><br> -- <br> <br> </span></font> </body> </html> --_000_C9B9FD7496E1PhilipChimentojhuapledu_-- From philip.chimento@jhuapl.edu Thu Mar 31 06:56:49 2011 Return-Path: <philip.chimento@jhuapl.edu> 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 EAB623A6B1A for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 06:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, 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 1s-qK3Mg9ImI for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 06:56:49 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) by core3.amsl.com (Postfix) with ESMTP id E39173A6B10 for <ippm@ietf.org>; Thu, 31 Mar 2011 06:56:48 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.112782886; Thu, 31 Mar 2011 09:58:05 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 31 Mar 2011 09:58:25 -0400 From: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> To: IETF IPPM WG <ippm@ietf.org> Date: Thu, 31 Mar 2011 09:58:21 -0400 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: Acvvq7GztHne9oeW8EWXkQWYJnxd1A== Message-ID: <C9BA00BD.96E5%Philip.Chimento@jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 13:56:50 -0000 Andreas:=20 We believe that the definition of capacity for "network section" in Y.1540 is the equivalent (roughly) of how we define it for "link" in RFC 5136. As Joseph has pointed out, we define "link" as a "path" of length 1. I do not believe that there is a fundamental conflict between the RFC 5136 and the Y.1540 definitions. Regards,=20 Phil Chimento JHU/APL 240-228-1743 443-778-1743 Philip.Chimento@jhuapl.edu --=20 From Xiangsong.Cui@huawei.com Thu Mar 31 07:08:21 2011 Return-Path: <Xiangsong.Cui@huawei.com> 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 9CA1F3A6AD7 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=0.945, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=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 zfsGWRmeFOcq for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:08:20 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 24FF13A6A92 for <ippm@ietf.org>; Thu, 31 Mar 2011 07:08:20 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00B3PE0N8U@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 09:09:59 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX002WPE0L6O@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 09:09:59 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [88.208.109.142]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 22:09:57 +0800 Date: Thu, 31 Mar 2011 22:09:57 +0800 From: Xiangsong Cui <Xiangsong.Cui@huawei.com> In-reply-to: <C9B9FD74.96E1%Philip.Chimento@jhuapl.edu> To: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> Message-id: <fd3bec306873.6873fd3bec30@huawei.com> 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_GenQbVnRqnCTIVYMChQz6Q)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <fdcfb65e1f5.1f5fdcfb65e@huawei.com> <C9B9FD74.96E1%Philip.Chimento@jhuapl.edu> Cc: IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 14:08:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_GenQbVnRqnCTIVYMChQz6Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline =3E =3E=3E The important points to derive from this discussion are these= =3A =3E =3E=3E First=2C=3E capacity is only meaningful when defined relativ= e to a =3E =3E=3E given protocol =3E =3E=3E=3E layer in the network=2E It is meaningless to speak of =22= link=22 =3E =3E=3E capacity=3E without qualifying exactly what is meant=2E Sec= ond=2C =3E =3E=3E capacity is not =3E =3E=3E=3E necessarily fixed=2C and consequently=2C a single measure= of =3E =3E=3E capacity at =3E =3E=3E=3E any layer may in fact provide a skewed picture (either =3E =3E=3E optimistic or =3E =3E=3E=3E pessimistic) of what is actually available=2E =3E =3E =3E =3E I almost agree this paragraph=2C and I just want to focus on =22I= P- =3E layer=22 here=2E =3E =3E =3E I am not sure what you mean by =A1=B0almost agree=A1=B1=2E What part = of it do = =3E you disagree with=3F The reason that I said =22almost=22 is the text from RFC2330=2C (copied b= elow) =22Such a metric will be called an =27analytically specified metric=27= or=2C more simply=2C an analytical metric=2E =7BComment=3A Examples of such analytical metrics might include=3A propagation time of a link The time=2C in seconds=2C required by a single bit to travel from th= e output port on one Internet host across a single link to another Internet host=2E bandwidth of a link for packets of size k The capacity=2C in bits/second=2C where only those bits of the IP packet are counted=2C for packets of size k bytes=2E routeThe path=2C as defined in Section 5=2C from A to B at a given time=2E= hop count of a route The value =27n=27 of the route path=2E =7D=22 But your above statement doesn=27t clearly show that it is an analytical = metric to me=2E =3E =3E=3E =3E =3E=3E =3E =3E=3E Section 2=2E3=2E1=2E2 =3E =3E=3E =3E =3E=3E The definitions in this document refer to =22Type P=22 packet= s to =3E =3E=3E=3E designate a particular type of flow or sets of flows=2E = As =3E =3E=3E defined in =3E =3E=3E=3E RFC 2330=2C Section 13=2C =22Type P=22 is a placeholder f= or what may =3E =3E=3E be an =3E =3E=3E=3E explicit specification of the packet flows referenced by = the =3E =3E=3E metric=2C=3E or it may be a very loose specification encompa= ssing =3E =3E=3E aggregates=2E We =3E =3E=3E=3E use the =22Type P=22 designation in these definitions in = order to =3E =3E=3E=3E emphasize two things=3A First=2C that the value of the ca= pacity =3E =3E=3E=3E measurement depends on the types of flows referenced in t= he =3E =3E=3E=3E definition=2E This is because networks may treat packets= =3E =3E=3E differently=3E (in terms of queuing and scheduling) based on= their =3E =3E=3E markings and =3E =3E=3E=3E classification=2E Networks may also arbitrarily decide t= o = =3E flow- =3E =3E=3E balance=3E based on the packet type or flow type and thereby= =3E =3E=3E affect capacity =3E =3E=3E=3E measurements=2E Second=2C the measurement of capacity de= pends not =3E =3E=3E only=3E on the type of the reference packets=2C but also on = the =3E =3E=3E types of the =3E =3E=3E=3E packets in the =22population=22 with which the flows of i= nterest = =3E share=3E=3E=3E the links in the path=2E =3E =3E=3E =3E =3E =3E =3E I have no problem with =22Type-P packet=22=2E =3E =3E What is more=2C I think above statement has no relation to our de= bate=2E =3E =3E =3E I think that perhaps you have missed the point of this paragraph=3A = =3E It is not only the =3E nodal capacity that has to be factored in=2E The capacity that any = =3E flow =A1=B0sees=A1=B1 is also affected by how the node is configured = to = =3E treat the packets=2E In a time of no congestion=2C where the flow is = =3E low priority=2C say the capacity available to it is X=2E In a time of= = =3E congestion=2C where there are higher priority flows of capacity Z=2C = =3E the capacity available to the low priority flow is X-Z=2C not X=2E =3E =3E=3E =3E =3E=3E Section 2=2E3=2E2=2E Definition=3A IP-type-P Link Capacity =3E =3E=3E =3E =3E=3E As mentioned earlier=2C this definition is affected by many f= actors =3E =3E=3E=3E that may change over time=2E *For example=2C a device=27= s ability to =3E =3E=3E=3E process and forward IP packets for a particular link may = have =3E =3E=3E varying=3E effect on capacity*=2C depending on the amount or= type of =3E =3E=3E traffic being =3E =3E=3E=3E processed=2E =3E =3E=3E =3E =3E =3E =3E Yes=2C I get your point here=2E However=2C that is exactly my con= cern=2E =3E =3E You mean you combined (or say enbeded) nodes inside link=2C right= =3F =3E =3E I just don=27think this is appropriate=2E =3E = =3E No=2E We are not saying that the nodes are embedded in the link=2E We= = =3E are saying that the endpoint is part of the link=2E Yes=2C I do make sure you are saying node is part of the link now=2E Do you think this is a major change to RFC2330 and RFC2460=3F This is also very different from the definition from Y=2E1540=2E And by the way=2C in my example=2C which link the router should belong to= =3F Link 1 or Link 2=3F Best regards=2C Xiangsong =3E =3E =3E =3E=3E =3E =3E=3E =3E =3E=3E To summarize RFC 5136=2C we define nodes as hosts=2C routers=2C= Ethernet =3E =3E=3E switches=2Cor any other device and a link as a connection betw= een =3E =3E=3E two of these =3E =3E=3E network devices or nodes=2E We then define a path P of length= n as =3E =3E=3E a series =3E =3E=3E of links (L1=2C L2=2C =2E=2E=2E=2C Ln) connecting a sequence o= f nodes (N1=2C N2=2C =3E =3E=3E =2E=2E=2E=2C Nn+1)=2E A source S and destination D reside at = N1 and =3E =3E=3E Nn+1=2C respectively=2E Furthermore=2C we define a link L as = a special =3E =3E=3E case where =3E =3E=3E the path length is one=2E =3E =3E=3E =3E =3E=3E Meaning=3A =3E =3E=3E =3E =3E=3E - The definition of nodes have been extended from RFC 2330 t= o =3E =3E=3E include any =3E =3E=3E devices which can impact IP datagrams =3E =3E=3E - A link is a connection between two network devices or node= s =3E =3E =3E =3E Do you mean the =22link=22 is exactly the connection between node= s=3F =3E =3E Or you mean the link is the =22combination=22 of =22the connectio= n = =3E between nodes=22 + =3E =3E =22the nodes themselves=22=3F =3E =3E =3E =3E=3E - The definition of a Path (P) is a sequence of (n+1) nodes = =3E and (n) =3E =3E=3E links for which a Source resides at N(1) and a Destination a= t =3E =3E=3E N(n+1) - The definition of a Link (L) is the case where n=3D= 1 =3E =3E=3E above=2E Thus =3E =3E=3E it includes two devices and one link =3E =3E=3E =3E =3E=3E Thus=2C the usage of a link L in this document refers to two = =3E nodes and =3E =3E=3E the link between those devices and not simply the link between= the =3E =3E=3E nodes=2E =3E =3E =3E =3E Let me try to understand your words=2C there are three =22link=22= in = =3E this sentence=2E =3E =3E =22LINK L=22=2C yes=2C I get it=2E =3E =3E There are also =3Cand the =22link=22 between those devices=3E =26= =3Cnot = =3E simply the =22link=22 =3E =3E between the nodes=3E=2C I=27m fully confused now=2C do you mean =22= link L=22 = =3E is NOT a =3E =3E link=3F I don=27t think people would understand this well=2E =3E =3E =3E I can see how this sentence can be confusing and I can see how re- =3E wording could clear up the confusion=2E However=2C we do not need a = =3E new draft to do that=2E =3E =3E =3E =3E When we later define the capacity of L=2C it incorporates the =3E =3E =3E =3E So you are speaking =22the capacity of L=22 is NOT =22the capacit= y of = =3E a link=22=2C but =3E =3E capacity of something else=2C right=3F Then=2C what is its meanin= g for = =3E people who =3E =3E are only familiar with normal =22link=22=2C =22node=22 and =22pat= h=22 concept=3F =3E =3E =3E We already say in the beginning of section 2=2E1 that we are = =3E modifying the definitions of Link and Path from what they were in = =3E RFC2330=2E You may not agree with how we have modified them=2C but we= = =3E made it clear that we were changing the definitions=2E =3E = =3E =3E By the way=2C could you please answer my questions in my = =3E presentation slides=3F =3E =3E In slide 7=2C =3E =3E =3E =3E ! Link1 capacity (IP layer)=2C 0=2E99 M or 990 M=3F =3E Link 1 IP Layer capacity is 0=2E99Mb/s =3E =3E ! Link1 utilization (IP layer)=2C 0=2E1=25 or 100=25=3F =3E IP Layer Utilization is 100=25 =3E =3E ! Link2 capacity (IP layer)=2C 0=2E99 M or 99 M=3F =3E Is the router only capable of forwarding 1Mb/s on link 2=3F =3E The answer depends on that=2E =3E =3E ! Link2 utilization (IP layer)=2C 1=25 or 100=25=3F =3E =3E ! Path (Src to Dst) capacity (IP layer)=3F =3E 0=2E99 =3E =3E ! Available path capacity (IP layer)=3F =3E 0 =3E =3E =3E It is clear that your view is that what we call Nominal Capacity = =3E is the same as IP Layer capacity=2E We explicitly differentiate = =3E these two concepts=2E =3E = =3E =3E Thanks and best regards=2C =3E =3E Xiangsong =3E =3E =3E =3E=3E complexities of both the devices and the link between them and= =3E =3E=3E does not =3E =3E=3E simply mean the =22capacity of the physical (virtual) link=22 = that = =3E exists=3E=3E between those two nodes=2E =3E =3E=3E =3E =3E=3E Thanks! =3E =3E=3E =3E =3E=3E -Joseph and Phil =3E =3E=3E =3E = =3E Regards=2C =3E Phil Chimento =3E = =3E JHU/APL =3E 240-228-1743 =3E 443-778-1743 =3E Philip=2EChimento=40jhuapl=2Eedu =3E -- =3E = =3E --Boundary_(ID_GenQbVnRqnCTIVYMChQz6Q) 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 <Xiangsong.Cui@huawei.com> begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_GenQbVnRqnCTIVYMChQz6Q)-- From Xiangsong.Cui@huawei.com Thu Mar 31 07:11:58 2011 Return-Path: <Xiangsong.Cui@huawei.com> 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 0E7CA3A6B49 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] 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 yln7nxzvo7sX for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:11:57 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 1AC053A6B13 for <ippm@ietf.org>; Thu, 31 Mar 2011 07:11:57 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00BIXE6O8U@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 09:13:36 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX0029NE6N6O@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 09:13:36 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [88.208.109.142]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 22:13:35 +0800 Date: Thu, 31 Mar 2011 22:13:35 +0800 From: Xiangsong Cui <Xiangsong.Cui@huawei.com> In-reply-to: <C9BA00BD.96E5%Philip.Chimento@jhuapl.edu> To: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> Message-id: <fd3b9b463bbd.3bbdfd3b9b46@huawei.com> 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_szd8XxRpJhYmeGn3U3DxKg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <C9BA00BD.96E5%Philip.Chimento@jhuapl.edu> Cc: IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 14:11:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_szd8XxRpJhYmeGn3U3DxKg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline The difference is=2C Y=2E1540 clearly specifies=2C =22Link=3A A point-to-point (physical or virtual) connection used for tra= nsporting IP packets between a pair of hosts=2E *It does not include any = parts of the hosts* or any other hosts=3B it operates below the IP layer=2E= =22 Isn=27t that a difference=3F Best Regards Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChimento=40= jhuapl=2Eedu=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C 2011 =CF=C2= =CE=E710=3A00 =D6=F7=CC=E2=3A Re=3A =5Bippm=5D Impact of hosts on network capacity and = RFC 5136 =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E Andreas=3A = =3E We believe that the definition of capacity for =22network section=22 = =3E in Y=2E1540 =3E is the equivalent (roughly) of how we define it for =22link=22 in RFC= = =3E 5136=2E As =3E Joseph has pointed out=2C we define =22link=22 as a =22path=22 of len= gth 1=2E = =3E I do not =3E believe that there is a fundamental conflict between the RFC 5136 = =3E and the =3E Y=2E1540 definitions=2E =3E = =3E Regards=2C = =3E Phil Chimento =3E = =3E JHU/APL =3E 240-228-1743 =3E 443-778-1743 =3E Philip=2EChimento=40jhuapl=2Eedu =3E -- = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E ippm mailing list =3E ippm=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E --Boundary_(ID_szd8XxRpJhYmeGn3U3DxKg) 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 <Xiangsong.Cui@huawei.com> begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_szd8XxRpJhYmeGn3U3DxKg)-- From philip.chimento@jhuapl.edu Thu Mar 31 07:15:37 2011 Return-Path: <philip.chimento@jhuapl.edu> 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 BBD603A6B13 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[AWL=-1.971, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 GQtpbB896Sfm for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:15:36 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) by core3.amsl.com (Postfix) with ESMTP id B6F2D3A6AD7 for <ippm@ietf.org>; Thu, 31 Mar 2011 07:15:35 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.112786436; Thu, 31 Mar 2011 10:16:38 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 31 Mar 2011 10:16:58 -0400 From: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> To: Xiangsong Cui <Xiangsong.Cui@huawei.com> Date: Thu, 31 Mar 2011 10:16:55 -0400 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: AcvvrdUvSmHtLCEHSYOYB3Jw4TWvggAAHSAL Message-ID: <C9BA0517.96FC%Philip.Chimento@jhuapl.edu> In-Reply-To: <fd3b9b463bbd.3bbdfd3b9b46@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 14:15:37 -0000 SSB3YXMgbm90IGNvbXBhcmluZyBvdXIgZGVmaW5pdGlvbiBvZiAibGluayIgdG8gWS4xNTQwJ3Mg ZGVmaW5pdGlvbiBvZg0KImxpbmsiLiBJIHdhcyBjb21wYXJpbmcgb3VyIGRlZmluaXRpb24gb2Yg ImxpbmsiIHRvIFkuMTU0MCdzIGRlZmluaXRpb24gb2YNCiJuZXR3b3JrIHNlY3Rpb24iIHNwZWNp ZmljYWxseSBhcyBpdCByZWxhdGVkIHRvIHRoZWlyIGRlZmluaXRpb24gb2Ygc2VjdGlvbg0KY2Fw YWNpdHkuIA0KDQpSZWdhcmRzLCANClBoaWwgQ2hpbWVudG8NCg0KDQpPbiAzLzMxLzExIDEwOjEz IEFNLCAiWGlhbmdzb25nIEN1aSIgPFhpYW5nc29uZy5DdWlAaHVhd2VpLmNvbT4gd3JvdGU6DQoN Cj4gVGhlIGRpZmZlcmVuY2UgaXMsIFkuMTU0MCBjbGVhcmx5IHNwZWNpZmllcywNCj4gDQo+ICJM aW5rOiBBIHBvaW50LXRvLXBvaW50IChwaHlzaWNhbCBvciB2aXJ0dWFsKSBjb25uZWN0aW9uIHVz ZWQgZm9yIHRyYW5zcG9ydGluZw0KPiBJUCBwYWNrZXRzIGJldHdlZW4gYSBwYWlyIG9mIGhvc3Rz LiAqSXQgZG9lcyBub3QgaW5jbHVkZSBhbnkgcGFydHMgb2YgdGhlDQo+IGhvc3RzKiBvciBhbnkg b3RoZXIgaG9zdHM7IGl0IG9wZXJhdGVzIGJlbG93IHRoZSBJUCBsYXllci4iDQo+IA0KPiBJc24n dCB0aGF0IGEgZGlmZmVyZW5jZT8NCj4gDQo+IEJlc3QgUmVnYXJkcw0KPiBYaWFuZ3NvbmcNCj4g DQo+IC0tLS0tINSt08q8/iAtLS0tLQ0KPiC3orz+yMs6ICJDaGltZW50bywgUGhpbGlwIEYuIiA8 UGhpbGlwLkNoaW1lbnRvQGpodWFwbC5lZHU+DQo+IMjVxto6INDHxtrLxCwgyP3UwiAzMcjVLCAy MDExIM/CzucxMDowMA0KPiDW98ziOiBSZTogW2lwcG1dIEltcGFjdCBvZiBob3N0cyBvbiBuZXR3 b3JrIGNhcGFjaXR5IGFuZCBSRkMgNTEzNg0KPiDK1bz+yMs6IElFVEYgSVBQTSBXRyA8aXBwbUBp ZXRmLm9yZz4NCj4gDQoNCg== From philip.chimento@jhuapl.edu Thu Mar 31 07:19:46 2011 Return-Path: <philip.chimento@jhuapl.edu> 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 1A0703A6AD7 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, J_CHICKENPOX_35=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 qAMfppPWsBPx for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:19:45 -0700 (PDT) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by core3.amsl.com (Postfix) with ESMTP id 28C273A6A92 for <ippm@ietf.org>; Thu, 31 Mar 2011 07:19:44 -0700 (PDT) Received: from ([128.244.198.90]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.107736356; Thu, 31 Mar 2011 10:21:10 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Thu, 31 Mar 2011 10:21:10 -0400 From: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> To: Xiangsong Cui <Xiangsong.Cui@huawei.com> Date: Thu, 31 Mar 2011 10:21:04 -0400 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: AcvvrVXHjkdrDKoaQ3qgZvVpkow6NwAAYhVP Message-ID: <C9BA0610.9700%Philip.Chimento@jhuapl.edu> In-Reply-To: <fd3bec306873.6873fd3bec30@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 14:19:46 -0000 On 3/31/11 10:09 AM, "Xiangsong Cui" <Xiangsong.Cui@huawei.com> wrote: >>>=20 >>> Yes, I get your point here. However, that is exactly my concern. >>> You mean you combined (or say enbeded) nodes inside link, right? >>> I just don'think this is appropriate. >>=20 >> No. We are not saying that the nodes are embedded in the link. We >> are saying that the endpoint is part of the link. >=20 > Yes, I do make sure you are saying node is part of the link now. > Do you think this is a major change to RFC2330 and RFC2460? > This is also very different from the definition from Y.1540. As just pointed out, I don't think that there is a fundamental different between our definition of capacity (IP Layer) for links and Y.1540's definition of capacity (IP Layer) for network section. >=20 > And by the way, in my example, which link the router should belong to? Li= nk 1 > or Link 2? Both. >=20 > Best regards, > Xiangsong >=20 Regards,=20 Phil Chimento From Xiangsong.Cui@huawei.com Thu Mar 31 07:22:51 2011 Return-Path: <Xiangsong.Cui@huawei.com> 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 36D8328C0F2 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.066 X-Spam-Level: X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] 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 stoGDYYdhlDm for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:22:50 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D4B7828C0FD for <ippm@ietf.org>; Thu, 31 Mar 2011 07:22:49 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00BVUEOT8U@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 09:24:29 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX002FVEOS6O@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 09:24:29 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [88.208.109.142]) by szxmc01-in.huawei.com (mshttpd); Thu, 31 Mar 2011 22:24:27 +0800 Date: Thu, 31 Mar 2011 22:24:27 +0800 From: Xiangsong Cui <Xiangsong.Cui@huawei.com> In-reply-to: <C9BA0517.96FC%Philip.Chimento@jhuapl.edu> To: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> Message-id: <fd03f91b7895.7895fd03f91b@huawei.com> 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_YULnSUy4tfvUOReEk7BsLg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <fd3b9b463bbd.3bbdfd3b9b46@huawei.com> <C9BA0517.96FC%Philip.Chimento@jhuapl.edu> Cc: IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 14:22:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YULnSUy4tfvUOReEk7BsLg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline So the problem is=2C when I am talking about =22link capacity=22=2C someb= ody would jump and ask me whose link I am speaking=2C IETF=26ITU-T=27s li= nk (per RFC2330=2C RFC2460 and ITU-T Y=2E1540=2C they are all the same) o= r IPPM=27s link (per RFC5136)=3F = Best Regards Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChimento=40= jhuapl=2Eedu=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C 2011 =CF=C2= =CE=E710=3A17 =D6=F7=CC=E2=3A Re=3A =5Bippm=5D Impact of hosts on network capacity and = RFC 5136 =CA=D5=BC=FE=C8=CB=3A Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E =B3=AD=CB=CD=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E I was not comparing our definition of =22link=22 to Y=2E1540=27s = =3E definition of =3E =22link=22=2E I was comparing our definition of =22link=22 to Y=2E154= 0=27s = =3E definition of =3E =22network section=22 specifically as it related to their definition = =3E of section =3E capacity=2E = =3E = =3E Regards=2C = =3E Phil Chimento =3E = =3E = =3E On 3/31/11 10=3A13 AM=2C =22Xiangsong Cui=22 =3CXiangsong=2ECui=40hua= wei=2Ecom=3E wrote=3A =3E = =3E =3E The difference is=2C Y=2E1540 clearly specifies=2C =3E =3E = =3E =3E =22Link=3A A point-to-point (physical or virtual) connection used= = =3E for transporting =3E =3E IP packets between a pair of hosts=2E *It does not include any = =3E parts of the =3E =3E hosts* or any other hosts=3B it operates below the IP layer=2E=22= =3E =3E = =3E =3E Isn=27t that a difference=3F =3E =3E = =3E =3E Best Regards =3E =3E Xiangsong =3E =3E = =3E =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =3E =B7=A2=BC=FE=C8=CB=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EC= himento=40jhuapl=2Eedu=3E =3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C 20= 11 =CF=C2=CE=E710=3A00 =3E =3E =D6=F7=CC=E2=3A Re=3A =5Bippm=5D Impact of hosts on network capac= ity and RFC 5136 =3E =3E =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E ippm mailing list =3E ippm=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E --Boundary_(ID_YULnSUy4tfvUOReEk7BsLg) 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 <Xiangsong.Cui@huawei.com> begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_YULnSUy4tfvUOReEk7BsLg)-- From jishac@nasa.gov Thu Mar 31 07:38:56 2011 Return-Path: <jishac@nasa.gov> 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 D86E83A6B33 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FM_FORGED_GMAIL=0.622, MIME_CHARSET_FARAWAY=2.45, 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 RbZUKf0-jsVc for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 07:38:56 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id D53643A6B24 for <ippm@ietf.org>; Thu, 31 Mar 2011 07:38:55 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id E719C2601FE for <ippm@ietf.org>; Thu, 31 Mar 2011 09:40:34 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id p2VEeY4f024776 for <ippm@ietf.org>; Thu, 31 Mar 2011 09:40:34 -0500 Received: from mail-wy0-f172.google.com (74.125.82.172) by smtp01.ndc.nasa.gov (198.117.1.161) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 31 Mar 2011 09:40:34 -0500 Received: by wyb29 with SMTP id 29so2344031wyb.31 for <ippm@ietf.org>; Thu, 31 Mar 2011 07:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.208.202 with SMTP id gd10mr2926215wbb.23.1301582432310; Thu, 31 Mar 2011 07:40:32 -0700 (PDT) Received: by 10.227.156.9 with HTTP; Thu, 31 Mar 2011 07:40:31 -0700 (PDT) In-Reply-To: <fd3b9b463bbd.3bbdfd3b9b46@huawei.com> References: <C9BA00BD.96E5%Philip.Chimento@jhuapl.edu> <fd3b9b463bbd.3bbdfd3b9b46@huawei.com> Date: Thu, 31 Mar 2011 10:40:31 -0400 Message-ID: <AANLkTi=YOdB4bz-SWnJTKE1RfoxpbVXax2ix-J5HrRpc@mail.gmail.com> From: Joseph Ishac <jishac@nasa.gov> To: Xiangsong Cui <Xiangsong.Cui@huawei.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-31_05:2011-03-31, 2011-03-31, 1970-01-01 signatures=0 Cc: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu>, IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 14:38:57 -0000 Xiangsong, That link definition doesn't directly apply to the capacity metrics in section 6.11.2. As Phil notes refer to the concept of "sections". The definitions in 6.11.2 of Y.1540 are identical to RFC 5136 sans for things like IP-Type-P. -Joseph 2011/3/31 Xiangsong Cui <Xiangsong.Cui@huawei.com> > > The difference is, Y.1540 clearly specifies, > > "Link: A point-to-point (physical or virtual) connection used for transpo= rting IP packets between a pair of hosts. *It does not include any parts of= the hosts* or any other hosts; it operates below the IP layer." > > Isn't that a difference? > > Best Regards > Xiangsong > > ----- =D4=AD=D3=CA=BC=FE ----- > =B7=A2=BC=FE=C8=CB: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> > =C8=D5=C6=DA: =D0=C7=C6=DA=CB=C4, =C8=FD=D4=C2 31=C8=D5, 2011 =CF=C2=CE= =E710:00 > =D6=F7=CC=E2: Re: [ippm] Impact of hosts on network capacity and RFC 5136 > =CA=D5=BC=FE=C8=CB: IETF IPPM WG <ippm@ietf.org> > > > Andreas: > > We believe that the definition of capacity for "network section" > > in Y.1540 > > is the equivalent (roughly) of how we define it for "link" in RFC > > 5136. As > > Joseph has pointed out, we define "link" as a "path" of length 1. > > I do not > > believe that there is a fundamental conflict between the RFC 5136 > > and the > > Y.1540 definitions. > > > > Regards, > > Phil Chimento > > > > JHU/APL > > 240-228-1743 > > 443-778-1743 > > Philip.Chimento@jhuapl.edu > > -- > > > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > From jishac@nasa.gov Thu Mar 31 08:30:58 2011 Return-Path: <jishac@nasa.gov> 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 D07073A680E for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 08:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FM_FORGED_GMAIL=0.622, MIME_CHARSET_FARAWAY=2.45, 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 ugpRLlQlPXVg for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 08:30:57 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 8EFC13A6B20 for <ippm@ietf.org>; Thu, 31 Mar 2011 08:30:57 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 31EB72D8267 for <ippm@ietf.org>; Thu, 31 Mar 2011 10:32:37 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id p2VFWbYx020993 for <ippm@ietf.org>; Thu, 31 Mar 2011 10:32:37 -0500 Received: from mail-wy0-f172.google.com (74.125.82.172) by smtp01.ndc.nasa.gov (198.117.1.161) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 31 Mar 2011 10:32:36 -0500 Received: by wyb29 with SMTP id 29so2397173wyb.31 for <ippm@ietf.org>; Thu, 31 Mar 2011 08:32:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.200.210 with SMTP id ex18mr2876256wbb.139.1301585554566; Thu, 31 Mar 2011 08:32:34 -0700 (PDT) Received: by 10.227.156.9 with HTTP; Thu, 31 Mar 2011 08:32:34 -0700 (PDT) In-Reply-To: <fd03f91b7895.7895fd03f91b@huawei.com> References: <fd3b9b463bbd.3bbdfd3b9b46@huawei.com> <C9BA0517.96FC%Philip.Chimento@jhuapl.edu> <fd03f91b7895.7895fd03f91b@huawei.com> Date: Thu, 31 Mar 2011 11:32:34 -0400 Message-ID: <AANLkTi=UVOFKyMk=msXdKxYhx_-63VVTyHV9U734H-pb@mail.gmail.com> From: Joseph Ishac <jishac@nasa.gov> To: Xiangsong Cui <Xiangsong.Cui@huawei.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-31_07:2011-03-31, 2011-03-31, 1970-01-01 signatures=0 Cc: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu>, IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 15:30:58 -0000 Xiangsong, I believe it is extremely undue to extrapolate an entire definition from a single word. Link Capacity is not defined in RFC 2330 or RFC 2460. Simply because link is defined, does not mean "Link Capacity" is a straightforward extension. Furthermore, RFC 5136 does not 'embed' nodes into a link, changing it's definition, but rather states that the nodes directly attached to the link can impact capacity among other factors. It's part of what makes "Link Capacity" a complex concept. I believe the definitions in RFC 5136 do an excellent job at capturing that and are supported by the definitions in Y.1540 which are equivalent. -Joseph 2011/3/31 Xiangsong Cui <Xiangsong.Cui@huawei.com>: > So the problem is, when I am talking about "link capacity", somebody woul= d jump and ask me whose link I am speaking, IETF&ITU-T's link (per RFC2330,= RFC2460 and ITU-T Y.1540, they are all the same) or IPPM's link (per RFC51= 36)? > > Best Regards > Xiangsong > > ----- =D4=AD=D3=CA=BC=FE ----- > =B7=A2=BC=FE=C8=CB: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> > =C8=D5=C6=DA: =D0=C7=C6=DA=CB=C4, =C8=FD=D4=C2 31=C8=D5, 2011 =CF=C2=CE= =E710:17 > =D6=F7=CC=E2: Re: [ippm] Impact of hosts on network capacity and RFC 5136 > =CA=D5=BC=FE=C8=CB: Xiangsong Cui <Xiangsong.Cui@huawei.com> > =B3=AD=CB=CD: IETF IPPM WG <ippm@ietf.org> > >> I was not comparing our definition of "link" to Y.1540's >> definition of >> "link". I was comparing our definition of "link" to Y.1540's >> definition of >> "network section" specifically as it related to their definition >> of section >> capacity. >> >> Regards, >> Phil Chimento >> >> >> On 3/31/11 10:13 AM, "Xiangsong Cui" <Xiangsong.Cui@huawei.com> wrote: >> >> > The difference is, Y.1540 clearly specifies, >> > >> > "Link: A point-to-point (physical or virtual) connection used >> for transporting >> > IP packets between a pair of hosts. *It does not include any >> parts of the >> > hosts* or any other hosts; it operates below the IP layer." >> > >> > Isn't that a difference? >> > >> > Best Regards >> > Xiangsong >> > >> > ----- =D4=AD=D3=CA=BC=FE ----- >> > =B7=A2=BC=FE=C8=CB: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> >> > =C8=D5=C6=DA: =D0=C7=C6=DA=CB=C4, =C8=FD=D4=C2 31=C8=D5, 2011 =CF=C2= =CE=E710:00 >> > =D6=F7=CC=E2: Re: [ippm] Impact of hosts on network capacity and RFC 5= 136 >> > =CA=D5=BC=FE=C8=CB: IETF IPPM WG <ippm@ietf.org> >> > >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > From jishac@nasa.gov Thu Mar 31 11:14:26 2011 Return-Path: <jishac@nasa.gov> 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 6B43B3A69C2 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 11:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 anPWlgF500VD for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 11:14:25 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 6112E3A6B6A for <ippm@ietf.org>; Thu, 31 Mar 2011 11:14:25 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id E7470181058 for <ippm@ietf.org>; Thu, 31 Mar 2011 13:16:04 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt02.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id p2VIG4Ll025272 for <ippm@ietf.org>; Thu, 31 Mar 2011 13:16:04 -0500 Received: from mail-iw0-f172.google.com (209.85.214.172) by smtp01.ndc.nasa.gov (198.117.1.160) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 31 Mar 2011 13:16:04 -0500 Received: by iwn39 with SMTP id 39so3063903iwn.31 for <ippm@ietf.org>; Thu, 31 Mar 2011 11:16:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.134.135 with SMTP id l7mr3565826ict.234.1301595362804; Thu, 31 Mar 2011 11:16:02 -0700 (PDT) Received: by 10.231.205.206 with HTTP; Thu, 31 Mar 2011 11:16:02 -0700 (PDT) In-Reply-To: <BANLkTikCgEPrA-H_41G0qcsakMbVZkFsfg@mail.gmail.com> References: <BANLkTikCgEPrA-H_41G0qcsakMbVZkFsfg@mail.gmail.com> Date: Thu, 31 Mar 2011 14:16:02 -0400 Message-ID: <BANLkTin-szZxkgwh_51yidnqHOstHScUPA@mail.gmail.com> From: Joseph Ishac <jishac@nasa.gov> To: IETF IPPM WG <ippm@ietf.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-31_09:2011-03-31, 2011-03-31, 1970-01-01 signatures=0 Cc: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 18:14:26 -0000 Passing on by request a nice concise example I was sent by Donald McLachlan of crc.ca: > I think what you are saying (for instance) is that: > - Even if the path between the Src and Dst hosts (cabling, switches etc) = can support (eg. 10 Gbps) > - If the Sending host can only transmit at 10 Mbps > - then the effective Link Capacity (as seen by Src and Dst) is at most 10= Mbps. I'd like to add a few more examples that are covered by the current wording in RFC 5136: 1) Employing encoding on a link, several of our links use Reed=96Solomon or rate 1/2 convolution encoding. 2) Passing through an underrated patch panel (say a Cat3 patch panel when your trying to do 1000GbE) [incidentally don't ask if I've experienced this first hand ...] The wording in the RFC is meant to cover such limitations with both the links and nodes. -Joseph From Xiangsong.Cui@huawei.com Thu Mar 31 13:56:57 2011 Return-Path: <Xiangsong.Cui@huawei.com> 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 204D03A6A88 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 13:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_47=0.6, MIME_CHARSET_FARAWAY=2.45] 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 xiOrGfOPc8a2 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 13:56:55 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 79D2A3A69B2 for <ippm@ietf.org>; Thu, 31 Mar 2011 13:56:55 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00AK7WXMZW@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 15:58:35 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00DQNWXLFB@usaga01-in.huawei.com> for ippm@ietf.org; Thu, 31 Mar 2011 15:58:34 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [88.208.109.142]) by szxmc01-in.huawei.com (mshttpd); Fri, 01 Apr 2011 04:58:33 +0800 Date: Fri, 01 Apr 2011 04:58:33 +0800 From: Xiangsong Cui <Xiangsong.Cui@huawei.com> In-reply-to: <BANLkTin-szZxkgwh_51yidnqHOstHScUPA@mail.gmail.com> To: Joseph Ishac <jishac@nasa.gov> Message-id: <fbbee87c2e1.2e1fbbee87c@huawei.com> 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_gLIcK1al2MB8z3Trbuzd1g)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <BANLkTikCgEPrA-H_41G0qcsakMbVZkFsfg@mail.gmail.com> <BANLkTin-szZxkgwh_51yidnqHOstHScUPA@mail.gmail.com> Cc: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu>, IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 20:56:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gLIcK1al2MB8z3Trbuzd1g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline I=27m wondering in what scenario=2C the link utilization is not equal to = 100=25=3F Who can tell me what type the link utilization is=2C it=27s bool type or = float type number=3F Thanks for your teaching! Best Regards Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CB=C4=D4=C2 1=C8=D5=2C 2011 =C9=CF= =CE=E72=3A16 =D6=F7=CC=E2=3A Re=3A =5Bippm=5D Impact of hosts on network capacity and = RFC 5136 =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChimento=40jhua= pl=2Eedu=3E =3E Passing on by request a nice concise example I was sent by Donald =3E McLachlan of crc=2Eca=3A =3E = =3E =3E I think what you are saying (for instance) is that=3A =3E =3E - Even if the path between the Src and Dst hosts (cabling=2C = =3E switches etc) can support (eg=2E 10 Gbps) =3E =3E - If the Sending host can only transmit at 10 Mbps =3E =3E - then the effective Link Capacity (as seen by Src and Dst) is = =3E at most 10 Mbps=2E =3E = =3E I=27d like to add a few more examples that are covered by the current= =3E wording in RFC 5136=3A =3E = =3E 1) Employing encoding on a link=2C several of our links use Reed=3FSo= lomon =3E or rate 1/2 convolution encoding=2E =3E 2) Passing through an underrated patch panel (say a Cat3 patch panel =3E when your trying to do 1000GbE) =5Bincidentally don=27t ask if I=27ve= =3E experienced this first hand =2E=2E=2E=5D =3E = =3E The wording in the RFC is meant to cover such limitations with both =3E the links and nodes=2E =3E = =3E -Joseph =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E ippm mailing list =3E ippm=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E --Boundary_(ID_gLIcK1al2MB8z3Trbuzd1g) 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 <Xiangsong.Cui@huawei.com> begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_gLIcK1al2MB8z3Trbuzd1g)-- From jishac@nasa.gov Thu Mar 31 14:50:22 2011 Return-Path: <jishac@nasa.gov> 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 EBC0B3A6BC0 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 14:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, CN_BODY_35=0.339, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, J_CHICKENPOX_47=0.6, MIME_CHARSET_FARAWAY=2.45, 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 FRKZoqsjfdTA for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 14:50:20 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 905763A6BC1 for <ippm@ietf.org>; Thu, 31 Mar 2011 14:50:20 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 16596328AAC for <ippm@ietf.org>; Thu, 31 Mar 2011 16:52:00 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id p2VLq01q006528 for <ippm@ietf.org>; Thu, 31 Mar 2011 16:52:00 -0500 Received: from mail-wy0-f172.google.com (74.125.82.172) by smtp01.ndc.nasa.gov (198.117.1.161) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 31 Mar 2011 16:51:59 -0500 Received: by wyb29 with SMTP id 29so2743505wyb.31 for <ippm@ietf.org>; Thu, 31 Mar 2011 14:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.203.76 with SMTP id fh12mr3378908wbb.110.1301608317667; Thu, 31 Mar 2011 14:51:57 -0700 (PDT) Received: by 10.227.156.9 with HTTP; Thu, 31 Mar 2011 14:51:57 -0700 (PDT) In-Reply-To: <fbbee87c2e1.2e1fbbee87c@huawei.com> References: <BANLkTikCgEPrA-H_41G0qcsakMbVZkFsfg@mail.gmail.com> <BANLkTin-szZxkgwh_51yidnqHOstHScUPA@mail.gmail.com> <fbbee87c2e1.2e1fbbee87c@huawei.com> Date: Thu, 31 Mar 2011 17:51:57 -0400 Message-ID: <AANLkTin848h10qs614OCKsMUAUj9TrjLoeqBQiFC+oBA@mail.gmail.com> From: Joseph Ishac <jishac@nasa.gov> To: Xiangsong Cui <Xiangsong.Cui@huawei.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-31_10:2011-03-31, 2011-03-31, 1970-01-01 signatures=0 Cc: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu>, IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 21:50:22 -0000 Well, for a given packet type, Used(L,T,I) measures the *actual* usage in a given time span. C(L,T,I) is the maximum you *could* obtain in that same time span. So if the link is not actually saturated with traffic, the link utilization will not be 100%. If you try to think of actually trying to measure C() and Used() at the same time, you're bound to get a headache. That's why developing the means of gathering the metrics was out of scope for the document. Does that help answer your question? -Joseph 2011/3/31 Xiangsong Cui <Xiangsong.Cui@huawei.com>: > I'm wondering in what scenario, the link utilization is not equal to 100%= ? > Who can tell me what type the link utilization is, it's bool type or floa= t type number? > > Thanks for your teaching! > > Best Regards > Xiangsong > > ----- =D4=AD=D3=CA=BC=FE ----- > =B7=A2=BC=FE=C8=CB: Joseph Ishac <jishac@nasa.gov> > =C8=D5=C6=DA: =D0=C7=C6=DA=CE=E5, =CB=C4=D4=C2 1=C8=D5, 2011 =C9=CF=CE=E7= 2:16 > =D6=F7=CC=E2: Re: [ippm] Impact of hosts on network capacity and RFC 5136 > =CA=D5=BC=FE=C8=CB: IETF IPPM WG <ippm@ietf.org> > =B3=AD=CB=CD: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu> > >> Passing on by request a nice concise example I was sent by Donald >> McLachlan of crc.ca: >> >> > I think what you are saying (for instance) is that: >> > - Even if the path between the Src and Dst hosts (cabling, >> switches etc) can support (eg. 10 Gbps) >> > - If the Sending host can only transmit at 10 Mbps >> > - then the effective Link Capacity (as seen by Src and Dst) is >> at most 10 Mbps. >> >> I'd like to add a few more examples that are covered by the current >> wording in RFC 5136: >> >> 1) Employing encoding on a link, several of our links use Reed?Solomon >> or rate 1/2 convolution encoding. >> 2) Passing through an underrated patch panel (say a Cat3 patch panel >> when your trying to do 1000GbE) [incidentally don't ask if I've >> experienced this first hand ...] >> >> The wording in the RFC is meant to cover such limitations with both >> the links and nodes. >> >> -Joseph >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > From Xiangsong.Cui@huawei.com Thu Mar 31 23:30:59 2011 Return-Path: <Xiangsong.Cui@huawei.com> 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 4E9C43A6A46 for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 23:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.458 X-Spam-Level: X-Spam-Status: No, score=0.458 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_41=0.6, MIME_CHARSET_FARAWAY=2.45] 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 qH66gETrat5W for <ippm@core3.amsl.com>; Thu, 31 Mar 2011 23:30:56 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 214393A6A28 for <ippm@ietf.org>; Thu, 31 Mar 2011 23:30:56 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIY00ABGNIBZW@usaga01-in.huawei.com> for ippm@ietf.org; Fri, 01 Apr 2011 01:32:35 -0500 (CDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIY001IANI95T@usaga01-in.huawei.com> for ippm@ietf.org; Fri, 01 Apr 2011 01:32:35 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [88.208.109.142]) by szxmc01-in.huawei.com (mshttpd); Fri, 01 Apr 2011 14:32:33 +0800 Date: Fri, 01 Apr 2011 14:32:33 +0800 From: Xiangsong Cui <Xiangsong.Cui@huawei.com> In-reply-to: <AANLkTin848h10qs614OCKsMUAUj9TrjLoeqBQiFC+oBA@mail.gmail.com> To: Joseph Ishac <jishac@nasa.gov> Message-id: <fbbef66865d3.65d3fbbef668@huawei.com> 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_UiZ9mnxc6Q54nUU8TjZDpg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <BANLkTikCgEPrA-H_41G0qcsakMbVZkFsfg@mail.gmail.com> <BANLkTin-szZxkgwh_51yidnqHOstHScUPA@mail.gmail.com> <fbbee87c2e1.2e1fbbee87c@huawei.com> <AANLkTin848h10qs614OCKsMUAUj9TrjLoeqBQiFC+oBA@mail.gmail.com> Cc: "Chimento, Philip F." <Philip.Chimento@jhuapl.edu>, IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ippm> List-Post: <mailto:ippm@ietf.org> List-Help: <mailto:ippm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 01 Apr 2011 06:30:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_UiZ9mnxc6Q54nUU8TjZDpg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Joseph=2C = thanks for your answer=2C but I think I still don=27t undersand that=2E I don=27t understand what =22link is saturated=22 means=2C for the exampl= e of my slides=2C in the Gb ethernet=2C 1M bit flow is saturated for the = ethernet link=3F My answer is no=2C because link is a layer 2 notion=2C w= e have to judge its status in layer 2 viewpoint=2E It comes back to the basic question=2C should the node is part of link=3F= What I want to say is=2C if we say node is part of link=2C perhaps we hav= e to say the Internet is the set of =22links=22=2C there is no host=2C no= router=2C no NAT=2C no firewall=2C no ALG =2E=2E=2E=2C is that strange=3F= Aha=2C because all these nodes are inside the links=2E Best Regards Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CB=C4=D4=C2 1=C8=D5=2C 2011 =C9=CF= =CE=E75=3A52 =D6=F7=CC=E2=3A Re=3A =5Bippm=5D Impact of hosts on network capacity and = RFC 5136 =CA=D5=BC=FE=C8=CB=3A Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChimento=40jhua= pl=2Eedu=3E=2C IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E Well=2C for a given packet type=2C Used(L=2CT=2CI) measures the *actu= al* usage =3E in a given time span=2E C(L=2CT=2CI) is the maximum you *could* obta= in in =3E that same time span=2E So if the link is not actually saturated with= =3E traffic=2C the link utilization will not be 100=25=2E =3E = =3E If you try to think of actually trying to measure C() and Used() at =3E the same time=2C you=27re bound to get a headache=2E That=27s why de= veloping =3E the means of gathering the metrics was out of scope for the document=2E= =3E = =3E Does that help answer your question=3F =3E = =3E -Joseph =3E = =3E 2011/3/31 Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E=3A =3E =3E I=27m wondering in what scenario=2C the link utilization is not = =3E equal to 100=25=3F =3E =3E Who can tell me what type the link utilization is=2C it=27s bool = =3E type or float type number=3F =3E =3E =3E =3E Thanks for your teaching! =3E =3E =3E =3E Best Regards =3E =3E Xiangsong =3E =3E =3E =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =3E =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CB=C4=D4=C2 1=C8=D5=2C 201= 1 =C9=CF=CE=E72=3A16 =3E =3E =D6=F7=CC=E2=3A Re=3A =5Bippm=5D Impact of hosts on network capac= ity and RFC 5136 =3E =3E =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E =3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChiment= o=40jhuapl=2Eedu=3E =3E =3E =3E =3E=3E Passing on by request a nice concise example I was sent by Don= ald =3E =3E=3E McLachlan of crc=2Eca=3A =3E =3E=3E =3E =3E=3E =3E I think what you are saying (for instance) is that=3A =3E =3E=3E =3E - Even if the path between the Src and Dst hosts (cabling=2C= =3E =3E=3E switches etc) can support (eg=2E 10 Gbps) =3E =3E=3E =3E - If the Sending host can only transmit at 10 Mbps =3E =3E=3E =3E - then the effective Link Capacity (as seen by Src and Dst= ) is =3E =3E=3E at most 10 Mbps=2E =3E =3E=3E =3E =3E=3E I=27d like to add a few more examples that are covered by the = current =3E =3E=3E wording in RFC 5136=3A =3E =3E=3E =3E =3E=3E 1) Employing encoding on a link=2C several of our links use = =3E Reed=3FSolomon=3E=3E or rate 1/2 convolution encoding=2E =3E =3E=3E 2) Passing through an underrated patch panel (say a Cat3 patch= = =3E panel=3E=3E when your trying to do 1000GbE) =5Bincidentally don=27t a= sk if = =3E I=27ve=3E=3E experienced this first hand =2E=2E=2E=5D =3E =3E=3E =3E =3E=3E The wording in the RFC is meant to cover such limitations with= both =3E =3E=3E the links and nodes=2E =3E =3E=3E =3E =3E=3E -Joseph =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F =3E =3E=3E ippm mailing list =3E =3E=3E ippm=40ietf=2Eorg =3E =3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E =3E=3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E ippm mailing list =3E ippm=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E --Boundary_(ID_UiZ9mnxc6Q54nUU8TjZDpg) 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 <Xiangsong.Cui@huawei.com> begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_UiZ9mnxc6Q54nUU8TjZDpg)--