From steve.baillargeon@ericsson.com Fri Apr 1 00:41:47 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6613A6BEC for ; Fri, 1 Apr 2011 00:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_41=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40ZP7jE4usDX for ; Fri, 1 Apr 2011 00:41:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 551C63A6C09 for ; Fri, 1 Apr 2011 00:41:46 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p317hGTG020101; Fri, 1 Apr 2011 02:43:18 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 1 Apr 2011 03:43:12 -0400 From: Steve Baillargeon To: Xiangsong Cui , Joseph Ishac Date: Fri, 1 Apr 2011 03:43:11 -0400 Thread-Topic: [ippm] Impact of hosts on network capacity and RFC 5136 Thread-Index: AcvwNp2pGxDfvg4FSs6l6hbcbzjf7gAB52WA Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC28BAEE@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Chimento, Philip F." , IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:41:47 -0000 VGhpcyBpcyBteSBsYXN0IGVtYWlsIG9uIHRoaXMgZXhjaGFuZ2UuDQpUaGUgSUVURiBNSUJzIGhh dmUgZGVmaW5lZCBzZXBhcmF0ZSBNSUJzIGZvciBlYWNoIGxheWVyLg0KVGhlcmVmb3JlIHN0YXRz IHNob3VsZCBiZSBwcm9kdWNlZCBhdCBlYWNoIGxheWVyIGFzIHdlbGwuDQpUaGUgc3RhbmRhcmRz IGhhdmUgYWxsb3dlZCBmb3IgYSBHRSBsaW5rIHV0aWxpemF0aW9uIHRvIGJlIGF0IDEwJSB3aGls ZSB0aGUgSVAgbGluayB1dGlsaXphdGlvbiBpcyBhdCAxMDAlLg0KDQoNCi1TdGV2ZQ0KDQoNCg0K IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBwbS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWGlhbmdzb25n IEN1aQ0KU2VudDogQXByaWwtMDEtMTEgMjozMyBBTQ0KVG86IEpvc2VwaCBJc2hhYw0KQ2M6IENo aW1lbnRvLCBQaGlsaXAgRi47IElFVEYgSVBQTSBXRw0KU3ViamVjdDogUmU6IFtpcHBtXSBJbXBh Y3Qgb2YgaG9zdHMgb24gbmV0d29yayBjYXBhY2l0eSBhbmQgUkZDIDUxMzYNCg0KSm9zZXBoLCAN Cg0KdGhhbmtzIGZvciB5b3VyIGFuc3dlciwgYnV0IEkgdGhpbmsgSSBzdGlsbCBkb24ndCB1bmRl cnNhbmQgdGhhdC4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgImxpbmsgaXMgc2F0dXJhdGVk IiBtZWFucywgZm9yIHRoZSBleGFtcGxlIG9mIG15IHNsaWRlcywgaW4gdGhlIEdiIGV0aGVybmV0 LCAxTSBiaXQgZmxvdyBpcyBzYXR1cmF0ZWQgZm9yIHRoZSBldGhlcm5ldCBsaW5rPyBNeSBhbnN3 ZXIgaXMgbm8sIGJlY2F1c2UgbGluayBpcyBhIGxheWVyIDIgbm90aW9uLCB3ZSBoYXZlIHRvIGp1 ZGdlIGl0cyBzdGF0dXMgaW4gbGF5ZXIgMiB2aWV3cG9pbnQuDQoNCkl0IGNvbWVzIGJhY2sgdG8g dGhlIGJhc2ljIHF1ZXN0aW9uLCBzaG91bGQgdGhlIG5vZGUgaXMgcGFydCBvZiBsaW5rPw0KDQpX aGF0IEkgd2FudCB0byBzYXkgaXMsIGlmIHdlIHNheSBub2RlIGlzIHBhcnQgb2YgbGluaywgcGVy aGFwcyB3ZSBoYXZlIHRvIHNheSB0aGUgSW50ZXJuZXQgaXMgdGhlIHNldCBvZiAibGlua3MiLCB0 aGVyZSBpcyBubyBob3N0LCBubyByb3V0ZXIsIG5vIE5BVCwgbm8gZmlyZXdhbGwsIG5vIEFMRyAu Li4sIGlzIHRoYXQgc3RyYW5nZT8gQWhhLCBiZWNhdXNlIGFsbCB0aGVzZSBub2RlcyBhcmUgaW5z aWRlIHRoZSBsaW5rcy4NCg0KQmVzdCBSZWdhcmRzDQpYaWFuZ3NvbmcNCg0KLS0tLS0g1K3Tyrz+ IC0tLS0tDQq3orz+yMs6IEpvc2VwaCBJc2hhYyA8amlzaGFjQG5hc2EuZ292Pg0KyNXG2jog0MfG 2s7lLCDLxNTCIDHI1SwgMjAxMSDJz87nNTo1Mg0K1vfM4jogUmU6IFtpcHBtXSBJbXBhY3Qgb2Yg aG9zdHMgb24gbmV0d29yayBjYXBhY2l0eSBhbmQgUkZDIDUxMzYNCsrVvP7IyzogWGlhbmdzb25n IEN1aSA8WGlhbmdzb25nLkN1aUBodWF3ZWkuY29tPg0Ks63LzTogIkNoaW1lbnRvLCBQaGlsaXAg Ri4iIDxQaGlsaXAuQ2hpbWVudG9Aamh1YXBsLmVkdT4sIElFVEYgSVBQTSBXRyA8aXBwbUBpZXRm Lm9yZz4NCg0KPiBXZWxsLCBmb3IgYSBnaXZlbiBwYWNrZXQgdHlwZSwgVXNlZChMLFQsSSkgbWVh c3VyZXMgdGhlICphY3R1YWwqIHVzYWdlIA0KPiBpbiBhIGdpdmVuIHRpbWUgc3Bhbi4gIEMoTCxU LEkpIGlzIHRoZSBtYXhpbXVtIHlvdSAqY291bGQqIG9idGFpbiBpbiANCj4gdGhhdCBzYW1lIHRp bWUgc3Bhbi4gIFNvIGlmIHRoZSBsaW5rIGlzIG5vdCBhY3R1YWxseSBzYXR1cmF0ZWQgd2l0aCAN Cj4gdHJhZmZpYywgdGhlIGxpbmsgdXRpbGl6YXRpb24gd2lsbCBub3QgYmUgMTAwJS4NCj4gDQo+ IElmIHlvdSB0cnkgdG8gdGhpbmsgb2YgYWN0dWFsbHkgdHJ5aW5nIHRvIG1lYXN1cmUgQygpIGFu ZCBVc2VkKCkgYXQgDQo+IHRoZSBzYW1lIHRpbWUsIHlvdSdyZSBib3VuZCB0byBnZXQgYSBoZWFk YWNoZS4gIFRoYXQncyB3aHkgZGV2ZWxvcGluZyANCj4gdGhlIG1lYW5zIG9mIGdhdGhlcmluZyB0 aGUgbWV0cmljcyB3YXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgZG9jdW1lbnQuDQo+IA0KPiBEb2Vz IHRoYXQgaGVscCBhbnN3ZXIgeW91ciBxdWVzdGlvbj8NCj4gDQo+IC1Kb3NlcGgNCj4gDQo+IDIw MTEvMy8zMSBYaWFuZ3NvbmcgQ3VpIDxYaWFuZ3NvbmcuQ3VpQGh1YXdlaS5jb20+Og0KPiA+IEkn bSB3b25kZXJpbmcgaW4gd2hhdCBzY2VuYXJpbywgdGhlIGxpbmsgdXRpbGl6YXRpb24gaXMgbm90 DQo+IGVxdWFsIHRvIDEwMCU/DQo+ID4gV2hvIGNhbiB0ZWxsIG1lIHdoYXQgdHlwZSB0aGUgbGlu ayB1dGlsaXphdGlvbiBpcywgaXQncyBib29sDQo+IHR5cGUgb3IgZmxvYXQgdHlwZSBudW1iZXI/ DQo+ID4NCj4gPiBUaGFua3MgZm9yIHlvdXIgdGVhY2hpbmchDQo+ID4NCj4gPiBCZXN0IFJlZ2Fy ZHMNCj4gPiBYaWFuZ3NvbmcNCj4gPg0KPiA+IC0tLS0tINSt08q8/iAtLS0tLQ0KPiA+ILeivP7I yzogSm9zZXBoIElzaGFjIDxqaXNoYWNAbmFzYS5nb3Y+DQo+ID4gyNXG2jog0MfG2s7lLCDLxNTC IDHI1SwgMjAxMSDJz87nMjoxNg0KPiA+INb3zOI6IFJlOiBbaXBwbV0gSW1wYWN0IG9mIGhvc3Rz IG9uIG5ldHdvcmsgY2FwYWNpdHkgYW5kIFJGQyA1MTM2DQo+ID4gytW8/sjLOiBJRVRGIElQUE0g V0cgPGlwcG1AaWV0Zi5vcmc+DQo+ID4gs63LzTogIkNoaW1lbnRvLCBQaGlsaXAgRi4iIDxQaGls aXAuQ2hpbWVudG9Aamh1YXBsLmVkdT4NCj4gPg0KPiA+PiBQYXNzaW5nIG9uIGJ5IHJlcXVlc3Qg YSBuaWNlIGNvbmNpc2UgZXhhbXBsZSBJIHdhcyBzZW50IGJ5IERvbmFsZCANCj4gPj4gTWNMYWNo bGFuIG9mIGNyYy5jYToNCj4gPj4NCj4gPj4gPiBJIHRoaW5rIHdoYXQgeW91IGFyZSBzYXlpbmcg KGZvciBpbnN0YW5jZSkgaXMgdGhhdDoNCj4gPj4gPiAtIEV2ZW4gaWYgdGhlIHBhdGggYmV0d2Vl biB0aGUgU3JjIGFuZCBEc3QgaG9zdHMgKGNhYmxpbmcsDQo+ID4+IHN3aXRjaGVzIGV0YykgY2Fu IHN1cHBvcnQgKGVnLiAxMCBHYnBzKQ0KPiA+PiA+IC0gSWYgdGhlIFNlbmRpbmcgaG9zdCBjYW4g b25seSB0cmFuc21pdCBhdCAxMCBNYnBzDQo+ID4+ID4gLSB0aGVuIHRoZSBlZmZlY3RpdmUgTGlu ayBDYXBhY2l0eSAoYXMgc2VlbiBieSBTcmMgYW5kIERzdCkgaXMNCj4gPj4gYXQgbW9zdCAxMCBN YnBzLg0KPiA+Pg0KPiA+PiBJJ2QgbGlrZSB0byBhZGQgYSBmZXcgbW9yZSBleGFtcGxlcyB0aGF0 IGFyZSBjb3ZlcmVkIGJ5IHRoZSBjdXJyZW50IA0KPiA+PiB3b3JkaW5nIGluIFJGQyA1MTM2Og0K PiA+Pg0KPiA+PiAxKSBFbXBsb3lpbmcgZW5jb2Rpbmcgb24gYSBsaW5rLCBzZXZlcmFsIG9mIG91 ciBsaW5rcyB1c2UNCj4gUmVlZD9Tb2xvbW9uPj4gb3IgcmF0ZSAxLzIgY29udm9sdXRpb24gZW5j b2RpbmcuDQo+ID4+IDIpIFBhc3NpbmcgdGhyb3VnaCBhbiB1bmRlcnJhdGVkIHBhdGNoIHBhbmVs IChzYXkgYSBDYXQzIHBhdGNoDQo+IHBhbmVsPj4gd2hlbiB5b3VyIHRyeWluZyB0byBkbyAxMDAw R2JFKSBbaW5jaWRlbnRhbGx5IGRvbid0IGFzayBpZg0KPiBJJ3ZlPj4gZXhwZXJpZW5jZWQgdGhp cyBmaXJzdCBoYW5kIC4uLl0NCj4gPj4NCj4gPj4gVGhlIHdvcmRpbmcgaW4gdGhlIFJGQyBpcyBt ZWFudCB0byBjb3ZlciBzdWNoIGxpbWl0YXRpb25zIHdpdGggYm90aCANCj4gPj4gdGhlIGxpbmtz IGFuZCBub2Rlcy4NCj4gPj4NCj4gPj4gLUpvc2VwaA0KPiA+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBpcHBtIG1haWxpbmcgbGlzdA0KPiA+ PiBpcHBtQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBwbQ0KPiA+Pg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo+IA0K From steve.baillargeon@ericsson.com Fri Apr 1 01:03:59 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D053A6B25 for ; Fri, 1 Apr 2011 01:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.979 X-Spam-Level: X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=1.619, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsyNe0QnolRy for ; Fri, 1 Apr 2011 01:03:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id AC99F3A6837 for ; Fri, 1 Apr 2011 01:03:58 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3185YNl020495; Fri, 1 Apr 2011 03:05:36 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 1 Apr 2011 04:05:35 -0400 From: Steve Baillargeon To: Joseph Ishac , "Chimento, Philip F." Date: Fri, 1 Apr 2011 04:05:34 -0400 Thread-Topic: Standard Track for Capacity Thread-Index: AcvwQ5PiW5mMy0UOQWK31PWQJ6uTdw== Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC28BAF3@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4383945B8C24AA4FBC33555BB7B829EF0DEC28BAF3EUSAACMS0701e_" MIME-Version: 1.0 Cc: Matthew J Zekauskas , Henk Uijterwaal , IETF IPPM WG Subject: [ippm] Standard Track for Capacity X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:03:59 -0000 --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC28BAF3EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joseph, Hi Philip I noticed that RFC 5136 is informational. Is it possible to discuss the possibility to move it to a standard track (w= ith the required additions)? Or create a separate document that will become an Internet standard entitle= d "Capacity Metrics"? What do you think? -Steve --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC28BAF3EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Joseph, Hi Philip
I noticed that RFC 5136 is informational.
Is it possible to discuss the possibility to move it to a standard tra= ck (with the required additions)?
Or create a separate document that will become an Internet standard en= titled "Capacity Metrics"?
What do you think?
 
