From Xiangsong.Cui@huawei.com Mon May 2 20:45:14 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4669E068C for ; Mon, 2 May 2011 20:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=1.255, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44yfodQ6hjRN for ; Mon, 2 May 2011 20:45:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7618AE0659 for ; Mon, 2 May 2011 20:45:09 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKL00LYJP04AP@szxga05-in.huawei.com> for ippm@ietf.org; Tue, 03 May 2011 11:43:16 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKL00H43P03XK@szxga05-in.huawei.com> for ippm@ietf.org; Tue, 03 May 2011 11:43:16 +0800 (CST) Date: Tue, 03 May 2011 11:43:14 +0800 From: Xiangsong Cui In-reply-to: <4D9D7225.6080506@uijterwaal.nl> To: 'Henk Uijterwaal' , ippm@ietf.org Message-id: <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQ References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2011 03:45:14 -0000 Hi Henk, Sorry for the late comments. I take a quick look on this draft and have some comments. First, this draft seems like about capacity, e.g. path capacity, This memo describes the optional extensions to the standard TWAMP test protocol for identifying test sessions and packet trains, and for measuring capacity metrics like the available path capacity, tight section capacity and UDP throughput in the forward and reverse path directions. (copied from abstract) But, we all know that path is a unidirectional concept, so I don't understand, why we need the two-way test to measure the "path capacity"? Why not the one-way test? For example, in the ADSL/3G/4G/etc. network, the upstream path and downstream path provide different "capacity", how can the two-way test be applied? And what is the expected "path capacity" metric result in this approach? Second, the motivation of this draft, the first challenge is "The different trains within a session cannot be differentiated" (copied from minutes), and the draft reads "The controller (or the Session-Sender) requires a method for demultiplexing the received test packets to the correct test session especially when it manages multiple active test sessions. " where is the requirement from? Why the controller cannot set up multiple control sessions to manage the multiple test sessions separately? Third, section 3 reads, The packet interval between consecutive packets for each train sent by the Session-Sender and reflected by the Session-Reflector MUST be calculated and determined by the controller or an application or entity communicating with the controller. [...] The transmission time tt to send one packet (i.e. determined by the interface speed and the IP packet size) is also shown in the picture. Observe that the packet interval MUST be larger than or equal to tt. Why we need the two "MUST"? Section 3.6 of RFC5357 tells us: The send schedule for test packets defined in Section 3.6 of OWAMP [RFC4656] is not used in TWAMP. The Control-Client and Session- Sender MAY autonomously decide the send schedule. The Session- Reflector SHOULD return each test packet to the Session-Sender as quickly as possible. As a conclusion, I DISAGREE with it BEFORE I was told the answers. Best regards, Xiangsong > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Henk Uijterwaal > Sent: Thursday, April 07, 2011 4:13 PM > To: ippm@ietf.org > Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > IPPM group, > > In Prague, Steve and colleagues presented > draft-baillargeon-ippm-twamp-value-added-octets and asked if this can become > a > WG document. If you support > this idea or disagree with it, please speak up on the list before April 21. > > Henk (as WG chair) > > -- > ---------------------------------------------------------------------------- -- > Henk Uijterwaal Email: henk(at)uijterwaal.nl > RIPE NCC > http://www.xs4all.nl/~henku > Phone: +31.6.55861746 > ---------------------------------------------------------------------------- -- > > There appears to have been a collective retreat from reality that day. > (John Glanfield, on an engineering > project) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From christofer.flinta@ericsson.com Tue May 3 03:14:34 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E801FE07C2 for ; Tue, 3 May 2011 03:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsrWQMrJInlN for ; Tue, 3 May 2011 03:14:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 86448E0719 for ; Tue, 3 May 2011 03:14:33 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-d4-4dbfd588e677 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 14.21.28525.885DFBD4; Tue, 3 May 2011 12:14:32 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.118]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 3 May 2011 12:14:32 +0200 From: Christofer Flinta To: Xiangsong Cui , 'Henk Uijterwaal' , "ippm@ietf.org" Date: Tue, 3 May 2011 12:14:31 +0200 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49A= Message-ID: <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> In-Reply-To: <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2011 10:14:35 -0000 Hi Xiangsong, Thanks for your input. I will try to answer the questions in your first com= ment. This draft is trying to provide a means for measuring the capacity in both = the forward and reverse directions as two separate measurements. This is si= milar to the current capabilities of TWAMP, where e.g. delay and packet los= s can be measured separately in both directions. Our expected output would = thus be: Forward Capacity and Reverse Capacity. TWAMP in its currently form cannot provide capacity estimates separatly in = both directions. Today we may send trains of packets in the forward directi= on and have those packets reflected back to the sender by the reflector. Th= e send rate of each train in the forward direction can be controlled by the= sender, which is needed for all capacity measuring methods. However, the s= end rate of the reflected trains in the reverse direction cannot be control= led, since each packet is reflected back as soon as it arrives at the refle= ctor. Capacity estimates can therefore only be provided in the forward dire= ction in a current TWAMP system. The aim of this draft is to extend TWAMP with a mechanism that lets the ref= lector store the packets of a train and then send each train back at a spec= ific rate. This way the send rate can be controlled in both directions. I hope this gave some clarification. Christofer -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Xia= ngsong Cui Sent: den 3 maj 2011 05:43 To: 'Henk Uijterwaal'; ippm@ietf.org Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Hi Henk, Sorry for the late comments. I take a quick look on this draft and have some comments. First, this draft seems like about capacity, e.g. path capacity, This memo describes the optional extensions to the standard TWAMP test protocol for identifying test sessions and packet trains, and for measuring capacity metrics like the available path capacity, tight section capacity and UDP throughput in the forward and reverse path directions. (copied from abstract) But, we all know that path is a unidirectional concept, so I don't understa= nd, why we need the two-way test to measure the "path capacity"? Why not th= e one-way test? For example, in the ADSL/3G/4G/etc. network, the upstream p= ath and downstream path provide different "capacity", how can the two-way t= est be applied? And what is the expected "path capacity" metric result in t= his approach? Second, the motivation of this draft, the first challenge is "The different= trains within a session cannot be differentiated" (copied from minutes), a= nd the draft reads=20 "The controller (or the Session-Sender) requires a method for demultiplexing the received test packets to the correct test session especially when it manages multiple active test sessions. " where is the requirement from? Why the controller cannot set up multiple co= ntrol sessions to manage the multiple test sessions separately? Third, section 3 reads, The packet interval between consecutive packets for each train sent by the Session-Sender and reflected by the Session-Reflector MUST be calculated and determined by the controller or an application or entity communicating with the controller. [...] The transmission time tt to send one packet (i.e. determined by the interface speed and the IP packet size) is also shown in the picture. Observe that the packet interval MUST be larger than or equal to tt. Why we need the two "MUST"? Section 3.6 of RFC5357 tells us: The send schedule for test packets defined in Section 3.6 of OWAMP [RFC4656] is not used in TWAMP. The Control-Client and Session- Sender MAY autonomously decide the send schedule. The Session- Reflector SHOULD return each test packet to the Session-Sender as quickly as possible. As a conclusion, I DISAGREE with it BEFORE I was told the answers. Best regards, Xiangsong > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf=20 > Of Henk Uijterwaal > Sent: Thursday, April 07, 2011 4:13 PM > To: ippm@ietf.org > Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets >=20 > IPPM group, >=20 > In Prague, Steve and colleagues presented=20 > draft-baillargeon-ippm-twamp-value-added-octets and asked if this can become > a > WG document. If you support > this idea or disagree with it, please speak up on the list before=20 > April 21. >=20 > Henk (as WG chair) >=20 > -- > ---------------------------------------------------------------------------= - -- > Henk Uijterwaal Email: henk(at)uijterwaal.nl > RIPE NCC > http://www.xs4all.nl/~henku > Phone: +31.6.55861746 > ---------------------------------------------------------------------------= - -- >=20 > There appears to have been a collective retreat from reality that day. > (John Glanfield, on an engineering > project) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From svante.ekelin@ericsson.com Tue May 3 07:23:24 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43942E06A8 for ; Tue, 3 May 2011 07:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hXX2utlkcwt for ; Tue, 3 May 2011 07:23:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0346DE0684 for ; Tue, 3 May 2011 07:23:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-85-4dc00fd44575 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.90.11171.4DF00CD4; Tue, 3 May 2011 16:23:16 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.118]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 3 May 2011 16:23:15 +0200 From: Svante Ekelin To: Christofer Flinta , Xiangsong Cui , 'Henk Uijterwaal' , "ippm@ietf.org" Date: Tue, 3 May 2011 16:21:13 +0200 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49AABVqFgA== Message-ID: <8CFFCC2A92732A4E9EA6063EE5C4217916ABD1BFB9@ESESSCMS0361.eemea.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2011 14:23:24 -0000 Hi Xiangsong, Christofer already answered your first comment, and I will try to answer th= e questions in the other two comments you made. As noted below by Christofer, an aim of this draft is extending TWAMP to pr= ovide a mechanism which will allow capacity measurement in both the forward= and reverse path, by transmitting test packets as a train at a specified r= ate in the forward path, and then reflected as a train with another specifi= ed rate in the reverse path. So, with regard to your second comment, as the controller (or the Session-S= ender) may be engaged in multiple concurrent measurement sessions, it needs= to be able to identify to which session a reflected test packet belongs, i= .e. demultiplexing. As for the third comment, the first MUST is due to the fact that the contro= ller needs to be able to specify the rate of the train in the reverse path.= As you quote from RFC5357, the send schedule for test packets is not used = in the baseline TWAMP. The same is true for the new proposed TWAMP mode. Th= e MAY statement in RFC5357 regarding the autonomous decision on the send sc= hedule at the source is not in conflict with the MUST statement in the draf= t. For instance, the actual inter-packet interval may be autonomously decid= ed by the Control-Client and Session-Sender, or it may be done by another n= ode or application, but the decision MUST be known at the source since the = destination (e.g Session-Reflector) is only reflecting the test packets at = the specified rate. The second MUST is simply a statement of the size relation between the pack= et interval and the transmission time tt, as is illustrated in the picture = on page 5 of the draft. Hope this helps, -- Svante -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Chr= istofer Flinta Sent: den 3 maj 2011 12:15 To: Xiangsong Cui; 'Henk Uijterwaal'; ippm@ietf.org Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Hi Xiangsong, Thanks for your input. I will try to answer the questions in your first com= ment. This draft is trying to provide a means for measuring the capacity in both = the forward and reverse directions as two separate measurements. This is si= milar to the current capabilities of TWAMP, where e.g. delay and packet los= s can be measured separately in both directions. Our expected output would = thus be: Forward Capacity and Reverse Capacity. TWAMP in its currently form cannot provide capacity estimates separatly in = both directions. Today we may send trains of packets in the forward directi= on and have those packets reflected back to the sender by the reflector. Th= e send rate of each train in the forward direction can be controlled by the= sender, which is needed for all capacity measuring methods. However, the s= end rate of the reflected trains in the reverse direction cannot be control= led, since each packet is reflected back as soon as it arrives at the refle= ctor. Capacity estimates can therefore only be provided in the forward dire= ction in a current TWAMP system. The aim of this draft is to extend TWAMP with a mechanism that lets the ref= lector store the packets of a train and then send each train back at a spec= ific rate. This way the send rate can be controlled in both directions. I hope this gave some clarification. Christofer -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Xia= ngsong Cui Sent: den 3 maj 2011 05:43 To: 'Henk Uijterwaal'; ippm@ietf.org Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Hi Henk, Sorry for the late comments. I take a quick look on this draft and have some comments. First, this draft seems like about capacity, e.g. path capacity, This memo describes the optional extensions to the standard TWAMP test protocol for identifying test sessions and packet trains, and for measuring capacity metrics like the available path capacity, tight section capacity and UDP throughput in the forward and reverse path directions. (copied from abstract) But, we all know that path is a unidirectional concept, so I don't understa= nd, why we need the two-way test to measure the "path capacity"? Why not th= e one-way test? For example, in the ADSL/3G/4G/etc. network, the upstream p= ath and downstream path provide different "capacity", how can the two-way t= est be applied? And what is the expected "path capacity" metric result in t= his approach? Second, the motivation of this draft, the first challenge is "The different= trains within a session cannot be differentiated" (copied from minutes), a= nd the draft reads=20 "The controller (or the Session-Sender) requires a method for demultiplexing the received test packets to the correct test session especially when it manages multiple active test sessions. " where is the requirement from? Why the controller cannot set up multiple co= ntrol sessions to manage the multiple test sessions separately? Third, section 3 reads, The packet interval between consecutive packets for each train sent by the Session-Sender and reflected by the Session-Reflector MUST be calculated and determined by the controller or an application or entity communicating with the controller. [...] The transmission time tt to send one packet (i.e. determined by the interface speed and the IP packet size) is also shown in the picture. Observe that the packet interval MUST be larger than or equal to tt. Why we need the two "MUST"? Section 3.6 of RFC5357 tells us: The send schedule for test packets defined in Section 3.6 of OWAMP [RFC4656] is not used in TWAMP. The Control-Client and Session- Sender MAY autonomously decide the send schedule. The Session- Reflector SHOULD return each test packet to the Session-Sender as quickly as possible. As a conclusion, I DISAGREE with it BEFORE I was told the answers. Best regards, Xiangsong > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf=20 > Of Henk Uijterwaal > Sent: Thursday, April 07, 2011 4:13 PM > To: ippm@ietf.org > Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets >=20 > IPPM group, >=20 > In Prague, Steve and colleagues presented=20 > draft-baillargeon-ippm-twamp-value-added-octets and asked if this can become > a > WG document. If you support > this idea or disagree with it, please speak up on the list before=20 > April 21. >=20 > Henk (as WG chair) >=20 > -- > ---------------------------------------------------------------------------= - -- > Henk Uijterwaal Email: henk(at)uijterwaal.nl > RIPE NCC > http://www.xs4all.nl/~henku > Phone: +31.6.55861746 > ---------------------------------------------------------------------------= - -- >=20 > There appears to have been a collective retreat from reality that day. > (John Glanfield, on an engineering > project) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Tue May 3 18:29:02 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EA4E0772 for ; Tue, 3 May 2011 18:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=3.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw1Y6GCt1otc for ; Tue, 3 May 2011 18:29:01 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9941EE0618 for ; Tue, 3 May 2011 18:29:00 -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 <0LKN00IPJDG5PN@szxga04-in.huawei.com> for ippm@ietf.org; Wed, 04 May 2011 09:28:54 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKN00J5XDG5CG@szxga04-in.huawei.com> for ippm@ietf.org; Wed, 04 May 2011 09:28:53 +0800 (CST) Date: Wed, 04 May 2011 09:28:52 +0800 From: Xiangsong Cui In-reply-to: <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> To: 'Christofer Flinta' , 'Henk Uijterwaal' , ippm@ietf.org Message-id: <009901cc09fa$a0d77310$e2865930$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49AAHnPYkA== References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2011 01:29:02 -0000 Hi Christofer, Thanks for your reply, please see my comments inline. > -----Original Message----- > From: Christofer Flinta [mailto:christofer.flinta@ericsson.com] > Sent: Tuesday, May 03, 2011 6:15 PM > To: Xiangsong Cui; 'Henk Uijterwaal'; ippm@ietf.org > Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > Hi Xiangsong, > > Thanks for your input. I will try to answer the questions in your first comment. > > This draft is trying to provide a means for measuring the capacity in both the > forward and reverse directions as two separate measurements. This is similar > to the current capabilities of TWAMP, where e.g. delay and packet loss can be > measured separately in both directions. No, I don't think they are similar, because, round-trip delay, which is a metric defined in RFC2681, is a "metric", however, we have no any definition on "round-trip path capacity" metric, right? What is more important, the round-trip delay metric is meaningful, for example, in TCP, the TCP sender depends on the ACK clock to increase its window, which is very relevant to the RTT metric. But what is the meaning of round-trip path capacity metric? Our expected output would thus be: > Forward Capacity and Reverse Capacity. Yes, I do know your expectation, you are expecting Forward Capacity /and/ Reverse Capacity, you are not needing the capacity of "Forward Capacity /plus/ Reverse Capacity". Why you not utilize the one-way test on forward path and reverse path? Why you have to couple the two independent metrics together, and use the two-way test to cover the two one-way metrics? > > TWAMP in its currently form cannot provide capacity estimates separatly in > both directions. Yes, I think you are right on this sentence. But I think you are using the wrong tool here, the same question, why you like to use TWAMP for metrics "separately in both directions", why not OWAMP "separately in both directions"? Today we may send trains of packets in the forward direction > and have those packets reflected back to the sender by the reflector. The send > rate of each train in the forward direction can be controlled by the sender, > which is needed for all capacity measuring methods. However, the send rate of > the reflected trains in the reverse direction cannot be controlled, since each > packet is reflected back as soon as it arrives at the reflector. Yes, and I guess this is the intention of RFC5357's co-authors (or IPPM WG), there is no MUST or SHOULD, and RFC5357 reads "In the case of TWAMP Light, the Session-Reflector does not necessarily have knowledge of the session state" (Note this statement is from informative appendix). Capacity > estimates can therefore only be provided in the forward direction in a current > TWAMP system. I think this is just because we only have one-way capacity (if you are talking about capacity metric defined in RFC5136). > > The aim of this draft is to extend TWAMP with a mechanism that lets the > reflector store the packets of a train and then send each train back at a specific > rate. It seems you are changing the session-reflector to "session-receiver plus session-sender", right? This way the send rate can be controlled in both directions. But the paths in the two directions are different and independent. And TWAMP is not equal to "local OWAMP plus remote OWAMP", I think. Best regards, Xiangsong > > > I hope this gave some clarification. > Christofer > > > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Xiangsong Cui > Sent: den 3 maj 2011 05:43 > To: 'Henk Uijterwaal'; ippm@ietf.org > Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > Hi Henk, > > Sorry for the late comments. > > I take a quick look on this draft and have some comments. > > First, this draft seems like about capacity, e.g. path capacity, > This memo describes the optional extensions to the standard TWAMP > test protocol for identifying test sessions and packet trains, and > for measuring capacity metrics like the available path capacity, > tight section capacity and UDP throughput in the forward and reverse > path directions. (copied from abstract) > > But, we all know that path is a unidirectional concept, so I don't understand, > why we need the two-way test to measure the "path capacity"? Why not the > one-way test? For example, in the ADSL/3G/4G/etc. network, the upstream > path and downstream path provide different "capacity", how can the two-way > test be applied? And what is the expected "path capacity" metric result in this > approach? > > > Second, the motivation of this draft, the first challenge is "The different trains > within a session cannot be differentiated" (copied from minutes), and the draft > reads > "The controller (or the Session-Sender) requires a method for > demultiplexing the received test packets to the correct test session > especially when it manages multiple active test sessions. " > > where is the requirement from? Why the controller cannot set up multiple > control sessions to manage the multiple test sessions separately? > > > Third, section 3 reads, > > The packet interval between consecutive packets for each train sent > by the Session-Sender and reflected by the Session-Reflector MUST be > calculated and determined by the controller or an application or > entity communicating with the controller. [...] > > The transmission time tt to send one packet (i.e. determined by the > interface speed and the IP packet size) is also shown in the picture. > Observe that the packet interval MUST be larger than or equal to tt. > > Why we need the two "MUST"? Section 3.6 of RFC5357 tells us: > > The send schedule for test packets defined in Section 3.6 of OWAMP > [RFC4656] is not used in TWAMP. The Control-Client and Session- > Sender MAY autonomously decide the send schedule. The Session- > Reflector SHOULD return each test packet to the Session-Sender as > quickly as possible. > > > As a conclusion, I DISAGREE with it BEFORE I was told the answers. > > Best regards, > Xiangsong > > > > -----Original Message----- > > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf > > Of Henk Uijterwaal > > Sent: Thursday, April 07, 2011 4:13 PM > > To: ippm@ietf.org > > Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > > IPPM group, > > > > In Prague, Steve and colleagues presented > > draft-baillargeon-ippm-twamp-value-added-octets and asked if this can > become > > a > > WG document. If you support > > this idea or disagree with it, please speak up on the list before > > April > 21. > > > > Henk (as WG chair) > > > > -- > > > ---------------------------------------------------------------------------- > -- > > Henk Uijterwaal Email: henk(at)uijterwaal.nl > > RIPE NCC > > http://www.xs4all.nl/~henku > > Phone: +31.6.55861746 > > > ---------------------------------------------------------------------------- > -- > > > > There appears to have been a collective retreat from reality that day. > > (John Glanfield, on an engineering > > project) > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Tue May 3 18:33:09 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBC8E0772 for ; Tue, 3 May 2011 18:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMHrysCe0w33 for ; Tue, 3 May 2011 18:33:08 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id EF465E0693 for ; Tue, 3 May 2011 18:33:07 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN00GFZDN4V7@szxga05-in.huawei.com> for ippm@ietf.org; Wed, 04 May 2011 09:33:04 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKN006THDN11D@szxga05-in.huawei.com> for ippm@ietf.org; Wed, 04 May 2011 09:33:04 +0800 (CST) Date: Wed, 04 May 2011 09:33:01 +0800 From: Xiangsong Cui In-reply-to: <8CFFCC2A92732A4E9EA6063EE5C4217916ABD1BFB9@ESESSCMS0361.eemea.ericsson.se> To: 'Svante Ekelin' , 'Christofer Flinta' , 'Henk Uijterwaal' , ippm@ietf.org Message-id: <009a01cc09fb$362e5870$a28b0950$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49AABVqFgAAazhfA References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> <8CFFCC2A92732A4E9EA6063EE5C4217916ABD1BFB9@ESESSCMS0361.eemea.ericsson.se> Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2011 01:33:09 -0000 Hi Svante, Thanks for your reply, too. I would like to discuss these issues one by one, imho if the rationale is incorrect we needn't to waste time on the details. Best regards, Xiangsong > -----Original Message----- > From: Svante Ekelin [mailto:svante.ekelin@ericsson.com] > Sent: Tuesday, May 03, 2011 10:21 PM > To: Christofer Flinta; Xiangsong Cui; 'Henk Uijterwaal'; ippm@ietf.org > Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > Hi Xiangsong, > > Christofer already answered your first comment, and I will try to answer the > questions in the other two comments you made. > > As noted below by Christofer, an aim of this draft is extending TWAMP to > provide a mechanism which will allow capacity measurement in both the > forward and reverse path, by transmitting test packets as a train at a specified > rate in the forward path, and then reflected as a train with another specified > rate in the reverse path. > > So, with regard to your second comment, as the controller (or the > Session-Sender) may be engaged in multiple concurrent measurement sessions, > it needs to be able to identify to which session a reflected test packet belongs, > i.e. demultiplexing. > > As for the third comment, the first MUST is due to the fact that the controller > needs to be able to specify the rate of the train in the reverse path. As you > quote from RFC5357, the send schedule for test packets is not used in the > baseline TWAMP. The same is true for the new proposed TWAMP mode. The > MAY statement in RFC5357 regarding the autonomous decision on the send > schedule at the source is not in conflict with the MUST statement in the draft. > For instance, the actual inter-packet interval may be autonomously decided by > the Control-Client and Session-Sender, or it may be done by another node or > application, but the decision MUST be known at the source since the > destination (e.g Session-Reflector) is only reflecting the test packets at the > specified rate. > > The second MUST is simply a statement of the size relation between the packet > interval and the transmission time tt, as is illustrated in the picture on page 5 > of the draft. > > Hope this helps, > -- Svante > > > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Christofer Flinta > Sent: den 3 maj 2011 12:15 > To: Xiangsong Cui; 'Henk Uijterwaal'; ippm@ietf.org > Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > Hi Xiangsong, > > Thanks for your input. I will try to answer the questions in your first comment. > > This draft is trying to provide a means for measuring the capacity in both the > forward and reverse directions as two separate measurements. This is similar > to the current capabilities of TWAMP, where e.g. delay and packet loss can be > measured separately in both directions. Our expected output would thus be: > Forward Capacity and Reverse Capacity. > > TWAMP in its currently form cannot provide capacity estimates separatly in > both directions. Today we may send trains of packets in the forward direction > and have those packets reflected back to the sender by the reflector. The send > rate of each train in the forward direction can be controlled by the sender, > which is needed for all capacity measuring methods. However, the send rate of > the reflected trains in the reverse direction cannot be controlled, since each > packet is reflected back as soon as it arrives at the reflector. Capacity > estimates can therefore only be provided in the forward direction in a current > TWAMP system. > > The aim of this draft is to extend TWAMP with a mechanism that lets the > reflector store the packets of a train and then send each train back at a specific > rate. This way the send rate can be controlled in both directions. > > > I hope this gave some clarification. > Christofer > > > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Xiangsong Cui > Sent: den 3 maj 2011 05:43 > To: 'Henk Uijterwaal'; ippm@ietf.org > Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > Hi Henk, > > Sorry for the late comments. > > I take a quick look on this draft and have some comments. > > First, this draft seems like about capacity, e.g. path capacity, > This memo describes the optional extensions to the standard TWAMP > test protocol for identifying test sessions and packet trains, and > for measuring capacity metrics like the available path capacity, > tight section capacity and UDP throughput in the forward and reverse > path directions. (copied from abstract) > > But, we all know that path is a unidirectional concept, so I don't understand, > why we need the two-way test to measure the "path capacity"? Why not the > one-way test? For example, in the ADSL/3G/4G/etc. network, the upstream > path and downstream path provide different "capacity", how can the two-way > test be applied? And what is the expected "path capacity" metric result in this > approach? > > > Second, the motivation of this draft, the first challenge is "The different trains > within a session cannot be differentiated" (copied from minutes), and the draft > reads > "The controller (or the Session-Sender) requires a method for > demultiplexing the received test packets to the correct test session > especially when it manages multiple active test sessions. " > > where is the requirement from? Why the controller cannot set up multiple > control sessions to manage the multiple test sessions separately? > > > Third, section 3 reads, > > The packet interval between consecutive packets for each train sent > by the Session-Sender and reflected by the Session-Reflector MUST be > calculated and determined by the controller or an application or > entity communicating with the controller. [...] > > The transmission time tt to send one packet (i.e. determined by the > interface speed and the IP packet size) is also shown in the picture. > Observe that the packet interval MUST be larger than or equal to tt. > > Why we need the two "MUST"? Section 3.6 of RFC5357 tells us: > > The send schedule for test packets defined in Section 3.6 of OWAMP > [RFC4656] is not used in TWAMP. The Control-Client and Session- > Sender MAY autonomously decide the send schedule. The Session- > Reflector SHOULD return each test packet to the Session-Sender as > quickly as possible. > > > As a conclusion, I DISAGREE with it BEFORE I was told the answers. > > Best regards, > Xiangsong > > > > -----Original Message----- > > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf > > Of Henk Uijterwaal > > Sent: Thursday, April 07, 2011 4:13 PM > > To: ippm@ietf.org > > Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > > IPPM group, > > > > In Prague, Steve and colleagues presented > > draft-baillargeon-ippm-twamp-value-added-octets and asked if this can > become > > a > > WG document. If you support > > this idea or disagree with it, please speak up on the list before > > April > 21. > > > > Henk (as WG chair) > > > > -- > > > ---------------------------------------------------------------------------- > -- > > Henk Uijterwaal Email: henk(at)uijterwaal.nl > > RIPE NCC > > http://www.xs4all.nl/~henku > > Phone: +31.6.55861746 > > > ---------------------------------------------------------------------------- > -- > > > > There appears to have been a collective retreat from reality that day. > > (John Glanfield, on an engineering > > project) > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Tue May 3 19:08:53 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ABFE0723 for ; Tue, 3 May 2011 19:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.755 X-Spam-Level: X-Spam-Status: No, score=-3.755 tagged_above=-999 required=5 tests=[AWL=2.844, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUJowB8AAbhS for ; Tue, 3 May 2011 19:08:52 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1577CE06AC for ; Tue, 3 May 2011 19:08:48 -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 <0LKN001KKFAFSI@szxga04-in.huawei.com> for ippm@ietf.org; Wed, 04 May 2011 10:08:39 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKN001WKFAEDZ@szxga04-in.huawei.com> for ippm@ietf.org; Wed, 04 May 2011 10:08:39 +0800 (CST) Date: Wed, 04 May 2011 10:08:38 +0800 From: Xiangsong Cui In-reply-to: <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> To: 'Christofer Flinta' , 'Henk Uijterwaal' , ippm@ietf.org Message-id: <00af01cc0a00$2ebf79c0$8c3e6d40$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49AAIV9eMA== References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2011 02:08:53 -0000 > This draft is trying to provide a means for measuring the capacity in both the > forward and reverse directions as two separate measurements. This is similar > to the current capabilities of TWAMP, where e.g. delay and packet loss can be > measured separately in both directions. If you are referring to one-way metric, e.g. one-way packet loss, how can you get the one-way metric by the two-way test? That said, how can the session-sender get to know whether the packet is lost before or after the session-reflector? Regards, Xiangsong From andreas.a.johnsson@ericsson.com Fri May 6 07:54:08 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE543E0747 for ; Fri, 6 May 2011 07:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCls2ysm876Z for ; Fri, 6 May 2011 07:54:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3821AE06EA for ; Fri, 6 May 2011 07:54:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-27-4dc40b8ed768 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.B6.11171.E8B04CD4; Fri, 6 May 2011 16:54:06 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.2.67]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 6 May 2011 16:54:05 +0200 From: Andreas Johnsson A To: 'Xiangsong Cui' , Christofer Flinta , 'Henk Uijterwaal' , "ippm@ietf.org" Date: Fri, 6 May 2011 16:54:05 +0200 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49AAIV9eMAB/agWQ Message-ID: <3B05069A569E6F4AB6397B968734EBEA196F7FB77A@ESESSCMS0363.eemea.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> <00af01cc0a00$2ebf79c0$8c3e6d40$%cui@huawei.com> In-Reply-To: <00af01cc0a00$2ebf79c0$8c3e6d40$%cui@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2011 14:54:08 -0000 Hi Xiangsong, We are drifting away from the topic here. What we want to do is to include = functionality in the TWAMP spec for measuring available capacity in both th= e forward and reverse direction. This interest was also raised by for examp= le Al and Yaakov (maybe throughput was the main idea here?). The problems w= ith loss measurements are outside the scope of this discussion, but do belo= ng to draft-ietf-ippm-rt-loss-00 by Al. There seem to be a little bit of confusion when it comes to TWAMP. As you k= now, TWAMP time stamps packets when a packet is sent at the session sender,= when it is received at the reflector, when it is sent by the reflector and= when it is again received by the session sender. From this it is very easy= to deduct forward and reverse delay, and with our proposal also forward an= d reverse available capacity. Sure, OWAMP can be used to do these measureme= nts, but the intention with TWAMP is to perform both measurements in both d= irections (and round trip) with only one trigger. I think this is a strong = argument for trying to put new functionality into TWAMP and not only focus = on OWAMP. I hope this resolves any issues you have with the intention with our draft,= although maybe the draft needs to be enhanced or split into several. Sugge= stions are welcome. Best regards Andreas Johnsson=20 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Xia= ngsong Cui Sent: Wednesday, May 04, 2011 4:09 AM To: Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > This draft is trying to provide a means for measuring the capacity in=20 > both the > forward and reverse directions as two separate measurements. This is similar > to the current capabilities of TWAMP, where e.g. delay and packet loss=20 > can be > measured separately in both directions.=20 If you are referring to one-way metric, e.g. one-way packet loss, how can y= ou get the one-way metric by the two-way test? That said, how can the session-sender get to know whether the packet is los= t before or after the session-reflector? Regards, Xiangsong _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Mon May 9 18:47:32 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BA5E06F1 for ; Mon, 9 May 2011 18:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=1.602, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X20Yzy8+11sv for ; Mon, 9 May 2011 18:47:31 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 62B47E069B for ; Mon, 9 May 2011 18:47:31 -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 <0LKY005MBIB4KX@szxga04-in.huawei.com> for ippm@ietf.org; Tue, 10 May 2011 09:47:28 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKY00BBOIB3P8@szxga04-in.huawei.com> for ippm@ietf.org; Tue, 10 May 2011 09:47:28 +0800 (CST) Date: Tue, 10 May 2011 09:47:27 +0800 From: Xiangsong Cui In-reply-to: <3B05069A569E6F4AB6397B968734EBEA196F7FB77A@ESESSCMS0363.eemea.ericsson.se> To: 'Andreas Johnsson A' , 'Christofer Flinta' , 'Henk Uijterwaal' , ippm@ietf.org Message-id: <019801cc0eb4$37ddb2c0$a7991840$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49AAIV9eMAB/agWQAKvJoxA= References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> <00af01cc0a00$2ebf79c0$8c3e6d40$%cui@huawei.com> <3B05069A569E6F4AB6397B968734EBEA196F7FB77A@ESESSCMS0363.eemea.ericsson.se> Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:47:32 -0000 Hi Andreas, Please see my comments below. > -----Original Message----- > From: Andreas Johnsson A [mailto:andreas.a.johnsson@ericsson.com] > Sent: Friday, May 06, 2011 10:54 PM > To: 'Xiangsong Cui'; Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org > Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > Hi Xiangsong, > We are drifting away from the topic here. What we want to do is to include > functionality in the TWAMP spec for measuring available capacity in both the > forward and reverse direction. This interest was also raised by for example Al > and Yaakov (maybe throughput was the main idea here?). I think this is not the problem we are talking about, I'm OK with this interest (i.e., measuring available capacity in both the forward and reverse direction), my concern is I don't think the approach of TWAMP extension to one-way metric is OK. The problems with > loss measurements are outside the scope of this discussion, but do belong to > draft-ietf-ippm-rt-loss-00 by Al. Yes, I agree with you, and I believe you can find that it's not me bringing "packet loss" into this discussion. > > There seem to be a little bit of confusion when it comes to TWAMP. As you > know, TWAMP time stamps packets when a packet is sent at the session > sender, when it is received at the reflector, when it is sent by the reflector and > when it is again received by the session sender. From this it is very easy to > deduct forward and reverse delay, and with our proposal also forward and > reverse available capacity. Sure, OWAMP can be used to do these > measurements, but the intention with TWAMP is to perform both > measurements in both directions (and round trip) with only one trigger. I think > this is a strong argument for trying to put new functionality into TWAMP and > not only focus on OWAMP. I'm not sure what the "trigger" means here, but I'm sure that the both entities (source node and destination node) in this approach need to be modified. But if we can do this by existing protocols, why we need the protocol modification? > > I hope this resolves any issues you have with the intention with our draft, > although maybe the draft needs to be enhanced or split into several. > Suggestions are welcome. I would like to suggest applying TWAMP to two-way metrics and ONLY to two-way metrics, at the same time, applying OWAMP to one-way metrics. As to this specific requirement of measuring available capacity in both the forward and reverse direction, since RFC5357 tells us: " OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. " And RFC4656 tells us: "Several roles are logically separated to allow for broad flexibility in use." and, "Different logical roles can be played by the same host. " I think this is ONLY a protocol deployment business, it not worth a protocol change or extension. And based on your concern of "Controlling the measurement at one point", my proposal is: +--------------------------------+ +------------------------------+ | Node A | | Node B | | +---------------------------+ | | +--------------------------+ | | | Forward-Control-Client |<--Forward-OWAMP-Control-->| Forward-Server | | | | Forward-Fetch-Client | | | | | | Forward-Session-Sender |---Forward-OWAMP-Test----->| Forward-Session-Receiver | | | +---------------------------+ | | +--------------------------+ | | | | | | +---------------------------+ | | +--------------------------+ | | | Reverse-Control-Client |<--Reverse-OWAMP-Control-->| Reverse-Server | | | | Reverse-Fetch-Client | | | | | | Reverse-Session-Receiver |<--Reverse-OWAMP-Test------| Reverse-Session-Receiver | | | +---------------------------+ | | +--------------------------+ | | | | | +--------------------------------+ +------------------------------+ Node A now is fully the controller of the measurement, can this achieve the capacity measurement in both the forward and reverse direction? Best regards, Xiangsong > > Best regards > Andreas Johnsson > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Xiangsong Cui > Sent: Wednesday, May 04, 2011 4:09 AM > To: Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org > Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > > This draft is trying to provide a means for measuring the capacity in > > both > the > > forward and reverse directions as two separate measurements. This is > similar > > to the current capabilities of TWAMP, where e.g. delay and packet loss > > can > be > > measured separately in both directions. > > If you are referring to one-way metric, e.g. one-way packet loss, how can you > get the one-way metric by the two-way test? > That said, how can the session-sender get to know whether the packet is lost > before or after the session-reflector? > > Regards, > Xiangsong > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From Xiangsong.Cui@huawei.com Mon May 9 18:55:45 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1F4E0739 for ; Mon, 9 May 2011 18:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q0XgI8q6uKH for ; Mon, 9 May 2011 18:55:44 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E02D9E06B7 for ; Mon, 9 May 2011 18:55:43 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKY00DZPIOTXD@szxga05-in.huawei.com> for ippm@ietf.org; Tue, 10 May 2011 09:55:41 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKY00K2WIOPZP@szxga05-in.huawei.com> for ippm@ietf.org; Tue, 10 May 2011 09:55:40 +0800 (CST) Date: Tue, 10 May 2011 09:55:37 +0800 From: Xiangsong Cui In-reply-to: <3B05069A569E6F4AB6397B968734EBEA196F7FB77A@ESESSCMS0363.eemea.ericsson.se> To: 'Andreas Johnsson A' , 'Christofer Flinta' , 'Henk Uijterwaal' , ippm@ietf.org Message-id: <019f01cc0eb5$5d34e9c0$179ebd40$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49AAIV9eMAB/agWQAK3911A= References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> <00af01cc0a00$2ebf79c0$8c3e6d40$%cui@huawei.com> <3B05069A569E6F4AB6397B968734EBEA196F7FB77A@ESESSCMS0363.eemea.ericsson.se> Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:55:45 -0000 Sorry, there is a typo in my previous mail, My proposal should be: +--------------------------------+ +------------------------------+ | Node A | | Node B | | +---------------------------+ | | +--------------------------+ | | | Forward-Control-Client |<--Forward-OWAMP-Control-->| Forward-Server | | | | Forward-Fetch-Client | | | | | | Forward-Session-Sender |---Forward-OWAMP-Test----->| Forward-Session-Receiver | | | +---------------------------+ | | +--------------------------+ | | | | | | +---------------------------+ | | +--------------------------+ | | | Reverse-Control-Client |<--Reverse-OWAMP-Control-->| Reverse-Server | | | | Reverse-Fetch-Client | | | | | | Reverse-Session-Receiver |<--Reverse-OWAMP-Test------| Reverse-Session-Sender | | | +---------------------------+ | | +--------------------------+ | | | | | +--------------------------------+ +------------------------------+ Regards, Xiangsong > -----Original Message----- > From: Andreas Johnsson A [mailto:andreas.a.johnsson@ericsson.com] > Sent: Friday, May 06, 2011 10:54 PM > To: 'Xiangsong Cui'; Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org > Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > Hi Xiangsong, > We are drifting away from the topic here. What we want to do is to include > functionality in the TWAMP spec for measuring available capacity in both the > forward and reverse direction. This interest was also raised by for example Al > and Yaakov (maybe throughput was the main idea here?). The problems with > loss measurements are outside the scope of this discussion, but do belong to > draft-ietf-ippm-rt-loss-00 by Al. > > There seem to be a little bit of confusion when it comes to TWAMP. As you > know, TWAMP time stamps packets when a packet is sent at the session > sender, when it is received at the reflector, when it is sent by the reflector and > when it is again received by the session sender. From this it is very easy to > deduct forward and reverse delay, and with our proposal also forward and > reverse available capacity. Sure, OWAMP can be used to do these > measurements, but the intention with TWAMP is to perform both > measurements in both directions (and round trip) with only one trigger. I think > this is a strong argument for trying to put new functionality into TWAMP and > not only focus on OWAMP. > > I hope this resolves any issues you have with the intention with our draft, > although maybe the draft needs to be enhanced or split into several. > Suggestions are welcome. > > Best regards > Andreas Johnsson > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Xiangsong Cui > Sent: Wednesday, May 04, 2011 4:09 AM > To: Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org > Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > > This draft is trying to provide a means for measuring the capacity in > > both > the > > forward and reverse directions as two separate measurements. This is > similar > > to the current capabilities of TWAMP, where e.g. delay and packet loss > > can > be > > measured separately in both directions. > > If you are referring to one-way metric, e.g. one-way packet loss, how can you > get the one-way metric by the two-way test? > That said, how can the session-sender get to know whether the packet is lost > before or after the session-reflector? > > Regards, > Xiangsong > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From henk@uijterwaal.nl Tue May 10 01:18:51 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F86CE071E for ; Tue, 10 May 2011 01:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDfXfG2T+0M8 for ; Tue, 10 May 2011 01:18:50 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id 89011E06D3 for ; Tue, 10 May 2011 01:18:50 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id p4A8IHw8024283 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 10:18:18 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4DC8F4C9.6090307@uijterwaal.nl> Date: Tue, 10 May 2011 10:18:17 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF IPPM WG , Stanislav Shalunov , Martin Swany References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> <4D9C23B1.8040205@uijterwaal.nl> <4DAE8E72.9020909@uijterwaal.nl> <4DB95269.9090102@uijterwaal.nl> In-Reply-To: <4DB95269.9090102@uijterwaal.nl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [ippm] End of WGLC for draft-ietf-ippm-reporting-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 08:18:51 -0000 On 28/04/2011 13:41, Henk Uijterwaal wrote: > Stas and Martin, > > Please take a look at this. Any progress??? Henk > > Henk > > > On 20/04/2011 09:42, Henk Uijterwaal wrote: >> IPPM group, >> >>> As discussed in Prague, this starts a WGLC for the draft: >>> >>> Reporting IP Performance Metrics to Users >>> draft-ietf-ippm-reporting-06.txt >>> >>> Please review the draft and raise any issues by Wednesday, April 20, 8:00 UTC. >>> An URL for the draft is: >>> >>> http://datatracker.ietf.org/doc/draft-ietf-ippm-reporting/?include_text=1 >> >> The WGLC just ended. There were a few issues raised by Steve Baillargeon. >> Authors: please answer this mail in the next days and submit an -07 if >> needed. >> >> Henk >> >> > > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Tue May 10 01:40:04 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40540E0780 for ; Tue, 10 May 2011 01:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.282 X-Spam-Level: X-Spam-Status: No, score=-0.282 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EZgEtBiuYMD for ; Tue, 10 May 2011 01:40:03 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 46075E076E for ; Tue, 10 May 2011 01:40:02 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id p4A8dUfU045060 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 10:39:30 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4DC8F9C1.2090705@uijterwaal.nl> Date: Tue, 10 May 2011 10:39:29 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Steve Baillargeon References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4DB95371.4070905@uijterwaal.nl> <4383945B8C24AA4FBC33555BB7B829EF0DECEDEDDD@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DECEDEDDD@EUSAACMS0701.eamcs.ericsson.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: IETF IPPM WG Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 08:40:04 -0000 (Catching up on this) On 28/04/2011 14:52, Steve Baillargeon wrote: > Hi The draft proposes to enhance the TWAMP control protocol with a new mode > and add the less possible set of new fields to the TWAMP test packets. The > objective is to allow a single test session of a given type-P to measure > capacity metrics over time on a given path using any capacity estimation > methods. Can someone tell me if there is anything wrong with such goal? No, not at all and I did not want to imply this. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From christofer.flinta@ericsson.com Tue May 10 06:18:05 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B13E07AC for ; Tue, 10 May 2011 06:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwcWMAPLd+1u for ; Tue, 10 May 2011 06:18:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 087B0E0797 for ; Tue, 10 May 2011 06:18:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-37-4dc93b0929a6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 92.C5.11171.90B39CD4; Tue, 10 May 2011 15:18:02 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.118]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 10 May 2011 15:17:59 +0200 From: Christofer Flinta To: Xiangsong Cui , Andreas Johnsson A , 'Henk Uijterwaal' , "ippm@ietf.org" Date: Tue, 10 May 2011 15:15:10 +0200 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv0+75834dEnQOmRfmxSCKQk56+owURALxQAA6U49AAIV9eMAB/agWQAKvJoxAAGXQL8A== Message-ID: <8BB85B4B99C85249B3D5D006D534001D19F51E77DE@ESESSCMS0361.eemea.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <00e201cc0944$3c598e70$b50cab50$%cui@huawei.com> <8BB85B4B99C85249B3D5D006D534001D19F3CC1309@ESESSCMS0361.eemea.ericsson.se> <00af01cc0a00$2ebf79c0$8c3e6d40$%cui@huawei.com> <3B05069A569E6F4AB6397B968734EBEA196F7FB77A@ESESSCMS0363.eemea.ericsson.se> <019801cc0eb4$37ddb2c0$a7991840$%cui@huawei.com> In-Reply-To: <019801cc0eb4$37ddb2c0$a7991840$%cui@huawei.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:18:05 -0000 Hi Xiangsong I will try to clarify the motivation behind our draft. If you look att the Introduction part of the RFC 5357 you can see that the = intention of the TWAMP protocol was to extend the OWAMP measurements with t= wo-way metrics and at the same time offer TWAMP as an alternative to settin= g up two separate OWAMP measurements. It is thus possible to measure delay in both directions either by setting u= p two separate OWAMP sessions or by setting up one single TWAMP session. Ho= wever, for capacity measurements in both directions there is currently no o= ther choice than setting up two separate OWAMP sessions. With the current T= WAMP protocol it's possible to perform capacity measurements in the forward= direction but not in the reverse direction.=20 >From our knowledge it appears that the advantages of TWAMP over OWAMP will = drive the market towards TWAMP. Therefore we want to extend the TWAMP mecha= nism with the possibility of also measuring capacity in both directions. Id= eally, it should be possible to use TWAMP for any kind of metric in both di= rections. Regards Christofer -----Original Message----- From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com]=20 Sent: den 10 maj 2011 03:47 To: Andreas Johnsson A; Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Hi Andreas, Please see my comments below. > -----Original Message----- > From: Andreas Johnsson A [mailto:andreas.a.johnsson@ericsson.com] > Sent: Friday, May 06, 2011 10:54 PM > To: 'Xiangsong Cui'; Christofer Flinta; 'Henk Uijterwaal';=20 > ippm@ietf.org > Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets >=20 > Hi Xiangsong, > We are drifting away from the topic here. What we want to do is to=20 > include functionality in the TWAMP spec for measuring available=20 > capacity in both the > forward and reverse direction. This interest was also raised by for example Al > and Yaakov (maybe throughput was the main idea here?).=20 I think this is not the problem we are talking about, I'm OK with this inte= rest (i.e., measuring available capacity in both the forward and reverse di= rection), my concern is I don't think the approach of TWAMP extension to on= e-way metric is OK. The problems with > loss measurements are outside the scope of this discussion, but do=20 > belong to > draft-ietf-ippm-rt-loss-00 by Al. Yes, I agree with you, and I believe you can find that it's not me bringing= "packet loss" into this discussion. >=20 > There seem to be a little bit of confusion when it comes to TWAMP. As=20 > you know, TWAMP time stamps packets when a packet is sent at the=20 > session sender, when it is received at the reflector, when it is sent=20 > by the reflector and > when it is again received by the session sender. From this it is very=20 > easy to > deduct forward and reverse delay, and with our proposal also forward=20 > and reverse available capacity. Sure, OWAMP can be used to do these=20 > measurements, but the intention with TWAMP is to perform both=20 > measurements in both directions (and round trip) with only one=20 > trigger. I think > this is a strong argument for trying to put new functionality into=20 > TWAMP and > not only focus on OWAMP. I'm not sure what the "trigger" means here, but I'm sure that the both enti= ties (source node and destination node) in this approach need to be modifie= d. But if we can do this by existing protocols, why we need the protocol mo= dification? >=20 > I hope this resolves any issues you have with the intention with our draft, > although maybe the draft needs to be enhanced or split into several. > Suggestions are welcome. I would like to suggest applying TWAMP to two-way metrics and ONLY to two-w= ay metrics, at the same time, applying OWAMP to one-way metrics. As to this specific requirement of measuring available capacity in both the= forward and reverse direction, since RFC5357 tells us: " OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. " And RFC4656 tells us: "Several roles are logically separated to allow for broad flexibility in= use." and, "Different logical roles can be played by the same host. " I think this is ONLY a protocol deployment business, it not worth a protoco= l change or extension. And based on your concern of "Controlling the measurement at one point", my= proposal is: +--------------------------------+ +------------------------------+ | Node A | | Node B | | +---------------------------+ | | +--------------------------+ | | | Forward-Control-Client |<--Forward-OWAMP-Control-->| Forward-Server | | | | Forward-Fetch-Client | | | | | | Forward-Session-Sender |---Forward-OWAMP-Test----->| Forward-Session-Receiver | | | +---------------------------+ | | +--------------------------+ | | | | |=20 | +---------------------------+ | | +--------------------------+ | | | Reverse-Control-Client |<--Reverse-OWAMP-Control-->| Reverse-Server | | | | Reverse-Fetch-Client | | | | | | Reverse-Session-Receiver |<--Reverse-OWAMP-Test------| Reverse-Session-Receiver | | | +---------------------------+ | | +--------------------------+ | | | | | =20 +--------------------------------+ +------------------------------+=20 Node A now is fully the controller of the measurement, can this achieve the= capacity measurement in both the forward and reverse direction? Best regards, Xiangsong >=20 > Best regards > Andreas Johnsson >=20 > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf=20 > Of Xiangsong Cui > Sent: Wednesday, May 04, 2011 4:09 AM > To: Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org > Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets >=20 >=20 > > This draft is trying to provide a means for measuring the capacity=20 > > in both > the > > forward and reverse directions as two separate measurements. This is > similar > > to the current capabilities of TWAMP, where e.g. delay and packet=20 > > loss can > be > > measured separately in both directions. >=20 > If you are referring to one-way metric, e.g. one-way packet loss, how=20 > can you > get the one-way metric by the two-way test? > That said, how can the session-sender get to know whether the packet=20 > is lost > before or after the session-reflector? >=20 > Regards, > Xiangsong >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From gezihui@research.att.com Mon May 16 21:07:16 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA526E07AF for ; Mon, 16 May 2011 21:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0S5OFn4rq8I for ; Mon, 16 May 2011 21:07:15 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7BCE07A8 for ; Mon, 16 May 2011 21:07:15 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id DEED312025C for ; Tue, 17 May 2011 00:07:14 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.177.180]) by mail-blue.research.att.com (Postfix) with ESMTP id C8ABDEF7BD for ; Tue, 17 May 2011 00:07:14 -0400 (EDT) Received: from [192.168.0.13] ([135.207.102.23]) by bigmail.research.att.com (8.13.8+Sun/8.11.6) with ESMTP id p4H47ENf007212 for ; Tue, 17 May 2011 00:07:14 -0400 (EDT) User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 17 May 2011 00:04:23 -0400 From: Zihui Ge To: Message-ID: Thread-Topic: CFP - update: CoNEXT 2011 Thread-Index: AcwUR4E2dY5BMiXRekOrmLqBnv+0hQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3388435633_35313369" Subject: [ippm] CFP - update: CoNEXT 2011 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 04:07:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388435633_35313369 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit --------------------------------------------------------------------- Call for Papers 7th International Conference on emerging Networking EXperiments and Technologies (CoNEXT) Sponsored by ACM SIGCOMM December 6-9, 2011 Tokyo, Japan http://conferences.sigcomm.org/co-next/2011/ --------------------------------------------------------------------- Regarding conference location: Tokyo only received limited physical damages from the earthquake. However, the organizing and steering committees are monitoring the evolution of the situation at the Fukushima nuclear power plant. While there does not currently seem to be any indication that the conference may not be held safely in Tokyo in December, the committees are aware of the concerns, and ready to take appropriate actions if necessary. In early May, the organizing committee surveyed recent CoNEXT attendees on the subject of the situation in Japan. Results are available at http://conferences.sigcomm.org/co-next/2011/survey-results.pdf . Based on community feedback along with assessments by various authorities, the organizing and steering committees have decided that the conference will go on as planned in Tokyo. Thanks to all who participated in the survey for their feedback. ================================================================= The 7th ACM International Conference on emerging Networking EXperiments and Technologies (ACM CoNEXT) will be held in Tokyo. The first goal of this conference is to provide a selective and interdisciplinary forum for research in Networking. The second goal is to foster meaningful technical interaction among members of our community, with a single-track program and opportunities for discussions. ACM CoNEXT 2011 welcomes submissions based on implementation and experimentation, as well as simulation and analytical approaches. We are committed to a fair, timely, and thorough review process providing authors of submitted papers with sound and detailed feedback. We solicit papers on emerging networking experiments, measurements, paradigms, analysis with particular emphasis on novel and creative work. Papers reporting on the deployment and performance of services, or exploring networks aimed at better supporting new services, are also appreciated. Relevant topics for the conference include, but are not limited to the following: * Internet measurement and modeling * Wireless networks * Mobile and cellular networks * Ad hoc and sensors networks * Economic aspects of the Internet * Network security * Datacenter networks * Peer-to-peer, overlay and content distribution networks * Online social networks * Routing, traffic engineering and network management * Interface among networking, communications and information theory * New networking protocols and architectures * Applications of network science in communication networks Submission Guidelines --------------------- Submissions must be original, unpublished work, and not under consideration at another conference or journal. Compliance with the 12 pages, 10pts ACM SIGCOMM format will be strictly enforced. Electronic proceedings will be published by ACM, and the best papers forwarded to the IEEE/ACM Transactions on Networking for possible fast-track publication. To submit papers to the ACM CoNEXT 2011 conference, please read the formatting guidelines provided on the conference web page and make sure that your submission complies with these requirements. Important Dates --------------- - Abstract registration: June 10 2011, 19:00 EDT - Paper submission: June 17 2011, 19:00 EDT - Notification: September 16 2011 - Conference held in Tokyo: December 6-9 General Co-Chairs ----------------- Kenjiro Cho, IIJ and Keio Univ, Japan Mark Crovella, Boston Univ, USA Program Co-Chairs ----------------- Constantine Dovrolis, Georgia Tech, USA Peter Key, Microsoft Research - Cambridge, UK Local Arrangements Chair ------------------------ Kensuke Fukuda, NII, Japan Publication and Publicity Chair ------------------------------- Zihui Ge, AT&T Research, USA Web Chair --------- Hirochika Asai, Univ of Tokyo, Japan Technical Program Committee --------------------------- Aditya Akella, Univ of Wisconsin - Madison, USA Lachlan Andrew, Swinburne University of Technology, Australia Chadi Barakat, INRIA, France Jun Bi, Tsinghua University, China Sem Borst, Bell Labs - Lucent Technologies, USA Matt Caesar, Univ of Illinois - Urbana-Champaign, USA Augustin Chaintreau, Columbia Univ, USA Rocky Chang, Hong Kong Polytechnic Univ, Hong Kong Dah Ming Chiu, CUHK, Hong Kong Chen-Nee Chuah, Univ of California - Davis, USA Mark Crovella, Boston Univ, USA Serge Fdida, LIP6, France Rodrigo Fonseca, Brown Univ, USA Kensuke Fukuda, NII, Japan Paolo Giaccone, Politecnico di Torino, Italy Christos Gkantsidis, Microsoft Research - Cambridge, UK Krishna Gummadi, Max Planck Institute for Software Systems, Germany Chuanxiong Guo, Microsoft Research - Asia, China Polly Huang, National Taiwan Univ, Taiwan Arvind Krishnamurthy, Univ of Washington, USA Jim Kurose, Univ of Massachusetts - Amherst, USA Amund Kvalbein, Simula, Norway Craig Labovitz, Arbor Networks, USA Nikolaos Laoutaris, Telefonica Research, Spain Simon Leinen, SWITCH, Switzerland Francesco Lo Presti, Univ of Rome, Italy John C.S. Lui, CUHK, Hong Kong Richard T.B. Ma, National Univ of Singapore, Singapore David Malone, Hamilton Institute - NUI Maynooth, Ireland Cecilia Mascolo, Univ of Cambridge, UK Laurent Massoulie, Technicolor Research and Innovation, France Laurent Mathy, Lancaster Univ, UK Z. Morley Mao, Univ of Michigan, USA Vishal Misra, Columbia Univ, USA Andrew Moore, Univ of Cambridge, UK Aki Nakao, Univ of Tokyo, Japan T.S.Eugene Ng, Rice Univ, USA KyoungSoo Park, KAIST, S.Korea Vern Paxson, Univ of California - Berkeley and ICSI, USA KK Ramakrishnan, ATT-Research, USA Rajeev Rastogi, Yahoo! Research, India Luigi Rizzo, Univ of Pisa, Italy Jim Roberts, INRIA, France Catherine Rosenberg, Univ of Waterloo, Canada Theodoros Salonidis, Technicolor Research and Innovation, France Peter Steenkiste, Carnegie Mellon Univ, USA Steve Uhlig, Deutsche Telekom Laboratories, Germany Arun Venkataramani, Univ of Massachusetts - Amherst, USA Zhi-Li Zhang, Univ of Minnessota, USA Ben Zhao, Univ of California - Santa Barbara, USA --B_3388435633_35313369 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable CFP - update: CoNEXT 2011 ---------------------------------------------------------------------
            &nb= sp;            &= nbsp; Call for Papers
