From henk@ripe.net Mon Mar 1 01:14:12 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0783A8B2A for ; Mon, 1 Mar 2010 01:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 wASXcFy6gXA4 for ; Mon, 1 Mar 2010 01:14:10 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id A04673A8B2D for ; Mon, 1 Mar 2010 01:14:10 -0800 (PST) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Nm1hU-0002yA-8v for ippm@ietf.org; Mon, 01 Mar 2010 10:14:09 +0100 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-109.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Nm1hU-0001Hm-4t for ippm@ietf.org; Mon, 01 Mar 2010 10:14:04 +0100 Message-ID: <4B8B855C.3080605@ripe.net> Date: Mon, 01 Mar 2010 10:14:04 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100216 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d532fd112e05077198b15c49a7ea52cbe1 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d532fd112e05077198b15c49a7ea52cbe1 Subject: [ippm] Meeting at IETF77 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, 01 Mar 2010 09:14:12 -0000 IPPM group, We will meet at the Anaheim IETF, Tuesday afternoon @ 17:40. If you have any agenda topics, please drop us a mail, Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Nobody ever went broke underestimating the taste of the American public. H.L.Mencken From wwwrun@core3.amsl.com Mon Mar 1 06:38:48 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8836928C379; Mon, 1 Mar 2010 06:38:48 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100301143848.8836928C379@core3.amsl.com> Date: Mon, 1 Mar 2010 06:38:48 -0800 (PST) Cc: ippm@ietf.org Subject: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 14:38:48 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Individual Session Control Feature for TWAMP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-session-cntrl-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17883&rfc_flag=0 From Barry.Constantine@jdsu.com Mon Mar 1 07:00:28 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7E028C3B2 for ; Mon, 1 Mar 2010 07:00:28 -0800 (PST) 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 hw+JGFECaycR for ; Mon, 1 Mar 2010 07:00:27 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id 27C4128C132 for ; Mon, 1 Mar 2010 07:00:25 -0800 (PST) Received: from source ([209.36.247.244]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS4vWiQcZuf0y2cIZ7mrgRqZKvPfjkjLd@postini.com; Mon, 01 Mar 2010 07:00:27 PST Received: from milexhtca1.ds.jdsu.net ([10.75.2.121]) by Outbound1.jdsu.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 06:51:33 -0800 Received: from MILEXCH1.ds.jdsu.net ([fe80::6444:f010:6d40:bdb]) by milexhtca1.ds.jdsu.net ([::1]) with mapi; Mon, 1 Mar 2010 06:51:33 -0800 From: Barry Constantine To: Henk Uijterwaal , IETF IPPM WG Date: Mon, 1 Mar 2010 06:51:31 -0800 Thread-Topic: [ippm] Meeting at IETF77 Thread-Index: Acq5H5FEwu/xgidvSnSPoFFxRKuUSgALdL/g Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE3856933F1E@MILEXCH1.ds.jdsu.net> References: <4B8B855C.3080605@ripe.net> In-Reply-To: <4B8B855C.3080605@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2010 14:51:33.0945 (UTC) FILETIME=[AFAD7A90:01CAB94E] Subject: Re: [ippm] Meeting at IETF77 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, 01 Mar 2010 15:00:28 -0000 Hello Henk and Matt, A team of IPPM members have worked significantly on the TCP draft work that= I first presented as draft-00 in November. We would like to present the draft-constantine-ippm-tcp-throughput-tm-01 at= IETF77. 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 Hen= k Uijterwaal Sent: Monday, March 01, 2010 4:14 AM To: IETF IPPM WG Subject: [ippm] Meeting at IETF77 IPPM group, We will meet at the Anaheim IETF, Tuesday afternoon @ 17:40. If you have any agenda topics, please drop us a mail, Matt & Henk --=20 ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.ne= t RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------= --- Nobody ever went broke underestimating the taste of the American public. H.L.Menck= en _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From root@core3.amsl.com Fri Mar 5 15:15:10 2010 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8A3553A8710; Fri, 5 Mar 2010 15:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100305231506.8A3553A8710@core3.amsl.com> Date: Fri, 5 Mar 2010 15:15:01 -0800 (PST) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-reporting-metrics-01.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, 05 Mar 2010 23:15:10 -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-01.txt Pages : 21 Date : 2010-03-05 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-01.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-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-05150635.I-D@ietf.org> --NextPart-- From henk@ripe.net Tue Mar 9 04:17:20 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318CC3A692D for ; Tue, 9 Mar 2010 04:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 fFmc9XAIF56Z for ; Tue, 9 Mar 2010 04:17:14 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id A5C633A68AA for ; Tue, 9 Mar 2010 04:17:13 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NoyN4-0005SH-B5 for ippm@ietf.org; Tue, 09 Mar 2010 13:17:16 +0100 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=geir.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NoyN4-0000aQ-4h for ippm@ietf.org; Tue, 09 Mar 2010 13:17:10 +0100 Message-ID: <4B963C46.7080907@ripe.net> Date: Tue, 09 Mar 2010 13:17:10 +0100 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d58e72e54b5404140e0e3f3d54196b0620 X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d58e72e54b5404140e0e3f3d54196b0620 Subject: [ippm] 1st draft agenda for Anaheim 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, 09 Mar 2010 12:17:20 -0000 IPPM group, The first draft agenda for Anaheim is: 0. Administrativia (Minutes, Scribe, Blue Sheet, Note Well, ...) 1. Status of drafts not discussed today a. draft-ietf-ippm-twamp-reflect-octets-04 b. draft-ietf-ippm-twamp-session-cntrl-04 c. draft-ietf-ippm-reporting-04.txt d. draft-ietf-ippm-framework-compagg-09 e. draft-ietf-ippm-spatial-composition-10 2. draft-geib-ippm-metrictest-02 (Al, Ruediger) 3. draft-constantine-ippm-tcp-throughput-tm (Barry) 4. draft-ietf-ippm-reporting-metrics-01 (Al) 5. draft-duffield-ippm-burst-loss-metrics-02 (Nick) 6. AOB See also: http://www.ietf.org/proceedings/10mar/agenda/ippm.txt I know it is early but if you are presenting, please send me your slides before the meeting starts. 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 ------------------------------------------------------------------------------ Nobody ever went broke underestimating the taste of the American public. H.L.Mencken From fqhuang@huawei.com Wed Mar 17 21:56:12 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA643A6A0F for ; Wed, 17 Mar 2010 21:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.418 X-Spam-Level: * X-Spam-Status: No, score=1.418 tagged_above=-999 required=5 tests=[AWL=-1.787, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVXZCac9LRYc for ; Wed, 17 Mar 2010 21:56:11 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2CC133A6A0B for ; Wed, 17 Mar 2010 21:56:10 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZG006OEODA0M@szxga03-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:55:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZG00J4UODAVN@szxga03-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:55:58 +0800 (CST) Received: from h36145c ([10.70.39.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZG005SBODAAQ@szxml06-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:55:58 +0800 (CST) Date: Thu, 18 Mar 2010 12:55:58 +0800 From: Fortune HUANG To: ippm@ietf.org Message-id: <004b01cac657$4cd28580$4027460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_3pSdBFX9aDuic7iM4ZLSJA)" Thread-index: AcrGUJJZlnp5haxQTGO04jUqKw4trgABiX0g Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 04:56:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3pSdBFX9aDuic7iM4ZLSJA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, I have some questions about this draft below. Sorry for being a little late. 1. It is not clear to me how the server or the reflector use the SID specified in the request from the client. The SID doesn't seem to be used to correlate the test packets and the accepted sessions because there is no SID in the test packets. 2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions. Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3. 3. In section 3.5, What can the client do if told by the server that some the sessions can not be stopped? To resend the stop request? But in that case, a simpler way would be that the server could try to stop the sessions again without any stop request resent from the client. The signalling could be reduced in this way. Regards, Fortune --Boundary_(ID_3pSdBFX9aDuic7iM4ZLSJA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Dear all,
 
I have some questions about this draft below. Sorry for being a little late.
 
1. It is not clear to me how the server or the reflector use the SID specified in the request from the client. The SID doesn't seem to be used to correlate the test packets and the accepted sessions because there is no SID in the test packets.
 
2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3.
 
3. In section 3.5, What can the client do if told by the server that some the sessions can not be stopped? To resend the stop request? But in that case, a simpler way would be that the server could try to stop the sessions again without any stop request resent from the client. The signalling could be reduced in this way.
 
 
Regards,
Fortune
 
 
 
 
 
 
--Boundary_(ID_3pSdBFX9aDuic7iM4ZLSJA)-- From acmorton@att.com Thu Mar 18 06:55:32 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A343A6998 for ; Thu, 18 Mar 2010 06:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.803 X-Spam-Level: X-Spam-Status: No, score=-102.803 tagged_above=-999 required=5 tests=[AWL=-2.495, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MANGLED_SIDE=2.3, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycjjBJ0X0ysi for ; Thu, 18 Mar 2010 06:55:31 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id A03543A6A29 for ; Thu, 18 Mar 2010 06:55:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-146.messagelabs.com!1268920538!20663301!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 14210 invoked from network); 18 Mar 2010 13:55:39 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2010 13:55:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2IDtT23026405 for ; Thu, 18 Mar 2010 09:55:30 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2IDtNn3026276 for ; Thu, 18 Mar 2010 09:55:24 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2IDtYpn010227 for ; Thu, 18 Mar 2010 08:55:34 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2IDtTDD010094 for ; Thu, 18 Mar 2010 08:55:29 -0500 Message-Id: <201003181355.o2IDtTDD010094@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100318135528gw100b8icme>; Thu, 18 Mar 2010 13:55:28 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 18 Mar 2010 09:55:31 -0400 To: ippm@ietf.org From: Al Morton In-Reply-To: <004b01cac657$4cd28580$4027460a@china.huawei.com> References: <004b01cac657$4cd28580$4027460a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 13:55:32 -0000 At 12:55 AM 3/18/2010, Fortune HUANG wrote:
I have some questions about this draft below. Sorry for being a little late.
 
1. It is not clear to me how the server or the reflector use the SID specified in the request from the client. The SID doesn't seem to be used to correlate the test packets and the accepted sessions because there is no SID in the test packets.

this thread should help:
At 10:37 PM 3/17/2010, Tina TSOU wrote:
At 10:26 PM 3/15/2010, Tina TSOU wrote:
In paragraph 3 of section 4.2, given that there is no change to the TWAMP-test packet format, I assume we use the exact TWAMP-test packet format as defined RFC5357, so that the SID is not carried in the test packets. My question is that how the reflector just whether a TWAMP-test packet belongs to the same session/SID or not. Since per definition the testing message does not include SID, how to differentiate the testing message of different testing sessions after multiple testing started?
The Request-TW-Session command includes sender address + port
and receiver address + port, and this is usually sufficient.
Can the server identify the corresponding SID based on sender address + port and  receiver address + port?

Yes, the server assigns the SID with all addr+port information in hand.


 
2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3.

Use of SID was decided in the OWAMP spec. We simply continue to
use it in TWAMP and it keeps the two specs similar.

 
3. In section 3.5, What can the client do if told by the server that some the sessions can not be stopped? To resend the stop request? But in that case, a simpler way would be that the server could try to stop the sessions again without any stop request resent from the client. The signalling could be reduced in this way.
 
The client can resend, but in any case, the sender will stop sending
test packets.  At the reflector, resources are freed-up when it stops
a test, so this scenario seems rather unusual.

IETF-wide Last Call ended on Monday,
Al
From acmorton@att.com Thu Mar 18 12:38:09 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C66D3A67EC for ; Thu, 18 Mar 2010 12:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.402 X-Spam-Level: X-Spam-Status: No, score=-104.402 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Gzb2r0sQCwvO for ; Thu, 18 Mar 2010 12:38:08 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id A3B613A67B4 for ; Thu, 18 Mar 2010 12:38:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1268941098!41899730!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28984 invoked from network); 18 Mar 2010 19:38:19 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2010 19:38:19 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2IJc71u032717 for ; Thu, 18 Mar 2010 15:38:07 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2IJbxpg032581 for ; Thu, 18 Mar 2010 15:38:00 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2IJcA8o031897 for ; Thu, 18 Mar 2010 14:38:10 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2IJc6cV031829 for ; Thu, 18 Mar 2010 14:38:07 -0500 Message-Id: <201003181938.o2IJc6cV031829@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100318193806gw100b8igre>; Thu, 18 Mar 2010 19:38:06 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 18 Mar 2010 15:37:58 -0400 To: ippm@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] initial comments on draft-constantine-tcp-throughput-tm-02 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, 18 Mar 2010 19:38:09 -0000 Hi Barry and all, I'm sharing a few comments on this draft as they occur to me, and they'll be spread out over several messages as interrupts ebb and flow. It seems that there's a bit of intro material worth sorting-out, but I think it will help to understand the throughput & capacity testing landscape as IPPM considers this new work. more to follow, Al >1. Introduction > > Even though RFC2544 was meant to benchmark network equipment in the lab-only (a key point to include) > and > used by network equipment manufacturers (NEMs), some >network providers > have used it to benchmark operational networks in order to > provide SLAs (Service Level Agreements) to their business customers. Comment: This is both unfortunate and true. However, *some* test equipment manufacturers simply put RFC2455 in test devices (hand-held), while others enhanced the methodology in ways that are unknown to me and probably most of the standards community. Thus, methods deployed for raw capacity testing are/were "like-RFC2544" more or less. > Network providers are coming to the realization that RFC2544 testing > and TCP layer testing are required to more adequately ensure end-user > satisfaction. I see interest in both raw capacity testing (without TCP's restrictions) and TCP (this drafting effort and others making measurements using a variety of methods). > Therefore, the network provider community desires to measure network > throughput performance at the TCP layer. Maybe so, but only if the results will pass the test of a valid metric, and I think a rather wide spectrum of methods are actually wanted. > Measuring TCP throughput provides Suggest instead: A standardized metric of TCP Throughput would provide ... > ... a meaningful measure with respect to the end user's > application SLA (and ultimately reach some level of TCP testing > interoperability which does not exist today). From fqhuang@huawei.com Thu Mar 18 18:44:30 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B5F43A6BD5 for ; Thu, 18 Mar 2010 18:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.472 X-Spam-Level: ** X-Spam-Status: No, score=2.472 tagged_above=-999 required=5 tests=[AWL=-1.948, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MANGLED_SIDE=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VTAcS8mShg4 for ; Thu, 18 Mar 2010 18:44:29 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 984DB3A6C20 for ; Thu, 18 Mar 2010 18:44:26 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZI00B3FA63B9@szxga04-in.huawei.com> for ippm@ietf.org; Fri, 19 Mar 2010 09:44:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZI002D6A63RD@szxga04-in.huawei.com> for ippm@ietf.org; Fri, 19 Mar 2010 09:44:27 +0800 (CST) Received: from h36145c ([10.70.39.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZI00INMA63LS@szxml06-in.huawei.com> for ippm@ietf.org; Fri, 19 Mar 2010 09:44:27 +0800 (CST) Date: Fri, 19 Mar 2010 09:44:27 +0800 From: Fortune HUANG In-reply-to: <201003181355.o2IDtTDD010094@klpd017.kcdc.att.com> To: 'Al Morton' , ippm@ietf.org Message-id: <002401cac705$b5fd7110$4027460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_+DSfskXS35iRk1xBtZu4aA)" Thread-index: AcrGori+DZKrFUGURuytgljgftaGrQAWUvWw Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 01:44:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+DSfskXS35iRk1xBtZu4aA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Al, Thank you very much for your reply. Please see my response in-line below, indicated by [Fortune]. Regards, Fortune _____ From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton Sent: Thursday, March 18, 2010 9:56 PM To: ippm@ietf.org Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard At 12:55 AM 3/18/2010, Fortune HUANG wrote: I have some questions about this draft below. Sorry for being a little late. 1. It is not clear to me how the server or the reflector use the SID specified in the request from the client. The SID doesn't seem to be used to correlate the test packets and the accepted sessions because there is no SID in the test packets. this thread should help: At 10:37 PM 3/17/2010, Tina TSOU wrote: At 10:26 PM 3/15/2010, Tina TSOU wrote: In paragraph 3 of section 4.2, given that there is no change to the TWAMP-test packet format, I assume we use the exact TWAMP-test packet format as defined RFC5357, so that the SID is not carried in the test packets. My question is that how the reflector just whether a TWAMP-test packet belongs to the same session/SID or not. Since per definition the testing message does not include SID, how to differentiate the testing message of different testing sessions after multiple testing started? The Request-TW-Session command includes sender address + port and receiver address + port, and this is usually sufficient. Can the server identify the corresponding SID based on sender address + port and receiver address + port? Yes, the server assigns the SID with all addr+port information in hand. [Fortune: OK. Thanks!] 2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions. Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3. Use of SID was decided in the OWAMP spec. We simply continue to use it in TWAMP and it keeps the two specs similar. [Fortune: I don't think we need redundant fields to keep the two specs similar, but I won't fight for it anyway. But could you tell me that if the server accepts the SID in the way as described above, please?] 3. In section 3.5, What can the client do if told by the server that some the sessions can not be stopped? To resend the stop request? But in that case, a simpler way would be that the server could try to stop the sessions again without any stop request resent from the client. The signalling could be reduced in this way. The client can resend, but in any case, the sender will stop sending test packets. At the reflector, resources are freed-up when it stops a test, so this scenario seems rather unusual. [Fortune: If we need to consider this scenario seriously, maybe we need more text on the behaviors of both the client and server for this scenario. But I agree with you that this scenario seems rather unusual, and given my comment missed the deadline of the IETF-LC, I can also accept it as it is.] IETF-wide Last Call ended on Monday, Al --Boundary_(ID_+DSfskXS35iRk1xBtZu4aA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi Al,
 
Thank you very much for your reply. Please see my response in-line below, indicated by [Fortune].
 
 
Regards,
Fortune

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton
Sent: Thursday, March 18, 2010 9:56 PM
To: ippm@ietf.org
Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard

At 12:55 AM 3/18/2010, Fortune HUANG wrote:
I have some questions about this draft below. Sorry for being a little late.
 
1. It is not clear to me how the server or the reflector use the SID specified in the request from the client. The SID doesn't seem to be used to correlate the test packets and the accepted sessions because there is no SID in the test packets.

this thread should help:
At 10:37 PM 3/17/2010, Tina TSOU wrote:
At 10:26 PM 3/15/2010, Tina TSOU wrote:
In paragraph 3 of section 4.2, given that there is no change to the TWAMP-test packet format, I assume we use the exact TWAMP-test packet format as defined RFC5357, so that the SID is not carried in the test packets. My question is that how the reflector just whether a TWAMP-test packet belongs to the same session/SID or not. Since per definition the testing message does not include SID, how to differentiate the testing message of different testing sessions after multiple testing started?
The Request-TW-Session command includes sender address + port
and receiver address + port, and this is usually sufficient.
Can the server identify the corresponding SID based on sender address + port and  receiver address + port?

Yes, the server assigns the SID with all addr+port information in hand. 
 
[Fortune: OK. Thanks!] 



2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3.

Use of SID was decided in the OWAMP spec. We simply continue to
use it in TWAMP and it keeps the two specs similar. 
 
[Fortune: I don't think we need redundant fields to keep the two specs similar, but I won't fight for it anyway. But could you tell me that if the server accepts the SID in the way as described above, please?] 

3. In section 3.5, What can the client do if told by the server that some the sessions can not be stopped? To resend the stop request? But in that case, a simpler way would be that the server could try to stop the sessions again without any stop request resent from the client. The signalling could be reduced in this way.
 
The client can resend, but in any case, the sender will stop sending
test packets.  At the reflector, resources are freed-up when it stops
a test, so this scenario seems rather unusual. 
[Fortune: If we need to consider this scenario seriously, maybe we need more text on the behaviors of both the client and server for this scenario. But I agree with you that this scenario seems rather unusual, and given my comment missed the deadline of the IETF-LC, I can also accept it as it is.] 

IETF-wide Last Call ended on Monday,
Al
--Boundary_(ID_+DSfskXS35iRk1xBtZu4aA)-- From acmorton@att.com Thu Mar 18 19:24:20 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D4F3A6C78 for ; Thu, 18 Mar 2010 19:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.352 X-Spam-Level: X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=-2.444, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhwgY4TKcfKh for ; Thu, 18 Mar 2010 19:24:19 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id BEC2C3A6C8D for ; Thu, 18 Mar 2010 19:24:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-167.messagelabs.com!1268965468!28900451!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 11191 invoked from network); 19 Mar 2010 02:24:29 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2010 02:24:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2J2OHeh032175 for ; Thu, 18 Mar 2010 22:24:17 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2J2ODPQ032133 for ; Thu, 18 Mar 2010 22:24:13 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2J2ON9q014725 for ; Thu, 18 Mar 2010 21:24:23 -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 o2J2OHtm014686 for ; Thu, 18 Mar 2010 21:24:18 -0500 Message-Id: <201003190224.o2J2OHtm014686@klpd017.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-233-24.vpn.east.att.com[135.70.233.24](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100319022416gw100b8iihe>; Fri, 19 Mar 2010 02:24:17 +0000 X-Originating-IP: [135.70.233.24] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 18 Mar 2010 22:24:21 -0400 To: Fortune HUANG , ippm@ietf.org From: Al Morton In-Reply-To: <002401cac705$b5fd7110$4027460a@china.huawei.com> References: <201003181355.o2IDtTDD010094@klpd017.kcdc.att.com> <002401cac705$b5fd7110$4027460a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 02:24:20 -0000 At 09:44 PM 3/18/2010, Fortune HUANG wrote:
2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3.

Use of SID was decided in the OWAMP spec. We simply continue to
use it in TWAMP and it keeps the two specs similar.
 
[Fortune: I don't think we need redundant fields to keep the two specs similar, but I won't fight for it anyway. But could you tell me that if the server accepts the SID in the way as described above, please?]

Your scenario seems to have the Control-client assigning the SID.
That's not how the protocol works - the Server assigns the SID.
from RFC 5357, section 3.5:

   The Session Identifier (SID) is as defined in OWAMP
[RFC4656].  Since
   the SID is always generated by the receiving side, the
Server
   determines the SID, and the SID in the Request-TW-Session
message
   MUST be set to 0.
Al

From fqhuang@huawei.com Wed Mar 17 21:07:42 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5658628C0ED for ; Wed, 17 Mar 2010 21:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.524 X-Spam-Level: X-Spam-Status: No, score=0.524 tagged_above=-999 required=5 tests=[AWL=-2.681, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMLpQEAPIC2q for ; Wed, 17 Mar 2010 21:07:41 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E598728C0F8 for ; Wed, 17 Mar 2010 21:07:39 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZG006NSM510M@szxga03-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:07:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZG0049FM51BT@szxga03-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:07:49 +0800 (CST) Received: from h36145c ([10.70.39.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZG005SIM51AQ@szxml06-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:07:49 +0800 (CST) Date: Thu, 18 Mar 2010 12:07:49 +0800 From: Fortune HUANG To: ippm@ietf.org Message-id: <004601cac650$9284a3d0$4027460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_kcWwp8t4u4eTBFsqD2U3TQ)" Thread-index: AcrGUJJZlnp5haxQTGO04jUqKw4trg== X-Mailman-Approved-At: Sun, 21 Mar 2010 08:01:41 -0700 Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 04:07:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_kcWwp8t4u4eTBFsqD2U3TQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, I have some questions about this draft below. Sorry for being a little late. 1. It is not clear to me how the server or the reflector use the SID specified in the request from the client. The SID doesn't seem to be used to correlate the test packets and the accepted sessions because there is no SID in the test packets. 2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions. Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3. 3. In section 3.5, What can the client do if told by the server that some the sessions can not be stopped? To resend the stop request? But in that case, a simpler way would be that the server could try to stop the sessions again without any stop request resent from the client. The signalling could be reduced in this way. Regards, Fortune --Boundary_(ID_kcWwp8t4u4eTBFsqD2U3TQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Dear all,
 
I have some questions about this draft below. Sorry for being a little late.
 
1. It is not clear to me how the server or the reflector use the SID specified in the request from the client. The SID doesn't seem to be used to correlate the test packets and the accepted sessions because there is no SID in the test packets.
 
2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3.
 
3. In section 3.5, What can the client do if told by the server that some the sessions can not be stopped? To resend the stop request? But in that case, a simpler way would be that the server could try to stop the sessions again without any stop request resent from the client. The signalling could be reduced in this way.
 
 
Regards,
Fortune
 
 
 
 
 
 
--Boundary_(ID_kcWwp8t4u4eTBFsqD2U3TQ)-- From mchiba@gmail.com Sun Mar 21 10:48:25 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0643A6863 for ; Sun, 21 Mar 2010 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.832 X-Spam-Level: X-Spam-Status: No, score=0.832 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Wz+RmUQJVRY for ; Sun, 21 Mar 2010 10:48:24 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id EE0A13A69F2 for ; Sun, 21 Mar 2010 10:48:23 -0700 (PDT) Received: by ywh38 with SMTP id 38so2498032ywh.29 for ; Sun, 21 Mar 2010 10:48:37 -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=j15e2nNwSEiIDSYzDLmoeHw9H3U5T7Me1wgh1KOA1+s=; b=ZWMPJG2ewAcsaFq+6EIpQfxyFf4kLIhHq6icIRywm5i1Nt2wp79CuC9fvE3jGMydrr X/gX3YsofaXk3NKxwAd6y2j4psEWEyxJr4b6pQ8RveQ2m+uz/9jNbBMWT11NuYA8hGxt ngQh+yfBrOCT7ZObIeWXsdwfDa2xn1CsdM/fM= 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=ql2Rk6rZdfVMBJ96zjiv9C4WVp3JuL2JFscvFnsOmGiXwiAycoR+giPollp3mwB51l s1VCcEr/O/4URAhxNBSi5P1DsL9W7umGkPIQfWxiyvN60G0swFb2seghUqT/zcJ7Hjq6 GLs9lX9TwEv9MXYekbHx39IRPiRAHCBQdhZu8= MIME-Version: 1.0 Received: by 10.100.55.22 with SMTP id d22mr13786079ana.82.1269193716898; Sun, 21 Mar 2010 10:48:36 -0700 (PDT) In-Reply-To: <201003190224.o2J2OHtm014686@klpd017.kcdc.att.com> References: <201003181355.o2IDtTDD010094@klpd017.kcdc.att.com> <002401cac705$b5fd7110$4027460a@china.huawei.com> <201003190224.o2J2OHtm014686@klpd017.kcdc.att.com> Date: Sun, 21 Mar 2010 10:48:36 -0700 Message-ID: <76acda071003211048v4330a008mf92f5494c1800b72@mail.gmail.com> From: Murtaza Chiba To: Al Morton Content-Type: multipart/alternative; boundary=0016e6476278a59c5b0482533040 Cc: ippm@ietf.org Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 17:48:25 -0000 --0016e6476278a59c5b0482533040 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 18, 2010 at 7:24 PM, Al Morton wrote: > At 09:44 PM 3/18/2010, Fortune HUANG wrote: > > 2. In section 3.3, I think the SIDs may not need to be carried back to the > client. Assuming the SID is accepted in sequence with no discrimination, the > client can figure out the list of accepted SIDs with the accepted number of > sessions. Suppose the client requests for SID1, SID2, SID3 and SID4 in > sequence, can the server accepts only SID1, SID3 without accepting SID2? If > it can do that, how does the server differentiate SID3 and SID2? If it can > not do that, that I think the server can return a acceptance count to the > client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and > SID3. > > > Use of SID was decided in the OWAMP spec. We simply continue to > use it in TWAMP and it keeps the two specs similar. > > [Fortune: I don't think we need redundant fields to keep the two specs > similar, but I won't fight for it anyway. But could you tell me that if the > server accepts the SID in the way as described above, please?] > > > Your scenario seems to have the Control-client assigning the SID. > That's not how the protocol works - the Server assigns the SID. > from RFC 5357, section 3.5: > > The Session Identifier (SID) is as defined in OWAMP > [RFC4656 ]. Since > the SID is always generated by the receiving side, the > Server > determines the SID, and the SID in the Request-TW-Session > message > MUST be set to 0. > > Furthermore, if the Client assigns a SID it is not guaranteed to be unique in the network. If the server assigns one, at the very least all the clients that the server accepts connections from are guaranteed to have unique identifiers. Thanks, -murtaza > Al > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --0016e6476278a59c5b0482533040 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 18, 2010 at 7:24 PM, Al Mort= on <acmorton@att.c= om> wrote:
At 09:44 PM 3/18/2010, Fortune HUANG wrote:
2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions.=A0 Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3.

Use of SID was decided in the OWAMP spec. We simply continue to
use it in TWAMP and it keeps the two specs similar.
=A0
[Fortune: I don't think we need redu= ndant fields to keep the two specs similar, but I won't fight for it anyway. But could you tell me that if the server accepts the SID in the way as described above, please?]

Your scenario seems to have the Control-client assigning the SID.
That's not how the protocol works - the Server assigns the SID.
from RFC 5357, section 3.5:

=A0=A0 The Session Identifier (SID) is as defined in OWAMP
[RFC4656].=A0 Since
=A0=A0 the SID is always generated by the receiving side, the
Server
=A0=A0 determines the SID, and the SID in the Request-TW-Session
message
=A0=A0 MUST be set to 0.

_______________________________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm


--0016e6476278a59c5b0482533040-- From jerome.benoit@grenouille.com Sun Mar 21 13:12:08 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13EF93A681E for ; Sun, 21 Mar 2010 13:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.948 X-Spam-Level: * X-Spam-Status: No, score=1.948 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, 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 AKsabu4+4UbH for ; Sun, 21 Mar 2010 13:12:07 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by core3.amsl.com (Postfix) with ESMTP id B680A3A67FD for ; Sun, 21 Mar 2010 13:12:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 6BE6B7F142 for ; Sun, 21 Mar 2010 21:12:21 +0100 (CET) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA16RlphiV4b for ; Sun, 21 Mar 2010 21:12:19 +0100 (CET) Received: from nemesis.grenouille.com (bea13-2-82-239-143-199.fbx.proxad.net [82.239.143.199]) by laposte.grenouille.com (Postfix) with ESMTP id 8CDD77F120 for ; Sun, 21 Mar 2010 21:12:19 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by nemesis.grenouille.com (Postfix) with SMTP id 1C9D46066C for ; Sun, 21 Mar 2010 21:12:19 +0100 (CET) Date: Sun, 21 Mar 2010 21:12:18 +0100 From: Jerome Benoit To: ippm@ietf.org Message-Id: <20100321211218.a906dc80.jerome.benoit@grenouille.com> In-Reply-To: <76acda071003211048v4330a008mf92f5494c1800b72@mail.gmail.com> References: <201003181355.o2IDtTDD010094@klpd017.kcdc.att.com> <002401cac705$b5fd7110$4027460a@china.huawei.com> <201003190224.o2J2OHtm014686@klpd017.kcdc.att.com> <76acda071003211048v4330a008mf92f5494c1800b72@mail.gmail.com> Organization: grenouille.com X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__21_Mar_2010_21_12_18_+0100_yHBL0nKQ0mqn=SyE" Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 20:12:08 -0000 --Signature=_Sun__21_Mar_2010_21_12_18_+0100_yHBL0nKQ0mqn=SyE Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Sun, 21 Mar 2010 10:48:36 -0700, Murtaza Chiba a =E9crit : Hello,=20 > Furthermore, if the Client assigns a SID it is not guaranteed to be > unique in the network. If the server assigns one, at the very least > all the clients that the server accepts connections from are > guaranteed to have unique identifiers. I lurk this IETF WG since some time in order to enhance an old measurement system (that need less naive measurements and hackers) used by end-user to troubleshoot their connexion in France. Quiet honestly, neither OWAMP or TWAMP can be implemented without a revamp to serve our need.=20 To be more explicit :=20 - We can't trust the end-user clock for timestamping measurement, we rely on time difference from the server clock source only (we plan to calibrate timestamping inaccuracy);=20 - The measurement agent run behind the end-user CPE, 1-to-n NATed for IPv4 and firewalled, so measurement agent must start the probing session and initiate the connection, same for probing configuration fetching).=20 The end-to-end delay and delay between landmarks and end host is a very useful metric to do troubleshooting but we can't do it by strictly following IETF RFC ...=20 For measurement agent UUID handling, we plan to :=20 - generate it at first agent start;=20 - register it on the server that will handle the birthday paradox;=20 - UUID has nothing to do with your probing session ID but it's the quickest way to map a probing configuration to an measurement agent on network topology criteria or other ...=20 Maybe it will be useful to this WG.=20 Cheers. --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Signature=_Sun__21_Mar_2010_21_12_18_+0100_yHBL0nKQ0mqn=SyE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkumfaIACgkQ+qDLUJ/pFh2J1ACgmdP67PeldmbsMjPSeWFpvxN7 WQgAoIFrsfNnGBzLPrJCEPv9xamcr7mS =KNf6 -----END PGP SIGNATURE----- --Signature=_Sun__21_Mar_2010_21_12_18_+0100_yHBL0nKQ0mqn=SyE-- From fqhuang@huawei.com Sun Mar 21 17:29:07 2010 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD3F3A6966 for ; Sun, 21 Mar 2010 17:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.562 X-Spam-Level: ** X-Spam-Status: No, score=2.562 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UadbJkw82AME for ; Sun, 21 Mar 2010 17:29:06 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B3A063A6955 for ; Sun, 21 Mar 2010 17:29:04 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZN00AEIQOIS0@szxga04-in.huawei.com> for ippm@ietf.org; Mon, 22 Mar 2010 08:29:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZN00ALOQOIDO@szxga04-in.huawei.com> for ippm@ietf.org; Mon, 22 Mar 2010 08:29:06 +0800 (CST) Received: from h36145c ([10.70.39.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZN00BLKQOIGF@szxml04-in.huawei.com> for ippm@ietf.org; Mon, 22 Mar 2010 08:29:06 +0800 (CST) Date: Mon, 22 Mar 2010 08:29:06 +0800 From: Fortune HUANG In-reply-to: <76acda071003211048v4330a008mf92f5494c1800b72@mail.gmail.com> To: 'Murtaza Chiba' , 'Al Morton' Message-id: <005601cac956$aea41600$4027460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_uAlh4xGXudQO/KgGuEVrQg)" Thread-index: AcrJHrz3K8R9Ka5KR8qxLlCKrU0T1gANoxDQ Cc: ippm@ietf.org Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (IndividualSession Control Feature for TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 00:29:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_uAlh4xGXudQO/KgGuEVrQg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Murtaza, Hi Al, Thank you very much for the explanations. I think I've had a better view on this draft with your help now. Regards, Fortune _____ From: Murtaza Chiba [mailto:mchiba@gmail.com] Sent: Monday, March 22, 2010 1:49 AM To: Al Morton Cc: Fortune HUANG; ippm@ietf.org Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (IndividualSession Control Feature for TWAMP) to Proposed Standard On Thu, Mar 18, 2010 at 7:24 PM, Al Morton wrote: At 09:44 PM 3/18/2010, Fortune HUANG wrote: 2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions. Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3. Use of SID was decided in the OWAMP spec. We simply continue to use it in TWAMP and it keeps the two specs similar. [Fortune: I don't think we need redundant fields to keep the two specs similar, but I won't fight for it anyway. But could you tell me that if the server accepts the SID in the way as described above, please?] Your scenario seems to have the Control-client assigning the SID. That's not how the protocol works - the Server assigns the SID. from RFC 5357, section 3.5: The Session Identifier (SID) is as defined in OWAMP [RFC4656 ]. Since the SID is always generated by the receiving side, the Server determines the SID, and the SID in the Request-TW-Session message MUST be set to 0. Furthermore, if the Client assigns a SID it is not guaranteed to be unique in the network. If the server assigns one, at the very least all the clients that the server accepts connections from are guaranteed to have unique identifiers. Thanks, -murtaza Al _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --Boundary_(ID_uAlh4xGXudQO/KgGuEVrQg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi Murtaza,
Hi Al,
 
Thank you very much for the explanations. I think I've had a better view on this draft with your help now.
 
 
Regards,
Fortune
 
 

From: Murtaza Chiba [mailto:mchiba@gmail.com]
Sent: Monday, March 22, 2010 1:49 AM
To: Al Morton
Cc: Fortune HUANG; ippm@ietf.org
Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (IndividualSession Control Feature for TWAMP) to Proposed Standard



On Thu, Mar 18, 2010 at 7:24 PM, Al Morton <acmorton@att.com> wrote:
At 09:44 PM 3/18/2010, Fortune HUANG wrote:
2. In section 3.3, I think the SIDs may not need to be carried back to the client. Assuming the SID is accepted in sequence with no discrimination, the client can figure out the list of accepted SIDs with the accepted number of sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only SID1, SID3 without accepting SID2? If it can do that, how does the server differentiate SID3 and SID2? If it can not do that, that I think the server can return a acceptance count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and SID3.

Use of SID was decided in the OWAMP spec. We simply continue to
use it in TWAMP and it keeps the two specs similar.
 
[Fortune: I don't think we need redundant fields to keep the two specs similar, but I won't fight for it anyway. But could you tell me that if the server accepts the SID in the way as described above, please?]

Your scenario seems to have the Control-client assigning the SID.
That's not how the protocol works - the Server assigns the SID.
from RFC 5357, section 3.5:

   The Session Identifier (SID) is as defined in OWAMP
[RFC4656].  Since
   the SID is always generated by the receiving side, the
Server
   determines the SID, and the SID in the Request-TW-Session
message
   MUST be set to 0.

Furthermore, if the Client assigns a SID it is not guaranteed to be unique in the network. If the server assigns one, at the very least all the clients that the server accepts connections from are guaranteed to have unique identifiers.

Thanks,
-murtaza
 
Al


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




--Boundary_(ID_uAlh4xGXudQO/KgGuEVrQg)--

From henk@ripe.net  Mon Mar 22 14:57:23 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A96B28C10B for ; Mon, 22 Mar 2010 14:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.238
X-Spam-Level: 
X-Spam-Status: No, score=-0.238 tagged_above=-999 required=5 tests=[AWL=1.232,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 LtDfwkZ+jYH3 for ; Mon, 22 Mar 2010 14:57:22 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 1BC533A6935 for ; Mon, 22 Mar 2010 14:57:19 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Ntpcm-0005tN-9C for ippm@ietf.org; Mon, 22 Mar 2010 22:57:33 +0100
Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=geir.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Ntpcl-0004zq-Ub for ippm@ietf.org; Mon, 22 Mar 2010 22:57:28 +0100
Message-ID: <4BA7E7C6.2030005@ripe.net>
Date: Mon, 22 Mar 2010 22:57:26 +0100
From: Henk Uijterwaal 
Organization: RIPE NCC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: IETF IPPM WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5ba8b9c93d26b182c44b9b0c16f89e7bf
X-RIPE-Spam-Level: ----
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5ba8b9c93d26b182c44b9b0c16f89e7bf
Subject: [ippm] Meeting in Anaheim
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, 22 Mar 2010 21:57:23 -0000

IPPM group,

I've uploaded the final agenda for tomorrow's meeting as well as the
2 slidepacks I received so far.   More slidepacks are welcome!

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
------------------------------------------------------------------------------

Nobody ever went broke underestimating the taste of the American public.
                                                                  H.L.Mencken

From matt@internet2.edu  Mon Mar 22 15:24:45 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407243A693F for ; Mon, 22 Mar 2010 15:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.54
X-Spam-Level: 
X-Spam-Status: No, score=-4.54 tagged_above=-999 required=5 tests=[AWL=0.930,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 t0sWshkT5ff8 for ; Mon, 22 Mar 2010 15:24:43 -0700 (PDT)
Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id 814813A67E1 for ; Mon, 22 Mar 2010 15:24:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id 83E8F22579C for ; Mon, 22 Mar 2010 18:25:01 -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 RbAFPZ8pGC-K for ; Mon, 22 Mar 2010 18:25:01 -0400 (EDT)
Received: from dhcp-wireless-open-a-40-76.meeting.ietf.org (dhcp-wireless-open-a-40-76.meeting.ietf.org [130.129.40.76]) (Authenticated sender: matt@internet2.edu) by magus.merit.edu (Postfix) with ESMTP id ECE7C2251B0 for ; Mon, 22 Mar 2010 18:25:00 -0400 (EDT)
Message-ID: <4BA7EE39.2000802@internet2.edu>
Date: Mon, 22 Mar 2010 15:24:57 -0700
From: Matthew J Zekauskas 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: IETF IPPM WG 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [ippm] Remote Participation Details for IPPM at IETF 77
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, 22 Mar 2010 22:24:45 -0000

If you plan to join remotely, we start tomorrow (Tuesday 23-Mar-2010)
1740 PDT in Anaheim.

Assuming the Audio stream is working, please join it:


All the latest versions of the slides received will be posted here by
meeting time:


Jabber info:

(We will monitor jabber; however, do not expect that the session will
be completely scribed there!)

--Matt

From duffield@research.att.com  Mon Mar 22 21:17:50 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065EA3A6A45 for ; Mon, 22 Mar 2010 21:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.569
X-Spam-Level: 
X-Spam-Status: No, score=-97.569 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, 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 FSzTcy3owqEu for ; Mon, 22 Mar 2010 21:17:49 -0700 (PDT)
Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by core3.amsl.com (Postfix) with ESMTP id 47C6C3A6A46 for ; Mon, 22 Mar 2010 21:17:42 -0700 (PDT)
Received: from njfpsrvexg3.research.att.com (njfpsrvexg3.research.att.com [135.207.176.37]) by mail-blue.research.att.com (Postfix) with ESMTP id 9840DEF7CE for ; Tue, 23 Mar 2010 00:18:00 -0400 (EDT)
Received: from njfpsrvexg4.research.att.com ([135.207.176.38]) by njfpsrvexg3.research.att.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 23 Mar 2010 00:17:57 -0400
Received: from njfpsrvexg4.research.att.com ([135.207.26.12]) by njfpsrvexg4.research.att.com ([135.207.26.12]) with mapi; Tue, 23 Mar 2010 00:17:57 -0400
From: "DUFFIELD, NICHOLAS G (NICK)" 
To: "ippm@ietf.org" 
Date: Tue, 23 Mar 2010 00:17:59 -0400
Thread-Topic: New Version Notification for draft-duffield-ippm-burst-loss-metrics-02 
Thread-Index: AcrKPbm/boM3Wyr7R26svqOz21oftwAAB77A
Message-ID: <4505FA7960878D4EB29CE0FDAADCB2D5143239F272@njfpsrvexg4.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 23 Mar 2010 04:17:57.0845 (UTC) FILETIME=[D1677850:01CACA3F]
Subject: [ippm] FW: New Version Notification for draft-duffield-ippm-burst-loss-metrics-02
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, 23 Mar 2010 04:17:50 -0000

SSBqdXN0IHBvc3RlZCBuZXcgdmVyc2lvbiBvZiBkcmFmdC1kdWZmaWVsZC1pcHBtLWJ1cnN0LWxv
c3MtbWV0cmljcy4gDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZHVmZmllbGQtaXBw
bS1idXJzdC1sb3NzLW1ldHJpY3MtMDIudHh0DQoNCg0KVGhpcyBpbmNvcnBvcmF0ZXMgZmVlZGJh
Y2sgZnJvbSBhcm91bmQgdGhlIHRpbWUgb2YgdGhlIGxhc3QgV0cgbWVldGluZy4gVGhlcmUgd2Vy
ZSBzZXZlcmFsIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgY29uY2VybmluZyB0aGUgcmVsYXRpb24g
b2YgdGhpcyB3b3JrIHRvIGxvc3MgbW9kZWxzLCBidXJzdGluZXNzIG1lYXN1cmVzLCBhbmQgcGFj
a2V0IHBhaXIgcHJvYmluZy4gVGhlc2UgbWF0dGVycyBhcmUgbm93IGFkZHJlc3NlZCBpbiBncmVh
dGVyIGRldGFpbCBpbiB0aGUgSW50cm9kdWN0aW9uIFNlY3Rpb24gMSwgYW5kIGluIGEgbmV3IGFw
cGxpY2F0aW9ucyBTZWN0aW9uIDcuDQoNCkFsc28gd2UgY2hhbmdlZCB0aGUgdGl0bGUgImJ1cnN0
IGxvc3MgbWV0cmljcyIgdG8gImxvc3MgZXBpc29kZSBtZXRyaWNzIiB0byBiZXR0ZXIgcmVwcmVz
ZW50IHRoZSBtYWluIGNvbnRyaWJ1dGlvbiBvZiB0aGUgd29yay4NCg0KV2UgbG9vayBmb3J3YXJk
IHRvIGZ1cnRoZXIgZmVlZGJhY2sgYW5kIHJldmlldyBmcm9tIHRoZSBtYWlsaW5nIGxpc3QgcGFy
dGljaXBhbnRzLiANCg0KTmljaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
SUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSAN
ClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIzLCAyMDEwIDEyOjAyIEFNDQpUbzogRFVGRklFTEQsIE5J
Q0hPTEFTIEcgKE5JQ0spDQpDYzogTU9SVE9OIEpSLiwgQUwgKEFUVExBQlMpOyBqc29tbWVyc0Bj
b2xnYXRlLmVkdQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1k
dWZmaWVsZC1pcHBtLWJ1cnN0LWxvc3MtbWV0cmljcy0wMiANCg0KDQpBIG5ldyB2ZXJzaW9uIG9m
IEktRCwgZHJhZnQtZHVmZmllbGQtaXBwbS1idXJzdC1sb3NzLW1ldHJpY3MtMDIudHh0IGhhcyBi
ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTmljayBEdWZmaWVsZCBhbmQgcG9zdGVkIHRv
IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZHVmZmllbGQtaXBwbS1i
dXJzdC1sb3NzLW1ldHJpY3MNClJldmlzaW9uOgkgMDINClRpdGxlOgkJIExvc3MgRXBpc29kZSBN
ZXRyaWNzIGZvciBJUFBNDQpDcmVhdGlvbl9kYXRlOgkgMjAxMC0wMy0yMQ0KV0cgSUQ6CQkgSW5k
ZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAyMg0KDQpBYnN0cmFjdDoNClRo
ZSBJUFBNIFdvcmtpbmcgR3JvdXAgaGFzIGRldmVsb3BlZCBhIG9uZSB3YXkgcGFja2V0IGxvc3Mg
bWV0cmljDQp0aGF0IG1lYXN1cmVzIHRoZSBsb3NzIHJhdGUgb24gYSBQb2lzc29uIHByb2JlIHN0
cmVhbSBiZXR3ZWVuIHR3bw0KaG9zdHMuICBIb3dldmVyLCB0aGUgaW1wYWN0IG9mIHBhY2tldCBs
b3NzIG9uIGFwcGxpY2F0aW9ucyBpcyBpbg0KZ2VuZXJhbCBzZW5zaXRpdmUgbm90IGp1c3QgdG8g
dGhlIGF2ZXJhZ2UgbG9zcyByYXRlLCBidXQgYWxzb3RvIHRoZQ0Kd2F5IGluIHdoaWNoIHBhY2tl
dCBsb3NzZXMgYXJlIGRpc3RyaWJ1dGVkIGluIGxvc3MgZXBpc29kZXMgKGkuZS4sDQptYXhpbWFs
IHNldHMgb2YgY29uc2VjdXRpdmVseSBsb3N0IHByb2JlIHBhY2tldHMpLiAgVGhpcyBkcmFmdA0K
ZGVmaW5lcyBvbmUtd2F5IHBhY2tldCBsb3NzIGVwaXNvZGUgbWV0cmljcywgc3BlY2lmaWNhbGx5
IHRoZQ0KZnJlcXVlbmN5IGFuZCBhdmVyYWdlIGR1cmF0aW9uIG9mIGxvc3MgZXBpc29kZXMsIGFu
ZCBhIHByb2JpbmcNCm1ldGhvZG9sb2d5IHVuZGVyIHdoaWNoIHRoZSBsb3NzIGVwaXNvZGUgbWV0
cmljcyBhcmUgdG8gYmUgbWVhc3VyZWQuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K
VGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0K

From vinayakh@gmail.com  Tue Mar 23 13:29:40 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212763A68DC for ; Tue, 23 Mar 2010 13:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 Qb45gijIjcz3 for ; Tue, 23 Mar 2010 13:29:39 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 493863A67F9 for ; Tue, 23 Mar 2010 13:29:38 -0700 (PDT)
Received: by wwg30 with SMTP id 30so3349091wwg.31 for ; Tue, 23 Mar 2010 13:29:54 -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=xp/VCepvJsC+zSQLU0UZlVZwdFb1zUfYQ6QtvyFzRkk=; b=Mbyjc3E3w3pI8zJhmi9+ScC9h0Cm6bQ9qPoFhXa9pO15s/0m1zS1aeGiMKLT+Xxew5 xzrgi4Svy0Ax9GXZj6VlSK1BQDARrCRiwBCi9cp0jmTsGIGxZfrgkAH4aM1XkyJmOzNT plgyxnyca4XGz9y+uIvH5QGbjygeL77T31wHo=
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=ame5OuGEDBWtoIcPsaM7g4nD+e5yxguH1duWTHnxVkPBT+Vh7lo3kX9B3zniD4d06H yKIb3HdjUunrwKYomiar/I89XJGGrzxJGAynlT3SyShV7/+utlglA8s+J5mq7GrZ/4GA 9MFAs6ZvTDkLGizRin1bSRnMd8Nuw/TvbQKIw=
MIME-Version: 1.0
Received: by 10.216.90.84 with SMTP id d62mr3022436wef.211.1269376194414; Tue,  23 Mar 2010 13:29:54 -0700 (PDT)
In-Reply-To: <201003181938.o2IJc6cV031829@klpd017.kcdc.att.com>
References: <201003181938.o2IJc6cV031829@klpd017.kcdc.att.com>
Date: Wed, 24 Mar 2010 01:59:54 +0530
Message-ID: <38940f3c1003231329u8b03296t294076c1a588c884@mail.gmail.com>
From: Vinayak Hegde 
To: Al Morton 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ippm@ietf.org
Subject: Re: [ippm] initial comments on draft-constantine-tcp-throughput-tm-02
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, 23 Mar 2010 20:29:40 -0000

Hi,

I am adding a couple more comments to the draft:

1. TCP throughput testing has a lot of variable and intermediate hops
(which can affect the results). Barry has done a good job of narrowing
down and pinning the scope so that the draft itself is very useful.
But given these complexity of the task, it would be nice to see a
minimal list of parameters that should be added to each of the
benchmark tests so that there can be atleast some meaningful
comparison of results across networks / network conditions. Examples
could include:
     1 TCP window size
     2. MSS
     3. Number of connections
     4. Congestion algorithm used at the end-points
     5. RTT (steady state as the draft notes).
     6. Various stack tunables (such as the sysctl output for network param=
s)

2. The range of variance in some of the above parameters
    1. Most notably latency - RTT on a live network
    2. The effect of the mix of traffic (and the ramping curve of
stateless traffic such as UDP) on the latency.

One last point was whether there might be merit in instrumenting any
of the intermediate hops for checking congestion. Would it be possible
to share code that does some of the measurement and generates streams
for testing (as a reference implementation).

-- Vinayak

On Fri, Mar 19, 2010 at 1:07 AM, Al Morton  wrote:
> Hi Barry and all,
>
> I'm sharing a few comments on this draft as they occur to me,
> and they'll be spread out over several messages as interrupts
> ebb and flow.
>
> It seems that there's a bit of intro material worth sorting-out,
> but I think it will help to understand the throughput & capacity
> testing landscape as IPPM considers this new work.
>
> more to follow,
> Al
>
>> 1. Introduction
>>
>> =A0 Even though RFC2544 was meant to benchmark network equipment
>
> in the lab-only (a key point to include)
>
>> =A0 and
>> =A0 used by network equipment manufacturers (NEMs),
>
> some
>
>> network providers
>> =A0 have used it to benchmark operational networks in order to
>> =A0 provide SLAs (Service Level Agreements) to their business customers.
>
> Comment:
> This is both unfortunate and true. =A0However, *some* test equipment
> manufacturers simply put RFC2455 in test devices (hand-held), while other=
s
> enhanced the methodology in ways that are unknown to me and probably
> most of the standards community. =A0Thus, methods deployed for raw
> capacity testing are/were "like-RFC2544" more or less.
>
>> =A0 Network providers are coming to the realization that RFC2544 testing
>> =A0 and TCP layer testing are required to more adequately ensure end-use=
r
>> =A0 satisfaction.
>
> I see interest in both raw capacity testing (without TCP's restrictions)
> and TCP (this drafting effort and others making measurements using a
> variety of methods).
>
>> =A0 Therefore, the network provider community desires to measure network
>> =A0 throughput performance at the TCP layer.
>
> Maybe so, but only if the results will pass the test of a
> valid metric, and I think a rather wide spectrum of methods
> are actually wanted.
>
>> =A0 Measuring TCP throughput provides
>
> Suggest instead:
> A standardized metric of TCP Throughput would provide ...
>
>> =A0 ... a meaningful measure with respect to the end user's
>> =A0 application SLA (and ultimately reach some level of TCP testing
>> =A0 interoperability which does not exist today).
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>

From dave.mcdysan@verizon.com  Tue Mar 23 19:15:40 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B81D3A6A2B for ; Tue, 23 Mar 2010 19:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.131
X-Spam-Level: 
X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 NYM-UU8G9onu for ; Tue, 23 Mar 2010 19:15:39 -0700 (PDT)
Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id A99733A6828 for ; Tue, 23 Mar 2010 19:15:39 -0700 (PDT)
Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id o2O2FgiS028480 for ; Tue, 23 Mar 2010 22:15:50 -0400 (EDT)
X-AuditID: 8a532267-b7bffae000007c42-9a-4ba975d03c96
Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id B7.83.31810.0D579AB4; Tue, 23 Mar 2010 21:15:44 -0500 (CDT)
Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o2O2FiR2018061 for ; Tue, 23 Mar 2010 22:15:44 -0400 (EDT)
Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 22:15:43 -0400
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, 23 Mar 2010 22:15:38 -0400
Message-ID: <793F49BA1FC821409F99F10862A0E4DB06454026@FHDP1LUMXCV14.us.one.verizon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-ippm-reporting-metrics-01
Thread-Index: AcrK9+UsDFoyPRhlS5i9CL+FgJhs3Q==
From: "Mcdysan, David E" 
To: 
X-OriginalArrivalTime: 24 Mar 2010 02:15:43.0828 (UTC) FILETIME=[E8670940:01CACAF7]
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Tue, 23 Mar 2010 20:03:49 -0700
Subject: [ippm] Comments on draft-ietf-ippm-reporting-metrics-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: Wed, 24 Mar 2010 02:15:40 -0000

As mentioned in the meeting, I propose the following changes to the
subject draft:
=20
- Mention SLA as an example use of network characterization
- Make the loss reporting section of this draft consistent with section
3 of http://tools.ietf.org/id/draft-ietf-ippm-reporting-04.txt
=20
   One consideration that would have to be addressed to make these
   metrics suitable for longer-term measurements (hours and days) is
   that of network availability: during such long periods of time the
   network may be completely down for some time and it does not seem to
   make sense to average out the reports in such a way that the network
   being down for 1% of the time becomes 1% packet loss.

- Mention the current Y.154x definition of sustatined high loss rate as
an ITU-defined unavailable state.

Thanks,

Dave
=20
=20



From henk@ripe.net  Wed Mar 24 16:15:46 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016073A6D0F for ; Wed, 24 Mar 2010 16:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 00fUlOmapEnJ for ; Wed, 24 Mar 2010 16:15:15 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 642B43A6DD2 for ; Wed, 24 Mar 2010 16:06:37 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NuZf1-00075C-EM for ippm@ietf.org; Thu, 25 Mar 2010 00:06:56 +0100
Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=geir.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NuZf0-0002bf-Ny for ippm@ietf.org; Thu, 25 Mar 2010 00:06:51 +0100
Message-ID: <4BAA9B09.30908@ripe.net>
Date: Thu, 25 Mar 2010 00:06:49 +0100
From: Henk Uijterwaal 
Organization: RIPE NCC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: "ippm >> IETF IPPM WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5c1f2e42d27fc838a9bdb1c75ae9101c6
X-RIPE-Spam-Level: ----
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5c1f2e42d27fc838a9bdb1c75ae9101c6
Subject: [ippm] Proposal to make draft-constantine- ippm-tcp-throughput-tm a WG document
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Mar 2010 23:15:46 -0000

IPPM Group,

We have been discussing  draft-constantine-ippm-tcp-throughput-tm for a
number of meetings by now and there appears to be considerable interest in
this document.  We propose to make this a working group document.  If you
have any comments on this, please post them to the list by April 12.

Matt & Henk

-- 

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Nobody ever went broke underestimating the taste of the American public.
                                                                  H.L.Mencken

From henk@ripe.net  Wed Mar 24 16:17:56 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC2A3A6B3E for ; Wed, 24 Mar 2010 16:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.912
X-Spam-Level: 
X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=0.557,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 lm6SsxfCjI-j for ; Wed, 24 Mar 2010 16:17:52 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id A025B3A6830 for ; Wed, 24 Mar 2010 16:07:35 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NuZfx-00075n-US for ippm@ietf.org; Thu, 25 Mar 2010 00:07:55 +0100
Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=geir.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NuZfw-0002eA-VF for ippm@ietf.org; Thu, 25 Mar 2010 00:07:49 +0100
Message-ID: <4BAA9B40.6010802@ripe.net>
Date: Thu, 25 Mar 2010 00:07:44 +0100
From: Henk Uijterwaal 
Organization: RIPE NCC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: "ippm >> IETF IPPM WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5d1c051389aacf258c78b74a163180b96
X-RIPE-Spam-Level: ----
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5d1c051389aacf258c78b74a163180b96
Subject: [ippm] Proposal to make draft-geib-ippm-metrictest a working group document
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Mar 2010 23:17:58 -0000

IPPM Group,

We have been discussing draft-geib-ippm-metrictest for a number of meetings
by now and there appears to be considerable interest in this document.  We
propose to make this a working group document.  If you have any comments on
this, please post them to the list by April 12.

Matt & Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Nobody ever went broke underestimating the taste of the American public.
                                                                  H.L.Mencken

From henk@ripe.net  Wed Mar 24 16:18:30 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4653A6A56 for ; Wed, 24 Mar 2010 16:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.991
X-Spam-Level: 
X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=0.478,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 WlKAWGzGa6tV for ; Wed, 24 Mar 2010 16:18:29 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 473C23A6E24 for ; Wed, 24 Mar 2010 16:08:01 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NuZgN-000762-JO for ippm@ietf.org; Thu, 25 Mar 2010 00:08:20 +0100
Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=geir.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NuZgM-0002ew-BL for ippm@ietf.org; Thu, 25 Mar 2010 00:08:15 +0100
Message-ID: <4BAA9B5B.4020409@ripe.net>
Date: Thu, 25 Mar 2010 00:08:11 +0100
From: Henk Uijterwaal 
Organization: RIPE NCC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: IETF IPPM WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d588e295f5043dcaea3d6954183029dac5
X-RIPE-Spam-Level: ----
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d588e295f5043dcaea3d6954183029dac5
Subject: [ippm] Proposal to make draft-duffield-ippm-burst-loss-metrics-02 a working group document
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Mar 2010 23:18:31 -0000

IPPM Group,

We have been discussing draft-duffield-ippm-burst-loss-metrics for a number of
meetings by now and there appears to be considerable interest in this document.  We
propose to make this a working group document.  If you have any comments on
this, please post them to the list by April 12.

Matt & Henk

-- 
-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Nobody ever went broke underestimating the taste of the American public.
                                                                  H.L.Mencken

From henk@ripe.net  Wed Mar 24 16:42:25 2010
Return-Path: 
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6F33A69B3 for ; Wed, 24 Mar 2010 16:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.051
X-Spam-Level: 
X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=0.418,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 eq5litqv8dEc for ; Wed, 24 Mar 2010 16:42:24 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 63D383A6805 for ; Wed, 24 Mar 2010 16:42:24 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NuaDe-00084g-Jq for ippm@ietf.org; Thu, 25 Mar 2010 00:42:43 +0100
Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=dhcp-wireless-open-abg-26-148.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NuaDe-0001Un-9w for ippm@ietf.org; Thu, 25 Mar 2010 00:42:38 +0100
Message-ID: <4BAAA36C.2010805@ripe.net>
Date: Thu, 25 Mar 2010 00:42:36 +0100
From: Henk Uijterwaal 
Organization: RIPE NCC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: IETF IPPM WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5a0dc3a7f7ec691ed7bb97554e8ec825d
X-RIPE-Spam-Level: ----
X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5a0dc3a7f7ec691ed7bb97554e8ec825d
Subject: [ippm] WGLC for draft TWAMP Reflect Octets and Symmetrical Size Features
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, 24 Mar 2010 23:42:25 -0000

IPPM group,

This is a WGLC for the draft: TWAMP Reflect Octets and Symmetrical Size Features

The draft appears to to be stable and no issues have been raised.  We like to
start a WGLC in order to move it forward. Please raise any remaining issues by
Monday, April 19, 9:00 UTC

An URL for the draft is:

   http://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-reflect-octets/

Matt & Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Nobody ever went broke underestimating the taste of the American public.
                                                                  H.L.Mencken

From root@core3.amsl.com  Wed Mar 31 14:15:03 2010
Return-Path: 
X-Original-To: ippm@ietf.org
Delivered-To: ippm@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id B3CE13A689A; Wed, 31 Mar 2010 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: <20100331211502.B3CE13A689A@core3.amsl.com>
Date: Wed, 31 Mar 2010 14:15:02 -0700 (PDT)
Cc: ippm@ietf.org
Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-session-cntrl-05.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Mar 2010 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           : Individual Session Control Feature for TWAMP
	Author(s)       : A. Morton, M. Chiba
	Filename        : draft-ietf-ippm-twamp-session-cntrl-05.txt
	Pages           : 18
	Date            : 2010-03-31

The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol.  This memo describes an
OPTIONAL feature for TWAMP, that gives the controlling host the
ability to start and stop one or more individual test sessions using
Session Identifiers.  The base capability of the TWAMP protocol
requires all test sessions 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-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ippm-twamp-session-cntrl-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-03-31140554.I-D@ietf.org>


--NextPart--