-Steve
 
 
 --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC28BAF3EUSAACMS0701e_-- From Xiangsong.Cui@huawei.com Fri Apr 1 01:05:53 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A793A6B25 for ; Fri, 1 Apr 2011 01:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.505 X-Spam-Level: X-Spam-Status: No, score=0.505 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_41=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEBzgdEmT1qp for ; Fri, 1 Apr 2011 01:05:52 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 0EE8C3A6837 for ; Fri, 1 Apr 2011 01:05:52 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIY0079TRWKMD@usaga01-in.huawei.com> for ippm@ietf.org; Fri, 01 Apr 2011 03:07:32 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIY00AQNRWIE1@usaga01-in.huawei.com> for ippm@ietf.org; Fri, 01 Apr 2011 03:07:31 -0500 (CDT) Received: from [172.24.1.55] (Forwarded-For: [88.208.109.142]) by szxmc01-in.huawei.com (mshttpd); Fri, 01 Apr 2011 16:07:29 +0800 Date: Fri, 01 Apr 2011 16:07:29 +0800 From: Xiangsong Cui In-reply-to: <4383945B8C24AA4FBC33555BB7B829EF0DEC28BAEE@EUSAACMS0701.eamcs.ericsson.se> To: Steve Baillargeon Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_AKlTeDXikBStly/hNJn4Lg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28BAEE@EUSAACMS0701.eamcs.ericsson.se> Cc: "Chimento, Philip F." , IETF IPPM WG Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:05:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_AKlTeDXikBStly/hNJn4Lg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Steve=2C =3E This is my last email on this exchange=2E =3E The IETF MIBs have defined separate MIBs for each layer=2E Which RFC or draft=3F =3E Therefore stats should be produced at each layer as well=2E =3E The standards have allowed for a GE link utilization to be at 10=25 = =3E while the IP link utilization is at 100=25=2E Imho=2C you did bring a new terminology of =22IP link=22 to IPPM =2E=2E=2E= Xiangsong =3E = =3E = =3E -Steve =3E = =3E = =3E = =3E = =3E = =3E -----Original Message----- =3E From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf=2Eo= rg=5D On = =3E Behalf Of Xiangsong Cui =3E Sent=3A April-01-11 2=3A33 AM =3E To=3A Joseph Ishac =3E Cc=3A Chimento=2C Philip F=2E=3B IETF IPPM WG =3E Subject=3A Re=3A =5Bippm=5D Impact of hosts on network capacity and R= FC 5136 =3E = =3E Joseph=2C = =3E = =3E thanks for your answer=2C but I think I still don=27t undersand that=2E= =3E = =3E I don=27t understand what =22link is saturated=22 means=2C for the ex= ample = =3E of my slides=2C in the Gb ethernet=2C 1M bit flow is saturated for th= e = =3E ethernet link=3F My answer is no=2C because link is a layer 2 notion=2C= = =3E we have to judge its status in layer 2 viewpoint=2E =3E = =3E It comes back to the basic question=2C should the node is part of lin= k=3F =3E = =3E What I want to say is=2C if we say node is part of link=2C perhaps we= = =3E have to say the Internet is the set of =22links=22=2C there is no hos= t=2C = =3E no router=2C no NAT=2C no firewall=2C no ALG =2E=2E=2E=2C is that str= ange=3F Aha=2C = =3E because all these nodes are inside the links=2E =3E = =3E Best Regards =3E Xiangsong =3E = =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CB=C4=D4=C2 1=C8=D5=2C 2011 =C9= =CF=CE=E75=3A52 =3E =D6=F7=CC=E2=3A Re=3A =5Bippm=5D Impact of hosts on network capacity = and RFC 5136 =3E =CA=D5=BC=FE=C8=CB=3A Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom= =3E =3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChimento=40= jhuapl=2Eedu=3E=2C IETF IPPM = =3E WG =3Cippm=40ietf=2Eorg=3E =3E = =3E =3E Well=2C for a given packet type=2C Used(L=2CT=2CI) measures the *= actual* = =3E usage = =3E =3E in a given time span=2E C(L=2CT=2CI) is the maximum you *could* = =3E obtain in = =3E =3E that same time span=2E So if the link is not actually saturated = =3E with = =3E =3E traffic=2C the link utilization will not be 100=25=2E =3E =3E = =3E =3E If you try to think of actually trying to measure C() and Used() = =3E at = =3E =3E the same time=2C you=27re bound to get a headache=2E That=27s wh= y = =3E developing = =3E =3E the means of gathering the metrics was out of scope for the = =3E document=2E=3E = =3E =3E Does that help answer your question=3F =3E =3E = =3E =3E -Joseph =3E =3E = =3E =3E 2011/3/31 Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E=3A =3E =3E =3E I=27m wondering in what scenario=2C the link utilization is n= ot =3E =3E equal to 100=25=3F =3E =3E =3E Who can tell me what type the link utilization is=2C it=27s b= ool =3E =3E type or float type number=3F =3E =3E =3E =3E =3E =3E Thanks for your teaching! =3E =3E =3E =3E =3E =3E Best Regards =3E =3E =3E Xiangsong =3E =3E =3E =3E =3E =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =3E =3E =B7=A2=BC=FE=C8=CB=3A Joseph Ishac =3Cjishac=40nasa=2Egov=3E =3E =3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CB=C4=D4=C2 1=C8=D5=2C= 2011 =C9=CF=CE=E72=3A16 =3E =3E =3E =D6=F7=CC=E2=3A Re=3A =5Bippm=5D Impact of hosts on network c= apacity and RFC 5136 =3E =3E =3E =CA=D5=BC=FE=C8=CB=3A IETF IPPM WG =3Cippm=40ietf=2Eorg=3E =3E =3E =3E =B3=AD=CB=CD=3A =22Chimento=2C Philip F=2E=22 =3CPhilip=2EChi= mento=40jhuapl=2Eedu=3E =3E =3E =3E =3E =3E =3E=3E Passing on by request a nice concise example I was sent by= = =3E Donald = =3E =3E =3E=3E McLachlan of crc=2Eca=3A =3E =3E =3E=3E =3E =3E =3E=3E =3E I think what you are saying (for instance) is that=3A =3E =3E =3E=3E =3E - Even if the path between the Src and Dst hosts (cabl= ing=2C =3E =3E =3E=3E switches etc) can support (eg=2E 10 Gbps) =3E =3E =3E=3E =3E - If the Sending host can only transmit at 10 Mbps =3E =3E =3E=3E =3E - then the effective Link Capacity (as seen by Src and= Dst) is =3E =3E =3E=3E at most 10 Mbps=2E =3E =3E =3E=3E =3E =3E =3E=3E I=27d like to add a few more examples that are covered by = the = =3E current = =3E =3E =3E=3E wording in RFC 5136=3A =3E =3E =3E=3E =3E =3E =3E=3E 1) Employing encoding on a link=2C several of our links us= e =3E =3E Reed=3FSolomon=3E=3E or rate 1/2 convolution encoding=2E =3E =3E =3E=3E 2) Passing through an underrated patch panel (say a Cat3 p= atch =3E =3E panel=3E=3E when your trying to do 1000GbE) =5Bincidentally don=27= t ask if =3E =3E I=27ve=3E=3E experienced this first hand =2E=2E=2E=5D =3E =3E =3E=3E =3E =3E =3E=3E The wording in the RFC is meant to cover such limitations = =3E with both = =3E =3E =3E=3E the links and nodes=2E =3E =3E =3E=3E =3E =3E =3E=3E -Joseph =3E =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F =3E =3E =3E=3E ippm mailing list =3E =3E =3E=3E ippm=40ietf=2Eorg =3E =3E =3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E =3E =3E=3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E ippm mailing list =3E =3E ippm=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E ippm mailing list =3E ippm=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E --Boundary_(ID_AKlTeDXikBStly/hNJn4Lg) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for Xiangsong Cui begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_AKlTeDXikBStly/hNJn4Lg)-- From gezihui@research.att.com Sun Apr 3 19:50:23 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FA73A68FA for ; Sun, 3 Apr 2011 19:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v7f33N-rYT4 for ; Sun, 3 Apr 2011 19:50:20 -0700 (PDT) Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by core3.amsl.com (Postfix) with ESMTP id C8B0E3A68F7 for ; Sun, 3 Apr 2011 19:50:19 -0700 (PDT) Received: from [192.168.0.13] ([135.207.102.54]) by bigmail.research.att.com (8.13.8+Sun/8.11.6) with ESMTP id p342q1eq020621 for ; Sun, 3 Apr 2011 22:52:01 -0400 (EDT) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 03 Apr 2011 22:52:01 -0400 From: Zihui Ge To: Message-ID: Thread-Topic: CFP: ACM CoNEXT 2011 Thread-Index: Acvyc0VrTaYOouXn50SlPPZsmvE7RQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [ippm] CFP: ACM CoNEXT 2011 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 02:52:07 -0000 --------------------------------------------------------------------- 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/ --------------------------------------------------------------------- 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 From henk@uijterwaal.nl Wed Apr 6 01:24:45 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164D83A681D for ; Wed, 6 Apr 2011 01:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76KFQRnrEUmS for ; Wed, 6 Apr 2011 01:24:43 -0700 (PDT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by core3.amsl.com (Postfix) with ESMTP id 783EC3A68D6 for ; Wed, 6 Apr 2011 01:24:43 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id p368QPfi083230 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Apr 2011 10:26:26 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4D9C23B1.8040205@uijterwaal.nl> Date: Wed, 06 Apr 2011 10:26:25 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF IPPM WG References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> In-Reply-To: <4D677893.2050200@ripe.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] WGLC for draft-ietf-ippm-reporting-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:24:45 -0000 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 Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Wed Apr 6 01:40:35 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208D13A69AE for ; Wed, 6 Apr 2011 01:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTscFKsDvkXo for ; Wed, 6 Apr 2011 01:40:34 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by core3.amsl.com (Postfix) with ESMTP id EAC433A68E6 for ; Wed, 6 Apr 2011 01:40:33 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id p368gF4R046747 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 10:42:16 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4D9C2767.1070407@uijterwaal.nl> Date: Wed, 06 Apr 2011 10:42:15 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yaakov Stein , IETF IPPM WG 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: [ippm] Presentation in Prague X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:40:35 -0000 Yaakov, Thank you for providing a slide pack with OWAMP/TWAMP issues for our Prague meeting. The slides were discussed but there was not sufficient expertise in the room to answer all questions. May I suggest that you post the issues to the list and give people a chance to comment. Depending on the outcome, we may file errata or write an update to the specs. If you consider this useful, I can try to set up an issue tracker for this. Thanks, Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Wed Apr 6 01:54:27 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F199828C0E7 for ; Wed, 6 Apr 2011 01:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BXzzq6xF4Q9 for ; Wed, 6 Apr 2011 01:54:26 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by core3.amsl.com (Postfix) with ESMTP id B9EB728C0DB for ; Wed, 6 Apr 2011 01:54:25 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id p368u8AR046544 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Apr 2011 10:56:08 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4D9C2AA7.3090209@uijterwaal.nl> Date: Wed, 06 Apr 2011 10:56:07 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ippm@ietf.org References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28BAEE@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: 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: [ippm] RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:54:27 -0000 IPPM group, We have had both email and voice discussions on this RFC over the last week. The mail that summarizes the issue, is, IMHO, this one: http://www.ietf.org/mail-archive/web/ippm/current/msg02585.html (with some follow-ups). I'd like to close this issue. If you were involved in this discussion, please indicate if there is anything to be said on the topic that hasn't been brought up before. If no new issues are raised, we'll make sure that the above gets documented somehow and the issue is solved. If there is more to discuss, we can do so. Deadline for responding is April 13, i.e. next week. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From steve.baillargeon@ericsson.com Wed Apr 6 05:42:41 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37CD3A693E for ; Wed, 6 Apr 2011 05:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.211 X-Spam-Level: X-Spam-Status: No, score=-5.211 tagged_above=-999 required=5 tests=[AWL=1.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkNYxinluTAB for ; Wed, 6 Apr 2011 05:42:39 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 8DEFD3A692E for ; Wed, 6 Apr 2011 05:42:39 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p36CiMtm011375; Wed, 6 Apr 2011 07:44:23 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 6 Apr 2011 08:44:17 -0400 From: Steve Baillargeon To: Henk Uijterwaal Date: Wed, 6 Apr 2011 08:44:15 -0400 Thread-Topic: [ippm] RFC 5136 Thread-Index: Acv0OIxPpYu2WJwxSbCE1bGmP+ss7AAHmGmg Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC3511FF@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28BAEE@EUSAACMS0701.eamcs.ericsson.se> <4D9C2AA7.3090209@uijterwaal.nl> In-Reply-To: <4D9C2AA7.3090209@uijterwaal.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_4383945B8C24AA4FBC33555BB7B829EF0DEC3511FFEUSAACMS0701e_" MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: Re: [ippm] RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:42:41 -0000 --_002_4383945B8C24AA4FBC33555BB7B829EF0DEC3511FFEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Henk I have nothing new to add except to repeat my last question highlighted in = the enclosed email. I think Philip and Joseph are willing to look into the possibility to creat= e a standard track document. -Steve =20 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: April-06-11 4:56 AM To: ippm@ietf.org Subject: [ippm] RFC 5136 IPPM group, We have had both email and voice discussions on this RFC over the last week= . The mail that summarizes the issue, is, IMHO, this one: http://www.ietf.org/mail-archive/web/ippm/current/msg02585.html (with some follow-ups). I'd like to close this issue. If you were involved in this discussion, ple= ase indicate if there is anything to be said on the topic that hasn't been brought up before. If no new issues are raised, we'll make sure that the above gets documented somehow and the issue is solved. If there i= s more to discuss, we can do so. Deadline for responding is April 13, i.e.= next week. Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ---------------------------------------------------------------------------= --- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project= ) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_002_4383945B8C24AA4FBC33555BB7B829EF0DEC3511FFEUSAACMS0701e_ Content-Type: message/rfc822 From: Steve Baillargeon To: Joseph Ishac , "Chimento, Philip F." CC: Henk Uijterwaal , Matthew J Zekauskas , IETF IPPM WG Date: Fri, 1 Apr 2011 04:05:34 -0400 Subject: Standard Track for Capacity Thread-Topic: Standard Track for Capacity Thread-Index: AcvwQ5PiW5mMy0UOQWK31PWQJ6uTdw== X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Joseph, Hi Philip I noticed that RFC 5136 is informational. Is it possible to discuss the possibility to move it to a standard track (w= ith the required additions)? Or create a separate document that will become an Internet standard entitle= d "Capacity Metrics"? What do you think? -Steve --_002_4383945B8C24AA4FBC33555BB7B829EF0DEC3511FFEUSAACMS0701e_-- From acmorton@att.com Wed Apr 6 05:55:37 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3273C28C0D7 for ; Wed, 6 Apr 2011 05:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.675 X-Spam-Level: X-Spam-Status: No, score=-105.675 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B2mZRgz5cLi for ; Wed, 6 Apr 2011 05:55:35 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 574A53A6938 for ; Wed, 6 Apr 2011 05:55:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1302094638!4269968!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 19203 invoked from network); 6 Apr 2011 12:57:18 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Apr 2011 12:57:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p36Cvg8X015904 for ; Wed, 6 Apr 2011 08:57:42 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p36Cvd8p015885 for ; Wed, 6 Apr 2011 08:57:39 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p36CvEFV025098 for ; Wed, 6 Apr 2011 08:57:15 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p36Cv9wm024863 for ; Wed, 6 Apr 2011 08:57:09 -0400 Message-Id: <201104061257.p36Cv9wm024863@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110406125708gw100e4l41e>; Wed, 6 Apr 2011 12:57:09 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Apr 2011 08:57:48 -0400 To: Henk Uijterwaal , ippm@ietf.org From: Al Morton In-Reply-To: <4D9C2AA7.3090209@uijterwaal.nl> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC28BAEE@EUSAACMS0701.eamcs.ericsson.se> <4D9C2AA7.3090209@uijterwaal.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:55:37 -0000 To capture (and expand on) what I suggested at the meeting, the last 3 paragraphs would make a good Eratta for the RFC, beginning with a new sentence and an edit in the next, as shown below: There is a term ("Link") in RFC 5136 that is used differently from the same term in RFC 2330, and this has caused some confusion. To summarize the network framework of RFC 5136, we define nodes as hosts, ^^^^^^^^^^^^^^^^^^^^^^^^ ... hope this helps, Al At 04:56 AM 4/6/2011, Henk Uijterwaal wrote: >IPPM group, > >We have had both email and voice discussions on this RFC over the last >week. The mail that summarizes the issue, is, IMHO, this one: > > http://www.ietf.org/mail-archive/web/ippm/current/msg02585.html > >(with some follow-ups). > >I'd like to close this issue. If you were involved in this discussion, >please indicate if there is anything to be said on the topic that hasn't >been brought up before. If no new issues are raised, we'll make sure >that the above gets documented somehow and the issue is solved. If there >is more to discuss, we can do so. Deadline for responding is April 13, >i.e. next week. > >Henk > >-- >------------------------------------------------------------------------------ >Henk Uijterwaal Email: henk(at)uijterwaal.nl >RIPE NCC http://www.xs4all.nl/~henku > Phone: +31.6.55861746 >------------------------------------------------------------------------------ > >There appears to have been a collective retreat from reality that day. > (John Glanfield, on an engineering project) >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From vze275m9@verizon.net Wed Apr 6 06:05:00 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDCE28C0EB for ; Wed, 6 Apr 2011 06:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khUqJp8tryh2 for ; Wed, 6 Apr 2011 06:04:59 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id C7AB828C0DD for ; Wed, 6 Apr 2011 06:04:59 -0700 (PDT) Received: from vznit170076 ([unknown] [172.18.12.131]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LJ800MI4F2WO0Y0@vms173005.mailsrvcs.net> for ippm@ietf.org; Wed, 06 Apr 2011 08:06:33 -0500 (CDT) Received: from 128.244.9.7 ([128.244.9.7]) by vznit170076 (Verizon Webmail) with HTTP; Wed, 06 Apr 2011 08:06:32 -0500 (CDT) Date: Wed, 06 Apr 2011 08:06:32 -0500 (CDT) From: vze275m9@verizon.net To: acmorton@att.com Message-id: <1148962926.1814524.1302095192972.JavaMail.root@vznit170076> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Originating-IP: [128.244.9.7] Cc: ippm@ietf.org Subject: Re: [ippm] RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pfc@ieee.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:05:01 -0000 Al: That sounds good to me. Joseph and I will work on it and submit an erra= tum. Thanks for the suggestion.