7th International Conference on emerging Networking
         EXperiments and Techn= ologies (CoNEXT)
            &nb= sp;  Sponsored by ACM SIGCOMM
            &nb= sp;       December 6-9, 2011
            &nb= sp;            T= okyo, Japan
    http://conferences.sigcomm.org/co-next/2011/
---------------------------------------------------------------------
Regarding conference location:

Tokyo only received limited phys= ical damages from the
earthquake. However, the organizing and steering committees are
monitoring the evolution of the situation at the Fukushima nuclear
power plant. While there does not currently seem to be any indication
that the conference may not be held safely in Tokyo in December, the
committees are aware of the concerns, and ready to take appropriate
actions if necessary.

In early May, the organizing committee surveyed recent CoNEXT
attendees on the subject of the situation in Japan.
Results are available at http://conferences.sigcomm.org/co-next/2011/survey-results.pdf .
Based on community feedback along with assessments by various
authorities, the organizing and steering committees have decided that
the conference will go on as planned in Tokyo. Thanks to all who
participated in the survey for their feedback.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The 7th ACM International Conference on emerging Networking EXperiments and Technologies (ACM CoNEXT) will be held in Tokyo. The first goal of
this conference is to provide a selective and interdisciplinary forum
for research in Networking. The second goal is to foster meaningful
technical interaction among members of our community, with a single-track <= BR> program and opportunities for discussions.

