From henk@ripe.net Fri Oct 2 00:44:49 2009 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 E367F28C0DB for ; Fri, 2 Oct 2009 00:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.696 X-Spam-Level: X-Spam-Status: No, score=-8.696 tagged_above=-999 required=5 tests=[AWL=1.903, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+bcOsODeWoA for ; Fri, 2 Oct 2009 00:44:46 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 2B71D3A6A24 for ; Fri, 2 Oct 2009 00:43:57 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MtcpJ-0004zy-VJ for ippm@ietf.org; Fri, 02 Oct 2009 09:45:23 +0200 Received: from geir-3.local (henk.vpn.ripe.net [193.0.21.33]) by herring.ripe.net (Postfix) with ESMTP id E881B2F593 for ; Fri, 2 Oct 2009 09:45:17 +0200 (CEST) Message-ID: <4AC5AF8D.7070108@ripe.net> Date: Fri, 02 Oct 2009 09:45:17 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d55ca082f9f7094ed2da8d9bddc3b8927b Subject: [ippm] [Fwd: Do any need WEBEX for their WG meeting in Hiroshima] 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, 02 Oct 2009 07:44:49 -0000 IPPM group, If you plan to present in Hiroshima but cannot be physically present, then please let me know and I'll arrange video conferencing access. Henk -------- Original Message -------- Subject: Do any need WEBEX for their WG meeting in Hiroshima Date: Fri, 02 Oct 2009 09:40:52 +0200 From: Magnus Westerlund To: tsv-chairs@ietf.org Hi, A question to you WG chairs. Is there any WG that need WEBEX to support a presenter that isn't going to be present in Hiroshima? Please send me and Lars an message in that case. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=20 -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.= net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. From henk@ripe.net Tue Oct 6 01:18:03 2009 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 D17F028C12D for ; Tue, 6 Oct 2009 01:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[AWL=-2.102, 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 3OIWxV2XQGYx for ; Tue, 6 Oct 2009 01:18:03 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id F37F028C12A for ; Tue, 6 Oct 2009 01:18:02 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Mv5Gf-0005Kj-JP for ippm@ietf.org; Tue, 06 Oct 2009 10:19:38 +0200 Received: from dhcp-26-222.ripemtg.ripe.net (henk.vpn.ripe.net [193.0.21.33]) by herring.ripe.net (Postfix) with ESMTP id 72C552F583 for ; Tue, 6 Oct 2009 10:19:33 +0200 (CEST) Message-ID: <4ACAFD95.80108@ripe.net> Date: Tue, 06 Oct 2009 10:19:33 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5f90e3d1989ffe8bd949a7ef02888d803 Subject: [ippm] Meeting in Hiroshima 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, 06 Oct 2009 08:18:03 -0000 IPPM group, With all the discussions on going to China, one almost forgets that we will have 3 meetings beforehand. The next one will be in Hiroshima, Tuesday 13:00-15:00. If you have anything to present, please let us know. I've requested Webex for those who cannot physically attend the meeting. 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 ------------------------------------------------------------------------------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. From Barry.Constantine@jdsu.com Tue Oct 6 15:06:19 2009 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 F38E93A67ED for ; Tue, 6 Oct 2009 15:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkczTMc+YBwE for ; Tue, 6 Oct 2009 15:06:16 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with SMTP id C5D343A6783 for ; Tue, 6 Oct 2009 15:06:15 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSsu/ufQIgWfoB6n5eMwxvHMxQtzo8Tqf@postini.com; Tue, 06 Oct 2009 15:07:54 PDT Received: from SJEXCH03.ds.jdsu.net ([10.75.0.214]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 15:07:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA46D1.356B392E" Date: Tue, 6 Oct 2009 15:06:07 -0700 Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Testing TCP Throughput Capacity in Operator Networks Thread-Index: AcpG0TSWcEI8MNFYT/SKu9CHpYbplA== From: "Barry Constantine" To: X-OriginalArrivalTime: 06 Oct 2009 22:07:05.0713 (UTC) FILETIME=[571D5610:01CA46D1] Subject: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 22:06:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA46D1.356B392E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, =20 I work in the communications test industry and we have seen a growing need to verify the capacity of a network in terms of end-end TCP throughput. =20 =20 Most network operators use RFC-2544 based Layer 3 tests to verify the SLA of the network, but this has significant shortcomings since it does not verify the ability of the network to carry a customer's TCP traffic. Ideally, a TCP layer throughput test would detect issues with prioritization, queuing, policing, etc. This type of test could also detect issues such as TCP Tail drop phenomena in the network. I have spoken to several network operators and equipment providers and there is a consistent desire to test throughput at the stateful TCP layer, at line rate speeds (1G-10G), and to conduct these tests in a standardized manner. =20 At a very high level, a standardized TCP layer throughput test would: =20 - Run a latency test and automatically compute the ideal TCP window size for the test network - Conduct a series of single and multiple connection TCP tests and vary the window size to verify throughput per window size - Conduct QoS testing, tagging the TCP connections with appropriate prioritization (DSCP, etc.) and test in the midst of background traffic loads =20 This is a very simplified description of the test workflow. =20 I would like to solicit the interest of members within the IPPM workgroup and would like to move forward with a draft document to describe this test in detail. =20 Thank you, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 =20 ------_=_NextPart_001_01CA46D1.356B392E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello,

 

I work in the communications test industry and we = have seen a growing need to verify the capacity of a network in terms of end-end = TCP throughput. 

 

Most network operators use RFC-2544 based Layer 3 = tests to verify the SLA of the network, but = this has significant shortcomings since it does not verify the ability of the = network to carry a customer’s TCP traffic.  Ideally, a TCP layer = throughput test would detect issues with = prioritization, queuing, policing, etc.  This type of test could also detect issues = such as TCP Tail drop phenomena in the network.

I have spoken to several network operators and = equipment providers and there is a consistent desire to test throughput at the = stateful TCP layer, at line rate speeds (1G-10G), and to conduct these tests in a standardized manner.

 

At a very high level, a standardized TCP layer = throughput test would:

 

-        Run a latency test and = automatically compute the ideal TCP window size for the test = network

-        Conduct a series of single = and multiple connection TCP tests and vary the window size to verify = throughput per window size

-        Conduct QoS testing, = tagging the TCP connections with appropriate prioritization (DSCP, etc.) and test in the = midst of background traffic loads

 

This is a very simplified description of the test = workflow.

 

I would like to solicit the interest of members = within the IPPM workgroup and would like to move forward with a draft document to = describe this test in detail.

 

Thank you,

Barry

 

Principal Member of Technical = Staff

 

JDSU Communication Test (formerly = Acterna)

Emerging Markets and Technology = Research        

One Milestone Center = Court       &nb= sp;           &nbs= p;          =

Germantown, MD 20876       &nb= sp;           &nbs= p;            = ;         =

(W) 240-404-2227          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;

(C) 301-325-7069

 

------_=_NextPart_001_01CA46D1.356B392E-- From Barry.Constantine@jdsu.com Thu Oct 8 05:55:04 2009 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 5C70B28C168 for ; Thu, 8 Oct 2009 05:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11, 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 rdEb-Az8H8VM for ; Thu, 8 Oct 2009 05:55:03 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with SMTP id E835B3A67EA for ; Thu, 8 Oct 2009 05:54:58 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSs3hiF4M83VYQfVBd6VlexYP/dtOcBy1@postini.com; Thu, 08 Oct 2009 05:56:45 PDT Received: from SJEXCH03.ds.jdsu.net ([10.75.0.214]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 05:50:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2009 05:49:51 -0700 Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09BB06BE@SJEXCH03.ds.jdsu.net> In-Reply-To: <383EF70E894C52438F955558754247FD098DAB83@mail.securitytestsystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ippm Digest, Vol 65, Issue 3 Thread-Index: AcpHgRxfmiD7t6q0QBKKPBL+sq1ltgABtGrgACNyhDA= References: <383EF70E894C52438F955558754247FD098DAB83@mail.securitytestsystems.com> From: "Barry Constantine" To: "Mike Hamilton" X-OriginalArrivalTime: 08 Oct 2009 12:50:21.0983 (UTC) FILETIME=[E5C422F0:01CA4815] Cc: ippm@ietf.org Subject: Re: [ippm] ippm Digest, Vol 65, Issue 3 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, 08 Oct 2009 12:55:04 -0000 Hi Mike, Thanks for the response and offer for support. Can you tell me a little bit about your background and any experiences you have had with the need for TCP layer throughput testing? I am in a technologist role for the test and measurement division of JDSU. I do system level work to define new IP testing capabilities for our products. We recently released Wirespeed TCP test capability (stateful) in our product; operators like it a lot but really want an RFC-2544 type test that is geared for TCP. Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: Mike Hamilton [mailto:mhamilton@breakingpoint.com]=20 Sent: Wednesday, October 07, 2009 3:56 PM To: Barry Constantine Cc: ippm@ietf.org Subject: RE: ippm Digest, Vol 65, Issue 3 Hi Barry, I would be very interested in contributing to this effort. Mike Hamilton ---------------------------------------------------------------------- Message: 1 Date: Tue, 6 Oct 2009 15:06:07 -0700 From: "Barry Constantine" Subject: [ippm] Testing TCP Throughput Capacity in Operator Networks To: Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> Content-Type: text/plain; charset=3D"us-ascii" Hello, =20 I work in the communications test industry and we have seen a growing need to verify the capacity of a network in terms of end-end TCP throughput. =20 =20 Most network operators use RFC-2544 based Layer 3 tests to verify the SLA of the network, but this has significant shortcomings since it does not verify the ability of the network to carry a customer's TCP traffic. Ideally, a TCP layer throughput test would detect issues with prioritization, queuing, policing, etc. This type of test could also detect issues such as TCP Tail drop phenomena in the network. I have spoken to several network operators and equipment providers and there is a consistent desire to test throughput at the stateful TCP layer, at line rate speeds (1G-10G), and to conduct these tests in a standardized manner. =20 At a very high level, a standardized TCP layer throughput test would: =20 - Run a latency test and automatically compute the ideal TCP window size for the test network - Conduct a series of single and multiple connection TCP tests and vary the window size to verify throughput per window size - Conduct QoS testing, tagging the TCP connections with appropriate prioritization (DSCP, etc.) and test in the midst of background traffic loads =20 This is a very simplified description of the test workflow. =20 I would like to solicit the interest of members within the IPPM workgroup and would like to move forward with a draft document to describe this test in detail. =20 Thank you, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm End of ippm Digest, Vol 65, Issue 3 *********************************** From mhamilton@breakingpoint.com Wed Oct 7 12:51:39 2009 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 17A7E28C1E4 for ; Wed, 7 Oct 2009 12:51:39 -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=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311] 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 QyWKwp+5UtIe for ; Wed, 7 Oct 2009 12:51:38 -0700 (PDT) Received: from bpointsys.com (65-36-7-9.static.grandenetworks.net [65.36.7.9]) by core3.amsl.com (Postfix) with ESMTP id 4929A28C1D7 for ; Wed, 7 Oct 2009 12:51:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Oct 2009 14:56:01 -0500 Message-ID: <383EF70E894C52438F955558754247FD098DAB83@mail.securitytestsystems.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ippm Digest, Vol 65, Issue 3 Thread-Index: AcpHgRxfmiD7t6q0QBKKPBL+sq1ltgABtGrg References: From: "Mike Hamilton" To: X-Mailman-Approved-At: Thu, 08 Oct 2009 08:02:40 -0700 Cc: ippm@ietf.org Subject: Re: [ippm] ippm Digest, Vol 65, Issue 3 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, 07 Oct 2009 19:51:39 -0000 Hi Barry, I would be very interested in contributing to this effort. Mike Hamilton ---------------------------------------------------------------------- Message: 1 Date: Tue, 6 Oct 2009 15:06:07 -0700 From: "Barry Constantine" Subject: [ippm] Testing TCP Throughput Capacity in Operator Networks To: Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> Content-Type: text/plain; charset=3D"us-ascii" Hello, =20 I work in the communications test industry and we have seen a growing need to verify the capacity of a network in terms of end-end TCP throughput. =20 =20 Most network operators use RFC-2544 based Layer 3 tests to verify the SLA of the network, but this has significant shortcomings since it does not verify the ability of the network to carry a customer's TCP traffic. Ideally, a TCP layer throughput test would detect issues with prioritization, queuing, policing, etc. This type of test could also detect issues such as TCP Tail drop phenomena in the network. I have spoken to several network operators and equipment providers and there is a consistent desire to test throughput at the stateful TCP layer, at line rate speeds (1G-10G), and to conduct these tests in a standardized manner. =20 At a very high level, a standardized TCP layer throughput test would: =20 - Run a latency test and automatically compute the ideal TCP window size for the test network - Conduct a series of single and multiple connection TCP tests and vary the window size to verify throughput per window size - Conduct QoS testing, tagging the TCP connections with appropriate prioritization (DSCP, etc.) and test in the midst of background traffic loads =20 This is a very simplified description of the test workflow. =20 I would like to solicit the interest of members within the IPPM workgroup and would like to move forward with a draft document to describe this test in detail. =20 Thank you, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm End of ippm Digest, Vol 65, Issue 3 *********************************** From matt.mathis@gmail.com Sat Oct 10 20:46:30 2009 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 A9E593A6800 for ; Sat, 10 Oct 2009 20:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_23=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 hSsCLLKL3qBV for ; Sat, 10 Oct 2009 20:46:29 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 79E4C3A677E for ; Sat, 10 Oct 2009 20:46:29 -0700 (PDT) Received: by bwz6 with SMTP id 6so2450328bwz.37 for ; Sat, 10 Oct 2009 20:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g+X+UJkWNhS/154DZLll7Xcqs9mTZIrMWEU6MmUXiPI=; b=vqK9FuNdyz7PE0JJ7RwJwc6Mrcsz/N5OSkYsd/MJA4AdbSmJYGh5mm68rFcK4a5h7d JoYxlJ8dFUI23kxbZLp05I65l0gbcpwubt1BmX1cVumx9/rUHJhVG1OuXjVPBRLb4IBp jVnU+YejMnBMAAY+vfiGGWI1qq9d7GirGraow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IZ4+znY2WPNFL2T/k173UyDhylIs3JJoiDyxUl/75Hx/3ZItFkSNgK9qs33xbD5k6Z SlGFgKAtB8Q6wrh9KI84doREXTCj6ThJucgL8rHr9A7nyD0cJkHfXmsKBIc2DooYgRVx tmfX4eRzfbqfWYHAUwpD9J14rF1vImm5FyY9U= MIME-Version: 1.0 Received: by 10.204.8.13 with SMTP id f13mr3770037bkf.150.1255232892115; Sat, 10 Oct 2009 20:48:12 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Oct 2009 23:48:12 -0400 Message-ID: From: Matt Mathis To: Barry Constantine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org Subject: Re: [ippm] [M-Lab-Steering] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 03:46:30 -0000 Barry, NPAD uses essentially the same algorithm as your proposed test. While it works quite well as a diagnostic, it doesn't work so well as a metric, because the results can't be well calibrated or modeled. I have been thinking about this problem for a very long time (It was my goal when I was the founding co-chair of the IPPM BOF, at IETF 35). Following my experiences developing NPAD (which was yet another iteration on the problem) have come to the conclusion that part of the problem is that we have been asking the wrong question all these years. TCP performance is to unstable and unpredictable to be a good metric of anything. A better metric would be a packet loss test at high data rate (e.g. 80% of the link capacity), that asks a pass-fail question (is the loss rate lower than X). With the proper parameters the test guarantees a lower bound on ideal TCP performance, and at the same time supports an algebra: if the separate sections of a path each pass the metric, then you can predict if the concatenated sections do as well. For an SLA the most useful metric would actually be the statistics of the test: what fraction of the time does it pass for what fraction of the endpoints? I will be at Hiroshima - will you? Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Tue, Oct 6, 2009 at 6:49 PM, Stephen Stuart wrote: > Hi, Barry. I saw your post on the IPPM list: > > =A0 =A0http://www.ietf.org/mail-archive/web/ippm/current/msg02176.html > > and I think it would be worth your while to have a look at the tools > used in Measurement Lab - http://measurementlab.net/ - NPAD and NDT in > particular. I'm cc'ing the rest of the steering committee so that they > can see the pointer to your IPPM post and so that you can follow up > with any questions regarding the platform, tools, test methodology, > etc. > > Thanks, > Stephen From gilles.forget@sympatico.ca Sun Oct 11 10:09:49 2009 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 4B9423A693A for ; Sun, 11 Oct 2009 10:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 JY1RAA+oBl37 for ; Sun, 11 Oct 2009 10:09:48 -0700 (PDT) Received: from blu0-omc4-s9.blu0.hotmail.com (blu0-omc4-s9.blu0.hotmail.com [65.55.111.148]) by core3.amsl.com (Postfix) with ESMTP id 7DC9D3A689D for ; Sun, 11 Oct 2009 10:09:48 -0700 (PDT) Received: from BLU0-SMTP98 ([65.55.111.135]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 10:09:48 -0700 X-Originating-IP: [64.228.80.172] X-Originating-Email: [gilles.forget@sympatico.ca] Message-ID: Received: from [192.168.2.35] ([64.228.80.172]) by BLU0-SMTP98.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 10:09:47 -0700 From: Gilles Forget To: Barry Constantine Content-Type: text/plain Date: Sun, 11 Oct 2009 13:09:47 -0400 Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2009 17:09:47.0379 (UTC) FILETIME=[A2B45430:01CA4A95] Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 17:09:49 -0000 Barry, I am an independent consultant in the telecommunication area with several decades of experience working for a network provider and I completely support your idea. In the circuit switching days, network providers were able to measure their end to end path performances with Bit Error Rate Test patterns like 2047, QRSS and others. Instruments like the FIREBERD 6000 from TTC were used as reference test sets and network path performances were measured against ITU-T standards like G.821 or ANSI standards. Network providers infrastructures have evolved from layer one only to layer two network paths using Frame relay and ATM protocols and then later on layer 3 network paths using IP and MPLS protocols. Now, in the packet switching days, there is a need for more precision in the way tests are conducted. Network providers can not provide their customers with a simple pass/fail result any more. They should be able to provide their customers with more complex feedback results. These results should help their business customers optimizing their complete IP network performances. Thanks. -- Gilles Forget, CCNP T : 450.473.5718 C : 514.895.8212 @ : gilles.forget@sympatico.ca From Ruediger.Geib@telekom.de Tue Oct 13 02:47:53 2009 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 638353A689A for ; Tue, 13 Oct 2009 02:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 u4E0b3Xp-BLu for ; Tue, 13 Oct 2009 02:47:47 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 2F81E3A680B for ; Tue, 13 Oct 2009 02:47:45 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 13 Oct 2009 11:47:41 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 11:47:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4BEA.34522E63" Date: Tue, 13 Oct 2009 11:47:39 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Testing TCP Throughput Capacity in Operator Networks Thread-Index: AcpG0TSWcEI8MNFYT/SKu9CHpYbplAFFrUlg References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> From: To: X-OriginalArrivalTime: 13 Oct 2009 09:47:41.0053 (UTC) FILETIME=[349BB2D0:01CA4BEA] Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 09:47:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4BEA.34522E63 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Barry, =20 I'm not sure, whether IPPM is chartered to specify transport layer = performance metrics. I've checked the PMOL charter and it clearly says = PMOL works above transport layer. A fair conclusion would be, that IPPM = is chartered to investigate transport layer performance. =20 Three questions to the chairs and to the IPPM WG come to my mind: =20 Chairs: Is IPPM chartered to execute the work proposed by Barry? =20 IPPM WG: If not, is there interest to charter IPPM for such an activity? =20 Chairs: If not, to which WG can Barry submit his proposal? =20 My personal interest in this activity is limited, saying no support, no = objection. The feedback I received from within the company I work for = is, that such an activity is relevant for application or service = providers, but not for carriers.=20 =20 Regards, =20 Ruediger =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 _____ =20 From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of = Barry Constantine Sent: Wednesday, October 07, 2009 12:06 AM To: ippm@ietf.org Subject: [ippm] Testing TCP Throughput Capacity in Operator Networks Hello, =20 I work in the communications test industry and we have seen a growing = need to verify the capacity of a network in terms of end-end TCP = throughput. =20 =20 Most network operators use RFC-2544 based Layer 3 tests to verify the = SLA of the network, but this has significant shortcomings since it does = not verify the ability of the network to carry a customer's TCP traffic. = Ideally, a TCP layer throughput test would detect issues with = prioritization, queuing, policing, etc. This type of test could also = detect issues such as TCP Tail drop phenomena in the network. I have spoken to several network operators and equipment providers and = there is a consistent desire to test throughput at the stateful TCP = layer, at line rate speeds (1G-10G), and to conduct these tests in a = standardized manner. =20 At a very high level, a standardized TCP layer throughput test would: =20 - Run a latency test and automatically compute the ideal TCP = window size for the test network - Conduct a series of single and multiple connection TCP tests = and vary the window size to verify throughput per window size - Conduct QoS testing, tagging the TCP connections with = appropriate prioritization (DSCP, etc.) and test in the midst of = background traffic loads =20 This is a very simplified description of the test workflow. =20 I would like to solicit the interest of members within the IPPM = workgroup and would like to move forward with a draft document to = describe this test in detail. =20 Thank you, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 =20 ------_=_NextPart_001_01CA4BEA.34522E63 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Barry,
 
I'm not sure, whether IPPM is chartered to = specify=20 transport layer performance metrics. I've checked the PMOL charter and = it=20 clearly says PMOL works above transport layer. A fair conclusion would = be, that=20 IPPM is chartered to investigate transport layer=20 performance.
 
Three questions to the chairs and to the IPPM = WG come=20 to my mind:
 
Chairs: Is IPPM chartered to execute the work = proposed by=20 Barry?
 
IPPM WG: If not, is there interest to = charter IPPM for such an activity?
 
Chairs: If not, to which WG can Barry submit = his=20 proposal?
 
My personal interest in this activity is = limited, saying no=20 support, no objection. The feedback I received from within the company I = work=20 for is, that such an activity is relevant for application or = service=20 providers, but not for carriers. 
 
Regards,
 
Ruediger
 

Deutsche Telekom Netzproduktion = GmbH
Zentrum=20 Technik Einf=FChrung
Technik Internet Backbone, TE142-19
R=FCdiger = Geib
Heinrich Hertz Str. 3-7
64297 Darmstadt
Tel.:=20 06151/6282747
Fax: 0251/7985109


Deutsche Telekom = Netzproduktion=20 GmbH
Aufsichtsrat: Dr. Steffen Roehn = (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr.=20 Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus=20 Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der = Gesellschaft:=20 Bonn
USt-IdNr.: DE 814645262


From: ippm-bounces@ietf.org=20 [mailto:ippm-bounces@ietf.org] On Behalf Of Barry=20 Constantine
Sent: Wednesday, October 07, 2009 12:06 = AM
To:=20 ippm@ietf.org
Subject: [ippm] Testing TCP Throughput Capacity = in=20 Operator Networks

Hello,

 

I work in the = communications test=20 industry and we have seen a growing need to verify the capacity of a = network in=20 terms of end-end TCP throughput. 

 

Most network operators use = RFC-2544=20 based Layer 3 tests to verify the SLA = of the=20 network, but this has significant shortcomings since it does not verify = the=20 ability of the network to carry a customer’s TCP traffic.  = Ideally, a TCP=20 layer throughput test would detect issues = with=20 prioritization, queuing, policing, etc.  This type of test could = also=20 detect issues such as TCP Tail drop phenomena in the=20 network.

I have spoken to several = network=20 operators and equipment providers and there is a consistent desire to = test=20 throughput at the stateful TCP layer, at line rate speeds (1G-10G), and = to=20 conduct these tests in a standardized = manner.

 

At a very high level, a = standardized=20 TCP layer throughput test would:

 

-       =20 Run a latency test and = automatically=20 compute the ideal TCP window size for the test=20 network

-       =20 Conduct a series of single = and=20 multiple connection TCP tests and vary the window size to verify = throughput per=20 window size

-       =20 Conduct QoS testing, = tagging the TCP=20 connections with appropriate prioritization (DSCP, etc.) and test in the = midst=20 of background traffic loads

 

This is a very simplified=20 description of the test workflow.

 

I would like to solicit = the interest=20 of members within the IPPM workgroup and would like to move forward with = a draft=20 document to describe this test in detail.

 

Thank=20 you,

Barry

 

Principal Member of = Technical=20 Staff

 

JDSU Communication Test = (formerly=20 Acterna)

Emerging Markets and = Technology=20 Research        =20

One Milestone Center=20 Court<= FONT=20 face=3DArial>           =             &= nbsp;     <= /SPAN>=20

Germantown,=20 MD=20 20876           =             &= nbsp;           &n= bsp;    =20

(W)=20 240-404-2227          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;=20

(C)=20 301-325-7069

 

------_=_NextPart_001_01CA4BEA.34522E63-- From henk@ripe.net Tue Oct 13 03:18:06 2009 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 80F7F3A680C for ; Tue, 13 Oct 2009 03:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPJtkNzW8+iZ for ; Tue, 13 Oct 2009 03:18:05 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 08F6C3A68C3 for ; Tue, 13 Oct 2009 03:18:04 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MxeS3-0001ey-7V; Tue, 13 Oct 2009 12:18:00 +0200 Received: from geir-3.local (henk.vpn.ripe.net [193.0.21.33]) by herring.ripe.net (Postfix) with ESMTP id 257952F583; Tue, 13 Oct 2009 12:17:55 +0200 (CEST) Message-ID: <4AD453D3.7030602@ripe.net> Date: Tue, 13 Oct 2009 12:17:55 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5404a762b0577821d4f8b8543d38f8fb2 Cc: Barry.Constantine@jdsu.com, ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 10:18:06 -0000 Hi Ruediger, Personal opinion, not discussed with Matt or AD's yet > I'm not sure, whether IPPM is chartered to specify transport layer > performance metrics. I've checked the PMOL charter and it clearly says > PMOL works above transport layer. A fair conclusion would be, that IPPM > is chartered to investigate transport layer performance. I looked at it from a slightly different angle. Network capacity has always been a topic of interest for IPPM, so this work would be in our charter. PMOL deals with higher layers, besides that (AFAIK) the PMOL WG is in some form of hybernation. So, my take on this is that we should see if there is interest to work on this topic _and_ have a first version of a draft, we can decide later where exactly this works fits in the IETF. 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 ------------------------------------------------------------------------------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. From Ruediger.Geib@telekom.de Tue Oct 13 03:21:13 2009 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 C690F3A6A33 for ; Tue, 13 Oct 2009 03:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt1B6id1EfMK for ; Tue, 13 Oct 2009 03:21:12 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id D4C9C3A695C for ; Tue, 13 Oct 2009 03:21:10 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 13 Oct 2009 12:21:06 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:21:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 12:21:05 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5024D0E09@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <4AB34BEA.9060109@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Adopt draft-duffield-ippm-burst-loss-metrics-01 as a WGdocument. Thread-Index: Aco4Po8tK1+Zp71hQbiuA3hZQIF76wTrofeg References: <4A77E556.9010905@ripe.net> <4AB34BEA.9060109@ripe.net> From: To: X-OriginalArrivalTime: 13 Oct 2009 10:21:06.0344 (UTC) FILETIME=[DFDAD280:01CA4BEE] Cc: ippm@ietf.org Subject: Re: [ippm] Adopt draft-duffield-ippm-burst-loss-metrics-01 as a WGdocument. 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, 13 Oct 2009 10:21:13 -0000 Henk, I've read the draft and the publications it partially refers to.=20 It defines metrics to determine the frequency and duration of loss = intervals, so it=20 would enhance existing work. This could be relevant to characterise = network performance=20 for higher layer applications. What one might be able to do with this metric is characterising loss = events. But I=20 can't judge whether the metrics in addition with the loss and loss = pattern metrics=20 deliver all whats required to characterise packet loss. Well, the "yes or no" question: a weak yes. I'd appreciate if some more = of the=20 metric engineering related discussion within the publication was = transfered to=20 the draft, should it become WG item. Regards, Ruediger Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of = Henk Uijterwaal Sent: Friday, September 18, 2009 10:59 AM To: Henk Uijterwaal Cc: IETF IPPM WG Subject: Re: [ippm] Adopt draft-duffield-ippm-burst-loss-metrics-01 as a = WGdocument. IPPM, > In Stockholm, we received a request to adopt >=20 > Burst Loss Metrics for IPPM > draft-duffield-ippm-burst-loss-metrics-01 >=20 > as a WG item. If you have any comments on this, please let us know = before > Monday, September 14, 2009. No comments were received. This makes it a bit hard to judge if there = is interest to work on this. So, if you are interested, please send an explicit "yes" to the list. Henk --=20 -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Tue Oct 13 05:27:47 2009 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 CAE9B28C169 for ; Tue, 13 Oct 2009 05:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9teNxTpWuHGL for ; Tue, 13 Oct 2009 05:27:47 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id F3B6F3A67A2 for ; Tue, 13 Oct 2009 05:27:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1255436866!31954339!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 30778 invoked from network); 13 Oct 2009 12:27:47 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-13.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Oct 2009 12:27:47 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n9DCRkA6023396 for ; Tue, 13 Oct 2009 07:27:46 -0500 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n9DCRd33022826 for ; Tue, 13 Oct 2009 07:27:39 -0500 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id n9DCRd6b012959 for ; Tue, 13 Oct 2009 07:27:39 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id n9DCRaj4012870 for ; Tue, 13 Oct 2009 07:27:36 -0500 Message-Id: <200910131227.n9DCRaj4012870@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004276dys.mt.att.com[135.16.251.251](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20091013122735gw1006v7ghe>; Tue, 13 Oct 2009 12:27:36 +0000 X-Originating-IP: [135.16.251.251] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Oct 2009 08:27:34 -0400 To: Henk Uijterwaal From: Al Morton In-Reply-To: <4AD453D3.7030602@ripe.net> References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 12:27:47 -0000 At 06:17 AM 10/13/2009, Henk Uijterwaal wrote: >...PMOL deals with higher layers, besides that (AFAIK) the PMOL >WG is in some form of hybernation. Expect to see more action in PMOL when the revised draft of the framework and guidelines is published (new editor). Also, there is considerable activity on the SIP metrics draft at the IESG level. Al pmol co-chair From henk@ripe.net Tue Oct 13 06:26:22 2009 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 9CBCC28C1C0 for ; Tue, 13 Oct 2009 06:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AnyESB-p7ne for ; Tue, 13 Oct 2009 06:26:21 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id A8A3E28C1A4 for ; Tue, 13 Oct 2009 06:26:21 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MxhOK-0005ha-KY; Tue, 13 Oct 2009 15:26:21 +0200 Received: from geir-3.local (henk.vpn.ripe.net [193.0.21.33]) by herring.ripe.net (Postfix) with ESMTP id 8CF942F583; Tue, 13 Oct 2009 15:26:16 +0200 (CEST) Message-ID: <4AD47FF8.8040409@ripe.net> Date: Tue, 13 Oct 2009 15:26:16 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Al Morton References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <200910131227.n9DCRaNO012869@klpd017.kcdc.att.com> In-Reply-To: <200910131227.n9DCRaNO012869@klpd017.kcdc.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d54d36c595f4b93573ec217265f5c031f1 Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:26:22 -0000 Al, > At 06:17 AM 10/13/2009, Henk Uijterwaal wrote: >> ...PMOL deals with higher layers, besides that (AFAIK) the PMOL >> WG is in some form of hybernation. > > Expect to see more action in PMOL when the revised draft of the > framework and guidelines is published (new editor). I wasn't aware of this activity. That said, do you agree that this work belongs in IPPM rather than PMOL? Henk > Also, there is considerable activity on the SIP metrics draft > at the IESG level. -- ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. From matt@internet2.edu Tue Oct 13 07:32:20 2009 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 6583228C1D5 for ; Tue, 13 Oct 2009 07:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eCAOXJ6Y-Jp for ; Tue, 13 Oct 2009 07:32:19 -0700 (PDT) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id E88F028C31D for ; Tue, 13 Oct 2009 07:32:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id 359B82252DD; Tue, 13 Oct 2009 10:32:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at magus.merit.edu Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfUhhWBbdlk6; Tue, 13 Oct 2009 10:32:19 -0400 (EDT) Received: from matt.local (ool-4357e3cf.dyn.optonline.net [67.87.227.207]) (Authenticated sender: matt@internet2.edu) by magus.merit.edu (Postfix) with ESMTP id C4961225296; Tue, 13 Oct 2009 10:32:18 -0400 (EDT) Message-ID: <4AD48F72.5030904@internet2.edu> Date: Tue, 13 Oct 2009 10:32:18 -0400 From: Matthew J Zekauskas User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: ippm@ietf.org References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> In-Reply-To: <4AD453D3.7030602@ripe.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barry.Constantine@jdsu.com Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 14:32:20 -0000 My thoughts are similar to Henk's. IPPM has always been interested in the area (see the bulk transport capacity work), so I'd claim the area is in-scope, but doing work would require AD discussion. I think Matt Mathis' last message to the list is also worth thought; it's hard to create a good metric. In some sense what has been proposed is documenting current practice (we do something similar for quality control on the R&E networks, and NPAD is used for debugging). I cannot be in Hiroshima do to a conflicting conference, but look forward to the results of any discussion there. --Matt On 10/13/09 6:17 AM, Henk Uijterwaal wrote: > Hi Ruediger, > > Personal opinion, not discussed with Matt or AD's yet > >> I'm not sure, whether IPPM is chartered to specify transport layer >> performance metrics. I've checked the PMOL charter and it clearly says >> PMOL works above transport layer. A fair conclusion would be, that >> IPPM is chartered to investigate transport layer performance. > > I looked at it from a slightly different angle. Network capacity has > always been a topic of interest for IPPM, so this work would be in our > charter. PMOL deals with higher layers, besides that (AFAIK) the PMOL > WG is in some form of hybernation. > > So, my take on this is that we should see if there is interest to work > on this topic _and_ have a first version of a draft, we can decide later > where exactly this works fits in the IETF. > > 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 > ------------------------------------------------------------------------------ > > > Belgium: an unsolvable problem, discussed in endless meetings, with no > hope for a solution, where everybody still lives happily. > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From Barry.Constantine@jdsu.com Tue Oct 13 07:43:39 2009 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 654B03A687F for ; Tue, 13 Oct 2009 07:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1ls5KGQi1zH for ; Tue, 13 Oct 2009 07:43:38 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with SMTP id BE9C73A6885 for ; Tue, 13 Oct 2009 07:43:34 -0700 (PDT) Received: from source ([209.36.247.244]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKStSSFZD0XYbAP3Zrlf6NyI6o5HO9QetG@postini.com; Tue, 13 Oct 2009 07:43:39 PDT Received: from SJEXCH03.ds.jdsu.net ([10.75.0.214]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 07:41:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 07:41:42 -0700 Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09BFE460@SJEXCH03.ds.jdsu.net> In-Reply-To: <4AD453D3.7030602@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Testing TCP Throughput Capacity in Operator Networks Thread-Index: AcpL71s20lM2emtDR8SGFrynAoAfkgAEdmrw References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net><151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> From: "Barry Constantine" To: "Henk Uijterwaal" , X-OriginalArrivalTime: 13 Oct 2009 14:41:42.0938 (UTC) FILETIME=[47FDB7A0:01CA4C13] Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 14:43:39 -0000 Henk and Ruediger, Thank for your comments and I would like to clarify a few points concerning the proposal for a draft related to TCP Throughput Capacity test methodology and metrics. When I first addressed the subject with Henk and Matt Zekauskas, I was pointed to RFC 3148, draft-ietf-ippm-treno-btc-03, and draft-ietf-ippm-btc-cap-00 as a starting point. By the way, I found these to be very interesting and useful papers. The TCP Throughput Capacity draft would reference these papers but would focus more at the network level metrics of TCP performance, not the specific behavior of various TCP mechanisms and implementations (i.e. CAC, False time-outs, Self-clocking, etc.). In other words, given a large complex network with various QoS and queuing techniques employed, the TCP throughput technique would allow a network provider to quantify the ability of the entire network to carry TCP traffic at specified SLA levels. Varying window sizes and MSS sizes is one component of this type of test. Another key component to this test is the throughput achieved with varying background traffic (perhaps UDP) and verifying proper prioritization between the TCP traffic and the background traffic. =20 It is very difficult for a network provider to extrapolate TCP layer performance from packet loss studies and metrics. RFC-2544 is widely used today and makes it difficult (if not impossible) to adequately characterize how TCP will perform. Concerning the interest level based upon the responses, the sample size is small, but I have received 3-4 who are interested and 3-4 with little interest. Referencing Henk's final remarks; does this constitute enough interest from this working group to work on a draft? Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Henk Uijterwaal Sent: Tuesday, October 13, 2009 6:18 AM To: Ruediger.Geib@telekom.de Cc: Barry Constantine; ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks Hi Ruediger, Personal opinion, not discussed with Matt or AD's yet > I'm not sure, whether IPPM is chartered to specify transport layer=20 > performance metrics. I've checked the PMOL charter and it clearly says > PMOL works above transport layer. A fair conclusion would be, that IPPM=20 > is chartered to investigate transport layer performance. I looked at it from a slightly different angle. Network capacity has always been a topic of interest for IPPM, so this work would be in our charter. PMOL deals with higher layers, besides that (AFAIK) the PMOL WG is in some form of hybernation. So, my take on this is that we should see if there is interest to work on this topic _and_ have a first version of a draft, we can decide later where exactly this works fits in the IETF. 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 ------------------------------------------------------------------------ ------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From gilles.forget@sympatico.ca Tue Oct 13 08:23:31 2009 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 B7D0128C1EA for ; Tue, 13 Oct 2009 08:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MSGID_FROM_MTA_HEADER=0.803] 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 yyKk8KnkX0XD for ; Tue, 13 Oct 2009 08:23:30 -0700 (PDT) Received: from blu0-omc4-s35.blu0.hotmail.com (blu0-omc4-s35.blu0.hotmail.com [65.55.111.174]) by core3.amsl.com (Postfix) with ESMTP id 9F8BF3A67AB for ; Tue, 13 Oct 2009 08:23:30 -0700 (PDT) Received: from BLU0-SMTP99 ([65.55.111.137]) by blu0-omc4-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 08:23:32 -0700 X-Originating-IP: [64.228.80.172] X-Originating-Email: [gilles.forget@sympatico.ca] Message-ID: Received: from [192.168.2.35] ([64.228.80.172]) by BLU0-SMTP99.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 08:23:31 -0700 From: Gilles Forget To: Ruediger.Geib@telekom.de In-Reply-To: <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain; charset="UTF-8" Date: Tue, 13 Oct 2009 11:23:31 -0400 Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 13 Oct 2009 15:23:31.0784 (UTC) FILETIME=[1F613C80:01CA4C19] Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 15:23:31 -0000 Bonjour Ruediger, If I may, I would like to comment on the feedback you received from within your company. Here in North America, over the last 30 years, we have seen the monopolistic carriers evolve to competitive Service Providers and even Application Service Providers.=20 There are still pure Carrier Transport SONET type equipments involved in their core network, but most of the business customer services are now delivered via an MPLS infrastructure using IP routers and multi-layer switches in the core, distribution and access layers of the network. There are also Professional Services groups and Network Security groups within the organizations involved in business services delivery for some major customers. I am pretty sure, that most European PT&Ts have done the same.=20 So I do not see why you still make differences between application or service providers and carriers! Thanks, Gilles Forget, CCNP. On Tue, 2009-10-13 at 11:47 +0200, Ruediger.Geib@telekom.de wrote: > Hello Barry, > =20 > I'm not sure, whether IPPM is chartered to specify transport layer > performance metrics. I've checked the PMOL charter and it clearly says > PMOL works above transport layer. A fair conclusion would be, that > IPPM is chartered to investigate transport layer performance. > =20 > Three questions to the chairs and to the IPPM WG come to my mind: > =20 > Chairs: Is IPPM chartered to execute the work proposed by Barry? > =20 > IPPM WG: If not, is there interest to charter IPPM for such an > activity? > =20 > Chairs: If not, to which WG can Barry submit his proposal? > =20 > My personal interest in this activity is limited, saying no support, > no objection. The feedback I received from within the company I work > for is, that such an activity is relevant for application or service > providers, but not for carriers.=20 > =20 > Regards, > =20 > Ruediger > =20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=C3=BChrung > Technik Internet Backbone, TE142-19 > R=C3=BCdiger Geib > Heinrich Hertz Str. 3-7 > 64297 Darmstadt > Tel.: 06151/6282747 > Fax: 0251/7985109 >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=C3=A4ftsf=C3=BChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albe= rt > Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 >=20 >=20 >=20 >=20 >=20 > ______________________________________________________________________ > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf > Of Barry Constantine > Sent: Wednesday, October 07, 2009 12:06 AM > To: ippm@ietf.org > Subject: [ippm] Testing TCP Throughput Capacity in Operator Networks >=20 >=20 >=20 > Hello, >=20 > =20 >=20 > I work in the communications test industry and we have seen a growing > need to verify the capacity of a network in terms of end-end TCP > throughput. =20 >=20 > =20 >=20 > Most network operators use RFC-2544 based Layer 3 tests to verify the > SLA of the network, but this has significant shortcomings since it > does not verify the ability of the network to carry a customer=E2=80=99s = TCP > traffic. Ideally, a TCP layer throughput test would detect issues > with prioritization, queuing, policing, etc. This type of test could > also detect issues such as TCP Tail drop phenomena in the network. >=20 >=20 >=20 > I have spoken to several network operators and equipment providers and > there is a consistent desire to test throughput at the stateful TCP > layer, at line rate speeds (1G-10G), and to conduct these tests in a > standardized manner. >=20 > =20 >=20 > At a very high level, a standardized TCP layer throughput test would: >=20 > =20 >=20 > - Run a latency test and automatically compute the ideal TCP > window size for the test network >=20 > - Conduct a series of single and multiple connection TCP tests > and vary the window size to verify throughput per window size >=20 > - Conduct QoS testing, tagging the TCP connections with > appropriate prioritization (DSCP, etc.) and test in the midst of > background traffic loads >=20 > =20 >=20 > This is a very simplified description of the test workflow. >=20 > =20 >=20 > I would like to solicit the interest of members within the IPPM > workgroup and would like to move forward with a draft document to > describe this test in detail. >=20 > =20 >=20 > Thank you, >=20 > Barry >=20 > =20 >=20 > Principal Member of Technical Staff >=20 > =20 >=20 > JDSU Communication Test (formerly Acterna) >=20 > Emerging Markets and Technology Research =20 >=20 > One Milestone Center Court =20 >=20 > Germantown, MD 20876 =20 >=20 > (W) 240-404-2227 =20 >=20 > (C) 301-325-7069 >=20 > =20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --=20 Gilles Forget, CCNP T : 450.473.5718 C : 514.895.8212 @ : gilles.forget@sympatico.ca From acmorton@att.com Tue Oct 13 08:56:37 2009 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 8B75F28C17B for ; Tue, 13 Oct 2009 08:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpgPk6tc5Lte for ; Tue, 13 Oct 2009 08:56:36 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id B6A6D3A6807 for ; Tue, 13 Oct 2009 08:56:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1255449396!20526861!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 24319 invoked from network); 13 Oct 2009 15:56:37 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Oct 2009 15:56:37 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n9DFuaYR000693 for ; Tue, 13 Oct 2009 10:56:36 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n9DFuU7k000545 for ; Tue, 13 Oct 2009 10:56:31 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id n9DFuTLJ030022 for ; Tue, 13 Oct 2009 11:56:29 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id n9DFuPQu029929 for ; Tue, 13 Oct 2009 11:56:25 -0400 Message-Id: <200910131556.n9DFuPQu029929@alpd052.aldc.att.com> Received: from acmt.att.com (dyp004276dys.mt.att.com[135.16.251.251](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20091013155624gw1006v7j0e>; Tue, 13 Oct 2009 15:56:25 +0000 X-Originating-IP: [135.16.251.251] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Oct 2009 11:56:15 -0400 To: Henk Uijterwaal From: Al Morton In-Reply-To: <4AD47FF8.8040409@ripe.net> References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <200910131227.n9DCRaNO012869@klpd017.kcdc.att.com> <4AD47FF8.8040409@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 15:56:37 -0000 At 09:26 AM 10/13/2009, Henk Uijterwaal wrote: >Al, > >>At 06:17 AM 10/13/2009, Henk Uijterwaal wrote: >>>...PMOL deals with higher layers, besides that (AFAIK) the PMOL >>>WG is in some form of hybernation. >>Expect to see more action in PMOL when the revised draft of the >>framework and guidelines is published (new editor). > >I wasn't aware of this activity. That said, do you agree that this >work belongs in IPPM rather than PMOL? > >Henk I think that TCP performance has always been in IPPM's charter. But like a few others, I have doubts that TCP-based throughput measurements will produce useful results, starting with the issue of what TCP version and other configuration options to use. However, Matt Mathis' suggestion deserves attention. I should also add that Ethernet-layer throughput testing has been proposed in ITU-T SG12 Q17, and contributions are expected on this topic at the November meeting (this is scheduled at the same time as IETF, so I won't be in Hiroshima in person). Al From ljorgenson@apparentnetworks.com Tue Oct 13 10:37:45 2009 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 7BE6E3A691B for ; Tue, 13 Oct 2009 10:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 FYQ+aJgAXFH4 for ; Tue, 13 Oct 2009 10:37:44 -0700 (PDT) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id A73843A6784 for ; Tue, 13 Oct 2009 10:37:44 -0700 (PDT) X-AuditID: ac108108-00000314000007a0-5b-4ad4bae70f99 Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Oct 2009 10:37:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 10:37:44 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: questions of TCP metrics Thread-Index: AcpMHcnwo6NbyziRQ7+s8PSgllQXVAACNuFg References: From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Subject: [ippm] questions of TCP metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 17:37:45 -0000 Please pardon my relative na=EFvet=E9 and probable ignorance of past = discussions on this topic - but there are two points that I am not clear = on: 1) "TCP performance has always been in IPPM's charter" - does this = statement derive entirely from historical precedence? =20 In light of the existence of PMOL (regardless of its current state of = quiescence), it would seem obvious that TCP is part of the "other = layers" scheme. Specifically, it would seem that TCP performs as = consequence of an application's implementation and therefore that TCP = performance would be non-specific to (although clearly a function of) = IP-level characteristics, just as MOS would related but non-specific in = the case of VoIP. The IPPM charter comes as close as referencing "bulk transport capacity" = but it is not trivial (for me) to conclude that a specific mechanism for = enabling bulk transport is necessarily within scope. Prior to PMOL, = IPPM would seem the likeliest group to have undertaken a TCP metric. = And, certainly, if another group such as PMOL were undertaking a TCP = metric, it would be obvious that IPPM would be involved. This may well be simply a matter of philosophical leaning - but so that = I am clear - on what basis do you say, Al, that TCP performance is = unquestionably an IPPM matter? 2) There are at least two regimes of TCP performance that seem important = to consider: i) non-equilibrium behaviors such as during slow-start ii) steady-state behaviors Apart from the vagaries of different TCP implementations, does not the = work of Padhye et al and Mathis et al (such as listed below) offer the = basis for at least developing useful steady-state descriptions? =20 Matt Mathis himself has said he does not see it being viable developing = metrics along these lines. While I can imagine they are not 100% = accurate under all circumstances, they would at least seem like useful = extrapolations of IP-level characteristics. What then are the most = important shortcomings of these models? Refs: Modeling TCP Reno Performance: A Simple Model and its Empirical = Validation J. Padhye, V. Firoiu, D. Towsley and J. Kurose, IEEE/ACM Transactions on Networking, April 2000. [1] M. Mathis, J. Semske, J. Mahdavi and T. Ott, The Macroscopic = Behavior of the TCP Congestion Avoidance Algorithm, Computer = Communication Review, Vol 27, Number 3, July 1997 Al Morton writes: >Message: 6 >Date: Tue, 13 Oct 2009 11:56:15 -0400 >From: Al Morton >Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator = Networks >To: Henk Uijterwaal >Cc: ippm@ietf.org >Message-ID: <200910131556.n9DFuPQu029929@alpd052.aldc.att.com> >Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed > >At 09:26 AM 10/13/2009, Henk Uijterwaal wrote: >>Al, >> >>>At 06:17 AM 10/13/2009, Henk Uijterwaal wrote: >>>>...PMOL deals with higher layers, besides that (AFAIK) the PMOL >>>>WG is in some form of hybernation. >>>Expect to see more action in PMOL when the revised draft of the >>>framework and guidelines is published (new editor). >> >>I wasn't aware of this activity. That said, do you agree that this >>work belongs in IPPM rather than PMOL? >> >>Henk > >I think that TCP performance has always been in IPPM's charter. > >But like a few others, I have doubts that TCP-based throughput >measurements will produce useful results, starting with the >issue of what TCP version and other configuration options to use. >However, Matt Mathis' suggestion deserves attention. > >I should also add that Ethernet-layer throughput testing has >been proposed in ITU-T SG12 Q17, and contributions are expected on >this topic at the November meeting (this is scheduled at the >same time as IETF, so I won't be in Hiroshima in person). > >Al --- Loki Jorgenson Apparent Networks t 604 433 2333 ext 105 m 604 250-4642 From Barry.Constantine@jdsu.com Tue Oct 13 11:30:11 2009 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 930A428C0DD for ; Tue, 13 Oct 2009 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jrNSf1+m2AN for ; Tue, 13 Oct 2009 11:30:07 -0700 (PDT) Received: from chip3og56.obsmtp.com (chip3og56.obsmtp.com [64.18.14.177]) by core3.amsl.com (Postfix) with SMTP id 4AD1E28B56A for ; Tue, 13 Oct 2009 11:29:51 -0700 (PDT) Received: from source ([209.36.247.245]) by chip3ob56.postini.com ([64.18.6.12]) with SMTP ID DSNKStTHIFKEsUAI9gH4sW9V9TfLkwp9w/CE@postini.com; Tue, 13 Oct 2009 11:29:54 PDT Received: from SJEXCH03.ds.jdsu.net ([10.75.0.214]) by Outbound2.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 11:24:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 11:24:55 -0700 Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09C94B26@SJEXCH03.ds.jdsu.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] questions of TCP metrics Thread-Index: AcpMHcnwo6NbyziRQ7+s8PSgllQXVAACNuFgAAKTaTA= References: From: "Barry Constantine" To: "Loki Jorgenson" , X-OriginalArrivalTime: 13 Oct 2009 18:24:56.0948 (UTC) FILETIME=[77717340:01CA4C32] Subject: Re: [ippm] questions of TCP metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 18:30:11 -0000 Hi Loki,=20 You mentioned MOS scores of VoIP and that is a very good analogy to what = providers face today. In a VoIP environment, IP layer packet metrics can be correlated to VoIP = quality, but network providers obviously find MOS scores a much more = meaningful metric of the VoIP application running over the network. Similarly, network providers can run IP layer tests (as they do today = with RFC-2544) and infer TCP / application layer performance. But = network providers seek a more meaningful and realistic measure of = potential application performance and would benefit from TCP layer = throughput measurements. Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of = Loki Jorgenson Sent: Tuesday, October 13, 2009 1:38 PM To: ippm@ietf.org Subject: [ippm] questions of TCP metrics Please pardon my relative na=EFvet=E9 and probable ignorance of past = discussions on this topic - but there are two points that I am not clear = on: 1) "TCP performance has always been in IPPM's charter" - does this = statement derive entirely from historical precedence? =20 In light of the existence of PMOL (regardless of its current state of = quiescence), it would seem obvious that TCP is part of the "other = layers" scheme. Specifically, it would seem that TCP performs as = consequence of an application's implementation and therefore that TCP = performance would be non-specific to (although clearly a function of) = IP-level characteristics, just as MOS would related but non-specific in = the case of VoIP. The IPPM charter comes as close as referencing "bulk transport capacity" = but it is not trivial (for me) to conclude that a specific mechanism for = enabling bulk transport is necessarily within scope. Prior to PMOL, = IPPM would seem the likeliest group to have undertaken a TCP metric. = And, certainly, if another group such as PMOL were undertaking a TCP = metric, it would be obvious that IPPM would be involved. This may well be simply a matter of philosophical leaning - but so that = I am clear - on what basis do you say, Al, that TCP performance is = unquestionably an IPPM matter? 2) There are at least two regimes of TCP performance that seem important = to consider: i) non-equilibrium behaviors such as during slow-start ii) steady-state behaviors Apart from the vagaries of different TCP implementations, does not the = work of Padhye et al and Mathis et al (such as listed below) offer the = basis for at least developing useful steady-state descriptions? =20 Matt Mathis himself has said he does not see it being viable developing = metrics along these lines. While I can imagine they are not 100% = accurate under all circumstances, they would at least seem like useful = extrapolations of IP-level characteristics. What then are the most = important shortcomings of these models? Refs: Modeling TCP Reno Performance: A Simple Model and its Empirical = Validation J. Padhye, V. Firoiu, D. Towsley and J. Kurose, IEEE/ACM Transactions on Networking, April 2000. [1] M. Mathis, J. Semske, J. Mahdavi and T. Ott, The Macroscopic = Behavior of the TCP Congestion Avoidance Algorithm, Computer = Communication Review, Vol 27, Number 3, July 1997 Al Morton writes: >Message: 6 >Date: Tue, 13 Oct 2009 11:56:15 -0400 >From: Al Morton >Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator = Networks >To: Henk Uijterwaal >Cc: ippm@ietf.org >Message-ID: <200910131556.n9DFuPQu029929@alpd052.aldc.att.com> >Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed > >At 09:26 AM 10/13/2009, Henk Uijterwaal wrote: >>Al, >> >>>At 06:17 AM 10/13/2009, Henk Uijterwaal wrote: >>>>...PMOL deals with higher layers, besides that (AFAIK) the PMOL >>>>WG is in some form of hybernation. >>>Expect to see more action in PMOL when the revised draft of the >>>framework and guidelines is published (new editor). >> >>I wasn't aware of this activity. That said, do you agree that this >>work belongs in IPPM rather than PMOL? >> >>Henk > >I think that TCP performance has always been in IPPM's charter. > >But like a few others, I have doubts that TCP-based throughput >measurements will produce useful results, starting with the >issue of what TCP version and other configuration options to use. >However, Matt Mathis' suggestion deserves attention. > >I should also add that Ethernet-layer throughput testing has >been proposed in ITU-T SG12 Q17, and contributions are expected on >this topic at the November meeting (this is scheduled at the >same time as IETF, so I won't be in Hiroshima in person). > >Al --- Loki Jorgenson Apparent Networks t 604 433 2333 ext 105 m 604 250-4642 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From RFardid@covad.com Tue Oct 13 12:13:55 2009 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 D115028C2A9 for ; Tue, 13 Oct 2009 12:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 O4jbJNr9yumC for ; Tue, 13 Oct 2009 12:13:54 -0700 (PDT) Received: from smtp.covad.com (smtp.covad.com [66.134.72.15]) by core3.amsl.com (Postfix) with ESMTP id CBD3A28C29C for ; Tue, 13 Oct 2009 12:13:54 -0700 (PDT) Received: from ZANEHT01b.cc-ntd1.covad.com (172.16.2.165) by smtp.covad.com (172.16.2.167) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Oct 2009 12:18:10 -0700 Received: from zanems01.cc-ntd1.covad.com ([fe80::b929:69ff:6f14:772d]) by ZANEHT01b.cc-ntd1.covad.com ([::1]) with mapi; Tue, 13 Oct 2009 12:15:17 -0700 From: "Fardid, Reza" To: 'Barry Constantine' , Henk Uijterwaal , "Ruediger.Geib@telekom.de" Date: Tue, 13 Oct 2009 12:15:17 -0700 Thread-Topic: [ippm] Testing TCP Throughput Capacity in Operator Networks Thread-Index: AcpL71s20lM2emtDR8SGFrynAoAfkgAEdmrwAA0AsgA= Message-ID: <4EF4BF1E8F43894386584BE36354494A2DB84286@ZANEMS01.cc-ntd1.covad.com> References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net><151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <6ECE57DF49376146B91A92A3C37EFC0E09BFE460@SJEXCH03.ds.jdsu.net> In-Reply-To: <6ECE57DF49376146B91A92A3C37EFC0E09BFE460@SJEXCH03.ds.jdsu.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 19:13:55 -0000 Barry, Other factors to consider are the effects of network path asymmetry on TCP = performance, which are of particular interest to Access Service Providers. = Some of the PILC (concluded WG) recommendations from RFC 3449 may be releva= nt to your proposal, regardless of which WG shepherds it. Regards, Reza Fardid Covad Communications -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Bar= ry Constantine Sent: Tuesday, October 13, 2009 7:42 AM To: Henk Uijterwaal; Ruediger.Geib@telekom.de Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks Henk and Ruediger, Thank for your comments and I would like to clarify a few points concerning the proposal for a draft related to TCP Throughput Capacity test methodology and metrics. When I first addressed the subject with Henk and Matt Zekauskas, I was pointed to RFC 3148, draft-ietf-ippm-treno-btc-03, and draft-ietf-ippm-btc-cap-00 as a starting point. By the way, I found these to be very interesting and useful papers. The TCP Throughput Capacity draft would reference these papers but would focus more at the network level metrics of TCP performance, not the specific behavior of various TCP mechanisms and implementations (i.e. CAC, False time-outs, Self-clocking, etc.). In other words, given a large complex network with various QoS and queuing techniques employed, the TCP throughput technique would allow a network provider to quantify the ability of the entire network to carry TCP traffic at specified SLA levels. Varying window sizes and MSS sizes is one component of this type of test. Another key component to this test is the throughput achieved with varying background traffic (perhaps UDP) and verifying proper prioritization between the TCP traffic and the background traffic. It is very difficult for a network provider to extrapolate TCP layer performance from packet loss studies and metrics. RFC-2544 is widely used today and makes it difficult (if not impossible) to adequately characterize how TCP will perform. Concerning the interest level based upon the responses, the sample size is small, but I have received 3-4 who are interested and 3-4 with little interest. Referencing Henk's final remarks; does this constitute enough interest from this working group to work on a draft? Thanks, Barry Principal Member of Technical Staff JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research One Milestone Center Court Germantown, MD 20876 (W) 240-404-2227 (C) 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Henk Uijterwaal Sent: Tuesday, October 13, 2009 6:18 AM To: Ruediger.Geib@telekom.de Cc: Barry Constantine; ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks Hi Ruediger, Personal opinion, not discussed with Matt or AD's yet > I'm not sure, whether IPPM is chartered to specify transport layer > performance metrics. I've checked the PMOL charter and it clearly says > PMOL works above transport layer. A fair conclusion would be, that IPPM > is chartered to investigate transport layer performance. I looked at it from a slightly different angle. Network capacity has always been a topic of interest for IPPM, so this work would be in our charter. PMOL deals with higher layers, besides that (AFAIK) the PMOL WG is in some form of hybernation. So, my take on this is that we should see if there is interest to work on this topic _and_ have a first version of a draft, we can decide later where exactly this works fits in the IETF. 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 ------------------------------------------------------------------------ ------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From lars.eggert@nokia.com Tue Oct 13 16:13:25 2009 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 924BA3A683A for ; Tue, 13 Oct 2009 16:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HtB68cEwz-GQ for ; Tue, 13 Oct 2009 16:13:24 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 272CB3A684E for ; Tue, 13 Oct 2009 16:13:23 -0700 (PDT) Received: from [10.71.2.216] (221x249x212x16.ap221.ftth.ucom.ne.jp [221.249.212.16]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9DNDECL044167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Oct 2009 02:13:16 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-59-142999005; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AD48F72.5030904@internet2.edu> Date: Wed, 14 Oct 2009 08:13:09 +0900 Message-Id: References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <4AD48F72.5030904@internet2.edu> To: Matthew J Zekauskas X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Wed, 14 Oct 2009 02:13:18 +0300 (EEST) Cc: "Barry.Constantine@jdsu.com" , "ippm@ietf.org" Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 23:13:25 -0000 --Apple-Mail-59-142999005 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-13, at 23:32, Matthew J Zekauskas wrote: > My thoughts are similar to Henk's. IPPM has always been interested in > the area (see the bulk transport capacity work), so I'd claim the area > is in-scope, but doing work would require AD discussion. I think it wouldn't be unreasonable for IPPM to take this on, if we more clearly nail down what "this" is. I can also follow the argument that it could go into PMOL - to me, it doesn't matter very much, although since we're talking TCP I believe there is a stronger affinity with the transport area, i.e., IPPM. > I think Matt Mathis' last message to the list is also worth thought; > it's hard to create a good metric. I agree that while the idea sounds simple, in reality it isn't. It already starts to get complicated when we try to say what we mean by "TCP" - pretty much all stacks implement a different set of TCP extensions, and even stacks that implement the same extension usually implement a different set of the SHOULDs and MAYs. Other stacks (e.g., Linux) even implement a congestion control scheme that is completely non-standard (Cubic). If the intent is to look at bulk throughput figures on otherwise idle paths with little to no loss, maybe those differences won't matter, but they will start to influence the result in more realistic scenarios. So while I can see why TCP throughout metrics would be interesting to have, I believe it'll take a bit of work to define them in a useful way. Lars --Apple-Mail-59-142999005 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAxMzIzMTMwOVowIwYJKoZIhvcNAQkEMRYEFADorNHn6vKwe83lE7cMuZOKu0TVMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC7kYRktaWdQDPpawOXUcNxCZVNUhEOQuq221xcQjl96O3QdT35Kq3X7mHCbcWykpqnHPZD CE7DmMWhYtIZZtY8FdtUE19zx5W6hUAbiETwt8DHQV+Ey3vHp2D87LBr18SDbt77tjD8QEVNiSN2 49D/BI7L5V2YH7jPvEaqx+W49N+k+HWLNZMP+pw9SbJDpw608TyQWgoruEzttpXmKQPfgRJJSFF6 PNRuarwzdqQxRx3VKWhYan6EjWJGVxuuMJY46ljear1U53B72/nQXh8rqd1kQl1iG7hz5Qh8h/l6 EqgbIN4FcbjLgJQhBStppqs/47FIG+9JcHNQWgWckbwvAAAAAAAA --Apple-Mail-59-142999005-- From Ruediger.Geib@telekom.de Wed Oct 14 00:11:35 2009 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 26F5F3A69DA for ; Wed, 14 Oct 2009 00:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, 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 QF3jfsgnWkfP for ; Wed, 14 Oct 2009 00:11:34 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 5A6323A6863 for ; Wed, 14 Oct 2009 00:11:32 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 14 Oct 2009 09:11:30 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:11:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 09:11:27 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5024D14AC@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Testing TCP Throughput Capacity in Operator Networks Thread-Index: AcpMGSDbWE98ubSBTQq19ASIhw0l1AAfwenQ References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> From: To: X-OriginalArrivalTime: 14 Oct 2009 07:11:29.0985 (UTC) FILETIME=[8D6DF310:01CA4C9D] Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 07:11:35 -0000 Hi Gilles, the company I work for is rather big and we differentiate between=20 branches providing products/services and those which provide transport.=20 I agree that one can't completely separate both (you probably are=20 aware that European regulation strongly favours a complete separation of transport and service). TCP performance is relevant for products. To my department that means,=20 if a product manager is interested, he may push standardisation of a=20 TCP throughput measurement system. Currently, I'm not aware of any=20 demand (but as I said, it's a big company). Different products and=20 services may have different typical TCP communication patterns (like=20 different RTTs). All different products are served across the same=20 backbone. I doubt that product specific backbone engineering makes=20 economical sense in a competitive environment. Different products may=20 however apply differentiated transport quality for their communication. The company I work for operates an IPPM compliant SLA validation=20 system for nearly 10 years. Several service/product validation systems=20 are operated in parallel. I can't recall that there ever has been a=20 discussion whether to disable a backbone SLA validation system because=20 there is a service validation system working in parallel. They serve=20 different purposes, even if they partially measure similar metrics=20 or along shared network sections. Regards, Ruediger Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 -----Original Message----- From: Gilles Forget [mailto:gilles.forget@sympatico.ca]=20 Sent: Tuesday, October 13, 2009 5:24 PM To: Geib, R=FCdiger Cc: ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks Bonjour Ruediger, If I may, I would like to comment on the feedback you received from within your company. Here in North America, over the last 30 years, we have seen the monopolistic carriers evolve to competitive Service Providers and even Application Service Providers.=20 There are still pure Carrier Transport SONET type equipments involved in their core network, but most of the business customer services are now delivered via an MPLS infrastructure using IP routers and multi-layer switches in the core, distribution and access layers of the network. There are also Professional Services groups and Network Security groups within the organizations involved in business services delivery for some major customers. I am pretty sure, that most European PT&Ts have done the same.=20 So I do not see why you still make differences between application or service providers and carriers! Thanks, Gilles Forget, CCNP. On Tue, 2009-10-13 at 11:47 +0200, Ruediger.Geib@telekom.de wrote: > Hello Barry, > =20 > I'm not sure, whether IPPM is chartered to specify transport layer > performance metrics. I've checked the PMOL charter and it clearly says > PMOL works above transport layer. A fair conclusion would be, that > IPPM is chartered to investigate transport layer performance. > =20 > Three questions to the chairs and to the IPPM WG come to my mind: > =20 > Chairs: Is IPPM chartered to execute the work proposed by Barry? > =20 > IPPM WG: If not, is there interest to charter IPPM for such an > activity? > =20 > Chairs: If not, to which WG can Barry submit his proposal? > =20 > My personal interest in this activity is limited, saying no support, > no objection. The feedback I received from within the company I work > for is, that such an activity is relevant for application or service > providers, but not for carriers.=20 > =20 > Regards, > =20 > Ruediger > =20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Technik Internet Backbone, TE142-19 > R=FCdiger Geib > Heinrich Hertz Str. 3-7 > 64297 Darmstadt > Tel.: 06151/6282747 > Fax: 0251/7985109 >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert > Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 >=20 >=20 >=20 >=20 >=20 > ______________________________________________________________________ > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf > Of Barry Constantine > Sent: Wednesday, October 07, 2009 12:06 AM > To: ippm@ietf.org > Subject: [ippm] Testing TCP Throughput Capacity in Operator Networks >=20 >=20 >=20 > Hello, >=20 > =20 >=20 > I work in the communications test industry and we have seen a growing > need to verify the capacity of a network in terms of end-end TCP > throughput. =20 >=20 > =20 >=20 > Most network operators use RFC-2544 based Layer 3 tests to verify the > SLA of the network, but this has significant shortcomings since it > does not verify the ability of the network to carry a customer's TCP > traffic. Ideally, a TCP layer throughput test would detect issues > with prioritization, queuing, policing, etc. This type of test could > also detect issues such as TCP Tail drop phenomena in the network. >=20 >=20 >=20 > I have spoken to several network operators and equipment providers and > there is a consistent desire to test throughput at the stateful TCP > layer, at line rate speeds (1G-10G), and to conduct these tests in a > standardized manner. >=20 > =20 >=20 > At a very high level, a standardized TCP layer throughput test would: >=20 > =20 >=20 > - Run a latency test and automatically compute the ideal TCP > window size for the test network >=20 > - Conduct a series of single and multiple connection TCP tests > and vary the window size to verify throughput per window size >=20 > - Conduct QoS testing, tagging the TCP connections with > appropriate prioritization (DSCP, etc.) and test in the midst of > background traffic loads >=20 > =20 >=20 > This is a very simplified description of the test workflow. >=20 > =20 >=20 > I would like to solicit the interest of members within the IPPM > workgroup and would like to move forward with a draft document to > describe this test in detail. >=20 > =20 >=20 > Thank you, >=20 > Barry >=20 > =20 >=20 > Principal Member of Technical Staff >=20 > =20 >=20 > JDSU Communication Test (formerly Acterna) >=20 > Emerging Markets and Technology Research =20 >=20 > One Milestone Center Court =20 >=20 > Germantown, MD 20876 =20 >=20 > (W) 240-404-2227 =20 >=20 > (C) 301-325-7069 >=20 > =20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --=20 Gilles Forget, CCNP T : 450.473.5718 C : 514.895.8212 @ : gilles.forget@sympatico.ca From Ruediger.Geib@telekom.de Wed Oct 14 00:29:05 2009 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 A1B523A67AC for ; Wed, 14 Oct 2009 00:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl8Y5ujLgtkO for ; Wed, 14 Oct 2009 00:29:04 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id EF3683A6859 for ; Wed, 14 Oct 2009 00:29:03 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 14 Oct 2009 09:29:02 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:29:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 09:29:01 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5024D1513@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] questions of TCP metrics Thread-Index: AcpMHcnwo6NbyziRQ7+s8PSgllQXVAACNuFgAB3ruNA= References: From: To: X-OriginalArrivalTime: 14 Oct 2009 07:29:01.0926 (UTC) FILETIME=[006F6860:01CA4CA0] Cc: ippm@ietf.org Subject: Re: [ippm] questions of TCP metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 07:29:05 -0000 Hi Loki, I like your statement, especially as you point out to Padhyes/Mathis et = al.'s work.=20 PMOL's charter states "Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks." That's why I thought, PMOL is chartered to deal with layers above TCP = only. Maybe=20 work on HTTP over TCP would fit to PMOL.=20 While I'm not interested in work on TCP, I also don't object to it. As = the IPPM charter isn't explicitely mentioning the layers which are in scope, I formulated = my questions=20 in a way, that Barry hopefully could find a WG, where his proposal fits = for the case=20 that IPPM isn't the right WG. I don't object however, if IPPM is the WG = to work on=20 the subject (as expressed by several work group members). Regards, Ruediger Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of = Loki Jorgenson Sent: Tuesday, October 13, 2009 7:38 PM To: ippm@ietf.org Subject: [ippm] questions of TCP metrics Please pardon my relative na=EFvet=E9 and probable ignorance of past = discussions on this topic - but there are two points that I am not clear = on: 1) "TCP performance has always been in IPPM's charter" - does this = statement derive entirely from historical precedence? =20 In light of the existence of PMOL (regardless of its current state of = quiescence), it would seem obvious that TCP is part of the "other = layers" scheme. Specifically, it would seem that TCP performs as = consequence of an application's implementation and therefore that TCP = performance would be non-specific to (although clearly a function of) = IP-level characteristics, just as MOS would related but non-specific in = the case of VoIP. The IPPM charter comes as close as referencing "bulk transport capacity" = but it is not trivial (for me) to conclude that a specific mechanism for = enabling bulk transport is necessarily within scope. Prior to PMOL, = IPPM would seem the likeliest group to have undertaken a TCP metric. = And, certainly, if another group such as PMOL were undertaking a TCP = metric, it would be obvious that IPPM would be involved. This may well be simply a matter of philosophical leaning - but so that = I am clear - on what basis do you say, Al, that TCP performance is = unquestionably an IPPM matter? 2) There are at least two regimes of TCP performance that seem important = to consider: i) non-equilibrium behaviors such as during slow-start ii) steady-state behaviors Apart from the vagaries of different TCP implementations, does not the = work of Padhye et al and Mathis et al (such as listed below) offer the = basis for at least developing useful steady-state descriptions? =20 Matt Mathis himself has said he does not see it being viable developing = metrics along these lines. While I can imagine they are not 100% = accurate under all circumstances, they would at least seem like useful = extrapolations of IP-level characteristics. What then are the most = important shortcomings of these models? Refs: Modeling TCP Reno Performance: A Simple Model and its Empirical = Validation J. Padhye, V. Firoiu, D. Towsley and J. Kurose, IEEE/ACM Transactions on Networking, April 2000. [1] M. Mathis, J. Semske, J. Mahdavi and T. Ott, The Macroscopic = Behavior of the TCP Congestion Avoidance Algorithm, Computer = Communication Review, Vol 27, Number 3, July 1997 Al Morton writes: >Message: 6 >Date: Tue, 13 Oct 2009 11:56:15 -0400 >From: Al Morton >Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator = Networks >To: Henk Uijterwaal >Cc: ippm@ietf.org >Message-ID: <200910131556.n9DFuPQu029929@alpd052.aldc.att.com> >Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed > >At 09:26 AM 10/13/2009, Henk Uijterwaal wrote: >>Al, >> >>>At 06:17 AM 10/13/2009, Henk Uijterwaal wrote: >>>>...PMOL deals with higher layers, besides that (AFAIK) the PMOL >>>>WG is in some form of hybernation. >>>Expect to see more action in PMOL when the revised draft of the >>>framework and guidelines is published (new editor). >> >>I wasn't aware of this activity. That said, do you agree that this >>work belongs in IPPM rather than PMOL? >> >>Henk > >I think that TCP performance has always been in IPPM's charter. > >But like a few others, I have doubts that TCP-based throughput >measurements will produce useful results, starting with the >issue of what TCP version and other configuration options to use. >However, Matt Mathis' suggestion deserves attention. > >I should also add that Ethernet-layer throughput testing has >been proposed in ITU-T SG12 Q17, and contributions are expected on >this topic at the November meeting (this is scheduled at the >same time as IETF, so I won't be in Hiroshima in person). > >Al --- Loki Jorgenson Apparent Networks t 604 433 2333 ext 105 m 604 250-4642 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From henk@ripe.net Wed Oct 14 04:20:08 2009 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 944D03A6945 for ; Wed, 14 Oct 2009 04:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=-3.783, 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 V9+0ZHGtc2Ag for ; Wed, 14 Oct 2009 04:20:07 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 878173A67C2 for ; Wed, 14 Oct 2009 04:20:06 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1My1td-0002xM-0D; Wed, 14 Oct 2009 13:20:02 +0200 Received: from geir-3.local (henk.vpn.ripe.net [193.0.21.33]) by herring.ripe.net (Postfix) with ESMTP id ED97C2F593; Wed, 14 Oct 2009 13:19:56 +0200 (CEST) Message-ID: <4AD5B3DC.4000307@ripe.net> Date: Wed, 14 Oct 2009 13:19:56 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Lars Eggert References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <4AD48F72.5030904@internet2.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d505c9d9d16b53c7b8e5363adad50d31b6 Cc: "Barry.Constantine@jdsu.com" , Matthew J Zekauskas , "ippm@ietf.org" Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:20:08 -0000 Lars Eggert wrote: > Hi, > > On 2009-10-13, at 23:32, Matthew J Zekauskas wrote: >> My thoughts are similar to Henk's. IPPM has always been interested in >> the area (see the bulk transport capacity work), so I'd claim the area >> is in-scope, but doing work would require AD discussion. > > I think it wouldn't be unreasonable for IPPM to take this on, if we more > clearly nail down what "this" is. In order to move forward: I suggest that Barry writes a -00 draft (including a definition of "this") before Hiroshima. 3-4 people showing interest should be sufficient to review it. In Hiroshima, we can discuss the draft further, afterwards we can decide on the mailing list and with the AD to pick it up as a WG item or not. Barry, can you produce something before Hiroshima? 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 ------------------------------------------------------------------------------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. From ljorgenson@apparentnetworks.com Wed Oct 14 12:15:10 2009 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 96FEC28C200 for ; Wed, 14 Oct 2009 12:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 5fCOwFDnt8o4 for ; Wed, 14 Oct 2009 12:15:09 -0700 (PDT) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id 8FA2B28C1FA for ; Wed, 14 Oct 2009 12:15:09 -0700 (PDT) X-AuditID: ac108108-00000de8000007a0-4c-4ad6233d0bea Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Oct 2009 12:15:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 12:15:11 -0700 Message-ID: In-Reply-To: <151C164FE2E066418D8D44D0801543A5024D1513@S4DE8PSAAQA.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] questions of TCP metrics Thread-Index: AcpMHcnwo6NbyziRQ7+s8PSgllQXVAACNuFgAB3ruNAAGITbkA== References: <151C164FE2E066418D8D44D0801543A5024D1513@S4DE8PSAAQA.mitte.t-com.de> From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Cc: ippm@ietf.org Subject: Re: [ippm] questions of TCP metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 19:15:10 -0000 Ruediger - thanks for your response. It probably does then come down to philosophical leanings (and historical precedence). For myself, PMOL's hiatus notwithstanding, I still see TCP as an additional layer on top of IP packets behavior - access to network resources is being actively gated at the end-hosts (not part of IP mid-path implementation), potentially in accordance with application parameterization. And especially in light of there being different stacks. That said, I have no objection to IPPM pursuing a TCP metric development though I still consider PMOL the better fit. I have some interest in participating depending on some clarification of what "this" is. Loki Jorgenson Apparent Networks t 604 433 2333 ext 105 m 604 250-4642 -----Original Message----- From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Sent: Wednesday, October 14, 2009 00:29 To: Loki Jorgenson Cc: ippm@ietf.org Subject: RE: [ippm] questions of TCP metrics Hi Loki, I like your statement, especially as you point out to Padhyes/Mathis et al.'s work.=20 PMOL's charter states "Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks." That's why I thought, PMOL is chartered to deal with layers above TCP only. Maybe=20 work on HTTP over TCP would fit to PMOL.=20 While I'm not interested in work on TCP, I also don't object to it. As the IPPM charter isn't explicitely mentioning the layers which are in scope, I formulated my questions=20 in a way, that Barry hopefully could find a WG, where his proposal fits for the case=20 that IPPM isn't the right WG. I don't object however, if IPPM is the WG to work on=20 the subject (as expressed by several work group members). From acmorton@att.com Wed Oct 14 18:54:53 2009 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 4D54E3A6807 for ; Wed, 14 Oct 2009 18:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndw0XNwFyBIa for ; Wed, 14 Oct 2009 18:54:52 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 8D8D83A67AB for ; Wed, 14 Oct 2009 18:54:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-161.messagelabs.com!1255571693!3893045!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 23192 invoked from network); 15 Oct 2009 01:54:54 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-11.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Oct 2009 01:54:54 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n9F1srnw003410 for ; Wed, 14 Oct 2009 20:54:53 -0500 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n9F1snio003347 for ; Wed, 14 Oct 2009 20:54:49 -0500 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id n9F1snKC015822 for ; Wed, 14 Oct 2009 20:54:49 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id n9F1sixH015809 for ; Wed, 14 Oct 2009 20:54:45 -0500 Message-Id: <200910150154.n9F1sixH015809@klpd017.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-122-5.vpn.swst.att.com[135.70.122.5](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20091015015443gw1006v7ude>; Thu, 15 Oct 2009 01:54:44 +0000 X-Originating-IP: [135.70.122.5] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Oct 2009 21:54:42 -0400 To: "Loki Jorgenson" , From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] questions of TCP metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 01:54:53 -0000 At 01:37 PM 10/13/2009, Loki Jorgenson wrote: >The IPPM charter comes as close as referencing "bulk transport >capacity" but it is not trivial (for me) to conclude that a specific >mechanism for enabling bulk transport is necessarily within >scope. Prior to PMOL, IPPM would seem the likeliest group to have >undertaken a TCP metric. And, certainly, if another group such as >PMOL were undertaking a TCP metric, it would be obvious that IPPM >would be involved. > >This may well be simply a matter of philosophical leaning - but so >that I am clear - on what basis do you say, Al, that TCP performance >is unquestionably an IPPM matter? I think the previous work on bulk transfer capacity framework seals the deal: http://www.ietf.org/rfc/rfc3148.txt Al From matt.mathis@gmail.com Thu Oct 15 11:52:12 2009 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 4B91A3A68ED for ; Thu, 15 Oct 2009 11:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IvLBlV8-kc6 for ; Thu, 15 Oct 2009 11:52:11 -0700 (PDT) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by core3.amsl.com (Postfix) with ESMTP id BBC363A659A for ; Thu, 15 Oct 2009 11:52:10 -0700 (PDT) Received: by fxm6 with SMTP id 6so1463758fxm.43 for ; Thu, 15 Oct 2009 11:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MQMzbkLrKD5fnOsnNcRQgEZUtjVoX+bttyYsGIG1Faw=; b=aF8S2Rga2fYAFIX+h2vUg87S9tjZCNTlAF8hcwyi5lrtL27y0zkBR63jaaOKIErM96 74Rl9UaDy017D2fAXLV1wq9j0Hg/XPCpXJhFrEgG1HcC9wtet8yZnwjeoRjBLXDCt5zU YxNxElwpYlmWdbMItrjTTqABS1ReLFNO//QYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Kw2AzixP3WxxAt/CZ3g/QDOXrpvzVe4/qzs25Vrs6BolzAKWkgV0SYafHFx+B5Idm/ /e5Ggd98pb6hYUlUjB8arxxmiaFD0jCrY8KSzrwkuClufIiYHbrX4c49ZeGNjG08I/KA e1YCrIvbh6sdPT/HqkGBA3x8YgxW0h9OIyAMo= MIME-Version: 1.0 Received: by 10.204.2.205 with SMTP id 13mr317928bkk.205.1255632727724; Thu, 15 Oct 2009 11:52:07 -0700 (PDT) In-Reply-To: <4AD5B3DC.4000307@ripe.net> References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <4AD48F72.5030904@internet2.edu> <4AD5B3DC.4000307@ripe.net> Date: Thu, 15 Oct 2009 14:52:07 -0400 Message-ID: From: Matt Mathis To: Henk Uijterwaal Content-Type: text/plain; charset=ISO-8859-1 Cc: "Barry.Constantine@jdsu.com" , Matthew J Zekauskas , "ippm@ietf.org" Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 18:52:12 -0000 >>> My thoughts are similar to Henk's. IPPM has always been interested in >>> the area (see the bulk transport capacity work), so I'd claim the area >>> is in-scope, but doing work would require AD discussion. >> >> I think it wouldn't be unreasonable for IPPM to take this on, if we more >> clearly nail down what "this" is. You might want to consider finishing the work started in RFCs 2330 and 3148 as a sufficient definition of "this". Developing a Bulk Transport Metric has been sort of a holy grail of IPPM from the very beginning. It was my primary agenda when I co-chaired the BOF at the Danvers IETF, April 1995). After publishing a tool [TReno] and making some important progress [RFC2330, RFC3148, and Marl Alman's[CAP] the effort was abandoned essentially because the results were not sufficiently robust to be useful to support SLAs. [NPAD] was my latest chapter of my efforts in this area. Although there are many difficulties with using TCP (notably differences in implementations as noted in other messages) the real killer is this: TCP congestion control is an equilibrium process. Correctly functioning TCP with sufficient data ALWAYS causes congestion somewhere in the network. This congestion manifests itself by raising the RTT and/or the packet loss until the data rate is consistent with the the model[MODEL]: date_rate=(MSS/RTT)*(0.7/squrt(loss_probability)) The problem is you can't tell how much of the congestion was caused by your measurement, and how much was already present in the network. This causes sort of a double Heisenberg problem where you can't even tell if you are measuring bowling balls with pingpong balls or vice versa. This is because the "stiffness" of a TCP flow (think "first derivative of the model") depends on the RTT, so when there are multiple flows sharing a bottleneck, each flow yields a different amount, depending on their relative RTTs. If the measurement flow has a very short RTT, it will push nearly all other traffic out of the bottleneck, if the cross traffic has a short RTT, it will greatly depress the data rate of the measured folw. As a consequence a simple measurement with a single TCP flow is useless for predicting performance of another flow through the same bottleneck. Note that a non-predictive measurement is useless to the point where it can't really be called a metric. THIS IS REALLY IMPORTANT: even with an ideal TCP implementation and network, equilibrium TCP performance is useless as a metric. The trick (used by NPAD) is the throttle TCP with a controlled bottleneck, such that it does not cause congestion.... This can be done using an RFC 4898 instrumented stack under real applications. I will describe it in email in a bit, and a presentation at IPPM, if people are interested. No I do not have enough cycles to generate an ID in time for the submission deadline. Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. From matt.mathis@gmail.com Thu Oct 15 12:46:19 2009 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 439573A6969 for ; Thu, 15 Oct 2009 12:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 v2h5C2fuP505 for ; Thu, 15 Oct 2009 12:46:18 -0700 (PDT) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by core3.amsl.com (Postfix) with ESMTP id B80DD3A6927 for ; Thu, 15 Oct 2009 12:46:17 -0700 (PDT) Received: by fxm6 with SMTP id 6so1525722fxm.43 for ; Thu, 15 Oct 2009 12:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OOwMeo1Zp8rJG1KSkZ/jCIw6th1rDck/9qnjNhewaO0=; b=h3fHmN6ilhAoPVJORNN8suZEX2emOAIkqpQo0/NHOqs3Yw0x1hyWYOm/R024lJwCSi 6cYRqKXpLgOgku+Zkzjjt9Mc6LaWvdGy8oRj7mp2+Sx8wkX5CEIIm4QMV16w3tOxgQNT 2niOWCH4g2x/0AAwhFue3i9fWSKmQwG8XjLw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wHKmSDw0QvE6KhfrG1QPnendaXgs5fCY3GqZ9JK57GXiHiTnxDD85CVVAglVoqzbP2 /64JMJ2PL7jHitO1hMSj+1j2BSFC0Na2DeIJAQ40b3VDsIhLDpXJZl7RIDLcnDapzAfq ruU6lh7Kf/OMsnTUPVckwL+nLDQWiOkakbdPk= MIME-Version: 1.0 Received: by 10.204.3.220 with SMTP id 28mr413047bko.4.1255635977702; Thu, 15 Oct 2009 12:46:17 -0700 (PDT) In-Reply-To: References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <4AD48F72.5030904@internet2.edu> <4AD5B3DC.4000307@ripe.net> Date: Thu, 15 Oct 2009 15:46:17 -0400 Message-ID: From: Matt Mathis To: Henk Uijterwaal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Barry.Constantine@jdsu.com" , Matthew J Zekauskas , "ippm@ietf.org" Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 19:46:19 -0000 Opps I forgot to paste in the references: [NPAD] M. Mathis, J. Heffner, P. O'Neil, P. Siemsen, "Pathdiag: Automated TCP Diagnosis", PAM 2008. See also: http://www.psc.edu/networking/projects/pathdiag/ [CAP] M. Allman "Measuring End-to-End Bulk Transport Capacity" ACM SIGCOMM Internet Measurement Workshop 2001. [RFC3148] M. Mathis, M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC3148, July 2001. [RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for IP Performance Metrics", RFC2330, May 1998. [MODEL] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Agorithm", Computer ommunication Review, volume 27, number 3, July 1997. [TReno] M. Mathis, "Diagnosing Internet Congestion with a Transport Layer Performance Tool", Proceedings of INET'96, June, 1996, Montreal, Quebec. Thanks, --MM-- On Thu, Oct 15, 2009 at 2:52 PM, Matt Mathis wrote: >>>> My thoughts are similar to Henk's. =A0IPPM has always been interested = in >>>> the area (see the bulk transport capacity work), so I'd claim the area >>>> is in-scope, but doing work would require AD discussion. >>> >>> I think it wouldn't be unreasonable for IPPM to take this on, if we mor= e >>> clearly nail down what "this" is. > > You might want to consider finishing the work started in RFCs 2330 and > 3148 as a sufficient definition of "this". > > Developing a Bulk Transport Metric has been sort of a holy grail of > IPPM from the very beginning. =A0 =A0It was my primary agenda when I > co-chaired the BOF at the Danvers IETF, April 1995). =A0 =A0After > publishing a tool [TReno] and making some important progress [RFC2330, > RFC3148, and Marl Alman's[CAP] the effort was abandoned essentially > because the results were not sufficiently robust to be useful to > support SLAs. =A0[NPAD] was my latest chapter of my efforts in this > area. > > Although there are many difficulties with using TCP (notably > differences in implementations as noted in other messages) the real > killer is this: > > TCP congestion control is an equilibrium process. =A0Correctly > functioning TCP with sufficient data ALWAYS causes congestion > somewhere in the network. =A0This congestion manifests itself by raising > the RTT and/or the packet loss until the data rate is consistent with > the the model[MODEL]: > date_rate=3D(MSS/RTT)*(0.7/squrt(loss_probability)) =A0 The problem is yo= u > can't tell how much of the congestion was caused by your measurement, > and how much was already present in the network. =A0 This causes sort of > a double Heisenberg problem where you can't even tell if you are > measuring bowling balls with pingpong balls or vice versa. =A0This is > because the "stiffness" of a TCP flow (think "first derivative of the > model") depends on the RTT, so when there are multiple flows sharing a > bottleneck, each flow yields a different amount, depending on their > relative RTTs. =A0 If the measurement flow has a very short RTT, it will > push nearly all other traffic out of the bottleneck, if the cross > traffic has a short RTT, it will greatly depress the data rate of the > measured folw. =A0As a consequence a simple measurement with a single > TCP flow is useless for predicting performance of another flow through > the same bottleneck. =A0 Note that a non-predictive measurement is > useless to the point where it can't really be called a metric. > > THIS IS REALLY IMPORTANT: even with an ideal TCP implementation and > network, equilibrium TCP performance is useless as a metric. > > The trick (used by NPAD) is the throttle TCP with a controlled > bottleneck, such that it does not cause congestion.... > > This can be done using an RFC 4898 instrumented stack under real > applications. =A0 I will describe it in email in a bit, and a > presentation at IPPM, if people are interested. =A0 =A0No I do not have > enough cycles to generate an ID in time for the submission deadline. > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis =A0 =A0 =A0http://staff.psc.edu/mathis > Work:412.268.3319 =A0 Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know > "The Truth" and use force to apply it to others. > From Barry.Constantine@jdsu.com Thu Oct 15 14:50:30 2009 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 244E83A681F for ; Thu, 15 Oct 2009 14:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4+7Ncbtyb3a for ; Thu, 15 Oct 2009 14:50:29 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with SMTP id 406723A67FA for ; Thu, 15 Oct 2009 14:50:24 -0700 (PDT) Received: from source ([209.36.247.245]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSteZI31+3vg4TWJSe7iHYbz6OLZ5xWra@postini.com; Thu, 15 Oct 2009 14:50:32 PDT Received: from SJEXCH03.ds.jdsu.net ([10.75.0.214]) by Outbound2.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 14:46:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 14:45:57 -0700 Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09CED726@SJEXCH03.ds.jdsu.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Testing TCP Throughput Capacity in Operator Networks Thread-Index: AcpNyJn7NDpSaYg0SBCjVRvCoYEiDQADvSng References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <4AD48F72.5030904@internet2.edu> <4AD5B3DC.4000307@ripe.net> From: "Barry Constantine" To: "Matt Mathis" , "Henk Uijterwaal" X-OriginalArrivalTime: 15 Oct 2009 21:46:56.0160 (UTC) FILETIME=[03E1F200:01CA4DE1] Cc: Matthew J Zekauskas , ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 21:50:30 -0000 Hi Matt, I understand your concerns with relation to TCP and you undoubtedly have vast experience in detailed TCP implementations and studies. I have read several of your papers and they are all excellent. Let me try to clearly lay out the problem statement and then determine if it is worthy of a -00 draft. I tried to keep this email concise, sorry if it is a little long-winded. In my work with network providers and network equipment manufacturers (NEMs), there is a growing realization that RFC-2544 packet level testing on today's networks is not adequate. This community desires to measure network throughput performance at the TCP layer, to gain a much more meaningful measure that the network can meet the end user's application SLA (and ultimately reach some level of TCP testing interoperability which does not exist today). The complexity of the network grows and the various queuing mechanisms in the network greatly affect TCP layer performance (i.e. improper default router settings for queuing, etc.) and devices such as firewalls, proxies, load-balancers can actively alter the TCP settings as a TCP session traverses the network (such as window size, MSS, etc.). These are all very complex topics to the general network community, and I can't overemphasize the desire for a standard test methodology/guideline at the TCP layer. So the intent behind this draft TCP Throughput work would be to define a methodology for testing TCP layer performance, and guidelines for expected TCP throughput results that *should* be experienced in the network under test. Network providers and NEMs are wrestling with end-end complexities of the above (queuing, active proxy devices, etc.); they desire to standardize the methodology to validate end-end TCP performance, as this is the precursor to acceptable end-user application performance. Before RFC-2544 testing existed, network providers and NEMs deployed a variety of ad hoc test techniques to verify the Layer2/3 performance of the network. RFC-2544 was a huge step forward in the network test world, standardizing the Layer 2/3 test methodology which greatly improved the quality of the network (and reduced operational test expenses). In the case of TCP, several network providers that I work with employ the following TCP testing methodology (high level simplified example): 1. Run tests to determine average end-end latency and end-end bottleneck bandwidth (the minimum bandwidth may be known by design). 2. Calculate bandwidth delay product (BDP) for this situation then run a series of window size experiments with TCP hosts on each end of the network. The network under test should be able to support the full TCP capacity unless there are packet loss conditions. This may point to devices in the network that are altering the window size IF retransmissions are not the issue and throughput is not achieved. 3. Run multiple connection tests (i.e. 32 connections) to over-utilize the link. Proper queuing techniques in the network should allow the TCP connections to maintain their "fair share" of the available bandwidth. Improper queuing (which is very common) would display bandwidth volatility between the connections. This is very valuable method as well. 4. Another example is by either running single or multiple TCP connections with a variety of MSS values (similar to varying the frame size in RFC-2544). Right now there is no established methodology for any of the above tests in the network provider / NEM space. So even taking a first step toward standardizing the test methodology at the TCP layer, would be a giant step forward. As a matter of fact, this paper would probably be co-authored with myself and at least one network provider and/or NEM. So again, sorry for the long winded response, but I hope that this provides better insight into the intent of such a draft.=20 Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: Matt Mathis [mailto:matt.mathis@gmail.com]=20 Sent: Thursday, October 15, 2009 2:52 PM To: Henk Uijterwaal Cc: Lars Eggert; Barry Constantine; Matthew J Zekauskas; ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks >>> My thoughts are similar to Henk's. IPPM has always been interested in >>> the area (see the bulk transport capacity work), so I'd claim the area >>> is in-scope, but doing work would require AD discussion. >> >> I think it wouldn't be unreasonable for IPPM to take this on, if we more >> clearly nail down what "this" is. You might want to consider finishing the work started in RFCs 2330 and 3148 as a sufficient definition of "this". Developing a Bulk Transport Metric has been sort of a holy grail of IPPM from the very beginning. It was my primary agenda when I co-chaired the BOF at the Danvers IETF, April 1995). After publishing a tool [TReno] and making some important progress [RFC2330, RFC3148, and Marl Alman's[CAP] the effort was abandoned essentially because the results were not sufficiently robust to be useful to support SLAs. [NPAD] was my latest chapter of my efforts in this area. Although there are many difficulties with using TCP (notably differences in implementations as noted in other messages) the real killer is this: TCP congestion control is an equilibrium process. Correctly functioning TCP with sufficient data ALWAYS causes congestion somewhere in the network. This congestion manifests itself by raising the RTT and/or the packet loss until the data rate is consistent with the the model[MODEL]: date_rate=3D(MSS/RTT)*(0.7/squrt(loss_probability)) The problem is you can't tell how much of the congestion was caused by your measurement, and how much was already present in the network. This causes sort of a double Heisenberg problem where you can't even tell if you are measuring bowling balls with pingpong balls or vice versa. This is because the "stiffness" of a TCP flow (think "first derivative of the model") depends on the RTT, so when there are multiple flows sharing a bottleneck, each flow yields a different amount, depending on their relative RTTs. If the measurement flow has a very short RTT, it will push nearly all other traffic out of the bottleneck, if the cross traffic has a short RTT, it will greatly depress the data rate of the measured folw. As a consequence a simple measurement with a single TCP flow is useless for predicting performance of another flow through the same bottleneck. Note that a non-predictive measurement is useless to the point where it can't really be called a metric. THIS IS REALLY IMPORTANT: even with an ideal TCP implementation and network, equilibrium TCP performance is useless as a metric. The trick (used by NPAD) is the throttle TCP with a controlled bottleneck, such that it does not cause congestion.... This can be done using an RFC 4898 instrumented stack under real applications. I will describe it in email in a bit, and a presentation at IPPM, if people are interested. No I do not have enough cycles to generate an ID in time for the submission deadline. Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. From matt.mathis@gmail.com Thu Oct 15 15:38:02 2009 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 1204B3A67FA for ; Thu, 15 Oct 2009 15:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 YnQOxU1h5cl8 for ; Thu, 15 Oct 2009 15:38:00 -0700 (PDT) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by core3.amsl.com (Postfix) with ESMTP id E3D5C28C181 for ; Thu, 15 Oct 2009 15:37:59 -0700 (PDT) Received: by fxm6 with SMTP id 6so1721791fxm.43 for ; Thu, 15 Oct 2009 15:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Lrh3Fa+HjDAlLBM6HzpxThBZVnVB28iJ8BQAZSwvz4Q=; b=fdQUGrs+syxP/72Al+8RonPz/2FJAa15y5x96Dr4huwxBH98/BygiGR7v1TLoBOnRL gwFyhFeHM6kK5L4NVBmYCYRQcLsFcezBcpnnjnkOyICbkNMt1EO8PCt9Hp3tLstVjurl 0I5jt1NCNI7XoNZAwl7v0CN+1LxnxOwLSLvbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SKknJSL+CoIKUYghICnok3DCjKPIh39ZCmQPWdkK9xocsRGdy6ZiI2987UkpsZ6Re8 KfmzoZgbJs+RB//G1632MgvbNFrsq170DPLXPEtBsyQY2DJmDRiWNtCZ9a77rH2srgJi 0OQjSG+lY+/q8yAN7EDOc5zig/qCZIIvn71Mc= MIME-Version: 1.0 Received: by 10.204.48.212 with SMTP id s20mr539771bkf.101.1255646282936; Thu, 15 Oct 2009 15:38:02 -0700 (PDT) In-Reply-To: <6ECE57DF49376146B91A92A3C37EFC0E09CED726@SJEXCH03.ds.jdsu.net> References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <4AD48F72.5030904@internet2.edu> <4AD5B3DC.4000307@ripe.net> <6ECE57DF49376146B91A92A3C37EFC0E09CED726@SJEXCH03.ds.jdsu.net> Date: Thu, 15 Oct 2009 18:38:02 -0400 Message-ID: From: Matt Mathis To: Barry Constantine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Henk Uijterwaal , Matthew J Zekauskas , ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 22:38:02 -0000 Your procedure makes perfect sense for bench testing gear in a laboratory, where you have complete control over all of the traffic. NPAD's algorithm is essentially the same as your steps 1&2. (It uses LimCwnd in the web100 prototype of 4898 to scan window sizes with one TCP connection). I suspect that NPAD's queue measurement algorithm captures most of the effects detected in your step 3, although not all of them (For example NPAD would not capture effects due to loss synchronization between flows). IPPM has traditionally been focused on in situ testing of Internet infrastructure, which also includes the effects of uncontrolled cross traffic. Please excuse me it this changed while I wasn't looking. BMWG was focused on Bench Testing, as the name implies. While it is true that many metrics might be the same both both arenas, this is not at all true for BTC. I completely agree that a good BTC bench test is needed. Your proposal is a very good first step in this direction. However, the world also desperately needs a way to write TCP performance SLAs, which was my whole reason for starting IPPM some 14 years ago. (Do people remember that it was called IP Provider Metrics at one time?) We knew we didn't have a clue how to do BTC, so we started with easy metrics like availability, loss and reordering. Remember, at that time we started, the basic TCP performance model would not be published for another couple of years. I think it is time to attempt to do a BTC for in situ Internet infrastructure, which is designed to support BTC SLAs. (BTW the algorithm I have in mind is not suitable for bench testing, so there is no overlap.) Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Thu, Oct 15, 2009 at 5:45 PM, Barry Constantine wrote: > Hi Matt, > > I understand your concerns with relation to TCP and you undoubtedly have > vast experience in detailed TCP implementations and studies. =A0I have > read several of your papers and they are all excellent. > > Let me try to clearly lay out the problem statement and then determine > if it is worthy of a -00 draft. =A0I tried to keep this email concise, > sorry if it is a little long-winded. > > In my work with network providers and network equipment manufacturers > (NEMs), there is a growing realization that RFC-2544 packet level > testing on today's networks is not adequate. =A0This community desires to > measure network throughput performance at the TCP layer, to gain a much > more meaningful measure that the network can meet the end user's > application SLA (and ultimately reach some level of TCP testing > interoperability which does not exist today). =A0The complexity of the > network grows and the various queuing mechanisms in the network greatly > affect TCP layer performance (i.e. improper default router settings for > queuing, etc.) and devices such as firewalls, proxies, load-balancers > can actively alter the TCP settings as a TCP session traverses the > network (such as window size, MSS, etc.). =A0These are all very complex > topics to the general network community, and I can't overemphasize the > desire for a standard test methodology/guideline at the TCP layer. > > So the intent behind this draft TCP Throughput work would be to define a > methodology for testing TCP layer performance, and guidelines for > expected TCP throughput results that *should* be experienced in the > network under test. =A0Network providers and NEMs are wrestling with > end-end complexities of the above (queuing, active proxy devices, etc.); > they desire to standardize the methodology to validate end-end TCP > performance, as this is the precursor to acceptable end-user application > performance. > > Before RFC-2544 testing existed, network providers and NEMs deployed a > variety of ad hoc test techniques to verify the Layer2/3 performance of > the network. =A0RFC-2544 was a huge step forward in the network test > world, standardizing the Layer 2/3 test methodology which greatly > improved the quality of the network (and reduced operational test > expenses). > > In the case of TCP, several network providers that I work with employ > the following TCP testing methodology (high level simplified example): > > 1. Run tests to determine average end-end latency and end-end bottleneck > bandwidth (the minimum bandwidth may be known by design). > 2. Calculate bandwidth delay product (BDP) for this situation then run a > series of window size experiments with TCP hosts on each end of the > network. =A0The network under test should be able to support the full TCP > capacity unless there are packet loss conditions. =A0This may point to > devices in the network that are altering the window size IF > retransmissions are not the issue and throughput is not achieved. > 3. Run multiple connection tests (i.e. 32 connections) to over-utilize > the link. =A0Proper queuing techniques in the network should allow the TC= P > connections to maintain their "fair share" of the available bandwidth. > Improper queuing (which is very common) would display bandwidth > volatility between the connections. =A0This is very valuable method as > well. > 4. Another example is by either running single or multiple TCP > connections with a variety of MSS values (similar to varying the frame > size in RFC-2544). > > Right now there is no established methodology for any of the above tests > in the network provider / NEM space. =A0So even taking a first step towar= d > standardizing the test methodology at the TCP layer, would be a giant > step forward. =A0As a matter of fact, this paper would probably be > co-authored with myself and at least one network provider and/or NEM. > > So again, sorry for the long winded response, but I hope that this > provides better insight into the intent of such a draft. > > Thanks, > Barry > > > > Principal Member of Technical Staff > > > > JDSU Communication Test (formerly Acterna) > > Emerging Markets and Technology Research > > One Milestone Center Court > > Germantown, MD 20876 > > (W) 240-404-2227 > > (C) 301-325-7069 > > > -----Original Message----- > From: Matt Mathis [mailto:matt.mathis@gmail.com] > Sent: Thursday, October 15, 2009 2:52 PM > To: Henk Uijterwaal > Cc: Lars Eggert; Barry Constantine; Matthew J Zekauskas; ippm@ietf.org > Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks > >>>> My thoughts are similar to Henk's. =A0IPPM has always been interested > in >>>> the area (see the bulk transport capacity work), so I'd claim the > area >>>> is in-scope, but doing work would require AD discussion. >>> >>> I think it wouldn't be unreasonable for IPPM to take this on, if we > more >>> clearly nail down what "this" is. > > You might want to consider finishing the work started in RFCs 2330 and > 3148 as a sufficient definition of "this". > > Developing a Bulk Transport Metric has been sort of a holy grail of > IPPM from the very beginning. =A0 =A0It was my primary agenda when I > co-chaired the BOF at the Danvers IETF, April 1995). =A0 =A0After > publishing a tool [TReno] and making some important progress [RFC2330, > RFC3148, and Marl Alman's[CAP] the effort was abandoned essentially > because the results were not sufficiently robust to be useful to > support SLAs. =A0[NPAD] was my latest chapter of my efforts in this > area. > > Although there are many difficulties with using TCP (notably > differences in implementations as noted in other messages) the real > killer is this: > > TCP congestion control is an equilibrium process. =A0Correctly > functioning TCP with sufficient data ALWAYS causes congestion > somewhere in the network. =A0This congestion manifests itself by raising > the RTT and/or the packet loss until the data rate is consistent with > the the model[MODEL]: > date_rate=3D(MSS/RTT)*(0.7/squrt(loss_probability)) =A0 The problem is yo= u > can't tell how much of the congestion was caused by your measurement, > and how much was already present in the network. =A0 This causes sort of > a double Heisenberg problem where you can't even tell if you are > measuring bowling balls with pingpong balls or vice versa. =A0This is > because the "stiffness" of a TCP flow (think "first derivative of the > model") depends on the RTT, so when there are multiple flows sharing a > bottleneck, each flow yields a different amount, depending on their > relative RTTs. =A0 If the measurement flow has a very short RTT, it will > push nearly all other traffic out of the bottleneck, if the cross > traffic has a short RTT, it will greatly depress the data rate of the > measured folw. =A0As a consequence a simple measurement with a single > TCP flow is useless for predicting performance of another flow through > the same bottleneck. =A0 Note that a non-predictive measurement is > useless to the point where it can't really be called a metric. > > THIS IS REALLY IMPORTANT: even with an ideal TCP implementation and > network, equilibrium TCP performance is useless as a metric. > > The trick (used by NPAD) is the throttle TCP with a controlled > bottleneck, such that it does not cause congestion.... > > This can be done using an RFC 4898 instrumented stack under real > applications. =A0 I will describe it in email in a bit, and a > presentation at IPPM, if people are interested. =A0 =A0No I do not have > enough cycles to generate an ID in time for the submission deadline. > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis =A0 =A0 =A0http://staff.psc.edu/mathis > Work:412.268.3319 =A0 Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know > "The Truth" and use force to apply it to others. > From Barry.Constantine@jdsu.com Thu Oct 15 16:28:02 2009 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 0BF653A6407 for ; Thu, 15 Oct 2009 16:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZItHPr4xzbKZ for ; Thu, 15 Oct 2009 16:28:00 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id 309713A68C9 for ; Thu, 15 Oct 2009 16:27:52 -0700 (PDT) Received: from source ([209.36.247.245]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKStev+9gNcktmi2zIQmccHBHqleKO/myy@postini.com; Thu, 15 Oct 2009 16:28:04 PDT Received: from SJEXCH03.ds.jdsu.net ([10.75.0.214]) by Outbound2.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 16:26:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 16:26:53 -0700 Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09CED7CF@SJEXCH03.ds.jdsu.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Testing TCP Throughput Capacity in Operator Networks Thread-Index: AcpN6CoOjtfpOArqQCWXp4wEMA8WywAAPScA References: <6ECE57DF49376146B91A92A3C37EFC0E09B5F7E9@SJEXCH03.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A5024D0D85@S4DE8PSAAQA.mitte.t-com.de> <4AD453D3.7030602@ripe.net> <4AD48F72.5030904@internet2.edu> <4AD5B3DC.4000307@ripe.net> <6ECE57DF49376146B91A92A3C37EFC0E09CED726@SJEXCH03.ds.jdsu.net> From: "Barry Constantine" To: "Matt Mathis" X-OriginalArrivalTime: 15 Oct 2009 23:26:56.0084 (UTC) FILETIME=[FC1DB140:01CA4DEE] Cc: Henk Uijterwaal , Matthew J Zekauskas , ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 23:28:02 -0000 Hi Matt,=20 Thanks for the quick reply and comments. For business class networks, it is somewhat of a hybrid. The networks = are privately managed so they are not exactly "bench" networks, but = certainly not the Internet. The business class networks are staged, = then provisioned (pre-prod), then new services are "turned-up" for = business customers on managed production network. There is a mix of = business traffic on these virtual private networks, but prioritization = (DSCP, VLANs, MPLS, etc) is supposed to be correct (you can imagine what = that means) to ensure new customer TCP traffic flows as expected. This = prioritization + TCP testing is another entire test method step that I = did not mention in the outline but would be covered in the draft. As a matter of fact, RFC-2544 was originally written for bench testing = devices and became (and still is) the defacto standard in these = privately managed networks. =20 These managed networks are intended to be predictable, but therein lies = the problem. Even in a staged provider network, errors in device = configuration can go undetected with RFC-2544 testing and can later show = up in production networks.=20 So I can understand why TCP testing methodology in a non-controlled, = non-managed network (internet) is inappropriate, but I hope this = explanation concerning managed, private networks helps to clarify the = intent. =20 Thanks again, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: Matt Mathis [mailto:matt.mathis@gmail.com]=20 Sent: Thursday, October 15, 2009 6:38 PM To: Barry Constantine Cc: Henk Uijterwaal; Lars Eggert; Matthew J Zekauskas; ippm@ietf.org Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator Networks Your procedure makes perfect sense for bench testing gear in a laboratory, where you have complete control over all of the traffic. NPAD's algorithm is essentially the same as your steps 1&2. (It uses LimCwnd in the web100 prototype of 4898 to scan window sizes with one TCP connection). I suspect that NPAD's queue measurement algorithm captures most of the effects detected in your step 3, although not all of them (For example NPAD would not capture effects due to loss synchronization between flows). IPPM has traditionally been focused on in situ testing of Internet infrastructure, which also includes the effects of uncontrolled cross traffic. Please excuse me it this changed while I wasn't looking. BMWG was focused on Bench Testing, as the name implies. While it is true that many metrics might be the same both both arenas, this is not at all true for BTC. I completely agree that a good BTC bench test is needed. Your proposal is a very good first step in this direction. However, the world also desperately needs a way to write TCP performance SLAs, which was my whole reason for starting IPPM some 14 years ago. (Do people remember that it was called IP Provider Metrics at one time?) We knew we didn't have a clue how to do BTC, so we started with easy metrics like availability, loss and reordering. Remember, at that time we started, the basic TCP performance model would not be published for another couple of years. I think it is time to attempt to do a BTC for in situ Internet infrastructure, which is designed to support BTC SLAs. (BTW the algorithm I have in mind is not suitable for bench testing, so there is no overlap.) Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Thu, Oct 15, 2009 at 5:45 PM, Barry Constantine wrote: > Hi Matt, > > I understand your concerns with relation to TCP and you undoubtedly = have > vast experience in detailed TCP implementations and studies. =A0I have > read several of your papers and they are all excellent. > > Let me try to clearly lay out the problem statement and then determine > if it is worthy of a -00 draft. =A0I tried to keep this email concise, > sorry if it is a little long-winded. > > In my work with network providers and network equipment manufacturers > (NEMs), there is a growing realization that RFC-2544 packet level > testing on today's networks is not adequate. =A0This community desires = to > measure network throughput performance at the TCP layer, to gain a = much > more meaningful measure that the network can meet the end user's > application SLA (and ultimately reach some level of TCP testing > interoperability which does not exist today). =A0The complexity of the > network grows and the various queuing mechanisms in the network = greatly > affect TCP layer performance (i.e. improper default router settings = for > queuing, etc.) and devices such as firewalls, proxies, load-balancers > can actively alter the TCP settings as a TCP session traverses the > network (such as window size, MSS, etc.). =A0These are all very = complex > topics to the general network community, and I can't overemphasize the > desire for a standard test methodology/guideline at the TCP layer. > > So the intent behind this draft TCP Throughput work would be to define = a > methodology for testing TCP layer performance, and guidelines for > expected TCP throughput results that *should* be experienced in the > network under test. =A0Network providers and NEMs are wrestling with > end-end complexities of the above (queuing, active proxy devices, = etc.); > they desire to standardize the methodology to validate end-end TCP > performance, as this is the precursor to acceptable end-user = application > performance. > > Before RFC-2544 testing existed, network providers and NEMs deployed a > variety of ad hoc test techniques to verify the Layer2/3 performance = of > the network. =A0RFC-2544 was a huge step forward in the network test > world, standardizing the Layer 2/3 test methodology which greatly > improved the quality of the network (and reduced operational test > expenses). > > In the case of TCP, several network providers that I work with employ > the following TCP testing methodology (high level simplified example): > > 1. Run tests to determine average end-end latency and end-end = bottleneck > bandwidth (the minimum bandwidth may be known by design). > 2. Calculate bandwidth delay product (BDP) for this situation then run = a > series of window size experiments with TCP hosts on each end of the > network. =A0The network under test should be able to support the full = TCP > capacity unless there are packet loss conditions. =A0This may point to > devices in the network that are altering the window size IF > retransmissions are not the issue and throughput is not achieved. > 3. Run multiple connection tests (i.e. 32 connections) to over-utilize > the link. =A0Proper queuing techniques in the network should allow the = TCP > connections to maintain their "fair share" of the available bandwidth. > Improper queuing (which is very common) would display bandwidth > volatility between the connections. =A0This is very valuable method as > well. > 4. Another example is by either running single or multiple TCP > connections with a variety of MSS values (similar to varying the frame > size in RFC-2544). > > Right now there is no established methodology for any of the above = tests > in the network provider / NEM space. =A0So even taking a first step = toward > standardizing the test methodology at the TCP layer, would be a giant > step forward. =A0As a matter of fact, this paper would probably be > co-authored with myself and at least one network provider and/or NEM. > > So again, sorry for the long winded response, but I hope that this > provides better insight into the intent of such a draft. > > Thanks, > Barry > > > > Principal Member of Technical Staff > > > > JDSU Communication Test (formerly Acterna) > > Emerging Markets and Technology Research > > One Milestone Center Court > > Germantown, MD 20876 > > (W) 240-404-2227 > > (C) 301-325-7069 > > > -----Original Message----- > From: Matt Mathis [mailto:matt.mathis@gmail.com] > Sent: Thursday, October 15, 2009 2:52 PM > To: Henk Uijterwaal > Cc: Lars Eggert; Barry Constantine; Matthew J Zekauskas; ippm@ietf.org > Subject: Re: [ippm] Testing TCP Throughput Capacity in Operator = Networks > >>>> My thoughts are similar to Henk's. =A0IPPM has always been = interested > in >>>> the area (see the bulk transport capacity work), so I'd claim the > area >>>> is in-scope, but doing work would require AD discussion. >>> >>> I think it wouldn't be unreasonable for IPPM to take this on, if we > more >>> clearly nail down what "this" is. > > You might want to consider finishing the work started in RFCs 2330 and > 3148 as a sufficient definition of "this". > > Developing a Bulk Transport Metric has been sort of a holy grail of > IPPM from the very beginning. =A0 =A0It was my primary agenda when I > co-chaired the BOF at the Danvers IETF, April 1995). =A0 =A0After > publishing a tool [TReno] and making some important progress [RFC2330, > RFC3148, and Marl Alman's[CAP] the effort was abandoned essentially > because the results were not sufficiently robust to be useful to > support SLAs. =A0[NPAD] was my latest chapter of my efforts in this > area. > > Although there are many difficulties with using TCP (notably > differences in implementations as noted in other messages) the real > killer is this: > > TCP congestion control is an equilibrium process. =A0Correctly > functioning TCP with sufficient data ALWAYS causes congestion > somewhere in the network. =A0This congestion manifests itself by = raising > the RTT and/or the packet loss until the data rate is consistent with > the the model[MODEL]: > date_rate=3D(MSS/RTT)*(0.7/squrt(loss_probability)) =A0 The problem is = you > can't tell how much of the congestion was caused by your measurement, > and how much was already present in the network. =A0 This causes sort = of > a double Heisenberg problem where you can't even tell if you are > measuring bowling balls with pingpong balls or vice versa. =A0This is > because the "stiffness" of a TCP flow (think "first derivative of the > model") depends on the RTT, so when there are multiple flows sharing a > bottleneck, each flow yields a different amount, depending on their > relative RTTs. =A0 If the measurement flow has a very short RTT, it = will > push nearly all other traffic out of the bottleneck, if the cross > traffic has a short RTT, it will greatly depress the data rate of the > measured folw. =A0As a consequence a simple measurement with a single > TCP flow is useless for predicting performance of another flow through > the same bottleneck. =A0 Note that a non-predictive measurement is > useless to the point where it can't really be called a metric. > > THIS IS REALLY IMPORTANT: even with an ideal TCP implementation and > network, equilibrium TCP performance is useless as a metric. > > The trick (used by NPAD) is the throttle TCP with a controlled > bottleneck, such that it does not cause congestion.... > > This can be done using an RFC 4898 instrumented stack under real > applications. =A0 I will describe it in email in a bit, and a > presentation at IPPM, if people are interested. =A0 =A0No I do not = have > enough cycles to generate an ID in time for the submission deadline. > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis =A0 =A0 =A0http://staff.psc.edu/mathis > Work:412.268.3319 =A0 Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know > "The Truth" and use force to apply it to others. > From root@core3.amsl.com Mon Oct 19 14:15:03 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E871C3A680C; Mon, 19 Oct 2009 14:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019211502.E871C3A680C@core3.amsl.com> Date: Mon, 19 Oct 2009 14:15:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-spatial-composition-10.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, 19 Oct 2009 21:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Spatial Composition of Metrics Author(s) : A. Morton, E. Stephan Filename : draft-ietf-ippm-spatial-composition-10.txt Pages : 27 Date : 2009-10-19 This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-spatial-composition-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-spatial-composition-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19140310.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 19 20:45:01 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8CF053A681D; Mon, 19 Oct 2009 20:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091020034501.8CF053A681D@core3.amsl.com> Date: Mon, 19 Oct 2009 20:45:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-reporting-metrics-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 03:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Reporting Metrics: Different Points of View Author(s) : A. Morton, et al. Filename : draft-ietf-ippm-reporting-metrics-00.txt Pages : 17 Date : 2009-10-19 Consumers of IP network performance metrics have many different uses in mind. This memo categorizes the different audience points of view. It describes how the categories affect the selection of metric parameters and options when seeking info that serves their needs. The memo then proceeds to discuss "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-metrics-00.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-metrics-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19204346.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 23 12:30:02 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6C78B3A6878; Fri, 23 Oct 2009 12:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023193001.6C78B3A6878@core3.amsl.com> Date: Fri, 23 Oct 2009 12:30:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-reflect-octets-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 19:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : TWAMP Reflect Octets and Symmetrical Size Features Author(s) : A. Morton, L. Ciavattone Filename : draft-ietf-ippm-twamp-reflect-octets-03.txt Pages : 19 Date : 2009-10-23 The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes two closely-related features for TWAMP: an optional capability where the responder host returns some of the command octets or padding octets to the controller, a new sender packet format that ensures equal test packet sizes are used in both directions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-reflect-octets-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-twamp-reflect-octets-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23122041.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 23 12:30:02 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AAEF13A6891; Fri, 23 Oct 2009 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023193002.AAEF13A6891@core3.amsl.com> Date: Fri, 23 Oct 2009 12:30:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-session-cntrl-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: Fri, 23 Oct 2009 19:30:02 -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 : Individual Session Control Feature for TWAMP Author(s) : A. Morton, M. Chiba Filename : draft-ietf-ippm-twamp-session-cntrl-02.txt Pages : 18 Date : 2009-10-23 The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions previously requested and accepted to start and stop at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-session-cntrl-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-twamp-session-cntrl-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23122101.I-D@ietf.org> --NextPart-- From rfc-editor@rfc-editor.org Fri Oct 23 16:22:09 2009 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 6FC6C3A67DA; Fri, 23 Oct 2009 16:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.942 X-Spam-Level: X-Spam-Status: No, score=-16.942 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 x7+RmYelxgBF; Fri, 23 Oct 2009 16:22:08 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id BD5A13A68C4; Fri, 23 Oct 2009 16:22:08 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 860CF3513E2; Fri, 23 Oct 2009 16:19:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091023231936.860CF3513E2@bosco.isi.edu> Date: Fri, 23 Oct 2009 16:19:36 -0700 (PDT) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 5644 on IP Performance Metrics (IPPM): Spatial and Multicast 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, 23 Oct 2009 23:22:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5644 Title: IP Performance Metrics (IPPM): Spatial and Multicast Author: E. Stephan, L. Liang, A. Morton Status: Standards Track Date: October 2009 Mailbox: emile.stephan@orange-ftgroup.com, L.Liang@surrey.ac.uk, acmorton@att.com Pages: 57 Characters: 110407 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-multimetrics-12.txt URL: http://www.rfc-editor.org/rfc/rfc5644.txt The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS TRACK] This document is a product of the IP Performance Metrics Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From henk@ripe.net Mon Oct 26 04:01:07 2009 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 F40843A68FB for ; Mon, 26 Oct 2009 04:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.079 X-Spam-Level: X-Spam-Status: No, score=-4.079 tagged_above=-999 required=5 tests=[AWL=-1.480, 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 pkWx+DI9SViA for ; Mon, 26 Oct 2009 04:01:05 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 91A3B3A684E for ; Mon, 26 Oct 2009 04:01:05 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N2NJz-000567-NY; Mon, 26 Oct 2009 12:01:13 +0100 Received: from geir-3.local (henk.vpn.ripe.net [193.0.21.33]) by herring.ripe.net (Postfix) with ESMTP id AA5012F583; Mon, 26 Oct 2009 12:01:07 +0100 (CET) Message-ID: <4AE58173.20502@ripe.net> Date: Mon, 26 Oct 2009 12:01:07 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: IETF IPPM WG , TSV ADs , TSV ADs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d59bdba8c038767c0e1d7c5582760e7930 Subject: [ippm] Draft Agenda for IPPM @ IETF76. 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, 26 Oct 2009 11:01:07 -0000 IPPM group, Here is the first draft agenda for our meeting at IETF76. Comments are welcome... Henk - - - - Agenda IPPM WG @ IETF76. ======================== Tuesday, 10/Nov, 13:00-15:00 1. Administrativia (Chairs, 5') 2. Status of drafts and milestones (Chairs, 10') 3. Reporting drafts. a. draft-ietf-ippm-reporting-04.txt Status of this draft (chairs, 5') b. http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-00 The new WG item. (Al Morton, 15') 4. Metrics composition drafts. (Al Morton, 10') 5. TWAMP features (10') a. draft-ietf-ippm-twamp-reflect-octets-03 (Morton, Ciavattone) b. draft-ietf-ippm-twamp-session-cntrl-02 (Morton, Chiba) 6. Advancing Metrics along the standards path (20') (Ruediger Geib et al, please tell me who will present). 7. TCP Throughput Testing (Barry Constantine, 20') http://www.ietf.org/id/draft-constantine-ippm-tcp-throughput-tm-00.txt 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 ------------------------------------------------------------------------------ Nobody ever went broke underestimating the taste of the American public. H.L.Mencken From Ruediger.Geib@telekom.de Mon Oct 26 05:01:51 2009 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 9658628C26A for ; Mon, 26 Oct 2009 05:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la39cvcjB0Ir for ; Mon, 26 Oct 2009 05:01:50 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id C3EF928C259 for ; Mon, 26 Oct 2009 05:01:45 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 26 Oct 2009 13:01:52 +0100 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:01:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 13:01:51 +0100 Message-ID: <151C164FE2E066418D8D44D0801543A50266758D@S4DE8PSAAQA.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Metric validation: new version of draft-geib-ippm-metrictest-01 thread-index: AcpWMpxdfpnQ8R1aQmq8v2uQpMqQfQAAByYQ From: To: X-OriginalArrivalTime: 26 Oct 2009 12:01:52.0515 (UTC) FILETIME=[1B060D30:01CA5634] Subject: [ippm] Metric validation: new version of draft-geib-ippm-metrictest-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: Mon, 26 Oct 2009 12:01:51 -0000 Dear all, the reviewed draft -01 is available under http://www.ietf.org/id/draft-geib-ippm-metrictest-01.txt First inputs of Al Morton's draft has been added. More may come,=20 to this regard the document isn't complete. What it is offering now is a metric implementation procedure: - compliance test single implementation against specification - statistical compliance test for precision of a single implementation=20 - statistical compliance test for precision of multiple implementations - Statistical test success criterion: document 95% confidence interval of the smallest precision, where this test was passed. No quantified minimum precision is required to be standards compliant. Regards, Ruediger -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Monday, October 26, 2009 12:50 PM To: Geib, R=FCdiger Cc: acmorton@att.com; RFardid@covad.com Subject: New Version Notification for draft-geib-ippm-metrictest-01=20 A new version of I-D, draft-geib-ippm-metrictest-01.txt has been = successfuly submitted by Ruediger Geib and posted to the IETF = repository. Filename: draft-geib-ippm-metrictest Revision: 01 Title: IPPM standard compliance testing Creation_date: 2009-10-26 WG ID: Independent Submission Number_of_pages: 19 Abstract: This document specifies tests to determine if multiple, independent, and interoperable implementations of a metrics specification document are at hand so that the metrics specification can be advanced to an Internet standard. Results of different IPPM implementations can be compared if they measure under the same underlying network conditions. Results are compared using state of the art statistical methods. = =20 The IETF Secretariat. -------- Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 From Barry.Constantine@jdsu.com Mon Oct 26 14:13:14 2009 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 275FF28C27F for ; Mon, 26 Oct 2009 14:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAN1dzO8g0YZ for ; Mon, 26 Oct 2009 14:13:12 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id D006528C17C for ; Mon, 26 Oct 2009 14:12:59 -0700 (PDT) Received: from source ([209.36.247.245]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSuYQ6XgQNqK4HOFjd1TChDtZNt3hQSie@postini.com; Mon, 26 Oct 2009 14:13:23 PDT Received: from SJEXCH03.ds.jdsu.net ([10.75.0.214]) by Outbound2.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 14:12:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 14:12:11 -0700 Message-ID: <6ECE57DF49376146B91A92A3C37EFC0E09E065C7@SJEXCH03.ds.jdsu.net> In-Reply-To: <4AE58173.20502@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Draft Agenda for IPPM @ IETF76. Thread-Index: AcpWK/BEx4W8pu8DQ32Iv4ZIExBdgwAVNidw References: <4AE58173.20502@ripe.net> From: "Barry Constantine" To: "Henk Uijterwaal" , "IETF IPPM WG" , "TSV ADs" , "TSV ADs" X-OriginalArrivalTime: 26 Oct 2009 21:12:12.0680 (UTC) FILETIME=[FC936080:01CA5680] Subject: Re: [ippm] Draft Agenda for IPPM @ IETF76. 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, 26 Oct 2009 21:13:14 -0000 Hi Henk, I seem to recall that there may be Webex / conferencing for this event, but could not seem to find the information on the IETF site. Will there be Webex / conferencing? Thanks, Barry =20 Principal Member of Technical Staff =20 JDSU Communication Test (formerly Acterna) Emerging Markets and Technology Research =20 One Milestone Center Court =20 Germantown, MD 20876 =20 (W) 240-404-2227 =20 (C) 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Henk Uijterwaal Sent: Monday, October 26, 2009 7:01 AM To: IETF IPPM WG; TSV ADs; TSV ADs Subject: [ippm] Draft Agenda for IPPM @ IETF76. IPPM group, Here is the first draft agenda for our meeting at IETF76. Comments are welcome... Henk - - - - Agenda IPPM WG @ IETF76. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tuesday, 10/Nov, 13:00-15:00 1. Administrativia (Chairs, 5') 2. Status of drafts and milestones (Chairs, 10') 3. Reporting drafts. a. draft-ietf-ippm-reporting-04.txt Status of this draft (chairs, 5') b. http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-00 The new WG item. (Al Morton, 15') 4. Metrics composition drafts. (Al Morton, 10') 5. TWAMP features (10') a. draft-ietf-ippm-twamp-reflect-octets-03 (Morton, Ciavattone) b. draft-ietf-ippm-twamp-session-cntrl-02 (Morton, Chiba) 6. Advancing Metrics along the standards path (20') (Ruediger Geib et al, please tell me who will present). 7. TCP Throughput Testing (Barry Constantine, 20') =20 http://www.ietf.org/id/draft-constantine-ippm-tcp-throughput-tm-00.txt 8. AOB --=20 ------------------------------------------------------------------------ ------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------ ------ Nobody ever went broke underestimating the taste of the American public. =20 H.L.Mencken _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Maha.Abdallah@lip6.fr Tue Oct 27 06:30:52 2009 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 BA64428C208 for ; Tue, 27 Oct 2009 06:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=0.35] 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 lIw4wn+Z8zIl for ; Tue, 27 Oct 2009 06:30:52 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by core3.amsl.com (Postfix) with ESMTP id 1797928C205 for ; Tue, 27 Oct 2009 06:30:51 -0700 (PDT) Received: from poleia.lip6.fr (mailtwo.desir.lip6.fr [132.227.205.24]) by isis.lip6.fr (8.14.3/lip6) with ESMTP id n9RDV3xQ022336 for ; Tue, 27 Oct 2009 14:31:03 +0100 (CET) X-pt: isis.lip6.fr Received: by poleia.lip6.fr (Postfix, from userid 33) id B02F441FE41; Tue, 27 Oct 2009 14:31:03 +0100 (CET) Received: from 85.169.79.128 (SquirrelMail authenticated user abdallah) by mailtwo.lip6.fr with HTTP; Tue, 27 Oct 2009 14:31:03 +0100 Message-ID: <4fc07576170fec620765780e7f6d2c8a.squirrel@mailtwo.lip6.fr> Date: Tue, 27 Oct 2009 14:31:03 +0100 From: "Maha Abdallah" To: ippm@ietf.org User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (isis.lip6.fr [132.227.60.2]); Tue, 27 Oct 2009 14:31:03 +0100 (CET) X-Scanned-By: MIMEDefang 2.63 on 132.227.60.2 Subject: [ippm] NetGames 2009 - Call for Participation (Nov. 23-24 - Paris, France) 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, 27 Oct 2009 13:30:52 -0000 CALL FOR PARTICIPATION ************************************************************************** * NetGames 2009 * * The 8th Annual Workshop on Network and Systems Support for Games * * November 23-24, 2009 * * Paris , France * * * * In co-operation with ACM SIGCOMM and ACM SIGMM * * Technically sponsored by IEEE Communications Society * * * * Early registration deadline: Nov 8, 2009 * * http://netgames2009.lip6.fr/ * ************************************************************************** We would like to cordially invite you to attend the 8th Annual Workshop on Network and Systems Support for Games (NetGames 2009), which will be held on November 23-24, 2009 in Paris, France. KEYNOTE SPEAKERS ================ Two exciting keynote talks will be given by distinguished speakers with tremendous experience in networked games and virtual environments: 1. Dr. Michael Macedonia (Vice President and General Manager, Forterra Federal Systems) Title: Next Generation Virtual Worlds 2. Dr. Rémi Arnaud (Chief Software Architect, Screampoint International) Title: Trends in 3D technologies and the impact on networked games OVERVIEW ======== The NetGames workshop is a major annual international workshop that brings together researchers and visionaries from academia, research labs, and industry to present new research in understanding networked games of today and in enabling the next generation of them. NetGames has become a recognized venue for Promoting exciting discussions among its participants in all areas related to online games and Virtual environments. Two keynotes addresses, and a total of 18 research papers, posters and demos spanning various topics related to networked games will be presented and discussed. We cordially invite you to attend the workshop and share with us your feedback, thoughts, and experience. Further details can be found at: http://netgames2009.lip6.fr/ ACCEPTED PAPERS =============== A. Full papers: ------------ Measurement and Analysis of World of Warcraft in Mobile WiMAX Networks Xiaofei Wang (Seoul national university, KR) Hyun-chul Kim (Seoul National University, KR) Taekyoung Kwon (Seoul National University, KR) Yanghee Choi (Seoul National University, KR) Sunghyun Choi (Seoul National University, KR) Jang Hanyoung (XRONet Corporation, KR) 802.11 Wireless LAN Multiplayer Game Capacity and Optimization Hanghang Qi (Hamilton Institute, NUIM, IE) David Malone (NUI Maynooth, IE) Dimitri D Botvich (Waterford Institute of Technology, IE) Hack, Slash, and Chat: A study of players’ behavior and communication in MMORPGs Mirko Sužnjevic (University of Zagreb, HR) Ognjen Dobrijevic (University of Zagreb, HR) Maja Matijasevic (University of Zagreb, HR) Peer NAT Proxies for Peer-to-Peer Applications Daryl Seah (National University of Singapore, SG) Wai Kay Leong (National University of Singapore, SG) Qingwei Yang (National University of Singapore, SG) Ben Leong (National University of Singapore, SG) Razeen Ali (National University of Singapore, SG) Distributed Avatar Management for Second Life Matteo Varvello (Eurecom - Thomson, FR) Stefano Ferrari (Politecnico di torino, IT) Ernst W Biersack (EURECOM, FR) Christophe Diot (Thomson, FR) PlayerRating: A Reputation System for Multiplayer Online Games Ed Kaiser (Portland State University, US) Wu-chang Feng (Portland State University, US) Avatar movement in World of Warcraft Battlegrounds John L. Miller (Microsoft Research, Cambridge, UK) Jon Crowcroft (University of Cambridge, UK) The Impact of Virtualization on the Performance of Massively Multiplayer Online Games Vlad Nae (University of Innsbruck, AT) Alexandru Iosup (Delft University of Technology, NL) Radu Prodan (University of Innsbruck, AT) Thomas Fahringer (University of Innsbruck, AT) Evaluating Ginnungagap: a middleware for migration of partial game-state utilizing core-selection for latency reduction Paul B Beskow (Simula Research Laboratory, NO) Geir Erikstad (Simula Research Laboratory/University of Oslo, NO) Pål Halvorsen (Simula Research Laboratory, NO) Carsten Griwodz (Simula Research Laboratory, NO) Bandwidth-Aware Peer-to-Peer 3D Streaming Chien-Hao Chien (National Central University, TW) Shun-Yun Hu (National Central University, TW) Jehn-Ruey Jiang (National Central University, TW) B. Posters & Demos: ---------------- FizzX: Multiplayer Time Manipulation in Networked Games Colin Towle (University of Ottawa, CA) Pascal Proulx (University of Ottawa, CA) Saurabh Ratti (University of Ottawa, CA) Shervin Shirmohammadi (University of Ottawa, CA) Transparency Analysis and Haptic Synchronization for Transparency of Force-reflecting Teleoperation Seokhee Lee (Gwangju Institute of Science and Technology, KR) Yutaka Ishibashi (Nagoya Institute of Technology, JP) JongWon Kim (GIST (Gwangju Institute of Science & Technology), KR) AOI cast by Tolerance Based Compass Routing in Distributed Virtual Environments Michele Albano (University of Pisa, IT) Luca Genovali (IMT, IT) Antonio Quartulli (University of Trento, IT) Laura Ricci (University of Pisa, IT) Peer-to-Peer Support for Low-Latency Massively Multiplayer Online Games in the Cloud Richard Süselbeck (University of Mannheim, DE) Gregor A Schiele (University of Mannheim, DE) Christian Becker (Universität Mannheim, DE) Player-Customized Puzzle Instance Generation for Massively Multiplayer Online Games Alexandru Iosup (Delft University of Technology, NL) On Prophesying Online Gamer Departure Pin-Yun Tarng (National Taiwan University, TW) Kuan-Ta Chen (Academia Sinica, TW) Polly Huang (National Taiwan University, TW) Capturing and Storing Profile Information for Gamers Playing Multiplayer Online Games Tomas Hildebrandt (TU Darmstadt, DE) Sonja Bergsträßer (Technical University of Darmstadt, DE) Christoph Rensing (Technical University of Darmstadt, DE) Ralf Steinmetz (Technische Universitaet Darmstadt, DE) Interconnection of Game Worlds and Physical Environments in Educational Settings Raphael Zender (University of Rostock, DE) Ulrike Lucke (University of Rostock, DE) Dennis Maciuszek (University of Rostock, DE) Alke Martens (University of Rostock, DE)