Steve: I think that it is up to the cha= irs and the WG at large to determine if they want to do additional work on = capacity. I have two questions: Is there sufficient interest? and Does it f= it into the current WG scope?

Regards,
Phil Chimento

Apr= 6, 2011 08:57:40 AM, acmorton@att.com wrote:
To capture (and expand on) what I su= ggested at the meeting,
the last 3 paragraphs would make a good Eratta f= or the RFC,
beginning with a new sentence and an edit in the next,
as= shown below:

There is a term ("Link") in RFC 5136 that is used diff= erently from
the same term in RFC 2330, and this has caused some confusi= on.

To summarize the network framework of RFC 5136, we define nodes = as hosts,
^^^^^^^^^^^^^^^^^^^^^^^^
...

hope this helps,
Al


At 04:56 AM 4/6/2011, Henk= Uijterwaal wrote:
>IPPM group,
>
>We have had both email= and voice discussions on this RFC over the last
>week. The mail tha= t summarizes the issue, is, IMHO, this one:
>
> http://www.i= etf.org/mail-archive/web/ippm/current/msg02585.html
>
>(with so= me follow-ups).
>
>I'd like to close this issue. If you were i= nvolved in this discussion,
>please indicate if there is anything to = be said on the topic that hasn't
>been brought up before. If no new= issues are raised, we'll make sure
>that the above gets documented s= omehow and the issue is solved. If there
>is more to discuss, we can= do so. Deadline for responding is April 13,
>i.e. next week.
>= ;
>Henk
>
>--
>------------------------------------= ------------------------------------------
>Henk Uijterwaal = Email: henk(at)uijterwaal.nl
>RIPE NCC = http://www.xs4all.nl/~henku
> = Phone: +31.6.55861746
>-----------------------= -------------------------------------------------------
>
>Ther= e appears to have been a collective retreat from reality that day.
> = (John Glanfield, on an engineering project= )
>_______________________________________________
>ippm mailin= g list
>ippm@ietf.org
>https://www.ietf.org/mailman/listinfo/ip= pm

_______________________________________________
ippm mailing l= ist
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
From steve.baillargeon@ericsson.com Wed Apr 6 06:41:33 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C0B28C0EF for ; Wed, 6 Apr 2011 06:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.384 X-Spam-Level: X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8Nqm5c4VZ1D for ; Wed, 6 Apr 2011 06:41:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id B8A8A3A67B2 for ; Wed, 6 Apr 2011 06:41:32 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p36DhF5e019966 for ; Wed, 6 Apr 2011 08:43:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 6 Apr 2011 09:43:14 -0400 From: Steve Baillargeon To: "ippm@ietf.org" Date: Wed, 6 Apr 2011 09:43:13 -0400 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv0YJMZhr61LuYySxudko5wnhGF6w== Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4383945B8C24AA4FBC33555BB7B829EF0DEC351277EUSAACMS0701e_" MIME-Version: 1.0 Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:41:33 -0000 --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC351277EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Can I ask the chairs to determine if there is interest to adopt the Value-A= dded Octets draft as a WG document? Thank you -Steve --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC351277EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
Can I ask the chairs to determine if there is interest to adopt the Va= lue-Added Octets draft as a WG document?
 
Thank you
 