ACM CoNEXT 2011 welcomes submissions based on implementation and
experimentation, as well as simulation and analytical approaches. We are committed to a fair, timely, and thorough review process providing authors =
of submitted papers with sound and detailed feedback. We solicit papers on =
emerging networking experiments, measurements, paradigms, analysis with particular emphasis on novel and creative work. Papers reporting on the deployment and performance of services, or exploring networks aimed at
better supporting new services, are also appreciated.

Relevant topics for the conference include, but are not limited to the
following:

    * Internet measurement and modeling
    * Wireless networks
    * Mobile and cellular networks
    * Ad hoc and sensors networks
    * Economic aspects of the Internet
    * Network security
    * Datacenter networks
    * Peer-to-peer, overlay and content distribution ne= tworks
    * Online social networks
    * Routing, traffic engineering and network manageme= nt
    * Interface among networking, communications and in= formation theory
    * New networking protocols and architectures
    * Applications of network science in communication = networks  


Submission Guidelines
---------------------
Submissions must be original, unpublished work, and not under
consideration at another conference or journal. Compliance with the
12 pages, 10pts ACM SIGCOMM format will be strictly enforced.
Electronic proceedings will be published by ACM, and the best papers
forwarded to the IEEE/ACM Transactions on Networking for possible
fast-track publication.

To submit papers to the ACM CoNEXT 2011 conference, please read the
formatting guidelines provided on the conference web page and make
sure that your submission complies with these requirements.


Important Dates
---------------
- Abstract registration: June 10 2011, 19:00 EDT
- Paper submission: June 17 2011, 19:00 EDT
- Notification: September 16 2011
- Conference held in Tokyo: December 6-9


General Co-Chairs
-----------------
Kenjiro Cho, IIJ and Keio Univ, Japan
Mark Crovella, Boston Univ, USA


Program Co-Chairs
-----------------
Constantine Dovrolis, Georgia Tech, USA
Peter Key, Microsoft Research - Cambridge, UK


Local Arrangements Chair
------------------------
Kensuke Fukuda, NII, Japan


Publication and Publicity Chair
-------------------------------
Zihui Ge, AT&T Research, USA


Web Chair
---------
Hirochika Asai, Univ of Tokyo, Japan


Technical Program Committee
---------------------------
 Aditya Akella, Univ of Wisconsin - Madison, USA
 Lachlan Andrew, Swinburne University of Technology, Australia
 Chadi Barakat, INRIA, France
 Jun Bi, Tsinghua University, China
 Sem Borst, Bell Labs - Lucent Technologies, USA
 Matt Caesar, Univ of Illinois - Urbana-Champaign, USA
 Augustin Chaintreau, Columbia Univ, USA
 Rocky Chang, Hong Kong Polytechnic Univ, Hong Kong
 Dah Ming Chiu, CUHK, Hong Kong
 Chen-Nee Chuah, Univ of California - Davis, USA
 Mark Crovella, Boston Univ, USA
 Serge Fdida, LIP6, France
 Rodrigo Fonseca, Brown Univ, USA
 Kensuke Fukuda, NII, Japan
 Paolo Giaccone, Politecnico di Torino, Italy  
 Christos Gkantsidis, Microsoft Research - Cambridge, UK
 Krishna Gummadi, Max Planck Institute for Software Systems, Germany  Chuanxiong Guo, Microsoft Research - Asia, China
 Polly Huang, National Taiwan Univ, Taiwan
 Arvind Krishnamurthy, Univ of Washington, USA
 Jim Kurose, Univ of Massachusetts - Amherst, USA
 Amund Kvalbein, Simula, Norway
 Craig Labovitz, Arbor Networks, USA
 Nikolaos Laoutaris, Telefonica Research, Spain
 Simon Leinen, SWITCH, Switzerland
 Francesco Lo Presti, Univ of Rome, Italy
 John C.S. Lui, CUHK, Hong Kong
 Richard T.B. Ma, National Univ of Singapore, Singapore
 David Malone, Hamilton Institute - NUI Maynooth, Ireland
 Cecilia Mascolo, Univ of Cambridge, UK
 Laurent Massoulie, Technicolor Research and Innovation, France
 Laurent Mathy, Lancaster Univ, UK
 Z. Morley Mao, Univ of Michigan, USA
 Vishal Misra, Columbia Univ, USA
 Andrew Moore, Univ of Cambridge, UK
 Aki Nakao, Univ of Tokyo, Japan
 T.S.Eugene Ng, Rice Univ, USA
 KyoungSoo Park, KAIST, S.Korea
 Vern Paxson, Univ of California - Berkeley and ICSI, USA
 KK Ramakrishnan, ATT-Research, USA
 Rajeev Rastogi, Yahoo! Research, India  
 Luigi Rizzo, Univ of Pisa, Italy
 Jim Roberts, INRIA, France
 Catherine Rosenberg, Univ of Waterloo, Canada
 Theodoros Salonidis, Technicolor Research and Innovation, France
 Peter Steenkiste, Carnegie Mellon Univ, USA
 Steve Uhlig, Deutsche Telekom Laboratories, Germany
 Arun Venkataramani, Univ of Massachusetts - Amherst, USA
 Zhi-Li Zhang, Univ of Minnessota, USA
 Ben Zhao, Univ of California - Santa Barbara, USA



 --B_3388435633_35313369-- From Xiangsong.Cui@huawei.com Sun May 22 19:09:45 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E738CE06EB for ; Sun, 22 May 2011 19:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4So6z2aizwEQ for ; Sun, 22 May 2011 19:09:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8611FE06A6 for ; Sun, 22 May 2011 19:09:44 -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 <0LLM00MEDLYJKS@szxga03-in.huawei.com> for ippm@ietf.org; Mon, 23 May 2011 10:08:43 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLM003MJLYIKV@szxga03-in.huawei.com> for ippm@ietf.org; Mon, 23 May 2011 10:08:43 +0800 (CST) Date: Mon, 23 May 2011 10:08:41 +0800 From: Xiangsong Cui In-reply-to: <4DBB4877.9040808@internet2.edu> To: 'Matthew J Zekauskas' , 'IETF IPPM WG' Message-id: <011301cc18ee$564669c0$02d33d40$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcwGxIMd6uOyIKP9SWigYQYmYr4FawSJvowg References: <4DBB4877.9040808@internet2.edu> Subject: Re: [ippm] initial version of the IETF 80 IPPM meeting minutes online X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 02:09:46 -0000 No intention to any discussion, just for your information, about "9. RFC5136 issues" ... The latest IAB's production, RFC6250, reads, A "link" in the IP service model refers to the topological area within which a packet with an IPv4 Time to Live (TTL) or IPv6 Hop Limit of 1 can be delivered. That is, where ** no IP-layer forwarding ** (which entails a TTL/Hop Limit decrement) occurs between two nodes. Best regards, Xiangsong > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Matthew J Zekauskas > Sent: Saturday, April 30, 2011 7:24 AM > To: IETF IPPM WG > Subject: [ippm] initial version of the IETF 80 IPPM meeting minutes online > > The initial version of the meeting minutes is available at > > > You can see the agenda, minutes, and all materials at > > > I looked for the audio from the meeting, but apparently the files that > represent the recordings the channel IPPM was broadcast on (8), were all > overwritten by versions from channel 5 due to human error, so the audio > is simply not available. > > Please send corrections and updates to the chairs or to the list; the > deadline to make any final changes is 18-May (so please review well > before then). > > Thanks, > > --Matt (for Matt & Henk) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From Ali.Nazari@dai-labor.de Sun May 22 09:28:13 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90173E06AC for ; Sun, 22 May 2011 09:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I282DfKRXrvt for ; Sun, 22 May 2011 09:28:12 -0700 (PDT) Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) by ietfa.amsl.com (Postfix) with ESMTP id 07090E0670 for ; Sun, 22 May 2011 09:28:12 -0700 (PDT) X-tubIT-Incoming-IP: 130.149.154.85 Received: from mail.dai-labor.de ([130.149.154.85]) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtps [TLSv1:RC4-MD5:128] for id 1QOBVj-0004P3-AI; Sun, 22 May 2011 18:28:11 +0200 Received: from birke4.dai-lab.de ([130.149.154.85]) by birke4.dai-lab.de ([130.149.154.85]) with mapi; Sun, 22 May 2011 18:28:09 +0200 From: Ali Nazari To: "ippm@ietf.org" Date: Sun, 22 May 2011 18:28:07 +0200 Thread-Topic: REMINDER: ACM Multimedia Workshop: Ubiquitous Meta User Interfaces (Ubi-MUI'11) Thread-Index: AcwYnO9kXdo/ACNESHC1rAmxsT/gfwAAAqwgAAADO5AAAAuJ8A== Message-ID: <996D29AAC4B8314882C25235E84ABED501143BFC0AD3@birke4.dai-lab.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_996D29AAC4B8314882C25235E84ABED501143BFC0AD3birke4daila_" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 22 May 2011 22:48:17 -0700 Subject: [ippm] REMINDER: ACM Multimedia Workshop: Ubiquitous Meta User Interfaces (Ubi-MUI'11) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2011 16:28:13 -0000 --_000_996D29AAC4B8314882C25235E84ABED501143BFC0AD3birke4daila_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Call for Papers Ubi-MUI2011: International ACM Workshop on Ubiquitous Meta User Interfaces http://www.dai-labor.de/Ubi-MUI2011/ In conjunction with ACM Multimedia 2011, Scottsdale, Arizona, US, Nov 28 - Dec 1 http://www.acm= mm11.org Intelligent Environments have the vision of enhancing our everyday environm= ent and interaction with its objects by sensing, computing, and communicati= on capabilities. Major characteristics of such environments are the increas= ing number of intelligent devices (ubiquity), their complexity, and their i= ntegration into the background (transparency). Devices will disappear or bl= end into the background and will be invisible to the user. However, because= of this transparency, users fail to develop an adequate mental model for i= nteraction with such environments. To overcome these challenges, new types = of user interfaces are required that will represent intelligent environment= s. Such representative user interfaces create an overall system image for i= ntelligent environments in order to help users to better understand the int= elligent environment. In this sense, representative user interfaces are Ubi= quitous Meta User Interfaces (Ubi-MUI) that could increase the transparency= and predictability of the whole system by visualizing the environments' in= ternal states, perception and decision making processes, available services= and devices, as well as ongoing and adoption plans. Using Ubi-MUI users co= uld observe, analyze, understand, control, and customize the adaptive behav= ior and context-dependent interactions of their surroundings. In such envir= onments, multimedia play two key roles: they support new ways of interactio= n that apply to multiple human senses, and they diffuse the presentation of= content in the environment of the user. The aim of this workshop is to bri= ng together different research groups to foster the developments of highly = intuitive, multimedia supported meta user interfaces that bring transparenc= y, predictability, and control into intelligent environments. Topics of interest include, but are not limited to, the following: [[Representing Intelligent Environments]] a. Visualization and animation of sensing activities, decisions, and implic= it interactions of intelligent systems, which allows users to understand an= d predict the behavior of the system. b. Creating awareness for implicit interaction concepts using multimedia ar= tifacts c. Using avatars, storytelling, or gaming to introduce the functional capab= ilities and adaptive behavior of intelligent environments to novice users [[Concepts for Meta User Interfaces]] a. Multimodal, multimedia interfaces to control and modify implicit i= nteractions and environments' responsive activities b. User interfaces to shut down the perception features or responsive= behaviors of intelligent environments c. Game-based interfaces to observe, control and modify system behav= ior d. Haptic, multi touch, or tangible ubiquitous meta user interfaces e. Supportive user interfaces that create a system face for intellig= ent environments f. Natural meta interaction concepts allowing users an easy access to mul= timedia environments (search, exploration, manipulation and control of medi= a and devices), touch and gesture based interfaces, 3D displays and audio i= mmersive systems for augmented-reality. g. Metaphors and coordination algorithms for distributed conflict managem= ent, mechanisms that allow users an explicit interaction with adaptive envi= ronments. [[ Implementation, and Evaluation Aspects]] a. Methods to evaluate the added-value of multimedia assisted meta use= r interfaces b. User studies related to mental models for human-environment-intera= ction and meta user interfaces c. Novel approaches to effectively manage the complexity of development, = Real-time, de-centralized media-processing architectures, middleware archit= ectures for sensor and multimedia integration. d. Activity analysis and domain observations related to phenomena suc= h as loss of control and over-automation e. Smart Multimedia sensors with the ability to capture, store, and = process audio and video signals for situation recognition and implicit inte= raction purposes. This specially includes human activity recognition and mo= nitoring as well as socially-aware multimedia Submitted papers must not have been previously published and must not be cu= rrently under consideration for publication elsewhere. Authors are invited = to submit a full paper according to the guidelines available on the confere= nce website at http://www.acmmm11.org. Reviewing will be double blind. Only= electronic submissions will be accepted. Papers will be reviewed with an e= mphasis on potential to contribute to the state-of-the-art in the field. Ea= ch paper will receive at least two reviews. Selection criteria include accu= racy and originality of ideas, clarity and significance of results, and pre= sentation quality. All papers accepted will appear in the workshops proceed= ings and will be included in the ACM Digital Library. All accepted papers that are registered and presented in the workshop are e= ligible to submit an extended version to the special issue. Program Chairs: Dr. Ali Asghar Nazari Shirehjini, DAI-Labor, Technische Universit=E4t Berli= n, Germany Dr. Abdulsalam Yassine, Alcatel-Lucent, Canada Prof. Dr.-Ing. Sahin Albayrak, DAI-Labor, Technische Universit=E4t Berlin, = Germany Important Dates: Submission Deadline: 19.06.2011 Acceptance Notification: 30.07.2011 Camera Ready: 05.09.2011 --_000_996D29AAC4B8314882C25235E84ABED501143BFC0AD3birke4daila_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Call for Papers

 