-Steve
 
 
 
 
 
 --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC351277EUSAACMS0701e_-- From iesg-secretary@ietf.org Wed Apr 6 12:44:39 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369503A6980; Wed, 6 Apr 2011 12:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-EaQef3lqJq; Wed, 6 Apr 2011 12:44:38 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0741028C0DE; Wed, 6 Apr 2011 12:44:38 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.15 Message-ID: <20110406194438.31232.71401.idtracker@localhost> Date: Wed, 06 Apr 2011 12:44:38 -0700 Cc: ippm@ietf.org Subject: [ippm] Last Call: (Framework for TCP Throughput Testing) to Informational RFC X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 19:44:39 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Framework for TCP Throughput Testing' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ippm-tcp-throughput-tm/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-tcp-throughput-tm/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1319/ From steve.baillargeon@ericsson.com Wed Apr 6 14:06:02 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A093A67C2 for ; Wed, 6 Apr 2011 14:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMSodAimTjO0 for ; Wed, 6 Apr 2011 14:06:01 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 30B6A3A63D3 for ; Wed, 6 Apr 2011 14:06:01 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p36L7fMa009144 for ; Wed, 6 Apr 2011 16:07:44 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 6 Apr 2011 17:07:41 -0400 From: Steve Baillargeon To: "ippm@ietf.org" Date: Wed, 6 Apr 2011 17:07:39 -0400 Thread-Topic: [ippm] WGLC for draft-ietf-ippm-reporting-06.txt Thread-Index: Acv0NFbZ8pyA++I6RmWAzHYFXT8fOAAYJDiw Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC35172D@EUSAACMS0701.eamcs.ericsson.se> References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> <4D9C23B1.8040205@uijterwaal.nl> In-Reply-To: <4D9C23B1.8040205@uijterwaal.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] WGLC for draft-ietf-ippm-reporting-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:06:02 -0000 Hi Stanislav, Hi Martin Here are my comments. - Section 2. The TWAMP protocol can also be used for obtaining the measurem= ent data to compute any metrics including one-way metrics. - Section 4. In the list, can you explicitly indicate that the "small set" = of metrics can be one-way metrics, two-way metrics or both? Sections 4.1 to= 4.5 almost imply there are one-way metrics. Reading section 5 and 5.2, I t= hink you indicate that one-way metrics are preferred but two-way metrics ma= y also be reported. Right? - Section 4. How will a vendor state compliancy to this RFC? Does one need = to support the reporting of all of the metrics in the "small set"? - Section 4. Should we consider adding a "temporal connectivity" metric to = the list as defined in RFC2678? It seems like a very basic and essential me= tric. During the measurement test, if a successful packet or reply is recei= ved, the value of the measurement is "true". I know it may seems to overlap= with delay and loss metrics but operators treat it separately. - Section 5.1. I understand that there are different measurement protocols = with different minimum packet sizes. But what is the actual default packet = size? If you don't explicitly indicate it, the implementation will always h= ave to report the packet size since the user cannot easily derive it. The o= ther option is to remove the statement. - General comment. Have you considered defining a MIB as well your draft? A= s far as I know, the IETF has always favored the reporting of stats in well= -defined MIB. I think it will help to compare performance reports from diff= erent implementations. Regards Steve B -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: April-06-11 4:26 AM To: IETF IPPM WG Subject: [ippm] WGLC for draft-ietf-ippm-reporting-06.txt 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 U= TC. An URL for the draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-reporting/?include_text= =3D1 Matt & Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ---------------------------------------------------------------------------= --- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project= ) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From henk@uijterwaal.nl Thu Apr 7 01:08:35 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CEFA28C108 for ; Thu, 7 Apr 2011 01:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCxFaHalQX7E for ; Thu, 7 Apr 2011 01:08:34 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by core3.amsl.com (Postfix) with ESMTP id 643713A67F3 for ; Thu, 7 Apr 2011 01:08:34 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id p3789sZM002662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 10:10:03 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4D9D7152.7060004@uijterwaal.nl> Date: Thu, 07 Apr 2011 10:09:54 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: pfc@ieee.org References: <1148962926.1814524.1302095192972.JavaMail.root@vznit170076> In-Reply-To: <1148962926.1814524.1302095192972.JavaMail.root@vznit170076> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: ippm@ietf.org, vze275m9@verizon.net, acmorton@att.com Subject: Re: [ippm] RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 08:08:35 -0000 On 06/04/2011 15:06, vze275m9@verizon.net wrote: > Al: That sounds good to me. Joseph and I will work on it and submit an erratum. > Thanks for the suggestion. > Steve: I think that it is up to the chairs and the WG at large to determine if > they want to do additional work on capacity. I have two questions: Is there > sufficient interest? and Does it fit into the current WG scope? It definitely fits into the charter, speak up if you are interested in working on this. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Thu Apr 7 01:11:43 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D9828C117 for ; Thu, 7 Apr 2011 01:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyFjBJg1fcRi for ; Thu, 7 Apr 2011 01:11:42 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by core3.amsl.com (Postfix) with ESMTP id BA6C728C105 for ; Thu, 7 Apr 2011 01:11:41 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id p378DP19005068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 7 Apr 2011 10:13:25 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4D9D7225.6080506@uijterwaal.nl> Date: Thu, 07 Apr 2011 10:13:25 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ippm@ietf.org References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@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 Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 08:11:43 -0000 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) From henk@uijterwaal.nl Thu Apr 7 01:13:29 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E863C28C108 for ; Thu, 7 Apr 2011 01:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaZd5Ct085Hr for ; Thu, 7 Apr 2011 01:13:29 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by core3.amsl.com (Postfix) with ESMTP id C153E28C105 for ; Thu, 7 Apr 2011 01:13:28 -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 p378FBIT096777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 7 Apr 2011 10:15:12 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4D9D728F.8040402@uijterwaal.nl> Date: Thu, 07 Apr 2011 10:15:11 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ippm@ietf.org References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> In-Reply-To: <4D9D7225.6080506@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] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 08:13:30 -0000 On 07/04/2011 10:13, Henk Uijterwaal wrote: > 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. And as a participant: I support this document becoming a WG document. There are more ideas in this direction, including work presented by Yaakov in Prague. I think it'd be good if the next iteration of the draft tried to combine all ideas. Henk (as a WG participant) -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From Barry.Constantine@jdsu.com Thu Apr 7 04:31:23 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB463A68FD for ; Thu, 7 Apr 2011 04:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx+2OAzvGKTf for ; Thu, 7 Apr 2011 04:31:22 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id 1ABD83A68C4 for ; Thu, 7 Apr 2011 04:31:18 -0700 (PDT) Received: from mx6.jdsu.com ([209.36.247.248]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ2g7qg46PAO0ymivtkSiU3aZXoBLzXU@postini.com; Thu, 07 Apr 2011 04:33:06 PDT Received: from milexhtca1.ds.jdsu.net (192.168.10.158) by mx6.jdsu.com (192.168.10.248) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 7 Apr 2011 04:27:36 -0700 Received: from MILEXCH1.ds.jdsu.net ([10.75.2.115]) by milexhtca1.ds.jdsu.net ([::1]) with mapi; Thu, 7 Apr 2011 04:27:44 -0700 From: Barry Constantine To: Henk Uijterwaal , "ippm@ietf.org" Date: Thu, 7 Apr 2011 04:27:41 -0700 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv0+7AoCNGtBcHER+mBwq4QB0/K0AAGwGgg Message-ID: <94DEE80C63F7D34F9DC9FE69E39436BE3A043BC54D@MILEXCH1.ds.jdsu.net> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> In-Reply-To: <4D9D7225.6080506@uijterwaal.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 11:31:23 -0000 I support this draft work, plan to review it as it moves along. -Barry -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: Thursday, April 07, 2011 4:13 AM 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 becom= e 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) --=20 ---------------------------------------------------------------------------= --- 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 acmorton@att.com Thu Apr 7 05:30:07 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF2528C128 for ; Thu, 7 Apr 2011 05:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.692 X-Spam-Level: X-Spam-Status: No, score=-105.692 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vtaASXOkeof for ; Thu, 7 Apr 2011 05:30:06 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 5A3E43A690C for ; Thu, 7 Apr 2011 05:30:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1302179510!11646478!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 1443 invoked from network); 7 Apr 2011 12:31:50 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Apr 2011 12:31:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p37CWEuk003352 for ; Thu, 7 Apr 2011 08:32:14 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p37CW86Z003259 for ; Thu, 7 Apr 2011 08:32:08 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p37CVhDf010009 for ; Thu, 7 Apr 2011 08:31:43 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p37CVbar009830 for ; Thu, 7 Apr 2011 08:31:38 -0400 Message-Id: <201104071231.p37CVbar009830@alpd052.aldc.att.com> Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110407123137gw100e4l82e>; Thu, 7 Apr 2011 12:31:37 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Apr 2011 08:32:17 -0400 To: Henk Uijterwaal , ippm@ietf.org From: Al Morton In-Reply-To: <4D9D728F.8040402@uijterwaal.nl> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4D9D728F.8040402@uijterwaal.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:30:07 -0000 At 04:15 AM 4/7/2011, Henk Uijterwaal wrote: >... > >There are more ideas in this direction, including work presented by Yaakov in >Prague. I think it'd be good if the next iteration of the draft tried to >combine all ideas. ...or at least, the ideas that make sense to be combined. I thought this was the next step we agreed at the meeting (then ask about adoption once the work was organized into chunks), It can still be worked this way, but on a schedule longer than 2 weeks. Al From steve.baillargeon@ericsson.com Thu Apr 7 05:51:43 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0F93A692D for ; Thu, 7 Apr 2011 05:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LVmF-lJDOoX for ; Thu, 7 Apr 2011 05:51:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id A116228C0E1 for ; Thu, 7 Apr 2011 05:51:40 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p37CrBn9022004; Thu, 7 Apr 2011 07:53:12 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 7 Apr 2011 08:53:04 -0400 From: Steve Baillargeon To: Henk Uijterwaal , "pfc@ieee.org" Date: Thu, 7 Apr 2011 08:53:04 -0400 Thread-Topic: [ippm] RFC 5136 Thread-Index: Acv0+0BFVmgVGuuoSMGEjNCx2wFJfAAJlHDQ Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC3518EE@EUSAACMS0701.eamcs.ericsson.se> References: <1148962926.1814524.1302095192972.JavaMail.root@vznit170076> <4D9D7152.7060004@uijterwaal.nl> In-Reply-To: <4D9D7152.7060004@uijterwaal.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "acmorton@att.com" , "vze275m9@verizon.net" , "ippm@ietf.org" Subject: Re: [ippm] RFC 5136 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:51:43 -0000 I support this new work.=20 As indicated by Joseph in a separate email, it will be important to clarify= the scope of the new work as well. For instance, is the goal to move the I= nformational RFC to Standard Track or create a new Standard Track? Persona= lly speaking, I prefer the "move up" option with the required delta. -Steve=20 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: April-07-11 4:10 AM To: pfc@ieee.org Cc: ippm@ietf.org; vze275m9@verizon.net; acmorton@att.com Subject: Re: [ippm] RFC 5136 On 06/04/2011 15:06, vze275m9@verizon.net wrote: > Al: That sounds good to me. Joseph and I will work on it and submit an er= ratum. > Thanks for the suggestion. > Steve: I think that it is up to the chairs and the WG at large to=20 > determine if they want to do additional work on capacity. I have two=20 > questions: Is there sufficient interest? and Does it fit into the current= WG scope? It definitely fits into the charter, speak up if you are interested in work= ing on this. Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ---------------------------------------------------------------------------= --- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project= ) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From steve.baillargeon@ericsson.com Thu Apr 7 07:52:01 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6206F28C0E6 for ; Thu, 7 Apr 2011 07:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEEmbwW+u1n4 for ; Thu, 7 Apr 2011 07:52:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 65ACA28C0CE for ; Thu, 7 Apr 2011 07:52:00 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p37ErhI1009272; Thu, 7 Apr 2011 09:53:44 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 7 Apr 2011 10:53:38 -0400 From: Steve Baillargeon To: Al Morton , Henk Uijterwaal , "ippm@ietf.org" Date: Thu, 7 Apr 2011 10:53:37 -0400 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv1H8jU7nvMAFsqSAyDbS0978M/HwAByBkA Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC351A34@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4D9D728F.8040402@uijterwaal.nl> <201104071231.p37CVbar009830@alpd052.aldc.att.com> In-Reply-To: <201104071231.p37CVbar009830@alpd052.aldc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 14:52:01 -0000 Hi As indicated in the meeting #80, we think the TWAMP value-added octets draf= t is designed to accommodate all (or almost all) "capacity test measurement= s" in the context of TWAMP. The benefits are: - can be used for intrusive or non-intrusive capacity tests e.g. the size o= f the train and/or inter-packet interval will determine if a packet stream = is considered intrusive or not for a given network environment in a given d= irection. - can also be used for measuring other metrics One aspect we discussed briefly is the possibility to add a new field in th= e TWAMP value-added padding octets that will allow for a different train si= ze in the reverse direction. This would enable the following "new use cases= ": - 1) a "non-intrusive" capacity test in the forward direction with an "intr= usive" capacity test in the reverse direction via a larger train size. Howe= ver this use case can also be achieved with the current draft using the con= figuration of the appropriate train size at the source, a "slow" inter-pack= et interval in the forward direction and an "intrusive" inter-packet interv= al in the reverse direction. - 2) an "intrusive" capacity test in the forward direction with an "intrusi= ve" capacity test in the reverse direction where packets that are lost in t= he forward direction are "re-generated".=20 This can achieved by introducing a new field called "Tran Size" or "Reverse= Train Size" with its corresponding flag bit. The use of such new field will introduce significant changes to the Session= -Reflector and the reporting of the metrics. For instance: - If the reverse train size is smaller than the "forward train size", the S= ession-Reflector will need to "create" loss in the "reverse direction" and = one must be careful to avoid reporting the one-way packet loss in the rever= se direction or must account for it. This scenario may also skew the capaci= ty estimates for the forward direction if the train size is to small. - If the reverse train size is larger than the "forward train size" or if p= acket loss has occurred in the forward direction, what will be the values o= f the Receive Timestamp, Sender Sequence Number, Sender Timestamp, Sender E= rror Estimate? I am assuming they can all be set to zero except the error e= stimate. I am open to add/explore such new fields and new behaviors on top of the pr= oposed TWAMP Value-Added Octets Version 1 mode. On the other hand, we shoul= d carefully evaluate if it is best to keep the essence of current TWAMP Val= ue-Added Octets Version 1 mode which attempts to minimize changes to the Se= ssion-Reflector behaviors versus RFC5357. In my opinion, it will be best to= avoid adding more complexity to the current draft. -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al = Morton Sent: April-07-11 8:32 AM To: Henk Uijterwaal; ippm@ietf.org Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets At 04:15 AM 4/7/2011, Henk Uijterwaal wrote: >... > >There are more ideas in this direction, including work presented by=20 >Yaakov in Prague. I think it'd be good if the next iteration of the=20 >draft tried to combine all ideas. ...or at least, the ideas that make sense to be combined. I thought this was the next step we agreed at the meeting (then ask about a= doption once the work was organized into chunks), It can still be worked th= is way, but on a schedule longer than 2 weeks. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Thu Apr 7 11:36:14 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B2C3A695C for ; Thu, 7 Apr 2011 11:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.705 X-Spam-Level: X-Spam-Status: No, score=-105.705 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT1pcJRH2nL5 for ; Thu, 7 Apr 2011 11:36:13 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id CF25B3A67B0 for ; Thu, 7 Apr 2011 11:36:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1302201477!11716461!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 9924 invoked from network); 7 Apr 2011 18:37:58 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Apr 2011 18:37:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p37IcLaJ008383 for ; Thu, 7 Apr 2011 14:38:21 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p37IcGPD008312 for ; Thu, 7 Apr 2011 14:38:16 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p37IbpYw018503 for ; Thu, 7 Apr 2011 14:37:51 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p37Ibhke018202 for ; Thu, 7 Apr 2011 14:37:44 -0400 Message-Id: <201104071837.p37Ibhke018202@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110407183743gw100e4la5e>; Thu, 7 Apr 2011 18:37:43 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Apr 2011 14:38:22 -0400 To: ippm@ietf.org From: Al Morton In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DEC351A34@EUSAACMS0701.ea mcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4D9D728F.8040402@uijterwaal.nl> <201104071231.p37CVbar009830@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351A34@EUSAACMS0701.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 18:36:14 -0000 At 10:53 AM 4/7/2011, Steve Baillargeon wrote: >...One aspect we discussed briefly is the possibility to add a new >field in the TWAMP value-added padding octets that will allow for a >different train size in the reverse direction. Well, this separate proposal was to allow different test packet sizes to be used in the forward and reverse directions, that's right. But the session request would convey this information in a new Request-TW-Session command, since it would likely be static for the entire session. This is the more usual way to operate TWAMP: telling the Server/Session-Reflector everything needed in advance of Starting the test session. It's good that the value-added-octets proposal incorporates the TWAMP-Control protocol in the latest version (01). So now, I wonder if the *many* new test session packet formats found in the value-added-octets proposal could be simplified by moving some information currently conveyed in the Test session (via flags/fields) to the Control session? In other words, this proposal asks the Session-Reflector to perform many new operations, and perhaps adoption will be wider if less processing is expected during the test session. Of course, Request-TW-Session variables are static for the life of the test session, if accepted. regards, Al From steve.baillargeon@ericsson.com Thu Apr 7 12:24:49 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661D528C0E5 for ; Thu, 7 Apr 2011 12:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq9pkTSLZju9 for ; Thu, 7 Apr 2011 12:24:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 635F33A690A for ; Thu, 7 Apr 2011 12:24:48 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p37JQVnA028699; Thu, 7 Apr 2011 14:26:32 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 7 Apr 2011 15:26:25 -0400 From: Steve Baillargeon To: Al Morton , "ippm@ietf.org" Date: Thu, 7 Apr 2011 15:26:25 -0400 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv1Uu4UeQSuJDqVTO6+3/7a6h+A2AABGD6g Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC351CB2@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4D9D728F.8040402@uijterwaal.nl> <201104071231.p37CVbar009830@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351A34@EUSAACMS0701.eamcs.ericsson.se> <201104071837.p37Ibhke018202@alpd052.aldc.att.com> In-Reply-To: <201104071837.p37Ibhke018202@alpd052.aldc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:24:49 -0000 Hi Al I was referring to the train size, not the packet size. All test packets using the value-added octets (forward and reverse test pac= kets) belonging to a specific test session MUST have the same IP packet siz= e. This indicated in the draft as well.=20 We are not recommending to change the requirement on the packet size becaus= e it will make reporting and capacity measurements very difficult to do. If= a different packet size is needed, a new/different test session SHALL be e= stablished. -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al = Morton Sent: April-07-11 2:38 PM To: ippm@ietf.org Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets At 10:53 AM 4/7/2011, Steve Baillargeon wrote: >...One aspect we discussed briefly is the possibility to add a new=20 >field in the TWAMP value-added padding octets that will allow for a=20 >different train size in the reverse direction. Well, this separate proposal was to allow different test packet sizes to be= used in the forward and reverse directions, that's right. But the session request would convey this information in a new Request-TW-S= ession command, since it would likely be static for the entire session. Thi= s is the more usual way to operate TWAMP: telling the Server/Session-Reflector everything needed in advance of Starti= ng the test session. It's good that the value-added-octets proposal incorporates the TWAMP-Contr= ol protocol in the latest version (01). So now, I wonder if the *many* new test session packet formats found in the= value-added-octets proposal could be simplified by moving some information= currently conveyed in the Test session (via flags/fields) to the Control s= ession? In other words, this proposal asks the Session-Reflector to perfor= m many new operations, and perhaps adoption will be wider if less processin= g is expected during the test session. Of course, Request-TW-Session variab= les are static for the life of the test session, if accepted. regards, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Thu Apr 7 12:56:16 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D91428C110 for ; Thu, 7 Apr 2011 12:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.715 X-Spam-Level: X-Spam-Status: No, score=-105.715 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7DExPRkaYjU for ; Thu, 7 Apr 2011 12:56:14 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id D53F53A672F for ; Thu, 7 Apr 2011 12:56:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1302206277!10062454!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 18906 invoked from network); 7 Apr 2011 19:57:58 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Apr 2011 19:57:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p37JwMwX031485 for ; Thu, 7 Apr 2011 15:58:22 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p37JwITi031399 for ; Thu, 7 Apr 2011 15:58:18 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p37Jvrtu029039 for ; Thu, 7 Apr 2011 15:57:53 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p37Jvm2i028864 for ; Thu, 7 Apr 2011 15:57:49 -0400 Message-Id: <201104071957.p37Jvm2i028864@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110407195747gw100e4lase>; Thu, 7 Apr 2011 19:57:48 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Apr 2011 15:58:26 -0400 To: Steve Baillargeon , "ippm@ietf.org" From: Al Morton In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DEC351CB2@EUSAACMS0701.ea mcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4D9D728F.8040402@uijterwaal.nl> <201104071231.p37CVbar009830@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351A34@EUSAACMS0701.eamcs.ericsson.se> <201104071837.p37Ibhke018202@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351CB2@EUSAACMS0701.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:56:16 -0000 Ok, I thought you were referring to other proposals which were discussed, and the suggestion of combining what makes sense, but apparently not. My comment below on the tendency toward placing Control in the Test Session in this proposal is still worth a look, I think. Al At 03:26 PM 4/7/2011, Steve Baillargeon wrote: >Hi Al >I was referring to the train size, not the packet size. >All test packets using the value-added octets (forward and reverse >test packets) belonging to a specific test session MUST have the >same IP packet size. This indicated in the draft as well. >We are not recommending to change the requirement on the packet size >because it will make reporting and capacity measurements very >difficult to do. If a different packet size is needed, a >new/different test session SHALL be established. > >-Steve > >-----Original Message----- >From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf >Of Al Morton >Sent: April-07-11 2:38 PM >To: ippm@ietf.org >Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > >At 10:53 AM 4/7/2011, Steve Baillargeon wrote: > >...One aspect we discussed briefly is the possibility to add a new > >field in the TWAMP value-added padding octets that will allow for a > >different train size in the reverse direction. > >Well, this separate proposal was to allow different test packet >sizes to be used in the forward and reverse directions, that's right. > >But the session request would convey this information in a new >Request-TW-Session command, since it would likely be static for the >entire session. This is the more usual way to operate TWAMP: >telling the Server/Session-Reflector everything needed in advance of >Starting the test session. > >It's good that the value-added-octets proposal incorporates the >TWAMP-Control protocol in the latest version (01). > >So now, I wonder if the *many* new test session packet formats found >in the value-added-octets proposal could be simplified by moving >some information currently conveyed in the Test session (via >flags/fields) to the Control session? In other words, this proposal >asks the Session-Reflector to perform many new operations, and >perhaps adoption will be wider if less processing is expected during >the test session. Of course, Request-TW-Session variables are static >for the life of the test session, if accepted. > >regards, >Al > >_______________________________________________ >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 steve.baillargeon@ericsson.com Thu Apr 7 14:08:29 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4433A6977 for ; Thu, 7 Apr 2011 14:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbsfcxQwNcww for ; Thu, 7 Apr 2011 14:08:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id E2A4A3A6974 for ; Thu, 7 Apr 2011 14:08:27 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p37LAApV016111; Thu, 7 Apr 2011 16:10:11 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 7 Apr 2011 17:10:07 -0400 From: Steve Baillargeon To: Al Morton , "ippm@ietf.org" Date: Thu, 7 Apr 2011 17:10:05 -0400 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv1Xh/29lKbn6muQeaHUBxSIXo1wQAAD7fg Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC351E07@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4D9D728F.8040402@uijterwaal.nl> <201104071231.p37CVbar009830@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351A34@EUSAACMS0701.eamcs.ericsson.se> <201104071837.p37Ibhke018202@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351CB2@EUSAACMS0701.eamcs.ericsson.se> <201104071957.p37JvmYg028863@alpd052.aldc.att.com> In-Reply-To: <201104071957.p37JvmYg028863@alpd052.aldc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 21:08:29 -0000 Hi Al I don't see much values to add the proposed fields in the TWAMP control pro= tocol because they are specifically applicable to the handling of the test = packets. For instance, carrying the Last SeqNo in the Train in the control protocol = is not useful since it may/will change on a per test packet basis. Same thi= ng for the Desired Reverse Packet Interval. Carrying the Sender Discriminator field in the TWAMP control protocol is a = possibility via a new definition of the Type-P descriptor for instance (e.g= . first two bits is 02 followed by SD). It will bring some benefits to the= solution but will not necessarily reduce complexity on the Session-Reflect= or. With or without the SD, the Session-Reflector (in most cases) needs to = continue inspecting various fields on a per test packet basis in order to m= atch the packets to the correct session. The flags are proposed in the test session in order to avoid creating/alloc= ating a large number of TWAMP modes with a large number of corresponding "f= ixed" test packet formats. Our proposal is to use a single mode that has a = single "variable" test packet format that is easy to parse through. On the = contrary, it helps reduce complexity for products supporting TWAMP. The oth= er option to completely remove the flags but this will remove the flexibili= ty to use the format for other purposes and re-open the case for creating a= larger number of modes and packet formats in the future. -Steve =20 -----Original Message----- From: Al Morton [mailto:acmorton@att.com]=20 Sent: April-07-11 3:58 PM To: Steve Baillargeon; ippm@ietf.org Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Ok, I thought you were referring to other proposals which were discussed, a= nd the suggestion of combining what makes sense, but apparently not. My comment below on the tendency toward placing Control in the Test Session= in this proposal is still worth a look, I think. Al At 03:26 PM 4/7/2011, Steve Baillargeon wrote: >Hi Al >I was referring to the train size, not the packet size. >All test packets using the value-added octets (forward and reverse test=20 >packets) belonging to a specific test session MUST have the same IP=20 >packet size. This indicated in the draft as well. >We are not recommending to change the requirement on the packet size=20 >because it will make reporting and capacity measurements very difficult=20 >to do. If a different packet size is needed, a new/different test=20 >session SHALL be established. > >-Steve > >-----Original Message----- >From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of=20 >Al Morton >Sent: April-07-11 2:38 PM >To: ippm@ietf.org >Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > >At 10:53 AM 4/7/2011, Steve Baillargeon wrote: > >...One aspect we discussed briefly is the possibility to add a new=20 > >field in the TWAMP value-added padding octets that will allow for a=20 > >different train size in the reverse direction. > >Well, this separate proposal was to allow different test packet sizes=20 >to be used in the forward and reverse directions, that's right. > >But the session request would convey this information in a new=20 >Request-TW-Session command, since it would likely be static for the=20 >entire session. This is the more usual way to operate TWAMP: >telling the Server/Session-Reflector everything needed in advance of=20 >Starting the test session. > >It's good that the value-added-octets proposal incorporates the=20 >TWAMP-Control protocol in the latest version (01). > >So now, I wonder if the *many* new test session packet formats found in=20 >the value-added-octets proposal could be simplified by moving some=20 >information currently conveyed in the Test session (via >flags/fields) to the Control session? In other words, this proposal=20 >asks the Session-Reflector to perform many new operations, and perhaps=20 >adoption will be wider if less processing is expected during the test=20 >session. Of course, Request-TW-Session variables are static for the=20 >life of the test session, if accepted. > >regards, >Al > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Thu Apr 7 17:13:29 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9A83A67EB for ; Thu, 7 Apr 2011 17:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.601 X-Spam-Level: X-Spam-Status: No, score=-105.601 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yswjx6n7Gnlf for ; Thu, 7 Apr 2011 17:13:28 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 2354A3A6948 for ; Thu, 7 Apr 2011 17:13:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1302221712!13225935!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 14721 invoked from network); 8 Apr 2011 00:15:12 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2011 00:15:12 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p380Fa0l005946 for ; Thu, 7 Apr 2011 20:15:36 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p380FYQ1005883 for ; Thu, 7 Apr 2011 20:15:34 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p380F9Mi007869 for ; Thu, 7 Apr 2011 20:15:09 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p380F2FT007662 for ; Thu, 7 Apr 2011 20:15:02 -0400 Message-Id: <201104080015.p380F2FT007662@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-247-137.vpn.east.att.com[135.70.247.137](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110408001501gw100e4lb7e>; Fri, 8 Apr 2011 00:15:02 +0000 X-Originating-IP: [135.70.247.137] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Apr 2011 20:15:42 -0400 To: "ippm@ietf.org" From: Al Morton In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DEC351E07@EUSAACMS0701.ea mcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4D9D728F.8040402@uijterwaal.nl> <201104071231.p37CVbar009830@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351A34@EUSAACMS0701.eamcs.ericsson.se> <201104071837.p37Ibhke018202@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351CB2@EUSAACMS0701.eamcs.ericsson.se> <201104071957.p37JvmYg028863@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351E07@EUSAACMS0701.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 00:13:29 -0000 Steve, It seems that we're not on the same page here, so I won't pick-apart what you said... From my POV, the Session-Reflector needs to be the most efficient process in the system. So, I don't understand sparing the non-real-time Control process from complexity, while adding much more complexity (including the ability to revise the task on a dynamic basis) to the real-time process of Reflector. I'm not sure you need a lot of Mode code points to move functions to Control, either, because it seems that a new Request-TW-Session command could convey most of the info in new fields for static test sessions (instead of last sequence number in a train, use constant train length in packets, and similar substitutions). It's an opinion on an option, FWIW. Al At 05:10 PM 4/7/2011, Steve Baillargeon wrote: >Hi Al >I don't see much values to add the proposed fields in the TWAMP >control protocol because they are specifically applicable to the >handling of the test packets. > >For instance, carrying the Last SeqNo in the Train in the control >protocol is not useful since it may/will change on a per test packet >basis. Same thing for the Desired Reverse Packet Interval. > >Carrying the Sender Discriminator field in the TWAMP control >protocol is a possibility via a new definition of the Type-P >descriptor for instance (e.g. first two bits is 02 followed by >SD). It will bring some benefits to the solution but will not >necessarily reduce complexity on the Session-Reflector. With or >without the SD, the Session-Reflector (in most cases) needs to >continue inspecting various fields on a per test packet basis in >order to match the packets to the correct session. > >The flags are proposed in the test session in order to avoid >creating/allocating a large number of TWAMP modes with a large >number of corresponding "fixed" test packet formats. Our proposal is >to use a single mode that has a single "variable" test packet format >that is easy to parse through. On the contrary, it helps reduce >complexity for products supporting TWAMP. The other option to >completely remove the flags but this will remove the flexibility to >use the format for other purposes and re-open the case for creating >a larger number of modes and packet formats in the future. > > >-Steve > >-----Original Message----- >From: Al Morton [mailto:acmorton@att.com] >Sent: April-07-11 3:58 PM >To: Steve Baillargeon; ippm@ietf.org >Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > >Ok, I thought you were referring to other proposals which were >discussed, and the suggestion of combining what makes sense, but >apparently not. > >My comment below on the tendency toward placing Control in the Test >Session in this proposal is still worth a look, I think. > >Al > >At 03:26 PM 4/7/2011, Steve Baillargeon wrote: > >Hi Al > >I was referring to the train size, not the packet size. > >All test packets using the value-added octets (forward and reverse test > >packets) belonging to a specific test session MUST have the same IP > >packet size. This indicated in the draft as well. > >We are not recommending to change the requirement on the packet size > >because it will make reporting and capacity measurements very difficult > >to do. If a different packet size is needed, a new/different test > >session SHALL be established. > > > >-Steve > > > >-----Original Message----- > >From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > >Al Morton > >Sent: April-07-11 2:38 PM > >To: ippm@ietf.org > >Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > >At 10:53 AM 4/7/2011, Steve Baillargeon wrote: > > >...One aspect we discussed briefly is the possibility to add a new > > >field in the TWAMP value-added padding octets that will allow for a > > >different train size in the reverse direction. > > > >Well, this separate proposal was to allow different test packet sizes > >to be used in the forward and reverse directions, that's right. > > > >But the session request would convey this information in a new > >Request-TW-Session command, since it would likely be static for the > >entire session. This is the more usual way to operate TWAMP: > >telling the Server/Session-Reflector everything needed in advance of > >Starting the test session. > > > >It's good that the value-added-octets proposal incorporates the > >TWAMP-Control protocol in the latest version (01). > > > >So now, I wonder if the *many* new test session packet formats found in > >the value-added-octets proposal could be simplified by moving some > >information currently conveyed in the Test session (via > >flags/fields) to the Control session? In other words, this proposal > >asks the Session-Reflector to perform many new operations, and perhaps > >adoption will be wider if less processing is expected during the test > >session. Of course, Request-TW-Session variables are static for the > >life of the test session, if accepted. > > > >regards, > >Al > > > >_______________________________________________ > >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 steve.baillargeon@videotron.ca Thu Apr 7 21:12:39 2011 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822B63A6784 for ; Thu, 7 Apr 2011 21:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOWsC+2MYq3A for ; Thu, 7 Apr 2011 21:12:37 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 19C503A6A36 for ; Thu, 7 Apr 2011 21:12:37 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PEntGaSiVbiwTlbipoNT6g)" Received: from vl-mo-mpf01.ip.videotron.ca ([10.23.37.50]) by vl-mo-mrz23.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LJB00LT1FQZ8RA0@vl-mo-mrz23.ip.videotron.ca> for ippm@ietf.org; Fri, 08 Apr 2011 00:13:48 -0400 (EDT) Received: from videotron.ca (unknown [10.23.32.112]) by vl-mo-mpf01.ip.videotron.ca (Postfix) with ESMTP id B7B7F294080; Fri, 08 Apr 2011 00:14:21 -0400 (EDT) Received: from [10.23.32.84] (Forwarded-For: 173.179.125.140) by VL-MO-MM004.ip.videotron.ca (mshttpd); Fri, 08 Apr 2011 00:14:21 -0400 From: steve.baillargeon@videotron.ca To: Al Morton Message-id: Date: Fri, 08 Apr 2011 00:14:21 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal Cc: "ippm@ietf.org" Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 04:12:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_PEntGaSiVbiwTlbipoNT6g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi Al I think we are going in circles. Yes the Session-Reflector needs to be the an efficient process and the proposed draft does not change that. Current Session-Reflectors already parse through test packet fields today. We just continue to extend this mechanism to a section of the TWAMP padding octets. The actual implementation is actually very simple to implement. It is much easier to identify and process the packets belonging to a "train" if the "train information" is carried within the test packet. It also enables other capabilities like variable train size and TWAMP light which are important cases to consider. The inter-packet interval will always vary. Why would you remove it from Test? Without it, different train rates within the same test session cannot be tested. The SD is a lightweight flag to improve the demultiplexing of the test packets to the correct test session. Why would you remove it from Test? -Steve ----- Original Message ----- From: Al Morton Date: Thursday, April 7, 2011 8:15 pm Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets To: "ippm@ietf.org" > Steve, > > It seems that we're not on the same page here, > so I won't pick-apart what you said... > > From my POV, the Session-Reflector needs to be the most > efficient process > in the system. So, I don't understand sparing the non-real-time > Control process from complexity, while adding much more complexity > (including the ability to revise the task on a dynamic basis) > to the real-time process of Reflector. I'm not sure you need a > lot of > Mode code points to move functions to Control, either, because > it seems > that a new Request-TW-Session command could convey most of the > info in new > fields for static test sessions (instead of last sequence number > in a train, > use constant train length in packets, and similar substitutions). > > It's an opinion on an option, FWIW. > Al > > At 05:10 PM 4/7/2011, Steve Baillargeon wrote: > >Hi Al > >I don't see much values to add the proposed fields in the TWAMP > >control protocol because they are specifically applicable to > the > >handling of the test packets. > > > >For instance, carrying the Last SeqNo in the Train in the > control > >protocol is not useful since it may/will change on a per test > packet > >basis. Same thing for the Desired Reverse Packet Interval. > > > >Carrying the Sender Discriminator field in the TWAMP control > >protocol is a possibility via a new definition of the Type-P > >descriptor for instance (e.g. first two bits is 02 followed by > >SD). It will bring some benefits to the solution > but will not > >necessarily reduce complexity on the Session-Reflector. With or > >without the SD, the Session-Reflector (in most cases) needs to > >continue inspecting various fields on a per test packet basis > in > >order to match the packets to the correct session. > > > >The flags are proposed in the test session in order to avoid > >creating/allocating a large number of TWAMP modes with a large > >number of corresponding "fixed" test packet formats. Our > proposal is > >to use a single mode that has a single "variable" test packet > format > >that is easy to parse through. On the contrary, it helps reduce > >complexity for products supporting TWAMP. The other option to > >completely remove the flags but this will remove the > flexibility to > >use the format for other purposes and re-open the case for > creating > >a larger number of modes and packet formats in the future. > > > > > >-Steve > > > >-----Original Message----- > >From: Al Morton [mailto:acmorton@att.com] > >Sent: April-07-11 3:58 PM > >To: Steve Baillargeon; ippm@ietf.org > >Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > >Ok, I thought you were referring to other proposals which were > >discussed, and the suggestion of combining what makes sense, > but > >apparently not. > > > >My comment below on the tendency toward placing Control in the > Test > >Session in this proposal is still worth a look, I think. > > > >Al > > > >At 03:26 PM 4/7/2011, Steve Baillargeon wrote: > > >Hi Al > > >I was referring to the train size, not the packet size. > > >All test packets using the value-added octets (forward and > reverse test > > >packets) belonging to a specific test session MUST have the > same IP > > >packet size. This indicated in the draft as well. > > >We are not recommending to change the requirement on the > packet size > > >because it will make reporting and capacity measurements very > difficult> >to do. If a different packet size is needed, a > new/different test > > >session SHALL be established. > > > > > >-Steve > > > > > >-----Original Message----- > > >From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On > Behalf Of > > >Al Morton > > >Sent: April-07-11 2:38 PM > > >To: ippm@ietf.org > > >Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > > > >At 10:53 AM 4/7/2011, Steve Baillargeon wrote: > > > >...One aspect we discussed briefly is the possibility to > add a new > > > >field in the TWAMP value-added padding octets that will > allow for a > > > >different train size in the reverse direction. > > > > > >Well, this separate proposal was to allow different test > packet sizes > > >to be used in the forward and reverse directions, that's right. > > > > > >But the session request would convey this information in a new > > >Request-TW-Session command, since it would likely be static > for the > > >entire session. This is the more usual way to operate TWAMP: > > >telling the Server/Session-Reflector everything needed in > advance of > > >Starting the test session. > > > > > >It's good that the value-added-octets proposal incorporates the > > >TWAMP-Control protocol in the latest version (01). > > > > > >So now, I wonder if the *many* new test session packet > formats found in > > >the value-added-octets proposal could be simplified by moving some > > >information currently conveyed in the Test session (via > > >flags/fields) to the Control session? In other words, > this proposal > > >asks the Session-Reflector to perform many new operations, > and perhaps > > >adoption will be wider if less processing is expected during > the test > > >session. Of course, Request-TW-Session variables are static > for the > > >life of the test session, if accepted. > > > > > >regards, > > >Al > > > > > >_______________________________________________ > > >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 --Boundary_(ID_PEntGaSiVbiwTlbipoNT6g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable Content-disposition: inline =3CDIV=3EHi Al=3C/DIV=3E =3CDIV=3EI think we are going in circles=2E=3C/DIV=3E =3CDIV=3E=26nbsp=3B=3C/DIV=3E =3CDIV=3EYes the=26nbsp=3BSession-Reflector needs to be the an efficient= process and the proposed draft does not change that=2E =3C/DIV=3E =3CDIV=3E=26nbsp=3B=3C/DIV=3E =3CDIV=3ECurrent Session-Reflectors already parse through test packet fi= elds today=2E We just continue to extend this mechanism to a section of = the TWAMP padding octets=2E=3C/DIV=3E =3CDIV=3EThe actual implementation is actually very simple to implement=2E= =3C/DIV=3E =3CDIV=3E=26nbsp=3B=3C/DIV=3E =3CDIV=3EIt is much easier to identify and process=26nbsp=3Bthe packets = belonging to a =22train=22 if the =22train information=22 is carried wit= hin the test packet=2E=3C/DIV=3E =3CDIV=3EIt also=26nbsp=3Benables other capabilities like variable train= size=26nbsp=3Band TWAMP light which are=26nbsp=3Bimportant cases to con= sider=2E=3C/DIV=3E =3CDIV=3E=26nbsp=3B=3C/DIV=3E =3CDIV=3EThe inter-packet interval will always vary=2E Why would you rem= ove it from Test=3F Without it=2C different train rates within the same = test session cannot be tested=2E=3C/DIV=3E =3CDIV=3E=26nbsp=3B=3C/DIV=3E =3CDIV=3EThe SD is a lightweight flag to improve the=26nbsp=3Bdemultiple= xing of the test packets to the correct test session=2E=26nbsp=3BWhy wou= ld you remove it from Test=3F =3C/DIV=3E =3CDIV=3E=26nbsp=3B=3C/DIV=3E =3CDIV=3E-Steve=3CBR=3E=3CBR=3E----- Original Message -----=3CBR=3EFrom=3A= Al Morton =26lt=3Bacmorton=40att=2Ecom=26gt=3B=3CBR=3EDate=3A Thursday=2C= April 7=2C 2011 8=3A15 pm=3CBR=3ESubject=3A Re=3A =5Bippm=5D draft-bail= largeon-ippm-twamp-value-added-octets=3CBR=3ETo=3A =22ippm=40ietf=2Eorg=22= =26lt=3Bippm=40ietf=2Eorg=26gt=3B=3CBR=3E=3CBR=3E=26gt=3B Steve=2C=3CBR= =3E=26gt=3B =3CBR=3E=26gt=3B It seems that we=27re not on the same page = here=2C=3CBR=3E=26gt=3B so I won=27t pick-apart what you said=2E=2E=2E=3C= BR=3E=26gt=3B =3CBR=3E=26gt=3B =26nbsp=3BFrom my POV=2C the Session-Refl= ector needs to be the most =3CBR=3E=26gt=3B efficient process=3CBR=3E=26= gt=3B in the system=2E So=2C I don=27t understand sparing the non-real-t= ime=3CBR=3E=26gt=3B Control process from complexity=2C while adding much= more complexity=3CBR=3E=26gt=3B (including the ability to revise the ta= sk on a dynamic basis)=3CBR=3E=26gt=3B to the real-time process of Refle= ctor=2E I=27m not sure you need a =3CBR=3E=26gt=3B lot of=3CBR=3E=26gt=3B= Mode code points to move functions to Control=2C either=2C because =3CB= R=3E=26gt=3B it seems=3CBR=3E=26gt=3B that a new Request-TW-Session comm= and could convey most of the =3CBR=3E=26gt=3B info in new=3CBR=3E=26gt=3B= fields for static test sessions (instead of last sequence number =3CBR=3E= =26gt=3B in a train=2C=3CBR=3E=26gt=3B use constant train length in pack= ets=2C and similar substitutions)=2E=3CBR=3E=26gt=3B =3CBR=3E=26gt=3B It= =27s an opinion on an option=2C FWIW=2E=3CBR=3E=26gt=3B Al=3CBR=3E=26gt=3B= =3CBR=3E=26gt=3B At 05=3A10 PM 4/7/2011=2C Steve Baillargeon wrote=3A=3C= BR=3E=26gt=3B =26gt=3BHi Al=3CBR=3E=26gt=3B =26gt=3BI don=27t see much v= alues to add the proposed fields in the TWAMP =3CBR=3E=26gt=3B =26gt=3Bc= ontrol protocol because they are specifically applicable to =3CBR=3E=26g= t=3B the =3CBR=3E=26gt=3B =26gt=3Bhandling of the test packets=2E=3CBR=3E= =26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3BFor instance=2C carrying the L= ast SeqNo in the Train in the =3CBR=3E=26gt=3B control =3CBR=3E=26gt=3B = =26gt=3Bprotocol is not useful since it may/will change on a per test =3C= BR=3E=26gt=3B packet =3CBR=3E=26gt=3B =26gt=3Bbasis=2E Same thing for th= e Desired Reverse Packet Interval=2E=3CBR=3E=26gt=3B =26gt=3B=3CBR=3E=26= gt=3B =26gt=3BCarrying the Sender Discriminator field in the TWAMP contr= ol =3CBR=3E=26gt=3B =26gt=3Bprotocol is a possibility via a new definiti= on of the Type-P =3CBR=3E=26gt=3B =26gt=3Bdescriptor for instance (e=2Eg= =2E first two bits is 02 followed by =3CBR=3E=26gt=3B =26gt=3BSD)=2E=26n= bsp=3B=26nbsp=3B It will bring some benefits to the solution =3CBR=3E=26= gt=3B but will not =3CBR=3E=26gt=3B =26gt=3Bnecessarily reduce complexit= y on the Session-Reflector=2E With or =3CBR=3E=26gt=3B =26gt=3Bwithout t= he SD=2C the Session-Reflector (in most cases) needs to =3CBR=3E=26gt=3B= =26gt=3Bcontinue inspecting various fields on a per test packet basis =3C= BR=3E=26gt=3B in =3CBR=3E=26gt=3B =26gt=3Border to match the packets to = the correct session=2E=3CBR=3E=26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3B= The flags are proposed in the test session in order to avoid =3CBR=3E=26= gt=3B =26gt=3Bcreating/allocating a large number of TWAMP modes with a l= arge =3CBR=3E=26gt=3B =26gt=3Bnumber of corresponding =22fixed=22 test p= acket formats=2E Our =3CBR=3E=26gt=3B proposal is =3CBR=3E=26gt=3B =26gt= =3Bto use a single mode that has a single =22variable=22 test packet =3C= BR=3E=26gt=3B format =3CBR=3E=26gt=3B =26gt=3Bthat is easy to parse thro= ugh=2E On the contrary=2C it helps reduce =3CBR=3E=26gt=3B =26gt=3Bcompl= exity for products supporting TWAMP=2E The other option to =3CBR=3E=26gt= =3B =26gt=3Bcompletely remove the flags but this will remove the =3CBR=3E= =26gt=3B flexibility to =3CBR=3E=26gt=3B =26gt=3Buse the format for othe= r purposes and re-open the case for =3CBR=3E=26gt=3B creating =3CBR=3E=26= gt=3B =26gt=3Ba larger number of modes and packet formats in the future=2E= =3CBR=3E=26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt= =3B-Steve=3CBR=3E=26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3B-----Original= Message-----=3CBR=3E=26gt=3B =26gt=3BFrom=3A Al Morton =5Bmailto=3Aacmo= rton=40att=2Ecom=5D=3CBR=3E=26gt=3B =26gt=3BSent=3A April-07-11 3=3A58 P= M=3CBR=3E=26gt=3B =26gt=3BTo=3A Steve Baillargeon=3B ippm=40ietf=2Eorg=3C= BR=3E=26gt=3B =26gt=3BSubject=3A Re=3A =5Bippm=5D draft-baillargeon-ippm= -twamp-value-added-octets=3CBR=3E=26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt= =3BOk=2C I thought you were referring to other proposals which were =3CB= R=3E=26gt=3B =26gt=3Bdiscussed=2C and the suggestion of combining what m= akes sense=2C =3CBR=3E=26gt=3B but =3CBR=3E=26gt=3B =26gt=3Bapparently n= ot=2E=3CBR=3E=26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3BMy comment below = on the tendency toward placing Control in the =3CBR=3E=26gt=3B Test =3CB= R=3E=26gt=3B =26gt=3BSession in this proposal is still worth a look=2C I= think=2E=3CBR=3E=26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3BAl=3CBR=3E=26= gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3BAt 03=3A26 PM 4/7/2011=2C Steve B= aillargeon wrote=3A=3CBR=3E=26gt=3B =26gt=3B =26gt=3BHi Al=3CBR=3E=26gt=3B= =26gt=3B =26gt=3BI was referring to the train size=2C not the packet si= ze=2E=3CBR=3E=26gt=3B =26gt=3B =26gt=3BAll test packets using the value-= added octets (forward and =3CBR=3E=26gt=3B reverse test=3CBR=3E=26gt=3B = =26gt=3B =26gt=3Bpackets) belonging to a specific test session MUST have= the =3CBR=3E=26gt=3B same IP=3CBR=3E=26gt=3B =26gt=3B =26gt=3Bpacket si= ze=2E This indicated in the draft as well=2E=3CBR=3E=26gt=3B =26gt=3B =26= gt=3BWe are not recommending to change the requirement on the =3CBR=3E=26= gt=3B packet size=3CBR=3E=26gt=3B =26gt=3B =26gt=3Bbecause it will make = reporting and capacity measurements very =3CBR=3E=26gt=3B difficult=26gt= =3B =26gt=3Bto do=2E If a different packet size is needed=2C a =3CBR=3E=26= gt=3B new/different test=3CBR=3E=26gt=3B =26gt=3B =26gt=3Bsession SHALL = be established=2E=3CBR=3E=26gt=3B =26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26g= t=3B =26gt=3B-Steve=3CBR=3E=26gt=3B =26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26= gt=3B =26gt=3B-----Original Message-----=3CBR=3E=26gt=3B =26gt=3B =26gt=3B= From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf=2Eorg=5D= On =3CBR=3E=26gt=3B Behalf Of=3CBR=3E=26gt=3B =26gt=3B =26gt=3BAl Morto= n=3CBR=3E=26gt=3B =26gt=3B =26gt=3BSent=3A April-07-11 2=3A38 PM=3CBR=3E= =26gt=3B =26gt=3B =26gt=3BTo=3A ippm=40ietf=2Eorg=3CBR=3E=26gt=3B =26gt=3B= =26gt=3BSubject=3A Re=3A =5Bippm=5D draft-baillargeon-ippm-twamp-value-= added-octets=3CBR=3E=26gt=3B =26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3B = =26gt=3BAt 10=3A53 AM 4/7/2011=2C Steve Baillargeon wrote=3A=3CBR=3E=26g= t=3B =26gt=3B =26gt=3B =26gt=3B=2E=2E=2EOne aspect we discussed briefly = is the possibility to =3CBR=3E=26gt=3B add a new=3CBR=3E=26gt=3B =26gt=3B= =26gt=3B =26gt=3Bfield in the TWAMP value-added padding octets that wil= l =3CBR=3E=26gt=3B allow for a=3CBR=3E=26gt=3B =26gt=3B =26gt=3B =26gt=3B= different train size in the reverse direction=2E=3CBR=3E=26gt=3B =26gt=3B= =26gt=3B=3CBR=3E=26gt=3B =26gt=3B =26gt=3BWell=2C this separate proposa= l was to allow different test =3CBR=3E=26gt=3B packet sizes=3CBR=3E=26gt= =3B =26gt=3B =26gt=3Bto be used in the forward and reverse directions=2C= that=27s right=2E=3CBR=3E=26gt=3B =26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26= gt=3B =26gt=3BBut the session request would convey this information in a= new=3CBR=3E=26gt=3B =26gt=3B =26gt=3BRequest-TW-Session command=2C sinc= e it would likely be static =3CBR=3E=26gt=3B for the=3CBR=3E=26gt=3B =26= gt=3B =26gt=3Bentire session=2E This is the more usual way to operate TW= AMP=3A=3CBR=3E=26gt=3B =26gt=3B =26gt=3Btelling the Server/Session-Refle= ctor everything needed in =3CBR=3E=26gt=3B advance of=3CBR=3E=26gt=3B =26= gt=3B =26gt=3BStarting the test session=2E=3CBR=3E=26gt=3B =26gt=3B =26g= t=3B=3CBR=3E=26gt=3B =26gt=3B =26gt=3BIt=27s good that the value-added-o= ctets proposal incorporates the=3CBR=3E=26gt=3B =26gt=3B =26gt=3BTWAMP-C= ontrol protocol in the latest version (01)=2E=3CBR=3E=26gt=3B =26gt=3B =26= gt=3B=3CBR=3E=26gt=3B =26gt=3B =26gt=3BSo now=2C I wonder if the *many* = new test session packet =3CBR=3E=26gt=3B formats found in=3CBR=3E=26gt=3B= =26gt=3B =26gt=3Bthe value-added-octets proposal could be simplified by= moving some=3CBR=3E=26gt=3B =26gt=3B =26gt=3Binformation currently conv= eyed in the Test session (via=3CBR=3E=26gt=3B =26gt=3B =26gt=3Bflags/fie= lds) to the Control session=3F=26nbsp=3B In other words=2C =3CBR=3E=26gt= =3B this proposal=3CBR=3E=26gt=3B =26gt=3B =26gt=3Basks the Session-Refl= ector to perform many new operations=2C =3CBR=3E=26gt=3B and perhaps=3CB= R=3E=26gt=3B =26gt=3B =26gt=3Badoption will be wider if less processing = is expected during =3CBR=3E=26gt=3B the test=3CBR=3E=26gt=3B =26gt=3B =26= gt=3Bsession=2E Of course=2C Request-TW-Session variables are static =3C= BR=3E=26gt=3B for the=3CBR=3E=26gt=3B =26gt=3B =26gt=3Blife of the test = session=2C if accepted=2E=3CBR=3E=26gt=3B =26gt=3B =26gt=3B=3CBR=3E=26gt= =3B =26gt=3B =26gt=3Bregards=2C=3CBR=3E=26gt=3B =26gt=3B =26gt=3BAl=3CBR= =3E=26gt=3B =26gt=3B =26gt=3B=3CBR=3E=26gt=3B =26gt=3B =26gt=3B=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=3CBR=3E=26g= t=3B =26gt=3B =26gt=3Bippm mailing list=3CBR=3E=26gt=3B =26gt=3B =26gt=3B= ippm=40ietf=2Eorg=3CBR=3E=26gt=3B =26gt=3B =26gt=3Bhttps=3A//www=2Eietf=2E= org/mailman/listinfo/ippm=3CBR=3E=26gt=3B =26gt=3B =26gt=3B=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=3CBR=3E=26gt=3B =26= gt=3B =26gt=3Bippm mailing list=3CBR=3E=26gt=3B =26gt=3B =26gt=3Bippm=40= ietf=2Eorg=3CBR=3E=26gt=3B =26gt=3B =26gt=3Bhttps=3A//www=2Eietf=2Eorg/m= ailman/listinfo/ippm=3CBR=3E=26gt=3B =3CBR=3E=26gt=3B =5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=3CBR=3E=26gt=3B ippm= mailing list=3CBR=3E=26gt=3B ippm=40ietf=2Eorg=3CBR=3E=26gt=3B https=3A= //www=2Eietf=2Eorg/mailman/listinfo/ippm=3C/DIV=3E --Boundary_(ID_PEntGaSiVbiwTlbipoNT6g)-- From wwwrun@rfc-editor.org Thu Apr 14 11:26:46 2011 Return-Path: X-Original-To: ippm@ietfc.amsl.com Delivered-To: ippm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 56BFCE08F7; Thu, 14 Apr 2011 11:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yZspWDxWiJG; Thu, 14 Apr 2011 11:26:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id 2922DE0766; Thu, 14 Apr 2011 11:26:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A5239E0790; Thu, 14 Apr 2011 11:26:37 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110414182637.A5239E0790@rfc-editor.org> Date: Thu, 14 Apr 2011 11:26:37 -0700 (PDT) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 6248 on RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete 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: Thu, 14 Apr 2011 18:26:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6248 Title: RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete Author: A. Morton Status: Informational Stream: IETF Date: April 2011 Mailbox: acmorton@att.com Pages: 6 Characters: 10192 Obsoletes: RFC4148 Updates: RFC4737, RFC5560, RFC5644, RFC6049 I-D Tag: draft-morton-ippm-rfc4148-obsolete-03.txt URL: http://www.rfc-editor.org/rfc/rfc6248.txt This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM) Metrics Registry", as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Performance Metrics Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From henk@uijterwaal.nl Wed Apr 20 00:38:48 2011 Return-Path: X-Original-To: ippm@ietfc.amsl.com Delivered-To: ippm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2D0CDE0698 for ; Wed, 20 Apr 2011 00:38:48 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIEOxi-1cGYb for ; Wed, 20 Apr 2011 00:38:47 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfc.amsl.com (Postfix) with ESMTP id 5BCCEE0697 for ; Wed, 20 Apr 2011 00:38:47 -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 p3K7cjxQ012842 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 20 Apr 2011 09:38:46 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4DAE8D85.1080900@uijterwaal.nl> Date: Wed, 20 Apr 2011 09:38:45 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ippm@ietf.org References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> <4D9C23B1.8040205@uijterwaal.nl> <4383945B8C24AA4FBC33555BB7B829EF0DEC35172D@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DEC35172D@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 Subject: Re: [ippm] 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: Wed, 20 Apr 2011 07:38:48 -0000 Steve, others, > - General comment. Have you considered > defining a MIB as well your draft? As far as I know, the IETF has always > favored the reporting of stats in well-defined MIB. I think it will help to > compare performance reports from different implementations. There have been proposals for a MIB in the past. However, there was very little interest to actually work on this as well as a lack of expertise in the group. The topic was dropped. Of course, it can be restarted if there is enough critical mass to work it. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC 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 Wed Apr 20 00:42:45 2011 Return-Path: X-Original-To: ippm@ietfc.amsl.com Delivered-To: ippm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3C5D0E07B5 for ; Wed, 20 Apr 2011 00:42:45 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyUetoXW4bwR for ; Wed, 20 Apr 2011 00:42:44 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by ietfc.amsl.com (Postfix) with ESMTP id 81F8FE07AD for ; Wed, 20 Apr 2011 00:42:44 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id p3K7gg8k022790 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 20 Apr 2011 09:42:43 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4DAE8E72.9020909@uijterwaal.nl> Date: Wed, 20 Apr 2011 09:42:42 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ippm@ietf.org References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> <4D9C23B1.8040205@uijterwaal.nl> In-Reply-To: <4D9C23B1.8040205@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: [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: Wed, 20 Apr 2011 07:42:45 -0000 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 RIPE NCC 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 Wed Apr 20 00:43:24 2011 Return-Path: X-Original-To: ippm@ietfc.amsl.com Delivered-To: ippm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D5E0E07C0 for ; Wed, 20 Apr 2011 00:43:24 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT4Ti0qhrKwT for ; Wed, 20 Apr 2011 00:43:24 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by ietfc.amsl.com (Postfix) with ESMTP id A02C6E07C6 for ; Wed, 20 Apr 2011 00:43:22 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id p3K7hKwG010863 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 09:43:21 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4DAE8E98.30200@uijterwaal.nl> Date: Wed, 20 Apr 2011 09:43:20 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ippm@ietf.org, Yaakov Stein References: <4D9C2767.1070407@uijterwaal.nl> In-Reply-To: <4D9C2767.1070407@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] Presentation in Prague 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, 20 Apr 2011 07:43:24 -0000 On 06/04/2011 10:42, Henk Uijterwaal wrote: > Yaakov, Did you get around to do this? Henk > > Thank you for providing a slide pack with OWAMP/TWAMP issues for our Prague > meeting. The slides were discussed but there was not sufficient expertise in > the room to answer all questions. > > May I suggest that you post the issues to the list and give people a > chance to comment. Depending on the outcome, we may file errata or write > an update to the specs. If you consider this useful, I can try to set up > an issue tracker for this. > > Thanks, > > Henk > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC 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 steve.baillargeon@ericsson.com Wed Apr 20 06:51:13 2011 Return-Path: X-Original-To: ippm@ietfc.amsl.com Delivered-To: ippm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D4E4BE067D for ; Wed, 20 Apr 2011 06:51:13 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPhCXQpKJTOo for ; Wed, 20 Apr 2011 06:51:13 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 01139E065A for ; Wed, 20 Apr 2011 06:51:12 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3KDpBcM032677; Wed, 20 Apr 2011 08:51:12 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 20 Apr 2011 09:51:05 -0400 From: Steve Baillargeon To: Henk Uijterwaal Date: Wed, 20 Apr 2011 09:51:04 -0400 Thread-Topic: [ippm] WGLC for draft-ietf-ippm-reporting-06.txt Thread-Index: Acv/MCVRv0A2K5lsQSSnNiFhJJf2eAALbpAw Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC48C561@EUSAACMS0701.eamcs.ericsson.se> References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> <4D9C23B1.8040205@uijterwaal.nl> <4383945B8C24AA4FBC33555BB7B829EF0DEC35172D@EUSAACMS0701.eamcs.ericsson.se> <4DAE8D85.1080900@uijterwaal.nl> In-Reply-To: <4DAE8D85.1080900@uijterwaal.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: Re: [ippm] 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: Wed, 20 Apr 2011 13:51:14 -0000 Hello Henk I am interested to work on MIB modules for IPPM. I think it will help bring some alignment to metric reporting and measureme= nt protocol operation. If we take such route, I suggest we start with two MIB modules as follows a= nd determine if more are actually needed in the future: - MIB module for the basic metrics defined in draft-ietf-ippm-reporting-06.= txt - MIB module for the TWAMP protocol and entities I am specifically interested to directly contribute to the TWAMP MIB module= . -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: April-20-11 3:39 AM To: ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-reporting-06.txt Steve, others, > - General comment. Have you considered defining a MIB as well your=20 > draft? As far as I know, the IETF has always favored the reporting of=20 > stats in well-defined MIB. I think it will help to compare performance=20 > reports from different implementations. There have been proposals for a MIB in the past. However, there was very l= ittle interest to actually work on this as well as a lack of expertise in t= he group. The topic was dropped. Of course, it can be restarted if there = is enough critical mass to work it. Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC 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= ) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Ali.Nazari@dai-labor.de Wed Apr 20 01:40:50 2011 Return-Path: X-Original-To: ippm@ietfc.amsl.com Delivered-To: ippm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50937E0655 for ; Wed, 20 Apr 2011 01:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeBob7iol2At for ; Wed, 20 Apr 2011 01:40:47 -0700 (PDT) Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) by ietfc.amsl.com (Postfix) with ESMTP id F0CBFE06F1 for ; Wed, 20 Apr 2011 01:40:46 -0700 (PDT) X-tubIT-Incoming-IP: 130.149.154.85 Received: from birke.dai-labor.de ([130.149.154.85] helo=mail.dai-labor.de) by mail.tu-berlin.de (exim-4.75/mailfrontend-2) with esmtps [TLSv1:RC4-MD5:128] for id 1QCSxq-0000i2-H9; Wed, 20 Apr 2011 10:40:46 +0200 Received: from birke4.dai-lab.de ([130.149.154.85]) by birke4.dai-lab.de ([130.149.154.85]) with mapi; Wed, 20 Apr 2011 10:39:09 +0200 From: Ali Nazari To: "ippm@ietf.org" Date: Wed, 20 Apr 2011 10:39:08 +0200 Thread-Topic: ACM NetGames 2011 & Special Issue on Network and Systems Support for Games in Springer's Multimedia Systems Journal Thread-Index: Acv/NmojNb+EA/a1QLeDEZQXUpI07g== Message-ID: <996D29AAC4B8314882C25235E84ABED501142FEA9A00@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_996D29AAC4B8314882C25235E84ABED501142FEA9A00birke4daila_" MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 23 Apr 2011 08:02:35 -0700 Subject: [ippm] ACM NetGames 2011 & Special Issue on Network and Systems Support for Games in Springer's Multimedia Systems Journal 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, 20 Apr 2011 08:47:37 -0000 --_000_996D29AAC4B8314882C25235E84ABED501142FEA9A00birke4daila_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CALL FOR PAPERS =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=3D=3D=3D=3D=3D 10th Anniversary of the annual International Workshop on Network and System= s Support for Games Ottawa, Canada, October 6-7 2011 http://www.discover.uottawa.ca/netgames2011/ & Special Issue on Network and Systems Support for Games in Springer's Multim= edia Systems Journal http://www.site.uottawa.ca/~shervin/netgamessi/ =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=3D=3D=3D=3D=3D NetGames brings together researchers and practitioners from both academia a= nd industry to present the latest research results and challenges of today'= s networked games, and to understand their requirements and possibilities i= n order to enable the next generation of networked games. NetGames also pro= vides industry keynote and panel discussions. Submissions are solicited on = all aspects of networked games, including (but not limited to): * Scalability, cloud support, client-server, and P2P system architecture= s * Efficient message distribution and network protocol design * Latency issues and lag compensation techniques * Network traffic modeling, measurement, and impact on network infrastru= cture * System benchmarking, performance evaluation, and provisioning * Operating system enhancements, service platforms, and middleware * Massively Multiplayer Online Gaming (MMOG) * Multiplayer usability and user behavior studies * Personal communications and conferencing in games * Mobile games, resource-constrained systems, and context-based adaptati= on * Networks of sensors and actuators, networked haptics * Quality of service, quality of experience, and content adaptation * Dynamic and user-generated content authoring and management * Content creation: non-linear storytelling, object capturing, algorithm= ic creation * Security, authentication, accounting and digital rights management * Cheat detection and prevention * Social networking in multiplayer games Formats Submissions can be in three forms, all in IEEE conference proceedings forma= t, US Letter: Full paper 6 pages Short paper 2 pages Demo 3 pages Full papers will be presented in the single track session, and short papers= will be presented as posters, while demos require actual demonstration of = a working proof-of-concept or prototype. For more information on demos, ple= ase visit the demo page. All accepted papers will be published in the workshop proceedings. Submissions are done in PDF and through EDAS. Please go to the submission p= age for more details. Journal Special Issue Accepted papers in NetGames 2011 will be invited to submit an extended vers= ion to a special issue in the Springer's Multimedia Systems Journal. Please= see the Special Issue page for more information. Important Dates Full/Short Paper Submission Deadline July 1, 2011 Demo Paper Submission Deadline August 1 2011 Notification of Decisions August 15, 2011 Registration/Final Paper Due September 1, 2011 Special Issue Paper Due November 15 2011 --_000_996D29AAC4B8314882C25235E84ABED501142FEA9A00birke4daila_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CALL FOR PAPERS
=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=3D=3D=3D= =3D=3D
10th Anniversary of the annual International Workshop on Network= and Systems Support for Games
Ottawa, Canada, October 6-7 2011
http://www.discover.uottawa.ca/netgames2011/
&

Special Issue on Network and Systems Support for Games in = Springer's Multimedia Systems Journal
htt= p://www.site.uottawa.ca/~shervin/netgamessi/<= br>=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=3D=3D=3D=3D=3D

Net= Games brings together researchers and practitioners from both academia and = industry to present the latest research results and challenges of todayR= 17;s networked games, and to understand their requirements and possibilitie= s in order to enable the next generation of networked games. NetGames also = provides industry keynote and panel discussions. Submissions are solicited = on all aspects of networked games, including (but not limited to):

  • Scalability, cloud support, client-server, and P2P system architecture= s
  • Efficient message distribution and network protocol design
  • Latency issues a= nd lag compensation techniques
  • Network traffic modeling, measurement, and im= pact on network infrastructure
  • System benchmarking, performance evaluation, = and provisioning
  • Operating system enhancements, service platforms, and middl= eware
  • Massively Multiplayer Online Gaming (MMOG)
  • Multiplayer usability and us= er behavior studies
  • = Personal communications and conferencing in games <= /o:p>
  • Mobile = games, resource-constrained systems, and context-based adaptation
  • Networks o= f sensors and actuators, networked haptics
  • Quality of service, quality of ex= perience, and content adaptation
  • Dynamic and user-generated content authorin= g and management
  • Content creation: non-linear storytelling, object capturing= , algorithmic creation
  • Security, authentication, accounting and digital ri= ghts management
  • Chea= t detection and prevention
  • = Social networking in multiplayer games