Ubi-MUI2011: International ACM Workshop on Ubiquitous Meta= User Interfaces

htt= p://www.dai-labor.de/Ubi-MUI2011/

In co= njunction with

ACM Multimedia 2011, Scottsdale, Arizona, US, Nov 28 - Dec 1 http://www.acmmm11.org

&nb= sp;

Intelligent = Environments have the vision of enhancing our everyday environment and inte= raction with its objects by sensing, computing, and communication capabilit= ies. Major characteristics of such environments are the increasing number o= f intelligent devices (ubiquity), their complexity, and their integration i= nto the background (transparency). Devices will disappear or blend into the= background and will be invisible to the user. However, because of this tra= nsparency, users fail to develop an adequate mental model for interaction w= ith such environments. To overcome these challenges, new types of user inte= rfaces are required that will represent intelligent environments. Such repr= esentative user interfaces create an overall system image for intelligent e= nvironments in order to help users to better understand the intelligent env= ironment. In this sense, representative user interfaces are Ubiquitous Meta= User Interfaces (Ubi-MUI) that could increase the transparency and predict= ability of the whole system by visualizing the environments' internal state= s, perception and decision making processes, available services and devices= , as well as ongoing and adoption plans. Using Ubi-MUI users could observe,= analyze, understand, control, and customize the adaptive behavior and cont= ext-dependent interactions of their surroundings. In such environments, mul= timedia play two key roles: they support new ways of interaction that apply= to multiple human senses, and they diffuse the presentation of content in = the environment of the user. The aim of this workshop is to bring together = different research groups to foster the developments of highly intuitive, m= ultimedia supported meta user interfaces that bring transparency, predictab= ility, and control into intelligent environments.

 