Formats
= Submissions can be in three forms, all in IEEE conference proceedings format, US Letter:
Full paper      &nbs= p; 6 pages
Short paper     2 pages
Demo     &nbs= p;        3 pages

Full papers will be pre= sented in the single track session, and short papers will be present= ed as posters, while demos require actual demonstration of a working= proof-of-concept or prototype. For more information on demos, please visit= the demo page.
All accepted papers will be published in the workshop pr= oceedings.

Submissions are done in PDF and through EDAS. Please go t= o the submission page for more details.

Journal Special Issue<= /u>
Accepted papers in NetGames 2011 will be invited to submit an ex= tended version to a special issue in the Springer’s Multimedia System= s Journal. Please see the Special Issue page for more information.

<= b>Important Dates

Full/Short Paper Sub= mission Deadline

July 1, 2011

Demo Paper Submission Deadline

=

August 1 2011

Notification of  Decisions<= o:p>

August 15, 2011

Registration/Final Paper Due

=

September = 1, 2011

<= p class=3DMsoNormal>Special Issue Paper Due

November 15 2011=

 

 

= --_000_996D29AAC4B8314882C25235E84ABED501142FEA9A00birke4daila_-- From henk@uijterwaal.nl Thu Apr 28 04:42:03 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 07D69E06B6 for ; Thu, 28 Apr 2011 04:42:03 -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 gbQorlTVgMon for ; Thu, 28 Apr 2011 04:42:02 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by ietfa.amsl.com (Postfix) with ESMTP id 218FCE068D for ; Thu, 28 Apr 2011 04:42:01 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id p3SBfTkp009036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 28 Apr 2011 13:41:30 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4DB95269.9090102@uijterwaal.nl> Date: Thu, 28 Apr 2011 13:41:29 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF IPPM WG References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> <4D9C23B1.8040205@uijterwaal.nl> <4DAE8E72.9020909@uijterwaal.nl> In-Reply-To: <4DAE8E72.9020909@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: Thu, 28 Apr 2011 11:42:03 -0000 Stas and Martin, Please take a look at this. 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 RIPE NCC 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 Thu Apr 28 04:46:30 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 88C62E06ED for ; Thu, 28 Apr 2011 04:46:30 -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 2bZD5Jt5Mjnj for ; Thu, 28 Apr 2011 04:46:30 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id C211EE06D0 for ; Thu, 28 Apr 2011 04:46:29 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id p3SBjs5g080238 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 28 Apr 2011 13:45:58 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4DB95371.4070905@uijterwaal.nl> Date: Thu, 28 Apr 2011 13:45:53 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF IPPM WG References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> In-Reply-To: <4D9D7225.6080506@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] 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: Thu, 28 Apr 2011 11:46:30 -0000 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. Apologies for the delay. I'm trying to figure out where to go with this proposal. If I look at the comments, then there seems to be agreement that we can enhance TWAMP for packet train based measurements. We are, however, not in agreement on how to do this. In the draft mentioned above, some of the work is done during the test session phase whereas people prepare that the entire setup is done during the setup phase. I suggest that we should first discuss the general direction of this idea on the list and only then get into details, where draft-baillargeon-... is one of the solutions. Would this work for everybody? If so, please start fighting over this ;-) Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC 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 steve.baillargeon@ericsson.com Thu Apr 28 05:53:03 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 94D3CE06EA for ; Thu, 28 Apr 2011 05:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6wfZbueXfoa for ; Thu, 28 Apr 2011 05:53:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF49E0674 for ; Thu, 28 Apr 2011 05:53:02 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3SCqkHm008575; Thu, 28 Apr 2011 07:53:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 28 Apr 2011 08:52:43 -0400 From: Steve Baillargeon To: Henk Uijterwaal , IETF IPPM WG Date: Thu, 28 Apr 2011 08:52:42 -0400 Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: AcwFmhX0CI5OxWpfTTu9vB0cDEuknAAAx5VQ Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DECEDEDDD@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4DB95371.4070905@uijterwaal.nl> In-Reply-To: <4DB95371.4070905@uijterwaal.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_4383945B8C24AA4FBC33555BB7B829EF0DECEDEDDDEUSAACMS0701e_" MIME-Version: 1.0 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: Thu, 28 Apr 2011 12:53:03 -0000 --_002_4383945B8C24AA4FBC33555BB7B829EF0DECEDEDDDEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi The draft proposes to enhance the TWAMP control protocol with a new mode an= d add the less possible set of new fields to the TWAMP test packets. The ob= jective is to allow a single test session of a given type-P to measure capa= city metrics over time on a given path using any capacity estimation method= s. Can someone tell me if there is anything wrong with such goal? Based on the last discussion, I believe we have a general agreement on the = draft. At least, I noticed that more people supporting it than opposing it.= I did not see any counter arguments from Al and I did not hear any concern= s from anyone else.=20 See enclosed email explaining the logic behind improving the test protocol. -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: April-28-11 7:46 AM To: IETF IPPM WG Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets IPPM Group, > In Prague, Steve and colleagues presented=20 > draft-baillargeon-ippm-twamp-value-added-octets and asked if this can=20 > become a WG document. If you support this idea or disagree with it,=20 > please speak up on the list before April 21. Apologies for the delay. I'm trying to figure out where to go with this proposal. If I look at the = comments, then there seems to be agreement that we can enhance TWAMP for pa= cket train based measurements. We are, however, not in agreement on how to= do this. In the draft mentioned above, some of the work is done during th= e test session phase whereas people prepare that the entire setup is done d= uring the setup phase. I suggest that we should first discuss the general direction of this idea o= n the list and only then get into details, where draft-baillargeon-... is one of the solutions. Would this work for everybody? If so, please start fighting over this ;-) Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC 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= ) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_002_4383945B8C24AA4FBC33555BB7B829EF0DECEDEDDDEUSAACMS0701e_ Content-Type: message/rfc822 Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 8 Apr 2011 00:14:30 -0400 Received: from mailgw7.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.86) with Microsoft SMTP Server id 8.3.137.0; Fri, 8 Apr 2011 06:14:29 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CC.3D.25859.4AB8E9D4; Fri, 8 Apr 2011 06:14:29 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336963A6A40; Thu, 7 Apr 2011 21:12:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822B63A6784 for ; Thu, 7 Apr 2011 21:12:39 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOWsC+2MYq3A for ; Thu, 7 Apr 2011 21:12:37 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 19C503A6A36 for ; Thu, 7 Apr 2011 21:12:37 -0700 (PDT) Received: from vl-mo-mpf01.ip.videotron.ca ([10.23.37.50]) by vl-mo-mrz23.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LJB00LT1FQZ8RA0@vl-mo-mrz23.ip.videotron.ca> for ippm@ietf.org; Fri, 08 Apr 2011 00:13:48 -0400 (EDT) Received: from videotron.ca (unknown [10.23.32.112]) by vl-mo-mpf01.ip.videotron.ca (Postfix) with ESMTP id B7B7F294080; Fri, 08 Apr 2011 00:14:21 -0400 (EDT) Received: from [10.23.32.84] (Forwarded-For: 173.179.125.140) by VL-MO-MM004.ip.videotron.ca (mshttpd); Fri, 08 Apr 2011 00:14:21 -0400 From: "steve.baillargeon@videotron.ca" To: Al Morton CC: "ippm@ietf.org" Sender: "ippm-bounces@ietf.org" Date: Fri, 8 Apr 2011 00:14:21 -0400 Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets Thread-Index: Acv1o3WiFmRo+YRcRF2drxhiAet2BA== Message-ID: List-Help: List-Subscribe: , List-Unsubscribe: , Accept-Language: en Content-Language: en X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0191.eemea.ericsson.se X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: acceptlanguage: en x-brightmail-tracker: AAAAARfQmn8= x-auditid: c1b4fb30-b7ba2ae000006503-36-4d9e8ba303d7 errors-to: ippm-bounces@ietf.org x-spam-flag: NO x-spam-status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] delivered-to: ippm@core3.amsl.com x-original-to: ippm@core3.amsl.com x-virus-scanned: amavisd-new at amsl.com list-post: x-spam-level: list-id: IETF IP Performance Metrics Working Group list-archive: x-beenthere: ippm@ietf.org x-mailman-version: 2.1.9 x-spam-score: -2.598 Content-Type: multipart/mixed; boundary="_002_fc41bb91f0f34d9e535dvideotronca_" MIME-Version: 1.0 --_002_fc41bb91f0f34d9e535dvideotronca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Al I think we are going in circles. Yes the Session-Reflector needs to be the an efficient process and the prop= osed draft does not change that. Current Session-Reflectors already parse through test packet fields today. = We just continue to extend this mechanism to a section of the TWAMP padding= octets. The actual implementation is actually very simple to implement. It is much easier to identify and process the packets belonging to a "train= " if the "train information" is carried within the test packet. It also enables other capabilities like variable train size and TWAMP light= which are important cases to consider. The inter-packet interval will always vary. Why would you remove it from Te= st? Without it, different train rates within the same test session cannot b= e tested. The SD is a lightweight flag to improve the demultiplexing of the test pack= ets to the correct test session. Why would you remove it from Test? -Steve ----- Original Message ----- From: Al Morton Date: Thursday, April 7, 2011 8:15 pm Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets To: "ippm@ietf.org" > Steve, > > It seems that we're not on the same page here, > so I won't pick-apart what you said... > > From my POV, the Session-Reflector needs to be the most > efficient process > in the system. So, I don't understand sparing the non-real-time > Control process from complexity, while adding much more complexity > (including the ability to revise the task on a dynamic basis) > to the real-time process of Reflector. I'm not sure you need a > lot of > Mode code points to move functions to Control, either, because > it seems > that a new Request-TW-Session command could convey most of the > info in new > fields for static test sessions (instead of last sequence number > in a train, > use constant train length in packets, and similar substitutions). > > It's an opinion on an option, FWIW. > Al > > At 05:10 PM 4/7/2011, Steve Baillargeon wrote: > >Hi Al > >I don't see much values to add the proposed fields in the TWAMP > >control protocol because they are specifically applicable to > the > >handling of the test packets. > > > >For instance, carrying the Last SeqNo in the Train in the > control > >protocol is not useful since it may/will change on a per test > packet > >basis. Same thing for the Desired Reverse Packet Interval. > > > >Carrying the Sender Discriminator field in the TWAMP control > >protocol is a possibility via a new definition of the Type-P > >descriptor for instance (e.g. first two bits is 02 followed by > >SD). It will bring some benefits to the solution > but will not > >necessarily reduce complexity on the Session-Reflector. With or > >without the SD, the Session-Reflector (in most cases) needs to > >continue inspecting various fields on a per test packet basis > in > >order to match the packets to the correct session. > > > >The flags are proposed in the test session in order to avoid > >creating/allocating a large number of TWAMP modes with a large > >number of corresponding "fixed" test packet formats. Our > proposal is > >to use a single mode that has a single "variable" test packet > format > >that is easy to parse through. On the contrary, it helps reduce > >complexity for products supporting TWAMP. The other option to > >completely remove the flags but this will remove the > flexibility to > >use the format for other purposes and re-open the case for > creating > >a larger number of modes and packet formats in the future. > > > > > >-Steve > > > >-----Original Message----- > >From: Al Morton [mailto:acmorton@att.com] > >Sent: April-07-11 3:58 PM > >To: Steve Baillargeon; ippm@ietf.org > >Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > >Ok, I thought you were referring to other proposals which were > >discussed, and the suggestion of combining what makes sense, > but > >apparently not. > > > >My comment below on the tendency toward placing Control in the > Test > >Session in this proposal is still worth a look, I think. > > > >Al > > > >At 03:26 PM 4/7/2011, Steve Baillargeon wrote: > > >Hi Al > > >I was referring to the train size, not the packet size. > > >All test packets using the value-added octets (forward and > reverse test > > >packets) belonging to a specific test session MUST have the > same IP > > >packet size. This indicated in the draft as well. > > >We are not recommending to change the requirement on the > packet size > > >because it will make reporting and capacity measurements very > difficult> >to do. If a different packet size is needed, a > new/different test > > >session SHALL be established. > > > > > >-Steve > > > > > >-----Original Message----- > > >From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On > Behalf Of > > >Al Morton > > >Sent: April-07-11 2:38 PM > > >To: ippm@ietf.org > > >Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets > > > > > >At 10:53 AM 4/7/2011, Steve Baillargeon wrote: > > > >...One aspect we discussed briefly is the possibility to > add a new > > > >field in the TWAMP value-added padding octets that will > allow for a > > > >different train size in the reverse direction. > > > > > >Well, this separate proposal was to allow different test > packet sizes > > >to be used in the forward and reverse directions, that's right. > > > > > >But the session request would convey this information in a new > > >Request-TW-Session command, since it would likely be static > for the > > >entire session. This is the more usual way to operate TWAMP: > > >telling the Server/Session-Reflector everything needed in > advance of > > >Starting the test session. > > > > > >It's good that the value-added-octets proposal incorporates the > > >TWAMP-Control protocol in the latest version (01). > > > > > >So now, I wonder if the *many* new test session packet > formats found in > > >the value-added-octets proposal could be simplified by moving some > > >information currently conveyed in the Test session (via > > >flags/fields) to the Control session? In other words, > this proposal > > >asks the Session-Reflector to perform many new operations, > and perhaps > > >adoption will be wider if less processing is expected during > the test > > >session. Of course, Request-TW-Session variables are static > for the > > >life of the test session, if accepted. > > > > > >regards, > > >Al > > > > > >_______________________________________________ > > >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 --_002_fc41bb91f0f34d9e535dvideotronca_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Fri, 08 Apr 2011 04:14:31 GMT"; modification-date="Fri, 08 Apr 2011 04:14:31 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFp bGluZyBsaXN0DQppcHBtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwcG0NCg== --_002_fc41bb91f0f34d9e535dvideotronca_-- --_002_4383945B8C24AA4FBC33555BB7B829EF0DECEDEDDDEUSAACMS0701e_-- From matt@internet2.edu Fri Apr 29 16:23:46 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 E351BE06AD for ; Fri, 29 Apr 2011 16:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 sLqesE30BfpL for ; Fri, 29 Apr 2011 16:23:46 -0700 (PDT) Received: from int-mailstore01.merit.edu (int-mailstore01.merit.edu [207.75.116.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4286AE0698 for ; Fri, 29 Apr 2011 16:23:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-mailstore01.merit.edu (Postfix) with ESMTP id 8CC35305A9D8 for ; Fri, 29 Apr 2011 19:23:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at int-mailstore01.merit.edu Received: from int-mailstore01.merit.edu ([127.0.0.1]) by localhost (int-mailstore01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xVDnBiQMVrK for ; Fri, 29 Apr 2011 19:23:39 -0400 (EDT) Received: from 69.sub-75-224-162.myvzw.com (69.sub-75-224-162.myvzw.com [75.224.162.69]) by int-mailstore01.merit.edu (Postfix) with ESMTPSA id 09600305CC55 for ; Fri, 29 Apr 2011 19:23:37 -0400 (EDT) Message-ID: <4DBB4877.9040808@internet2.edu> Date: Fri, 29 Apr 2011 19:23:35 -0400 From: Matthew J Zekauskas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ippm] 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: Fri, 29 Apr 2011 23:23:47 -0000 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)