Topics of interest include, but are not = limited to, the following:

 

[[Representing Intelligent Environments]]

=

a. Visualization and animation o= f sensing activities, decisions, and implicit interactions of intelligent s= ystems, which allows users to understand and predict the behavior of the sy= stem.

b. Cr= eating awareness for implicit interaction concepts using multimedia artifac= ts

c. Using= avatars, storytelling, or gaming to introduce the functional capabilities = and adaptive behavior of intelligent environments to novice users

 

[[Concepts for Meta User= Interfaces]]

a.       Multimodal, multimedia interfaces= to control and modify implicit interactions and environments' responsive a= ctivities

b= .       User interfaces to shut down the perc= eption features or responsive behaviors of intelligent environments

c.  &nbs= p;     Game-based interfaces to observe, control and mo= dify system behavior

d.       Haptic, multi touch, or ta= ngible ubiquitous meta user interfaces

e.        Su= pportive user interfaces that create a system face for intelligent environm= ents

f.&nbs= p;  Natural meta interaction concepts allowing users an easy access to= multimedia environments (search, exploration, manipulation and control of = media and devices), touch and gesture based interfaces, 3D displays and aud= io immersive systems for augmented-reality.

g.   Metaphors and coordinatio= n algorithms for distributed conflict management, mechanisms that allow use= rs an explicit interaction with adaptive environments.

 

[[ Implementation, and Evaluation A= spects]]

a.=      Methods to evaluate the added-value of multi= media assisted meta user interfaces

b.       User studie= s related to mental models for human-environment-interaction and meta user = interfaces

= c.   Novel approaches to effectively manage the complexity of dev= elopment, Real-time, de-centralized media-processing architectures, middlew= are architectures for sensor and multimedia integration.<= /p>

d.    &nb= sp;  Activity analysis and domain observations related to phenomena su= ch as loss of control and over-automation

e.       = Smart Multimedia sensors with the ability to capture, store, and process a= udio and video signals for situation recognition and implicit interaction p= urposes. This specially includes human activity recognition and monitoring = as well as socially-aware multimedia

 

Submitted papers must not have been previously publis= hed and must not be currently under consideration for publication elsewhere= . Authors are invited to submit a full paper according to the guidelines av= ailable on the conference website at http= ://www.acmmm11.org. Reviewing will be double = blind. Only electronic submissions will be accepted. Papers will be reviewe= d with an emphasis on potential to contribute to the state-of-the-art in th= e field. Each paper will receive at least two reviews. Selection criteria i= nclude accuracy and originality of ideas, clarity and significance of resul= ts, and presentation quality. All papers accepted will appear in the worksh= ops proceedings and will be included in the ACM Digital Library.=

All accepted papers t= hat are registered and presented in the workshop are eligible to submit an = extended version to the special issue.

 

Program Chairs:

Dr. Ali Asghar Nazari Shirehjini, DAI-Labor, T= echnische Universit=E4t Berlin, Germany

Dr. Abdulsalam Yassine, Alcatel-Lucent, Canad= a

Prof. Dr= .-Ing. Sahin Albayrak, DAI-Labor, Technische Universit=E4t Berlin, Germany<= o:p>

 =

Important Dates= :

Submissio= n Deadline:        19.06.2011=

Acceptance Notificati= on:  30.07.2011

Camera Re= ady:            = ;      05.09.2011

 

= --_000_996D29AAC4B8314882C25235E84ABED501143BFC0AD3birke4daila_-- From internet-drafts@ietf.org Tue May 31 04:54:58 2011 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A2BE0832; Tue, 31 May 2011 04:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v457ml-LZP3h; Tue, 31 May 2011 04:54:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797C6E07AE; Tue, 31 May 2011 04:54:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110531115454.28185.87787.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 04:54:54 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-tcp-throughput-tm-13.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 11:54:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group = of the IETF. Title : Framework for TCP Throughput Testing Author(s) : Barry Constantine Gilles Forget Ruediger Geib Reinhard Schrage Filename : draft-ietf-ippm-tcp-throughput-tm-13.txt Pages : 24 Date : 2011-05-31 This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regards to user experience. In this framework, TCP and IP parameters are specified to optimize TCP throughput. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-13.txt