From Even.roni@huawei.com Thu Sep 1 02:20:32 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B71521F8B3D for ; Thu, 1 Sep 2011 02:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.946 X-Spam-Level: X-Spam-Status: No, score=-105.946 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuN5xlgEnMxi for ; Thu, 1 Sep 2011 02:20:32 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D564B21F8B47 for ; Thu, 1 Sep 2011 02:20:31 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQU0076B7CPFY@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 01 Sep 2011 17:22:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQU006KS7CPG3@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 01 Sep 2011 17:22:01 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQU002EJ7CLB0@szxml11-in.huawei.com>; Thu, 01 Sep 2011 17:22:01 +0800 (CST) Date: Thu, 01 Sep 2011 12:20:57 +0300 From: Roni Even In-reply-to: <4E5DE6D1.3070702@glycon.org> To: =?iso-8859-1?Q?'st=E9phane_bryant'?= , p2psip@ietf.org Message-id: <00e701cc6888$78095420$681bfc60$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acxnsx/3xhJ5/AouQMC2ZPUmpysvHQA0qYVw References: <4E5DE6D1.3070702@glycon.org> Subject: Re: [P2PSIP] structure definition issue in draft-zong-p2psip-drr-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 09:20:32 -0000 Hi Stephane, Yes you are right I thought this meant the number of elements in the structure but now I see from the base draft that it is the length of the structure. Since destination may have 1 or 2 elements I think that the following will be enough. struct { RouteMode routemode; OverlayLink transport; IpAddressPort ipaddressport; Destination destination<1..2^8-1>; } ExtensiveRoutingModeOption Regards Roni > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of st?phane bryant > Sent: Wednesday, August 31, 2011 10:46 AM > To: p2psip@ietf.org > Subject: [P2PSIP] structure definition issue in draft-zong-p2psip-drr- > 00 > > Hello, > > In draft-zong-p2psip-drr-00, section 6.2.2. Extensive Routing Mode, > the ExtensiveRoutingModeOption structure is defined thus: > > struct { > RouteMode routemode; > OverlayLink transport; > IpAddressPort ipaddressport; > Destination destination<1..2>; > } ExtensiveRoutingModeOption; > > however the convention for variable length > fields is designed to represent the length in bytes > of the field, the range allowing to also derive > the size of the length field. <1..2> does not work. > My take is that it should be <0...2^16>. > > I am currently adding new parsing capabilities to > the wireshark dissector: as soon as this is defined > i will add capabilities for this draft. > > regards > stephane bryant > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@IDSSOFTWARE.COM Thu Sep 1 19:52:04 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367DF21F91AB for ; Thu, 1 Sep 2011 19:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[AWL=-2.029, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn8TnYf3SuBO for ; Thu, 1 Sep 2011 19:52:03 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id 7F69521F918F for ; Thu, 1 Sep 2011 19:52:03 -0700 (PDT) Received: (qmail 14972 invoked from network); 2 Sep 2011 02:53:37 -0000 Received: from unknown (HELO gem-wbe31.prod.mesa1.secureserver.net) (64.202.189.209) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 2 Sep 2011 02:53:37 -0000 Received: (qmail 4221 invoked by uid 99); 2 Sep 2011 02:53:37 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.5.18 Message-Id: <20110901195336.61e8c06078a3b23a733c71e914c0b9df.6a411c54ef.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Thu, 01 Sep 2011 19:53:36 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Base draft 9.7.4.1 title does not match its content X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 02:52:04 -0000
Hi,

I surprise this has slipped by everyone. The title= of the base draft section 9.7.4.1. is

 "9.7.4.1.  Updati= ng neighbor table"

Its first sentence says,

&n= bsp;"A peer MUST periodically send an Update request to every peer in its   Connection Table."

Which o= ne is the intended collection of peer for periodic update? The first bullet= of 9.7.4 seems to confirm that it should be "neighbor" table.

Thanks

Michael Chen

 From zongning@huawei.com Thu Sep 1 22:42:08 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C3F21F8FEC for ; Thu, 1 Sep 2011 22:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.73 X-Spam-Level: X-Spam-Status: No, score=-97.73 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD1I1tgkmjKz for ; Thu, 1 Sep 2011 22:42:08 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 267E221F8FEB for ; Thu, 1 Sep 2011 22:42:02 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQV00ELIRWOG4@szxga05-in.huawei.com> for p2psip@ietf.org; Fri, 02 Sep 2011 13:43:36 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQV006NDRWHM4@szxga05-in.huawei.com> for p2psip@ietf.org; Fri, 02 Sep 2011 13:43:36 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADT26712; Fri, 02 Sep 2011 13:43:34 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 02 Sep 2011 13:43:26 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.189]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Fri, 02 Sep 2011 13:43:32 +0800 Date: Fri, 02 Sep 2011 05:43:30 +0000 From: ZongNing In-reply-to: <00e701cc6888$78095420$681bfc60$%roni@huawei.com> X-Originating-IP: [10.138.41.128] To: Roni Even , =?gb2312?B?J3N0qKZwaGFuZSBicnlhbnQn?= , "p2psip@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: [P2PSIP] structure definition issue in draft-zong-p2psip-drr-00 Thread-index: AQHMZ7McssOSk+IaiU+2o/SUOT+RhZU3u2aAgAHbZ1A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E5DE6D1.3070702@glycon.org> <00e701cc6888$78095420$681bfc60$%roni@huawei.com> Subject: [P2PSIP] =?gb2312?b?tPC4tDogIHN0cnVjdHVyZSBkZWZpbml0aW9uIGlzc3Vl?= =?gb2312?b?IGluIGRyYWZ0LXpvbmctcDJwc2lwLWRyci0wMA==?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 05:42:08 -0000 SGksIFN0ZXBoYW5lIGFuZCBSb25pDQpJIHdpbGwgYWRkcmVzcyB0aGlzIGluIG5leHQgcmV2aXNp b24uIFRoYW5rIHlvdSBmb3IgdGhlIGRpc2N1c3Npb24uDQoNCkJSLA0KTmluZyBab25nDQoNCi0t LS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnAycHNpcC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvbmkgRXZlbg0Kt6LLzcqxvOQ6IDIwMTHE 6jnUwjHI1SAxNzoyMQ0KytW8/sjLOiAnc3SopnBoYW5lIGJyeWFudCc7IHAycHNpcEBpZXRmLm9y Zw0K1vfM4jogUmU6IFtQMlBTSVBdIHN0cnVjdHVyZSBkZWZpbml0aW9uIGlzc3VlIGluIGRyYWZ0 LXpvbmctcDJwc2lwLWRyci0wMA0KDQpIaSBTdGVwaGFuZSwNClllcyB5b3UgYXJlIHJpZ2h0IEkg dGhvdWdodCB0aGlzIG1lYW50IHRoZSBudW1iZXIgb2YgZWxlbWVudHMgaW4gdGhlDQpzdHJ1Y3R1 cmUgYnV0IG5vdyBJIHNlZSBmcm9tIHRoZSBiYXNlIGRyYWZ0IHRoYXQgaXQgaXMgdGhlIGxlbmd0 aCBvZiB0aGUNCnN0cnVjdHVyZS4gDQpTaW5jZSBkZXN0aW5hdGlvbiBtYXkgaGF2ZSAxIG9yIDIg ZWxlbWVudHMgSSB0aGluayB0aGF0IHRoZSBmb2xsb3dpbmcgd2lsbA0KYmUgZW5vdWdoLiANCg0K c3RydWN0IHsNCiAgICAgICAgICAgUm91dGVNb2RlICAgICAgICAgICAgICAgcm91dGVtb2RlOw0K ICAgICAgICAgICBPdmVybGF5TGluayAgICAgICAgICAgICB0cmFuc3BvcnQ7DQogICAgICAgICAg IElwQWRkcmVzc1BvcnQgICAgICAgICAgaXBhZGRyZXNzcG9ydDsNCiAgICAgICAgICAgRGVzdGlu YXRpb24gICAgICAgICAgICAgZGVzdGluYXRpb248MS4uMl44LTE+Ow0KICAgfSBFeHRlbnNpdmVS b3V0aW5nTW9kZU9wdGlvbg0KDQoNClJlZ2FyZHMNClJvbmkNCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IHAycHNpcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cDJw c2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBzdD9waGFuZSBicnlhbnQNCj4g U2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTEgMTA6NDYgQU0NCj4gVG86IHAycHNpcEBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBbUDJQU0lQXSBzdHJ1Y3R1cmUgZGVmaW5pdGlvbiBpc3N1ZSBp biBkcmFmdC16b25nLXAycHNpcC1kcnItDQo+IDAwDQo+IA0KPiBIZWxsbywNCj4gDQo+IEluIGRy YWZ0LXpvbmctcDJwc2lwLWRyci0wMCwgc2VjdGlvbiA2LjIuMi4gRXh0ZW5zaXZlIFJvdXRpbmcg TW9kZSwNCj4gdGhlIEV4dGVuc2l2ZVJvdXRpbmdNb2RlT3B0aW9uIHN0cnVjdHVyZSBpcyBkZWZp bmVkIHRodXM6DQo+IA0KPiAgc3RydWN0IHsNCj4gICAgICAgICAgICBSb3V0ZU1vZGUgICAgICAg ICAgICAgICByb3V0ZW1vZGU7DQo+ICAgICAgICAgICAgT3ZlcmxheUxpbmsgICAgICAgICAgICAg dHJhbnNwb3J0Ow0KPiAgICAgICAgICAgIElwQWRkcmVzc1BvcnQgICAgICAgICAgaXBhZGRyZXNz cG9ydDsNCj4gICAgICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAgICAgICBkZXN0aW5hdGlvbjwx Li4yPjsNCj4gICAgfSBFeHRlbnNpdmVSb3V0aW5nTW9kZU9wdGlvbjsNCj4gDQo+IGhvd2V2ZXIg dGhlIDx4Li55PiBjb252ZW50aW9uIGZvciB2YXJpYWJsZSBsZW5ndGgNCj4gZmllbGRzIGlzIGRl c2lnbmVkIHRvIHJlcHJlc2VudCB0aGUgbGVuZ3RoIGluIGJ5dGVzDQo+IG9mIHRoZSBmaWVsZCwg dGhlIHJhbmdlIGFsbG93aW5nIHRvIGFsc28gZGVyaXZlDQo+IHRoZSBzaXplIG9mIHRoZSBsZW5n dGggZmllbGQuIDwxLi4yPiBkb2VzIG5vdCB3b3JrLg0KPiBNeSB0YWtlIGlzIHRoYXQgaXQgc2hv dWxkIGJlIDwwLi4uMl4xNj4uDQo+IA0KPiBJIGFtIGN1cnJlbnRseSBhZGRpbmcgbmV3IHBhcnNp bmcgY2FwYWJpbGl0aWVzIHRvDQo+IHRoZSB3aXJlc2hhcmsgZGlzc2VjdG9yOiBhcyBzb29uIGFz IHRoaXMgaXMgZGVmaW5lZA0KPiBpIHdpbGwgYWRkIGNhcGFiaWxpdGllcyBmb3IgdGhpcyBkcmFm dC4NCj4gDQo+IHJlZ2FyZHMNCj4gc3RlcGhhbmUgYnJ5YW50DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4g UDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cDJwc2lwDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpQMlBTSVAgbWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQo= From michaelc@IDSSOFTWARE.COM Sat Sep 3 20:51:01 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C4A21F884C for ; Sat, 3 Sep 2011 20:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_50=0.001, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j872G1Vb-PNi for ; Sat, 3 Sep 2011 20:51:01 -0700 (PDT) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id 24DB821F8829 for ; Sat, 3 Sep 2011 20:50:56 -0700 (PDT) Received: (qmail 20279 invoked from network); 4 Sep 2011 03:52:36 -0000 Received: from unknown (HELO gem-wbe19.prod.mesa1.secureserver.net) (64.202.189.174) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 4 Sep 2011 03:52:36 -0000 Received: (qmail 22242 invoked by uid 99); 4 Sep 2011 03:52:36 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.5.18 Message-Id: <20110903205235.61e8c06078a3b23a733c71e914c0b9df.11acea4d0e.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sat, 03 Sep 2011 20:52:35 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Question about base draft 9.7.4.4 Detecting partitioning X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 03:51:01 -0000 Hi,=0A=0ABase draft section "9.7.4.4. Detecting partitioning" says,=0A=0A = "P should then send a Ping for its own Node-ID routed through B."=0A=0ASay = you have a ring looks like this: ...-> X -> B -> Y -> P -> Z ->...=0Awhere = B is P's bootstrap node. If the overlay is healthy, wouldn't a=0APing to P= 's own Node-ID sent to B be routed back to P itself? In that=0Acase, P wil= l not be able to discover its possible new successor Z.=0A=0AAny thoughts? = =0A=0A--Michael=0A From michaelc@IDSSOFTWARE.COM Sat Sep 3 22:07:56 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBDC21F8A96 for ; Sat, 3 Sep 2011 22:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK9mBjG1vWt6 for ; Sat, 3 Sep 2011 22:07:55 -0700 (PDT) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id 9A6CE21F8A80 for ; Sat, 3 Sep 2011 22:07:55 -0700 (PDT) Received: (qmail 16868 invoked from network); 4 Sep 2011 05:09:35 -0000 Received: from unknown (HELO gem-wbe18.prod.mesa1.secureserver.net) (64.202.189.222) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 4 Sep 2011 05:09:35 -0000 Received: (qmail 26273 invoked by uid 99); 4 Sep 2011 05:09:35 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.5.18 Message-Id: <20110903220934.61e8c06078a3b23a733c71e914c0b9df.b69b4e6238.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sat, 03 Sep 2011 22:09:34 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Base draft 9.5 bullet 2 needs to be revised X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 05:07:56 -0000 Hi,=0A=0ABase draft section 5.5.1 second paragraph states:=0A=0A "As descr= ibed in Section 5.1, an Attach may be routed to either a=0A Node-ID or to= a Resource-ID. An Attach routed to a specific Node-ID=0A will fail if t= hat node is not reached."=0A=0AThe second sentence above invalidates sectio= n 9.5 bullet 2, which says=0A=0A "2. JP SHOULD send an Attach request to = the admitting peer (AP) for=0A Node-ID n. The "send_update" flag sho= uld be used to acquire the=0A routing table for AP."=0A=0ASince JP's = Node-ID is not yet valid, AP should fail the request as=0Ainstructed by 5.5= .1.=0A=0AI believe this should be changed to (similar to how to discover=0A= successor in later paragraph):=0A=0A "2. JP SHOULD send an Attach request= to the admitting peer (AP) for=0A Resource-ID n+1. The "send_update= " flag should be used to=0A acquire the routing table for AP."=0A=0AT= hanks=0A=0A--Michael=0A=0A=0A From stephane.ml.bryant@gmail.com Sun Sep 4 23:21:25 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDB221F851A for ; Sun, 4 Sep 2011 23:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ca+jClR4goU for ; Sun, 4 Sep 2011 23:21:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C62F21F8AD9 for ; Sun, 4 Sep 2011 23:21:24 -0700 (PDT) Received: by wwf5 with SMTP id 5so3107119wwf.13 for ; Sun, 04 Sep 2011 23:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=yLoWsS9e4BE1giPD0oc4vI1rE1yhpRib1cTcAyZaKjc=; b=KRILPl+RTGNUIeaq298EOdlyrt+7XgpzNd9xhZLR8ThUVQcUUtD1nnWgMjfLuD8eGr yr1iSrUHE2YBywQfp9qDeB259voAIceLL5Fbhpwo1a0dD11km8UDfWMQ9FjojKpQJG13 SLMteSE/2N9vb+dKtRM3T+n124hr7gXT9Yy1M= Received: by 10.227.68.202 with SMTP id w10mr479320wbi.71.1315203787530; Sun, 04 Sep 2011 23:23:07 -0700 (PDT) Received: from ?IPv6:2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e? ([2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e]) by mx.google.com with ESMTPS id fq2sm7020567wbb.24.2011.09.04.23.23.06 (version=SSLv3 cipher=OTHER); Sun, 04 Sep 2011 23:23:06 -0700 (PDT) Sender: stephane bryant Message-ID: <4E646AC6.10905@glycon.org> Date: Mon, 05 Sep 2011 08:23:02 +0200 From: =?ISO-8859-1?Q?st=E9phane_bryant?= Organization: StonyFish, Inc User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] typos in draft-ietf-p2psip-diagnostics-06 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 06:21:25 -0000 Hello, In draft-ietf-p2psip-diagnostics-06, the structures DiagnosticsRequest and DiagnosticsResponse (Diagnostics with an s) are at times referred to as DiagnosticRequest and DiagnosticResponse (no s. In particular in the definition of the PathTrackReq and PathTrackAns structures). regards stephane bryant From haibin.song@huawei.com Mon Sep 5 00:17:57 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4FA21F8ABE for ; Mon, 5 Sep 2011 00:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2eS-dZiadSR for ; Mon, 5 Sep 2011 00:17:56 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id EC82021F8A97 for ; Mon, 5 Sep 2011 00:17:55 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR1006C9GBOAW@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 05 Sep 2011 15:19:00 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR100CUDGBBSH@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 05 Sep 2011 15:19:00 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADU26478; Mon, 05 Sep 2011 15:18:59 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 05 Sep 2011 15:18:57 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.251]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Mon, 05 Sep 2011 15:18:54 +0800 Date: Mon, 05 Sep 2011 07:18:55 +0000 From: Songhaibin In-reply-to: <4E646AC6.10905@glycon.org> X-Originating-IP: [10.138.41.129] To: =?iso-8859-1?Q?st=E9phane_bryant?= , "p2psip@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [P2PSIP] typos in draft-ietf-p2psip-diagnostics-06 Thread-index: AQHMa5WC1WvXQ7AXxEaa0jkeWuic1ZU+YPEg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E646AC6.10905@glycon.org> Subject: Re: [P2PSIP] typos in draft-ietf-p2psip-diagnostics-06 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 07:17:57 -0000 Thank you very much, Stephane. The authors will correct them in the next re= vision. BR, -Haibin > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of > st=E9phane bryant > Sent: Monday, September 05, 2011 2:23 PM > To: p2psip@ietf.org > Subject: [P2PSIP] typos in draft-ietf-p2psip-diagnostics-06 >=20 > Hello, >=20 > In draft-ietf-p2psip-diagnostics-06, the structures > DiagnosticsRequest and DiagnosticsResponse (Diagnostics > with an s) are at times referred to as DiagnosticRequest > and DiagnosticResponse (no s. In particular in the > definition of the PathTrackReq and PathTrackAns structures). >=20 > regards > stephane bryant > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From Michael.Scharf@alcatel-lucent.com Sun Sep 4 05:48:36 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818D321F88B6; Sun, 4 Sep 2011 05:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2-1syIm20Qz; Sun, 4 Sep 2011 05:48:35 -0700 (PDT) Received: from mailrelay1.alcatel.de (mailrelay1.alcatel.de [194.113.59.95]) by ietfa.amsl.com (Postfix) with ESMTP id ED8C721F8862; Sun, 4 Sep 2011 05:48:34 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay1.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p84CneWc030216; Sun, 4 Sep 2011 14:49:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Sep 2011 14:50:12 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C066833EF@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tsv-dir review of draft-ietf-p2psip-base-18 Thread-Index: AcxrAS9YNJ0c9PHZQPmRqig56aAy4Q== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.72 X-Mailman-Approved-At: Mon, 05 Sep 2011 08:34:14 -0700 Cc: tsv-dir@ietf.org, tsv-area@ietf.org, p2psip@ietf.org, draft-ietf-p2psip-base@tools.ietf.org Subject: [P2PSIP] tsv-dir review of draft-ietf-p2psip-base-18 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 12:48:36 -0000 Hi, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review.=20 This draft is on the right track but has open issues, described in the review. Given the length and complexity of the document, I only comment on transport issues. However, for what it is worth, my personal impression is that other sections not addressed by this review seem to be somehow experimental. My main concern is the Forwarding and Link Management Layer. It is designed to run over different transports, most notably TCP and UDP. Having such a generic transport including built-in NAT traversal support is very valuable. But I find parts of the specification confusing, as explained below. Also, building a simple, generic transport mechanism on top of UDP and TCP (or, DTLS and TLS) is actually something that is hardly specific to RELOAD. Main concerns: Section 1.2.5: "This layer also utilizes a framing header to encapsulate messages as they are forwarding along each hop. This header aids reliability congestion control, flow control, etc. It has meaning only in the context of that individual link." (BTW: Note that a comma is missing after reliability.) =3D> This already well explains my concern that is further detailed = below: If TCP (or SCTP) transport is used, reliability, congestion control, flow control are already solved by the transport protocol. Does the Forwarding and Link Management Layer duplicate these functions then? This and potential interactions are not well described in the document. Section 5.2.1: "Because messages may be lost in transit through the overlay, RELOAD incorporates an end-to-end reliability mechanism. When an originating node transmits a request it MUST set a 3 second timer. If a response has not been received when the timer fires, the request is retransmitted with the same transaction identifier. The request MAY be retransmitted up to 4 times (for a total of 5 messages). After the timer for the fifth transmission fires, the message SHALL be considered to have failed." =3D> It may make sense to exponentially backoff this timer. Or, at least it would be useful to explain why not to backoff. 3 sec is the initial retransmission timeout duration of older TCP stacks, i. e., in worst case scenarios even the transfer over a single overlap hop can result in 3 sec delay. Section 5.5.1.6: "Highest priority is assigned to protocols that offer well-understood congestion and flow control without head of line blocking. For example, SCTP without message ordering, DCCP, or those protocols encapsulated using UDP. [...] Second highest priority is assigned to protocols that offer well-understood congestion and flow control but have head of line blocking such as TCP." =3D> While SCTP may be better suited for signaling applications than = TCP, I wonder why DCCP should have a high priority than TCP. AFAIK, DCCP offers no reliability and is not build for signaling transport. Any application-level retransmission mechanism on top of DCCP is likely to be slower than transport protocol mechanism offered by SCTP and TCP. Maybe I miss something? (As a side note: Research results have shown that head-of-line blocking only has a significant impact for high packet loss rates (> 1%). In that case, the link is seriously congested and congestion control will significantly throttle the data transfer. Head-of-line blocking might then not be the most important delay component. Personally, I don't think that avoiding head-of-line blocking is the most important advantage of SCTP over TCP, and thus I don't think that it has to be stressed in that section. But that is my personal view and it might not be shared by the whole research community.) Section 5.6: "The Framing Header (FH) is used to frame messages and provide timing when used on a reliable stream-based transport protocol. Simple Reliability (SR) makes use of the FH to provide congestion control and semi-reliability when using unreliable message-oriented transport protocols."=20 =3D> In this and in followup sections, the operation on top of a = reliable congestion-controlled protocol (TCP, possibly SCTP in future) should be better separated from datagram transport (UDP). The required functions in the Overlay Link Layer seem to be quite different.=20 Sections 5.6.1.1, Section 5.6.1.3, Section 5.6.1.4 =3D> These cases are apparently not covered by this spec. Move to appendix? Section 5.6.2: "The same header is used for both reliable and unreliable transports for simplicity of implementation." =3D> True, one can do that. But as both endpoints anyway have to agree = to on a transport, it would not be overly complex to use headers that are better aligned with the features of the underlying transport, right? I. e., one could use a more complex header if UDP transport is needed. RELOAD has a similar flexibility concerning data structures in many other parts of the protocol. Section 5.6.2: "When the receiver receives a message, it SHOULD immediately send an ACK message. The receiver MUST keep track of the 32 most recent sequence numbers received on this association in order to generate the appropriate ack." =3D> Maybe I am completely lost here: Why is this MUST needed for = TCP/TLS links? In that case, messages arrive in order on a link, i. e., acking the most recent one is sufficient. All previous ones must already have been received. Section 5.6.2: " received A bitmask indicating if each of the previous 32 sequence numbers before this packet has been among the 32 packets most recently received on this connection." =3D> I had a hard time in understanding this sentence, and it implications. I guess that this bitmask doesn't ensure full reliability, at least in corner cases (e. g. 33 messages being lost in sequence). In other words, this is a partial reliability scheme. I wonder why not to use a cumulative ack with a bitmask acking out-of-order data, similar to TCP's SACK. Also, the requirement of only acking the "32 packets most recently received" may have undesired effects (e. g., what happens in case of packet duplication?). In fact, instead of this customized scheme, running a small subset of TCP's mechanisms in the user space might just be fine, and I don't understand why this would be more complex than implementing this scheme. Section 5.6.2: "The received field bits in the ACK provide a high degree of redundancy so that the sender can figure out which packets the receiver has received and can then estimate packet loss rates. If the sender also keeps track of the time at which recent sequence numbers have been sent, the RTT can be estimated." =3D> There is a lot of redunancy, indeed. But it would help to have a short paragraph that explains how the sender indeed estimates the packet loss rate. And note that the wording is slightly misleading: IMHO it is not the *redundancy* that enables the sender to estimate the packet loss rate. Other acknowlegdement schemes with less redundancy would work as well. Section 5.6.3.1: "In general, senders MAY implement any rate control scheme of their choice, provided that it is REQUIRED to be no more aggressive then TFRC[RFC5348]. The following section describes a simple, inefficient scheme that complies with this requirement." =3D> Maybe I again miss something, but as far as I can see the following sections doesn't fully explain how TFRC is implemented here. For example, TFRC requires information about the segment size; this is not considered here. In general, it is not clear to me why a simple baseline implementation does not follow the TFRC protocol (RFC 5348) more closely (or a light-weight user-space TCP-like protocol). Section 5.6.3.1.1: "In each retransmission, the sequence number is incremented." =3D> It would be worth to spend a sentence about the rational and consequences of this. For instance, whether this implies that a receiver may process the original message and the retransmission twice. Section 5.6.3.1.1: "Implementations that use a dynamic estimate to compute the RTO MUST use the algorithm described in RFC 6298[RFC6298], with the exception that the value of RTO SHOULD NOT be rounded up to the nearest second but instead rounded up to the nearest millisecond." =3D> This sentence doesn't cite RFC 6298 correctly. RFC 6298 doesn't mandate to round up to the nearest second. It mandates a minimum RTO of 1 second. And I strongly suggest to use such a minimum RTO as well (maybe 500ms as minimum would be OK as well). Section 5.6.3.1.1: "Once an ACK has been received for a message, the next message can be sent, but the peer SHOULD ensure that there is at least 10 ms between sending any two messages. The only time a value less than 10 ms can be used is when it is known that all nodes are on a network that can support retransmissions faster than 10 ms with no congestion issues." =3D> This last requirement cannot be achieved in practice, IMHO. It is impossible to know in advance congestion situations unless the overlay operates in a fully controlled environment without any risk of link failures etc. Thus, this paragraph effectively seems to limit the peak load per link to 100 messages/s. I could imagine that this is not sufficient in very large overlays. Would it make sense to put this parameter in the configuration file instead? Section 5.6.5: "Because the TCP layer's application-level timeout is too slow to be useful for overlay routing, the Overlay Link implementation MUST use the framing header to measure the RTT of the connection and calculate an RTO as specified in Section 2 of [RFC6298]. The resulting RTO is not used for retransmissions, but as a timeout to indicate when the link SHOULD be removed from the routing table." =3D> Again, instead of such implicit statements, I somehow miss in the document an explicit statement that explains that relability, congestion control, flow control etc. does not have to be provided by the overlay link protocol when running over TCP. Editorial issues: Section 5.3.2.1: "Because the sequence number may in principle wrap, greater than or less than are interpreted by modulo arithmetic as in TCP." =3D> Maybe better "... as sequence numbers in TCP"? Section 5.5.1: "A node sends an Attach request when it wishes to establish a direct TCP or UDP connection to another node for the purpose of sending RELOAD messages." =3D> As correctly noted later in Section 5.6, UDP does not properly have "connections". The rationale for still using that term should be moved to Section 5.5.1. Section 5.5.1.8 and following sections: "An agent MUST skip the verification procedures in Section 5.1 and 6.1 of ICE." =3D> Less confusing would be "... of the ICE specification". All Sections: Please ensure that concepts and acronyms are explained when they are first used. I apolologize if I should have missed something. Michael From haibin.song@huawei.com Sun Sep 4 23:33:11 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C837721F8802 for ; Sun, 4 Sep 2011 23:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSi-KHCBfw1x for ; Sun, 4 Sep 2011 23:33:11 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 30CCC21F874B for ; Sun, 4 Sep 2011 23:33:11 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR100AAJE9MUF@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 05 Sep 2011 14:34:34 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR100C9AE91SH@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 05 Sep 2011 14:34:34 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADU22118; Mon, 05 Sep 2011 14:34:34 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 05 Sep 2011 14:34:28 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.251]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Mon, 05 Sep 2011 14:34:27 +0800 Date: Mon, 05 Sep 2011 06:34:27 +0000 From: Songhaibin In-reply-to: <4E646AC6.10905@glycon.org> X-Originating-IP: [10.138.41.129] To: =?iso-8859-1?Q?st=E9phane_bryant?= , "p2psip@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [P2PSIP] typos in draft-ietf-p2psip-diagnostics-06 Thread-index: AQHMa5WC1WvXQ7AXxEaa0jkeWuic1ZU+VFwQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E646AC6.10905@glycon.org> X-Mailman-Approved-At: Mon, 05 Sep 2011 08:34:14 -0700 Subject: Re: [P2PSIP] typos in draft-ietf-p2psip-diagnostics-06 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 06:33:11 -0000 Thank you very much, Stephane. The authors will correct them in the next re= vision. BR, -Haibin > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of > st=E9phane bryant > Sent: Monday, September 05, 2011 2:23 PM > To: p2psip@ietf.org > Subject: [P2PSIP] typos in draft-ietf-p2psip-diagnostics-06 >=20 > Hello, >=20 > In draft-ietf-p2psip-diagnostics-06, the structures > DiagnosticsRequest and DiagnosticsResponse (Diagnostics > with an s) are at times referred to as DiagnosticRequest > and DiagnosticResponse (no s. In particular in the > definition of the PathTrackReq and PathTrackAns structures). >=20 > regards > stephane bryant > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Mon Sep 5 12:03:28 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4FB21F8BC3; Mon, 5 Sep 2011 12:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdCTY4zHgF69; Mon, 5 Sep 2011 12:03:27 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4628C21F8BBE; Mon, 5 Sep 2011 12:03:26 -0700 (PDT) Received: by ewy19 with SMTP id 19so2409345ewy.31 for ; Mon, 05 Sep 2011 12:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.11.227 with SMTP id 75mr1361874eex.178.1315249510328; Mon, 05 Sep 2011 12:05:10 -0700 (PDT) Received: by 10.14.127.13 with HTTP; Mon, 5 Sep 2011 12:05:09 -0700 (PDT) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C066833EF@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C066833EF@SLFSNX.rcs.alcatel-research.de> Date: Mon, 5 Sep 2011 15:05:09 -0400 Message-ID: From: Bruce Lowekamp To: "SCHARF, Michael" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org, draft-ietf-p2psip-base@tools.ietf.org, tsv-area@ietf.org, iesg@ietf.org, tsv-dir@ietf.org Subject: Re: [P2PSIP] tsv-dir review of draft-ietf-p2psip-base-18 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 19:03:28 -0000 Thanks for the review. Responses inline Bruce On Sun, Sep 4, 2011 at 8:50 AM, SCHARF, Michael wrote: > Hi, > > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address > any issues raised. The authors should consider this review together with > any other last-call comments they receive. Please always CC > tsv-dir@ietf.org if you reply to or forward this review. > > > This draft is on the right track but has open issues, described in the > review. Given the length and complexity of the document, I only comment > on transport issues. However, for what it is worth, my personal > impression is that other sections not addressed by this review seem to > be somehow experimental. > > My main concern is the Forwarding and Link Management Layer. It is > designed to run over different transports, most notably TCP and UDP. > Having such a generic transport including built-in NAT traversal support > is very valuable. But I find parts of the specification confusing, as > explained below. Also, building a simple, generic transport mechanism on > top of UDP and TCP (or, DTLS and TLS) is actually something that is > hardly specific to RELOAD. Totally agree. One of the reasons we left room for extension points for new transports is in the hope that a more general solution will become mature enough to be dropped in at a later date. In line with that idea, we tried to go for overly simple to avoid spending too much time specifying complexity that we hope would be replaced with a better solution. > > > Main concerns: > > Section 1.2.5: "This layer also utilizes a framing header to encapsulate > messages as they are forwarding along each hop. =C2=A0This header aids > reliability congestion control, flow control, etc. =C2=A0It has meaning o= nly > in the context of that individual link." (BTW: Note that a comma is > missing after reliability.) > > =3D> This already well explains my concern that is further detailed below= : > If TCP (or SCTP) transport is used, reliability, congestion control, > flow control are already solved by the transport protocol. Does the > Forwarding and Link Management Layer duplicate these functions then? > This and potential interactions are not well described in the document. Within the role of the overlay network, TCP/SCTP are used as link-layer protocols for hop-by-hop connections (part of forwarding and link management, as you observe). However, e2e control is still needed and provided by the Message Transport layer. While we may get some benefit from TCP/SCTP over the individual hops, they don't address the end-to-end transport issues. > > > Section 5.2.1: "Because messages may be lost in transit through the > overlay, RELOAD incorporates an end-to-end reliability mechanism. =C2=A0W= hen > an originating node transmits a request it MUST set a 3 second timer. If > a response has not been received when the timer fires, the request is > retransmitted with the same transaction identifier. The request MAY be > retransmitted up to 4 times (for a total of 5 messages). =C2=A0After the > timer for the fifth transmission fires, the message SHALL be considered > to have failed." > > =3D> It may make sense to exponentially backoff this timer. Or, at least > it would be useful to explain why not to backoff. 3 sec is the initial > retransmission timeout duration of older TCP stacks, i. e., in worst > case scenarios even the transfer over a single overlap hop can result in > 3 sec delay. I think we had a discussion about this timer at some point. I would hope we don't need to worry about such ancient TCP stacks, but a more realistic problem is the RTT for the multi-hop path across a large overlay exceeding 3 seconds. I admit I thought we had turned this into a configurable parameter, at least. There might be an argument that this should actually be adaptive, applying something like 6298's RTO estimator across all e2e RTTs on the overlay network and using that as an initial timeout for each new message. However, given the high variance in RTTs, it's not clear the effect this would have on performance, and it would add a lot of complexity to the implementation. Given that the underlying hop-by-hop transport has congestion control already, we decided to leave it as a simple constant as network stability shouldn't be a factor here. > > > Section 5.5.1.6: "Highest priority is assigned to protocols that offer > well-understood congestion and flow control without head of line > blocking. For example, SCTP without message ordering, DCCP, or those > protocols encapsulated using UDP. [...] Second highest priority is > assigned to protocols that offer well-understood congestion and flow > control but have head of line blocking such as TCP." > > =3D> While SCTP may be better suited for signaling applications than TCP, > I wonder why DCCP should have a high priority than TCP. AFAIK, DCCP > offers no reliability and is not build for signaling transport. Any > application-level retransmission mechanism on top of DCCP is likely to > be slower than transport protocol mechanism offered by SCTP and TCP. > Maybe I miss something? We don't care about hop-by-hop reliability here---so a datagram-based protocol with congestion control seems ideal. > > (As a side note: Research results have shown that head-of-line blocking > only has a significant impact for high packet loss rates (> 1%). In that > case, the link is seriously congested and congestion control will > significantly throttle the data transfer. Head-of-line blocking might > then not be the most important delay component. Personally, I don't > think that avoiding head-of-line blocking is the most important > advantage of SCTP over TCP, and thus I don't think that it has to be > stressed in that section. But that is my personal view and it might not > be shared by the whole research community.) Without being completely sure what results you're referring to, I'm going to assume that the analysis is whether HoL blocking affects the overall throughput of a TCP link, which I agree it shouldn't given modern SACK/retransmission etc. However, as we're using TCP here as the hop-by-hop link layer underlying a higher-level e2e protocol in the overlay network, the overall throughput of the hop isn't necessarily as important as eliminating the latency imposed by HoL blocking, which is there whenever there's a loss that requires retransmission and a delay in delivering subsequent messages to the application layer, and would greatly increase the e2e latency (and variance in latency) of the messages. > > > Section 5.6: "The Framing Header (FH) is used to frame messages and > provide timing when used on a reliable stream-based transport protocol. > Simple Reliability (SR) makes use of the FH to provide congestion > control and semi-reliability when using unreliable message-oriented > transport protocols." > > =3D> In this and in followup sections, the operation on top of a reliable > congestion-controlled protocol (TCP, possibly SCTP in future) should be > better separated from datagram transport (UDP). The required functions > in the Overlay Link Layer seem to be quite different. > why? e2e issues seem the same---even between consecutive TCP hops, the peers may experience congestion on the outgoing link and be forced to drop messages. > > Sections 5.6.1.1, Section 5.6.1.3, Section 5.6.1.4 > > =3D> These cases are apparently not covered by this spec. Move to > appendix? > We agreed a long time ago to leave things in 5.6.1.x in as callouts to future transports that were hoped to be added. I have no particular opinion whether it should be there or in an appendix. > > Section 5.6.2: "The same header is used for both reliable and unreliable > transports for simplicity of implementation." > > =3D> True, one can do that. But as both endpoints anyway have to agree to > on a transport, it would not be overly complex to use headers that are > better aligned with the features of the underlying transport, right? I. > e., one could use a more complex header if UDP transport is needed. > RELOAD has a similar flexibility concerning data structures in many > other parts of the protocol. > > > Section 5.6.2: "When the receiver receives a message, it SHOULD > immediately send an ACK message. =C2=A0The receiver MUST keep track of th= e 32 > most recent sequence numbers received on this association in order to > generate the appropriate ack." > > =3D> Maybe I am completely lost here: Why is this MUST needed for TCP/TLS > links? In that case, messages arrive in order on a link, i. e., acking > the most recent one is sufficient. All previous ones must already have > been received. Given the already significant length and complexity of the draft and protocol, I think "simplicity of implementation" is a significant concern. I don't see a negative impact here. > > > Section 5.6.2: " received =C2=A0A bitmask indicating if each of the previ= ous > 32 sequence numbers before this packet has been among the 32 packets > most recently received on this connection." > > =3D> I had a hard time in understanding this sentence, and it > implications. I guess that this bitmask doesn't ensure full reliability, > at least in corner cases (e. g. 33 messages being lost in sequence). In > other words, this is a partial reliability scheme. I wonder why not to > use a cumulative ack with a bitmask acking out-of-order data, similar to > TCP's SACK. Also, the requirement of only acking the "32 packets most > recently received" may have undesired effects (e. g., what happens in > case of packet duplication?). In fact, instead of this customized > scheme, running a small subset of TCP's mechanisms in the user space > might just be fine, and I don't understand why this would be more > complex than implementing this scheme. > below > > Section 5.6.2: "The received field bits in the ACK provide a high degree > of redundancy so that the sender can figure out which packets the > receiver has received and can then estimate packet loss rates. If the > sender also keeps track of the time at which recent sequence numbers > have been sent, the RTT can be estimated." > > =3D> There is a lot of redunancy, indeed. But it would help to have a > short paragraph that explains how the sender indeed estimates the packet > loss rate. And note that the wording is slightly misleading: IMHO it is > not the *redundancy* that enables the sender to estimate the packet loss > rate. Other acknowlegdement schemes with less redundancy would work as > well. > The discussion about what protocol to use here was one of the most controversial issues we had to address (both among the authors and within the wg). While I personally wanted to include a more tcp-like layer here, I was outvoted on the issue on the ground that what we have now is simpler (at least to those not sufficiently familiar with TCP), safe for network stability, and has sufficient performance for most overlays. We hope that more work will come out of TSV on appropriate user-layer/tunneled over UDP protocols that can be used to replace what's here in the future, but we decided to leave such work out of this draft as it was already sufficiently complexed. (and at the time I had hoped to spend time working with folks in TSV on such issues, but have had to curtail my IETF time recently as my current position doesn't support such work) > > Section 5.6.3.1: "In general, senders MAY implement any rate control > scheme of their choice, provided that it is REQUIRED to be no more > aggressive then TFRC[RFC5348]. The following section describes a simple, > inefficient scheme that complies with this requirement." > > =3D> Maybe I again miss something, but as far as I can see the following > sections doesn't fully explain how TFRC is implemented here. For > example, TFRC requires information about the segment size; this is not > considered here. In general, it is not clear to me why a simple baseline > implementation does not follow the TFRC protocol (RFC 5348) more closely > (or a light-weight user-space TCP-like protocol). > again, simplicity won out. We believe what's there is a simpler protocol (the simplest we could think of) that follows the requirement of being less aggressive than TFRC. > > Section 5.6.3.1.1: "In each retransmission, the sequence number is > incremented." > > =3D> It would be worth to spend a sentence about the rational and > consequences of this. For instance, whether this implies that a receiver > may process the original message and the retransmission twice. > Happy to spend a sentence on this, but just to be clear, this is designed to allow the world's dumbest stop-and-wait protocol. Specifically, the goal of 5.6.3.1.1 is to specify a ludicrously simple, totally safe algorithm that is sufficient for most envisioned deployments of P2PSIP for implementors who don't want to spend the time implementing TFRC. I would hope most do spend the time, but it seemed unnecessary to specify how TFRC works in this document. As far as the separate sequence numbers, they can be used because there's no issue with processing here as with TCP sequence numbers (this is the link-level hop-by-hop protocol), and if you want to do something fancier than stop-and-wait, it avoids ambiguity in calculating RTO (i.e. you don't need Karn's algorithm). Essentially, the receiver should is designed to be compliant with a much more intelligent sender than the stop-and-wait specified in this section, similar to the simplest TCP receivers. > > Section 5.6.3.1.1: "Implementations that use a dynamic estimate to > compute the RTO MUST use the algorithm described in RFC 6298[RFC6298], > with the exception that the value of RTO SHOULD NOT be rounded up to the > nearest second but instead rounded up to the nearest millisecond." > > =3D> This sentence doesn't cite RFC 6298 correctly. RFC 6298 doesn't > mandate to round up to the nearest second. It mandates a minimum RTO of > 1 second. And I strongly suggest to use such a minimum RTO as well > (maybe 500ms as minimum would be OK as well). > I think you refer to where 6298 says: Until a round-trip time (RTT) measurement has been made for a segment sent between the sender and receiver, the sender SHOULD set RTO <- 1 second, though the "backing off" on repeated retransmission discussed in (5.5) still applies. there's no need for that as ICE has already completed, so we have an RTT measurement. > > Section 5.6.3.1.1: "Once an ACK has been received for a message, the > next message can be sent, but the peer SHOULD ensure that there is at > least 10 ms between sending any two messages. =C2=A0The only time a value > less than 10 ms can be used is when it is known that all nodes are on a > network that can support retransmissions faster than 10 ms with no > congestion issues." > > =3D> This last requirement cannot be achieved in practice, IMHO. It is > impossible to know in advance congestion situations unless the overlay > operates in a fully controlled environment without any risk of link > failures etc. The operating environment referred to would be a LAN or similar. (more bel= ow) > Thus, this paragraph effectively seems to limit the peak > load per link to 100 messages/s. I could imagine that this is not > sufficient in very large overlays. Agreed. This protocol isn't intended to be operated in such an environment (would need TFRC, etc for that), but for many of the envisioned deployments of P2PSIP, it should be fine. (or some future emerging option) > Would it make sense to put this > parameter in the configuration file instead? I guess it's a valid point that you can't determine if you're in a network where you can do better without a configuration option. I hate to spend the time overthinking this option, given its deliberate limited applicability. Maybe we should just remove that. > > > Section 5.6.5: "Because the TCP layer's application-level timeout is too > slow to be useful for overlay routing, the Overlay Link implementation > MUST use the framing header to measure the RTT of the connection and > calculate an RTO as specified in Section 2 of [RFC6298]. The resulting > RTO is not used for retransmissions, but as a timeout to indicate when > the link SHOULD be removed from the routing table." > > =3D> Again, instead of such implicit statements, I somehow miss in the > document an explicit statement that explains that relability, congestion > control, flow control etc. does not have to be provided by the overlay > link protocol when running over TCP. Can add something to the beginning of 5.6 to this effect. From bbl@lowekamp.net Mon Sep 5 12:11:05 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC0F21F8BDC; Mon, 5 Sep 2011 12:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1LK8dfKgu-4; Mon, 5 Sep 2011 12:11:05 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA4521F8BDE; Mon, 5 Sep 2011 12:11:04 -0700 (PDT) Received: by eyx24 with SMTP id 24so3616678eyx.19 for ; Mon, 05 Sep 2011 12:12:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.34.13 with SMTP id r13mr1396568eea.82.1315249967600; Mon, 05 Sep 2011 12:12:47 -0700 (PDT) Received: by 10.14.127.13 with HTTP; Mon, 5 Sep 2011 12:12:47 -0700 (PDT) In-Reply-To: References: <133D9897FB9C5E4E9DF2779DC91E947C066833EF@SLFSNX.rcs.alcatel-research.de> Date: Mon, 5 Sep 2011 15:12:47 -0400 Message-ID: From: Bruce Lowekamp To: "SCHARF, Michael" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org, draft-ietf-p2psip-base@tools.ietf.org, tsv-area@ietf.org, iesg@ietf.org, tsv-dir@ietf.org Subject: Re: [P2PSIP] tsv-dir review of draft-ietf-p2psip-base-18 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 19:11:05 -0000 Sorry to follow up on my on post. Meant to change a comment before I sent.= .. On Mon, Sep 5, 2011 at 3:05 PM, Bruce Lowekamp wrote: > On Sun, Sep 4, 2011 at 8:50 AM, SCHARF, Michael > wrote: >> >> Section 5.6: "The Framing Header (FH) is used to frame messages and >> provide timing when used on a reliable stream-based transport protocol. >> Simple Reliability (SR) makes use of the FH to provide congestion >> control and semi-reliability when using unreliable message-oriented >> transport protocols." >> >> =3D> In this and in followup sections, the operation on top of a reliabl= e >> congestion-controlled protocol (TCP, possibly SCTP in future) should be >> better separated from datagram transport (UDP). The required functions >> in the Overlay Link Layer seem to be quite different. >> > > why? =C2=A0e2e issues seem the same---even between consecutive TCP hops, > the peers may experience congestion on the outgoing link and be forced > to drop messages. Ignore that comment, please. Functionally, since TCP doesn't provide fast enough timeouts to be useful as an overlay link protocol, an application-layer protocol is required regardless of its underlying guarantees. Implementation-wise, I think simplicity is the overriding concern. Bruce From Michael.Scharf@alcatel-lucent.com Tue Sep 6 10:18:54 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5F421F8BA7; Tue, 6 Sep 2011 10:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPpdNLLNzyTd; Tue, 6 Sep 2011 10:18:53 -0700 (PDT) Received: from mailrelay1.alcatel.de (mailrelay1.alcatel.de [194.113.59.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1D21F8B6F; Tue, 6 Sep 2011 10:18:49 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay1.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p86HJxFf012151; Tue, 6 Sep 2011 19:19:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Sep 2011 19:19:55 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C066834EF@SLFSNX.rcs.alcatel-research.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tsv-dir review of draft-ietf-p2psip-base-18 Thread-Index: Acxr/sHodKzlbUC3RGi/o83TbAQWGgAp+OdQ References: <133D9897FB9C5E4E9DF2779DC91E947C066833EF@SLFSNX.rcs.alcatel-research.de> From: "SCHARF, Michael" To: "Bruce Lowekamp" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.72 X-Mailman-Approved-At: Tue, 06 Sep 2011 10:33:30 -0700 Cc: p2psip@ietf.org, draft-ietf-p2psip-base@tools.ietf.org, tsv-area@ietf.org, iesg@ietf.org, tsv-dir@ietf.org Subject: Re: [P2PSIP] tsv-dir review of draft-ietf-p2psip-base-18 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 17:18:54 -0000 Some remarks on selected aspects inline.=20 > > This draft is on the right track but has open issues,=20 > described in the=20 > > review. Given the length and complexity of the document, I only=20 > > comment on transport issues. However, for what it is worth, my=20 > > personal impression is that other sections not addressed by this=20 > > review seem to be somehow experimental. > > > > My main concern is the Forwarding and Link Management Layer. It is=20 > > designed to run over different transports, most notably TCP and UDP. > > Having such a generic transport including built-in NAT traversal=20 > > support is very valuable. But I find parts of the specification=20 > > confusing, as explained below. Also, building a simple, generic=20 > > transport mechanism on top of UDP and TCP (or, DTLS and TLS) is=20 > > actually something that is hardly specific to RELOAD. >=20 > Totally agree. One of the reasons we left room for extension=20 > points for new transports is in the hope that a more general=20 > solution will > become mature enough to be dropped in at a later date. In line with > that idea, we tried to go for overly simple to avoid spending=20 > too much time specifying complexity that we hope would be=20 > replaced with a better solution. Then we should really avoid that someone read this spec and thinks that it describes a good one-fits-all solution. > > Section 5.6.3.1: "In general, senders MAY implement any=20 > rate control=20 > > scheme of their choice, provided that it is REQUIRED to be no more=20 > > aggressive then TFRC[RFC5348]. The following section describes a=20 > > simple, inefficient scheme that complies with this requirement." > > > > =3D> Maybe I again miss something, but as far as I can see=20 > the following=20 > > sections doesn't fully explain how TFRC is implemented here. For=20 > > example, TFRC requires information about the segment size;=20 > this is not=20 > > considered here. In general, it is not clear to me why a simple=20 > > baseline implementation does not follow the TFRC protocol=20 > (RFC 5348)=20 > > more closely (or a light-weight user-space TCP-like protocol). > > >=20 > again, simplicity won out. We believe what's there is a=20 > simpler protocol (the simplest we could think of) that=20 > follows the requirement of being less aggressive than TFRC. Just to repeat what I said: The draft doesn't explain how the requirement of being less aggressive than TFRC is indeed achieved. > > Section 5.6.3.1.1: "In each retransmission, the sequence number is=20 > > incremented." > > > > =3D> It would be worth to spend a sentence about the rational and=20 > > consequences of this. For instance, whether this implies that a=20 > > receiver may process the original message and the=20 > retransmission twice. > > >=20 > Happy to spend a sentence on this, but just to be clear, this=20 > is designed to allow the world's dumbest stop-and-wait protocol. Well, this sentence prevents even the alternating bit protocol... In fact, this solution is closer to a timestamp than a sequence number. > Specifically, the goal of 5.6.3.1.1 is to specify a=20 > ludicrously simple, totally safe algorithm that is sufficient=20 > for most envisioned deployments of P2PSIP for implementors=20 > who don't want to spend the time implementing TFRC. I would=20 > hope most do spend the time, but it seemed unnecessary to=20 > specify how TFRC works in this document. AFAIK, section 5.6.3.1.1 is *not* save as it is, and it does *not* guarantee that it is less aggressive than TFRC. The specified protocol is probably save *if and only if* the sender ensures that only very few messages are sent. Then, section 3.1.2. of RFC 5405 applies ("Low Data-Volume Applications").=20 For instance, I guess that the protocol would indeed be OK if the spec did mandate that only a single message MUST be outstanding on a link. But, unless I miss something, at the moment there is only an upper limit to 100 messages/sec. IMHO this is orders of magnitude above the low data-volume applications discussed in RFC 5405. > > Section 5.6.3.1.1: "Implementations that use a dynamic estimate to=20 > > compute the RTO MUST use the algorithm described in RFC=20 > 6298[RFC6298],=20 > > with the exception that the value of RTO SHOULD NOT be=20 > rounded up to=20 > > the nearest second but instead rounded up to the nearest=20 > millisecond." > > > > =3D> This sentence doesn't cite RFC 6298 correctly. RFC 6298 doesn't = > > mandate to round up to the nearest second. It mandates a=20 > minimum RTO=20 > > of > > 1 second. And I strongly suggest to use such a minimum RTO as well=20 > > (maybe 500ms as minimum would be OK as well). > > >=20 > I think you refer to where 6298 says: >=20 > Until a round-trip time (RTT) measurement has been made for a > segment sent between the sender and receiver, the=20 > sender SHOULD > set RTO <- 1 second, though the "backing off" on repeated > retransmission discussed in (5.5) still applies. >=20 > there's no need for that as ICE has already completed, so we=20 > have an RTT measurement. My understanding of this sentence is completely different. In my opinion, it suggests not to use this part 6298: " (2.4) Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second." In other words, Section 5.6.3.1.1 argues that the minumum RTO should be 1ms. IMHO, this value is orders of magnitude too small. Maybe this is just a phrasing issue. But, again, I think that you should use a minimum RTO of the order of 500ms independent of how you measure the RTT. Otherwise, the protocol is very vulnerable to changes of the path RTT etc. Michael From bbl@lowekamp.net Tue Sep 6 19:20:37 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF35421F8D64; Tue, 6 Sep 2011 19:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39ziEkaJirWR; Tue, 6 Sep 2011 19:20:36 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74E9B21F8D63; Tue, 6 Sep 2011 19:20:32 -0700 (PDT) Received: by ewy19 with SMTP id 19so3083057ewy.31 for ; Tue, 06 Sep 2011 19:22:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.9.96 with SMTP id 72mr2044505ees.114.1315362136353; Tue, 06 Sep 2011 19:22:16 -0700 (PDT) Received: by 10.14.127.13 with HTTP; Tue, 6 Sep 2011 19:22:16 -0700 (PDT) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C066834EF@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C066833EF@SLFSNX.rcs.alcatel-research.de> <133D9897FB9C5E4E9DF2779DC91E947C066834EF@SLFSNX.rcs.alcatel-research.de> Date: Tue, 6 Sep 2011 22:22:16 -0400 Message-ID: From: Bruce Lowekamp To: "SCHARF, Michael" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org, draft-ietf-p2psip-base@tools.ietf.org, tsv-area@ietf.org, iesg@ietf.org, tsv-dir@ietf.org Subject: Re: [P2PSIP] tsv-dir review of draft-ietf-p2psip-base-18 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 02:20:38 -0000 On Tue, Sep 6, 2011 at 1:19 PM, SCHARF, Michael wrote: > Some remarks on selected aspects inline. > >> > This draft is on the right track but has open issues, >> described in the >> > review. Given the length and complexity of the document, I only >> > comment on transport issues. However, for what it is worth, my >> > personal impression is that other sections not addressed by this >> > review seem to be somehow experimental. >> > >> > My main concern is the Forwarding and Link Management Layer. It is >> > designed to run over different transports, most notably TCP and UDP. >> > Having such a generic transport including built-in NAT traversal >> > support is very valuable. But I find parts of the specification >> > confusing, as explained below. Also, building a simple, generic >> > transport mechanism on top of UDP and TCP (or, DTLS and TLS) is >> > actually something that is hardly specific to RELOAD. >> >> Totally agree. =C2=A0One of the reasons we left room for extension >> points for new transports is in the hope that a more general >> solution will >> become mature enough to be dropped in at a later date. =C2=A0 In line wi= th >> that idea, we tried to go for overly simple to avoid spending >> too much time specifying complexity that we hope would be >> replaced with a better solution. > > Then we should really avoid that someone read this spec and thinks that > it describes a good one-fits-all solution. > I think one-size-fits-all is a dangerous claim for anything. I looked for and was surprised not to find a disclaimer at the beginning of 5.6.3 (or at least 5.6.3.1.1). And certainly we took this into account in the design---for example in 5.5.1.6, DTLS/UDP with Simple Reliability (as specified in the document) is the lowest priority option. But we can be a bit clearer in 5.6 as to the limitations of what's there and the reasons. > >> > Section 5.6.3.1: "In general, senders MAY implement any >> rate control >> > scheme of their choice, provided that it is REQUIRED to be no more >> > aggressive then TFRC[RFC5348]. The following section describes a >> > simple, inefficient scheme that complies with this requirement." >> > >> > =3D> Maybe I again miss something, but as far as I can see >> the following >> > sections doesn't fully explain how TFRC is implemented here. For >> > example, TFRC requires information about the segment size; >> this is not >> > considered here. In general, it is not clear to me why a simple >> > baseline implementation does not follow the TFRC protocol >> (RFC 5348) >> > more closely (or a light-weight user-space TCP-like protocol). >> > >> >> again, simplicity won out. =C2=A0We believe what's there is a >> simpler protocol (the simplest we could think of) that >> follows the requirement of being less aggressive than TFRC. > > Just to repeat what I said: The draft doesn't explain how the > requirement of being less aggressive than TFRC is indeed achieved. > Regarding this and following discussion, maybe it would be better to back up a level and make sure we're talking about the same things. 5.6.3.1.1, which is the only actual retransmission scheme defined in the document says: The node MUST double the time to wait after each retransmission. ... Once an ACK has been received for a message, the next message can be sent, but the peer SHOULD ensure that there is at least 10 ms between sending any two messages. so this is a stop and wait algorithm with exponential backoff on retransmissions. Furthermore, If all retransmissions for a message fail, then the sending node SHOULD close the connection routing the message. So it actually abandons a link if retransmissions don't work, rather than continuing to put traffic into it. Is there any actual question that this is a safe (albeit non-performant) algorithm? > >> > Section 5.6.3.1.1: "In each retransmission, the sequence number is >> > incremented." >> > >> > =3D> It would be worth to spend a sentence about the rational and >> > consequences of this. For instance, whether this implies that a >> > receiver may process the original message and the >> retransmission twice. >> > >> >> Happy to spend a sentence on this, but just to be clear, this >> is designed to allow the world's dumbest stop-and-wait protocol. > > Well, this sentence prevents even the alternating bit protocol... In > fact, this solution is closer to a timestamp than a sequence number. > It's a sequence number, it's just not conflating the index of data in a stream with the retransmission of fragments, as we are all used to with TCP. Being able to calculate RTTs from every ACK is a really useful feature. > >> Specifically, the goal of 5.6.3.1.1 is to specify a >> ludicrously simple, totally safe algorithm that is sufficient >> for most envisioned deployments of P2PSIP for implementors >> who don't want to spend the time implementing TFRC. =C2=A0I would >> hope most do spend the time, but it seemed unnecessary to >> specify how TFRC works in this document. > > AFAIK, section 5.6.3.1.1 is *not* save as it is, and it does *not* > guarantee that it is less aggressive than TFRC. > > The specified protocol is probably save *if and only if* the sender > ensures that only very few messages are sent. Then, section 3.1.2. of > RFC 5405 applies ("Low Data-Volume Applications"). > > For instance, I guess that the protocol would indeed be OK if the spec > did mandate that only a single message MUST be outstanding on a link. > But, unless I miss something, at the moment there is only an upper limit > to 100 messages/sec. IMHO this is orders of magnitude above the low > data-volume applications discussed in RFC 5405. > > >> > Section 5.6.3.1.1: "Implementations that use a dynamic estimate to >> > compute the RTO MUST use the algorithm described in RFC >> 6298[RFC6298], >> > with the exception that the value of RTO SHOULD NOT be >> rounded up to >> > the nearest second but instead rounded up to the nearest >> millisecond." >> > >> > =3D> This sentence doesn't cite RFC 6298 correctly. RFC 6298 doesn't >> > mandate to round up to the nearest second. It mandates a >> minimum RTO >> > of >> > 1 second. And I strongly suggest to use such a minimum RTO as well >> > (maybe 500ms as minimum would be OK as well). >> > >> >> I think you refer to where 6298 says: >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Until a round-trip time (RTT) measurem= ent has been made for a >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0segment sent between the sender and re= ceiver, the >> sender SHOULD >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set RTO <- 1 second, though the "backi= ng off" on repeated >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission discussed in (5.5) stil= l applies. >> >> there's no need for that as ICE has already completed, so we >> have an RTT measurement. > > My understanding of this sentence is completely different. In my > opinion, it suggests not to use this part 6298: > > " =C2=A0(2.4) Whenever RTO is computed, if it is less than 1 second, then= the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO SHOULD be rounded up to 1 second." > > In other words, Section 5.6.3.1.1 argues that the minumum RTO should be > 1ms. IMHO, this value is orders of magnitude too small. > > Maybe this is just a phrasing issue. But, again, I think that you should > use a minimum RTO of the order of 500ms independent of how you measure > the RTT. Otherwise, the protocol is very vulnerable to changes of the > path RTT etc. > > > Michael > > From brian.rosen@neustar.biz Wed Sep 7 05:41:43 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A7A21F8A58 for ; Wed, 7 Sep 2011 05:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkui8G2g02ao for ; Wed, 7 Sep 2011 05:41:42 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5221F8610 for ; Wed, 7 Sep 2011 05:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1315399407; x=1630660308; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=WIWL3V8RevV0+qUi7oLuVGGvh2dWV2v6bf+G1UJprG0=; b=dQoVpumY1fLHzWp+yoKXNao7BbO9R6eH59GUjXIBOZ7vLwY1i8tVx0mR2N6sEM KdfAOqceslx+JfhUPt/q4zSA== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.49263904; Wed, 07 Sep 2011 08:43:25 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 7 Sep 2011 08:43:24 -0400 From: "Rosen, Brian" To: P2PSIP WG Date: Wed, 7 Sep 2011 08:43:23 -0400 Thread-Topic: Auto-discard notification Thread-Index: AcxtW7stT1rlOV9sQFKpoMi4qrOybg== Message-ID: <8CC51984-7A2A-42DB-84D1-B3C828873BEE@neustar.biz> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: sLyfA7SWlqhknHnllzFNKA== Content-Type: multipart/alternative; boundary="_000_8CC519847A2A42DB84D1B3C828873BEEneustarbiz_" MIME-Version: 1.0 Subject: [P2PSIP] Fwd: Auto-discard notification X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 12:41:43 -0000 --_000_8CC519847A2A42DB84D1B3C828873BEEneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For some reason, the mailer discarded this message. Doesn't appear to have= hit the list any other way, so I'm forwarding it Begin forwarded message: From: "SCHARF, Michael" > Subject: RE: tsv-dir review of draft-ietf-p2psip-base-18 Date: September 7, 2011 7:59:11 AM EDT To: "Bruce Lowekamp" > Cc: >, >, >, >, > I'll just comment on one detail below, as it is indeed important Section 5.6.3.1: "In general, senders MAY implement any rate control scheme of their choice, provided that it is REQUIRED to be no more aggressive then TFRC[RFC5348]. The following section describes a simple, inefficient scheme that complies with this requirement." =3D> Maybe I again miss something, but as far as I can see the following sections doesn't fully explain how TFRC is implemented here. For example, TFRC requires information about the segment size; this is not considered here. In general, it is not clear to me why a simple baseline implementation does not follow the TFRC protocol (RFC 5348) more closely (or a light-weight user-space TCP-like protocol). again, simplicity won out. We believe what's there is a simpler protocol (the simplest we could think of) that follows the requirement of being less aggressive than TFRC. Just to repeat what I said: The draft doesn't explain how the requirement of being less aggressive than TFRC is indeed achieved. Regarding this and following discussion, maybe it would be better to back up a level and make sure we're talking about the same things. 5.6.3.1.1, which is the only actual retransmission scheme defined in the document says: The node MUST double the time to wait after each retransmission. ... Once an ACK has been received for a message, the next message can be sent, but the peer SHOULD ensure that there is at least 10 ms between sending any two messages. so this is a stop and wait algorithm with exponential backoff on retransmissions. Furthermore, If all retransmissions for a message fail, then the sending node SHOULD close the connection routing the message. So it actually abandons a link if retransmissions don't work, rather than continuing to put traffic into it. Is there any actual question that this is a safe (albeit non-performant) algorithm? I don't think that the current text in section 5.6.3.1.1 actually describes= a stop-and-wait protocol. In my reading, the sentence "Once an ACK has bee= n received for a message, the next message can be sent" does not prevent th= e sender from transmitting several messages in parallel (but well, I am not= a native speaker). To me, the text describes a windowing protocol that is = allowed to send one message per 10ms, i. e., in summary 100 messages per se= cond. If this section is about a stop-and-wait protocol, then please mention that= and use appropriate normative language. For instance, stop-and-wait would = result in something like "The next message MUST only be sent after the ACK = of the previous message has been received (or the retransmission finally ti= mes out)". One reason why this section may be confusing is the "received" field, as al= ready noted in my review. A stop-and-wait protocol doesn't need it; it only= makes sense if there is more than one message outstanding, i. e., if there= is a send window. If the intention is to specify a stop-and-wait protocol = only, then I suggest to remove the "received" field from the spec. Anyway, = other semantics for this field might make sense if a better transport mecha= nism will be defined in future, as already noted in my review. A stop-and-wait protocol with a single outstanding message (not too large, = i. e., not significantly exceeding 3-5 KB) and adaptive RTO including back-= off would be rather safe to use and sufficiently TCP friendly, according to= RFC 5405. A corresponding rephrasing of these sections might address most = of my concerns regarding congestion control. Of course, such a stop-and-wait doesn't make sense for any larger overlay, = but apparently we agree on that. Michael --_000_8CC519847A2A42DB84D1B3C828873BEEneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For some reason, the maile= r discarded this message.  Doesn't appear to have hit the list any oth= er way, so I'm forwarding it

Begin forwarded message:
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com><= /div>
Subject: RE: tsv-dir review of draft-ie= tf-p2psip-base-18
Date= : Sep= tember 7, 2011 7:59:11 AM EDT
To: "Bruce Lowekamp" <bbl@lowekamp.ne= t>
Cc: <= span style=3D"font-family:'Helvetica'; font-size:medium;"><iesg@ietf.org>, <tsv-dir@ietf.org>, <= tsv-area@ietf.org>, <p2psip@ie= tf.org>, <draft-ietf-p2psip-base@tools.ietf.org>


I'l= l just comment on one detail below, as it is indeed important

Section 5.6.3.1: "In general, senders MAY implement = any
rate control<= br>
sche= me of their choice, provided that it is REQUIRED to
be no more
<= /blockquote>
aggressive then TFRC[RFC5348]. The= following section describes a
<= /blockquote>
simple, inefficient scheme that co= mplies with this requirement."

=3D> Maybe I again mis= s something, but as far as I can see
the following
sections doesn't fully explain how TFRC is im= plemented here. For
example, TFRC requires information about the = segment size;
thi= s is not
considered here. In general, it is not clear to me why a simple
baseline implementation does not follow the TFRC protocol
(RFC 5348)
=
more closely (or a ligh= t-weight user-space TCP-like protocol).


again, simplicity won out.  We believe what's there is a simpler <= br>
protocol (the simplest we coul= d think of) that follows the
= requirement of being less aggressive than TFRC.

J= ust to repeat what I said: The draft doesn't explain how the
require= ment of being less aggressive than TFRC is indeed achieved.


Regarding this and following discussion, maybe it would be <= br>
better to back up a level and mak= e sure we're talking about
the s= ame things.
5.6.3.1.1, which is t= he only actual retransmission scheme
defined in the document says:

  The node MUST
=
  double the time to wait= after each retransmission.
&nbs= p; ...
  Once an = ACK has been received for a message, the next
message can be
&nb= sp; sent, but the peer SHOULD ensure that there is at least 10
ms between
  sending any two messages.

so this is a= stop and wait algorithm with exponential backoff
on retransmissions.  Furthermore,

 &= nbsp;If all
  retransm= issions for a message fail, then the sending node SHOULD
  close the connection routing the messa= ge.

So it actually abandons a link if retransmissions don't work,=
rather than continuing to put t= raffic into it.

=
Is there any actual question that this is a safe = (albeit
non-performant) algorithm= ?

I don't think that the current text in section 5.6.3.= 1.1 actually describes a stop-and-wait protocol. In my reading, the sentenc= e "Once an ACK has been received for a message, the next message can be sen= t" does not prevent the sender from transmitting several messages in parall= el (but well, I am not a native speaker). To me, the text describes a windo= wing protocol that is allowed to send one message per 10ms, i. e., in summa= ry 100 messages per second.

If this section is about a stop-and-wait= protocol, then please mention that and use appropriate normative language.= For instance, stop-and-wait would result in something like "The next messa= ge MUST only be sent after the ACK of the previous message has been receive= d (or the retransmission finally times out)".

One reason why this se= ction may be confusing is the "received" field, as already noted in my revi= ew. A stop-and-wait protocol doesn't need it; it only makes sense if there = is more than one message outstanding, i. e., if there is a send window. If = the intention is to specify a stop-and-wait protocol only, then I suggest t= o remove the "received" field from the spec. Anyway, other semantics for th= is field might make sense if a better transport mechanism will be defined i= n future, as already noted in my review.

A stop-and-wait protocol wi= th a single outstanding message (not too large, i. e., not significantly ex= ceeding 3-5 KB) and adaptive RTO including back-off would be rather safe to= use and sufficiently TCP friendly, according to RFC 5405. A corresponding = rephrasing of these sections might address most of my concerns regarding co= ngestion control.

Of course, such a stop-and-wait doesn't make sense= for any larger overlay, but apparently we agree on that.

Michael


= --_000_8CC519847A2A42DB84D1B3C828873BEEneustarbiz_-- From bbl@lowekamp.net Wed Sep 7 20:10:30 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42C621F8CAB; Wed, 7 Sep 2011 20:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw38tUV0zz6u; Wed, 7 Sep 2011 20:10:30 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27DEC21F8B63; Wed, 7 Sep 2011 20:10:29 -0700 (PDT) Received: by ewy19 with SMTP id 19so113688ewy.31 for ; Wed, 07 Sep 2011 20:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.8.143 with SMTP id h15mr34738ebh.149.1315451523040; Wed, 07 Sep 2011 20:12:03 -0700 (PDT) Received: by 10.213.4.194 with HTTP; Wed, 7 Sep 2011 20:12:02 -0700 (PDT) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C06683549@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C066833EF@SLFSNX.rcs.alcatel-research.de> <133D9897FB9C5E4E9DF2779DC91E947C066834EF@SLFSNX.rcs.alcatel-research.de> <133D9897FB9C5E4E9DF2779DC91E947C06683549@SLFSNX.rcs.alcatel-research.de> Date: Wed, 7 Sep 2011 23:12:02 -0400 Message-ID: From: Bruce Lowekamp To: "SCHARF, Michael" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org, draft-ietf-p2psip-base@tools.ietf.org, tsv-area@ietf.org, iesg@ietf.org, tsv-dir@ietf.org Subject: Re: [P2PSIP] tsv-dir review of draft-ietf-p2psip-base-18 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 03:10:31 -0000 On Wed, Sep 7, 2011 at 7:59 AM, SCHARF, Michael wrote: > I'll just comment on one detail below, as it is indeed important > >> >> > Section 5.6.3.1: "In general, senders MAY implement any >> >> rate control >> >> > scheme of their choice, provided that it is REQUIRED to >> be no more >> >> > aggressive then TFRC[RFC5348]. The following section describes a >> >> > simple, inefficient scheme that complies with this requirement." >> >> > >> >> > =3D> Maybe I again miss something, but as far as I can see >> >> the following >> >> > sections doesn't fully explain how TFRC is implemented here. For >> >> > example, TFRC requires information about the segment size; >> >> this is not >> >> > considered here. In general, it is not clear to me why a simple >> >> > baseline implementation does not follow the TFRC protocol >> >> (RFC 5348) >> >> > more closely (or a light-weight user-space TCP-like protocol). >> >> > >> >> >> >> again, simplicity won out. =C2=A0We believe what's there is a simpler >> >> protocol (the simplest we could think of) that follows the >> >> requirement of being less aggressive than TFRC. >> > >> > Just to repeat what I said: The draft doesn't explain how the >> > requirement of being less aggressive than TFRC is indeed achieved. >> > >> >> Regarding this and following discussion, maybe it would be >> better to back up a level and make sure we're talking about >> the same things. >> 5.6.3.1.1, which is the only actual retransmission scheme >> defined in the document says: >> >> =C2=A0 =C2=A0The node MUST >> =C2=A0 =C2=A0double the time to wait after each retransmission. >> =C2=A0 =C2=A0... >> =C2=A0 =C2=A0Once an ACK has been received for a message, the next >> message can be >> =C2=A0 =C2=A0sent, but the peer SHOULD ensure that there is at least 10 >> ms between >> =C2=A0 =C2=A0sending any two messages. >> >> so this is a stop and wait algorithm with exponential backoff >> on retransmissions. =C2=A0Furthermore, >> >> =C2=A0 =C2=A0If all >> =C2=A0 =C2=A0retransmissions for a message fail, then the sending node S= HOULD >> =C2=A0 =C2=A0close the connection routing the message. >> >> So it actually abandons a link if retransmissions don't work, >> rather than continuing to put traffic into it. >> >> Is there any actual question that this is a safe (albeit >> non-performant) algorithm? > > I don't think that the current text in section 5.6.3.1.1 actually describ= es a stop-and-wait protocol. In my reading, the sentence "Once an ACK has b= een received for a message, the next message can be sent" does not prevent = the sender from transmitting several messages in parallel (but well, I am n= ot a native speaker). To me, the text describes a windowing protocol that i= s allowed to send one message per 10ms, i. e., in summary 100 messages per = second. > > If this section is about a stop-and-wait protocol, then please mention th= at and use appropriate normative language. For instance, stop-and-wait woul= d result in something like "The next message MUST only be sent after the AC= K of the previous message has been received (or the retransmission finally = times out)". > Agree. > One reason why this section may be confusing is the "received" field, as = already noted in my review. A stop-and-wait protocol doesn't need it; it on= ly makes sense if there is more than one message outstanding, i. e., if the= re is a send window. If the intention is to specify a stop-and-wait protoco= l only, then I suggest to remove the "received" field from the spec. Anyway= , other semantics for this field might make sense if a better transport mec= hanism will be defined in future, as already noted in my review. > At one point there was an additional more TCP-like sender algorithm, which we removed at some point due to concerns over complexity and the hope that a suitable alternative would arrive via TSV. But we wanted to leave the receiver algorithm in there as-is with the potential of allowing an improved sender algorithm to interact with it if such a thing evolved. > A stop-and-wait protocol with a single outstanding message (not too large= , i. e., not significantly exceeding 3-5 KB) and adaptive RTO including bac= k-off would be rather safe to use and sufficiently TCP friendly, according = to RFC 5405. A corresponding rephrasing of these sections might address mos= t of my concerns regarding congestion control. > On that issue, would it be better to explicitly state section 3.1.1 of 5405 for other non stop-and-wait senders rather than TFRC itself? I'm not quite sure why we were pointed at TFRC---it may have actually predated 5405, but that once you go beyond stop-and-wait, 3.1.1 is the section that applies (as 3.1.3 case 2 points back to 3.1.1). Thanks, Bruce > Of course, such a stop-and-wait doesn't make sense for any larger overlay= , but apparently we agree on that. > > Michael > From brian.rosen@neustar.biz Thu Sep 8 09:41:11 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1F821F86D0 for ; Thu, 8 Sep 2011 09:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr794PA+aqGa for ; Thu, 8 Sep 2011 09:41:11 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C810D21F86A0 for ; Thu, 8 Sep 2011 09:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1315500179; x=1630854675; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=Z+HfjwvWit3dJdmQzguUNo6zuz2C4/OJKIArOnO7SEw=; b=MWDZeVAdjI+G6Roi+OeMU/i/4OpwBu+IxWuEYV+WLutTshsrtciWLHlnJJePZy JMT5ghdtEE7bTtgajpPHmqsQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.49335619; Thu, 08 Sep 2011 12:42:58 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 8 Sep 2011 12:42:58 -0400 From: "Rosen, Brian" To: P2PSIP WG Date: Thu, 8 Sep 2011 12:42:55 -0400 Thread-Topic: Auto-discard notification Thread-Index: AcxuRlz3dSlE10hDSLKNTpXhpsgxeA== Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: M1L+LcAJe3LkGfqMXwbz7Q== Content-Type: multipart/alternative; boundary="_000_DB3583A8EC87432E9AF70EA1D4B2B7A1neustarbiz_" MIME-Version: 1.0 Subject: [P2PSIP] Fwd: Auto-discard notification X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 16:41:11 -0000 --_000_DB3583A8EC87432E9AF70EA1D4B2B7A1neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "SCHARF, Michael" > Subject: RE: tsv-dir review of draft-ietf-p2psip-base-18 Date: September 8, 2011 3:36:20 AM EDT To: "Bruce Lowekamp" > Cc: >, >, >, >, > A stop-and-wait protocol with a single outstanding message (not too large, i. e., not significantly exceeding 3-5 KB) and adaptive RTO including back-off would be rather safe to use and sufficiently TCP friendly, according to RFC 5405. A corresponding rephrasing of these sections might address most of my concerns regarding congestion control. On that issue, would it be better to explicitly state section 3.1.1 of 5405 for other non stop-and-wait senders rather than TFRC itself? I'm not quite sure why we were pointed at TFRC---it may have actually predated 5405, but that once you go beyond stop-and-wait, 3.1.1 is the section that applies (as 3.1.3 case 2 points back to 3.1.1). The document should probably reference RFC 5405, as the guidelines are obviously relevant for RELOAD in general. The first sentence of Section 3.1.1 in RFC 5405 states that TFRC or something equivalent SHOULD be used once going beyond stop-and-wait. So, finally it comes down to TFRC whatever reference you use. IMHO the simplest solution for moving this forward would be just to specify stop-and-wait and to postpone considerations regarding a TCP-friendly transport mechanism with better performance to a future document. Michael --_000_DB3583A8EC87432E9AF70EA1D4B2B7A1neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>


A sto= p-and-wait protocol with a single outstanding message
(not too large, i. e., not significantly= exceeding 3-5 KB)
and adaptive = RTO including back-off would be rather safe to
use and sufficiently TCP friendly, according to RFC 5405. A =
corresponding rephrasing of thes= e sections might address most
of= my concerns regarding congestion control.


On that issue, = would it be better to explicitly state section 3.1.1 of
5405 for other non stop-and-wait senders rather than= TFRC
itself?  I'm not quit= e sure why we were pointed at TFRC---it
may have actually predated 5405, but that once you go beyond
=
stop-and-wait, 3.1.1 is the section = that applies (as 3.1.3
case 2 po= ints back to 3.1.1).

The document should probably refer= ence RFC 5405, as the guidelines are
obviously relevant for RELOAD in ge= neral.

The first sentence of Section 3.1.1 in RFC 5405 states that T= FRC or
something equivalent SHOULD be used once going beyond stop-and-wa= it. So,
finally it comes down to TFRC whatever reference you use.
IMHO the simplest solution for moving this forward would be just to
spe= cify stop-and-wait and to postpone considerations regarding a
TCP-friend= ly transport mechanism with better performance to a future
document.
=
Michael



= --_000_DB3583A8EC87432E9AF70EA1D4B2B7A1neustarbiz_-- From gonzalo.camarillo@ericsson.com Mon Sep 12 00:34:31 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586F521F8634 for ; Mon, 12 Sep 2011 00:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIrlynQIv+LR for ; Mon, 12 Sep 2011 00:34:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 53D0221F8546 for ; Mon, 12 Sep 2011 00:34:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-43-4e6db68098b5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8D.7A.02839.086BD6E4; Mon, 12 Sep 2011 09:36:32 +0200 (CEST) Received: from [131.160.36.103] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 09:36:32 +0200 Message-ID: <4E6DB67F.3030604@ericsson.com> Date: Mon, 12 Sep 2011 10:36:31 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] RELOAD implementers mailing list X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 07:34:31 -0000 Folks, we have created the RELOAD implementers mailing list: If you are implementing, have implemented, or intend to implement RELOAD, please join this list. We hope to build up a community of RELOAD implementers around this forum. You can find information on this list under the following link: http://implementers.org/mailman/listinfo/reload "This list is for discussing implementation issues for the current version of RELOAD, including questions on current protocol features and extensions. Protocol development issues are discussed on the p2psip@ietf.org list. The first posting for a new member is always moderated, so it can take up to 24 hours for this post to appear. Commercial advertisements of any form (for products, software, jobs) are inappropriate. Announcements related to RELOAD interoperability test events or FOSS software are welcome. Product names may be mentioned if necessary ("Software X, Y and Z does it that way."), while disparaging or general comments ("Software W sucks rocks.") are inappropriate. Because there is no way to correctly process them, emails containing legal boilerplate are inappropriate. Never cross-post a message to both the RELOAD list (p2psip@ietf.org) and this list." Cheers, Gonzalo From zongning@huawei.com Mon Sep 19 01:41:47 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6D221F8A55 for ; Mon, 19 Sep 2011 01:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=3.774, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj-cWjItnyLY for ; Mon, 19 Sep 2011 01:41:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9C70B21F845D for ; Mon, 19 Sep 2011 01:41:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRR00I8YHL0JN@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 19 Sep 2011 16:43:48 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRR008R3HKWN5@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 19 Sep 2011 16:43:48 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADT67824; Mon, 19 Sep 2011 16:43:47 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 19 Sep 2011 16:43:46 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.252]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 16:43:43 +0800 Date: Mon, 19 Sep 2011 08:43:42 +0000 From: ZongNing X-Originating-IP: [10.138.41.128] To: "p2psip@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-zong-p2psip-drr-01.txt Thread-index: AQHMdp6Bly2RNnFwF0mLVdZPu8iru5VUYYZw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [P2PSIP] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-zong-p2psip-drr-01=2Etxt?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:41:47 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgRGlyZWN0IFJlc3BvbnNl IFJvdXRpbmcgZHJhZnQgYXMgZm9sbG93aW5nIGxpbms6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtem9uZy1wMnBzaXAtZHJyLTAxLnR4dA0KDQpNYWluIGNoYW5nZXMgYXJlOg0KMSkg Q2hhbmdlIGZsYWcgdmFsdWUgb2YgSWdub3JlLVN0YXRlLUtlZXBpbmcgdG8gMHg4DQoyKSBDaGFu Z2UgZXh0ZW5zaXZlX3JvdXRpbmdfbW9kZSB0eXBlIHZhbHVlIHRvIDB4MiBpbiBJQU5BIHNlY3Rp b24NCjMpIFVwZGF0ZSB0aGUgZGVmaW5pdGlvbiBvZiBkZXN0aW5hdGlvbiBpbiBzdHJ1Y3R1cmUg RXh0ZW5zaXZlUm91dGluZ01vZGVPcHRpb24NCjQpIFVwZGF0ZSByZWZlcmVuY2VzDQoNClJldmll dyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJSLA0KTmluZyBab25nDQoNCi0tLS0t6YKu 5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxMeW5tDnmnIgx OeaXpSAxNTozMg0K5pS25Lu25Lq6OiBab25nTmluZw0K5oqE6YCBOiB6aGFuZ3l1bmZlaUBjaGlu YW1vYmlsZS5jb207IEpvaG5zb24gSmlhbmcoWGluZ2ZlbmcpOyBldmVuLnJvbmlAaHVhd2VpLmNv bTsgWm9uZ05pbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16 b25nLXAycHNpcC1kcnItMDEudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16b25n LXAycHNpcC1kcnItMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTmlu ZyBab25nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBk cmFmdC16b25nLXAycHNpcC1kcnINClJldmlzaW9uOgkgMDENClRpdGxlOgkJIEFuIGV4dGVuc2lv biB0byBSRUxPQUQgdG8gc3VwcG9ydCBEaXJlY3QgUmVzcG9uc2UgUm91dGluZw0KQ3JlYXRpb24g ZGF0ZToJIDIwMTEtMDktMTkNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVy IG9mIHBhZ2VzOiAxOA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYW4g b3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFJFTE9BRCB0byBzdXBwb3J0DQogICBkaXJlY3QgcmVzcG9u c2Ugcm91dGluZyBtb2RlLiAgUkVMT0FEIHJlY29tbWVuZHMgc3ltbWV0cmljIHJlY3Vyc2l2ZQ0K ICAgcm91dGluZyBmb3Igcm91dGluZyBtZXNzYWdlcy4gIFRoZSBuZXcgb3B0aW9uYWwgZXh0ZW5z aW9uIHByb3ZpZGVzIGENCiAgIHNob3J0ZXIgcm91dGUgZm9yIHJlc3BvbnNlcyByZWR1Y2luZyB0 aGUgb3ZlcmhlYWQgb24gaW50ZXJtZWRpYXJ5DQogICBwZWVycyBhbmQgZGVzY3JpYmVzIHRoZSBw b3RlbnRpYWwgY2FzZXMgd2hlcmUgdGhpcyBleHRlbnNpb24gY2FuIGJlDQogICB1c2VkLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From zongning@huawei.com Mon Sep 19 01:43:10 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C901221F8AD1 for ; Mon, 19 Sep 2011 01:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=3.397, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ-B7Eygq4j1 for ; Mon, 19 Sep 2011 01:43:10 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D6F9621F845D for ; Mon, 19 Sep 2011 01:43:09 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRR0063BHNJ9Z@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 19 Sep 2011 16:45:19 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRR00391HNII3@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 19 Sep 2011 16:45:19 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEA81044; Mon, 19 Sep 2011 16:45:00 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 19 Sep 2011 16:44:58 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.252]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 16:44:56 +0800 Date: Mon, 19 Sep 2011 08:44:56 +0000 From: ZongNing X-Originating-IP: [10.138.41.128] To: "p2psip@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-zong-p2psip-rpr-01.txt Thread-index: AQHMdqP4MKFKL0DQvEq8onwFZ3U1Y5VUY1aA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [P2PSIP] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-zong-p2psip-rpr-01=2Etxt?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:43:10 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgUmVsYXkgUGVlciBSb3V0 aW5nIGRyYWZ0IGFzIGZvbGxvd2luZyBsaW5rOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LXpvbmctcDJwc2lwLXJwci0wMS50eHQNCg0KTWFpbiBjaGFuZ2VzIGFyZToNCjEpIFVwZGF0 ZSByZWZlcmVuY2VzDQoNClJldmlldyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJSLA0K TmluZyBab25nDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemA geaXtumXtDogMjAxMeW5tDnmnIgxOeaXpSAxNjowOA0K5pS25Lu25Lq6OiBab25nTmluZw0K5oqE 6YCBOiB6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb207IEpvaG5zb24gSmlhbmcoWGluZ2Zlbmcp OyBldmVuLnJvbmlAaHVhd2VpLmNvbTsgWm9uZ05pbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC16b25nLXAycHNpcC1ycHItMDEudHh0DQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC16b25nLXAycHNpcC1ycHItMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgTmluZyBab25nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC16b25nLXAycHNpcC1ycHINClJldmlzaW9uOgkgMDEN ClRpdGxlOgkJIEFuIGV4dGVuc2lvbiB0byBSRUxPQUQgdG8gc3VwcG9ydCBSZWxheSBQZWVyIFJv dXRpbmcNCkNyZWF0aW9uIGRhdGU6CSAyMDExLTA5LTE5DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTUNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3Vt ZW50IHByb3Bvc2VzIGFuIG9wdGlvbmFsIGV4dGVuc2lvbiB0byBSRUxPQUQgdG8gc3VwcG9ydA0K ICAgcmVsYXkgcGVlciByb3V0aW5nIG1vZGUuICBSRUxPQUQgcmVjb21tZW5kcyBzeW1tZXRyaWMg cmVjdXJzaXZlDQogICByb3V0aW5nIGZvciByb3V0aW5nIG1lc3NhZ2VzLiAgVGhlIG5ldyBvcHRp b25hbCBleHRlbnNpb24gcHJvdmlkZXMgYQ0KICAgc2hvcnRlciByb3V0ZSBmb3IgcmVzcG9uc2Vz IHJlZHVjaW5nIHRoZSBvdmVyaGVhZCBvbiBpbnRlcm1lZGlhcnkNCiAgIHBlZXJzIGFuZCBkZXNj cmliZXMgdGhlIHBvdGVudGlhbCBjYXNlcyB3aGVyZSB0aGlzIGV4dGVuc2lvbiBjYW4gYmUNCiAg IHVzZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0K From petithug@acm.org Mon Sep 19 08:39:00 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055FB21F8C6A for ; Mon, 19 Sep 2011 08:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sqNv1BsTwZJ for ; Mon, 19 Sep 2011 08:38:59 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 84DEB21F8C68 for ; Mon, 19 Sep 2011 08:38:59 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 84E33204AD; Mon, 19 Sep 2011 15:35:25 +0000 (UTC) Message-ID: <4E7762A0.3020800@acm.org> Date: Mon, 19 Sep 2011 08:41:20 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: ZongNing References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-zong-p2psip-drr-01=2Etxt?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 15:39:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought these drafts were adopted as WG document in Quebec City. On 09/19/2011 01:43 AM, ZongNing wrote: > Hi, > > We have submitted a new version of Direct Response Routing draft as following link: > http://tools.ietf.org/id/draft-zong-p2psip-drr-01.txt > > Main changes are: > 1) Change flag value of Ignore-State-Keeping to 0x8 > 2) Change extensive_routing_mode type value to 0x2 in IANA section > 3) Update the definition of destination in structure ExtensiveRoutingModeOption > 4) Update references > > Review and comments are welcome. > > BR, > Ning Zong > > -----邮件原件----- > 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > 发送时间: 2011年9月19日 15:32 > 收件人: ZongNing > 抄送: zhangyunfei@chinamobile.com; Johnson Jiang(Xingfeng); even.roni@huawei.com; ZongNing > 主题: New Version Notification for draft-zong-p2psip-drr-01.txt > > A new version of I-D, draft-zong-p2psip-drr-01.txt has been successfully submitted by Ning Zong and posted to the IETF repository. > > Filename: draft-zong-p2psip-drr > Revision: 01 > Title: An extension to RELOAD to support Direct Response Routing > Creation date: 2011-09-19 > WG ID: Individual Submission > Number of pages: 18 > > Abstract: > This document proposes an optional extension to RELOAD to support > direct response routing mode. RELOAD recommends symmetric recursive > routing for routing messages. The new optional extension provides a > shorter route for responses reducing the overhead on intermediary > peers and describes the potential cases where this extension can be > used. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk53Yp8ACgkQ9RoMZyVa61cFmACfSEHVxJs1sDwMMKKk8s6z6NRj nCEAn1ybcoEAHZITmEr3uMwxBA0MZmPM =hkhi -----END PGP SIGNATURE----- From petithug@acm.org Mon Sep 19 13:55:57 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB4721F8D9D for ; Mon, 19 Sep 2011 13:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHmZbLBcbYwd for ; Mon, 19 Sep 2011 13:55:57 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id EE3CD21F8D85 for ; Mon, 19 Sep 2011 13:55:56 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 9518820375 for ; Mon, 19 Sep 2011 20:52:22 +0000 (UTC) Message-ID: <4E77ACEA.8020401@acm.org> Date: Mon, 19 Sep 2011 13:58:18 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] RELOAD fragmentation X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 20:55:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In section 5.7: "Each fragment MUST contain a full copy of the via and destination list and MUST contain at least 256 bytes of the message body. If the via and destination list are so large that this is not possible, RELOAD fragmentation is not performed and IP-layer fragmentation is allowed to occur." I think that the text should say this instead: "Each fragment MUST contain a full copy of the via list, destination list and options and MUST contain at least 256 bytes of the message body. If the via list, destination list and options are so large that this is not possible, RELOAD fragmentation is not performed and IP-layer fragmentation is allowed to occur." - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk53rOgACgkQ9RoMZyVa61cN/QCZATAXCAGPN8u5Opw4aBYQmmbX 60IAoJRyoBZQIe0XR4vvB4BNxVOY8Obo =RDGo -----END PGP SIGNATURE----- From Even.roni@huawei.com Mon Sep 19 14:28:07 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF78D21F8D3C for ; Mon, 19 Sep 2011 14:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.987 X-Spam-Level: X-Spam-Status: No, score=-105.987 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8x2=0.246, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMZsxqw6nHTO for ; Mon, 19 Sep 2011 14:28:07 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 146BE21F8CF8 for ; Mon, 19 Sep 2011 14:28:07 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRS00F99H2USV@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 20 Sep 2011 05:30:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRS00KIEH2UAR@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 20 Sep 2011 05:30:30 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LRS00C0LH2FLL@szxml12-in.huawei.com>; Tue, 20 Sep 2011 05:30:30 +0800 (CST) Date: Tue, 20 Sep 2011 00:28:54 +0300 From: Roni Even In-reply-to: <4E7762A0.3020800@acm.org> To: 'Marc Petit-Huguenin' , 'ZongNing' Message-id: <01dc01cc7713$2b4507d0$81cf1770$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acx24wA0mfxRnsQaRG6LmIbvmzJDZwAMACkg References: <4E7762A0.3020800@acm.org> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-zong-p2psip-drr-01=2Etxt?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 21:28:08 -0000 These is from the notes from Quebec sent by David to the list "Additionally, the chairs would like to solicit the list to confirm the = following consensus reached by hum at the IETF-81 meeting. 1) Hum that the RELOAD base draft (-17) is ready for publication = (hum indicated strong consensus) 2) Hum that draft-zong-p2psip-drr-00 and draft-zong-p2psip-rpr-00 = be adopted as WG items to address milestones for direct and recursive = routing (hum indicated consensus) Again, please send any comments to the list." > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Marc Petit-Huguenin > Sent: Monday, September 19, 2011 6:41 PM > To: ZongNing > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] =E8=BD=AC=E5=8F=91: New Version Notification for = draft-zong- > p2psip-drr-01.txt >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I thought these drafts were adopted as WG document in Quebec City. >=20 > On 09/19/2011 01:43 AM, ZongNing wrote: > > Hi, > > > > We have submitted a new version of Direct Response Routing draft as > following link: > > http://tools.ietf.org/id/draft-zong-p2psip-drr-01.txt > > > > Main changes are: > > 1) Change flag value of Ignore-State-Keeping to 0x8 > > 2) Change extensive_routing_mode type value to 0x2 in IANA section > > 3) Update the definition of destination in structure > ExtensiveRoutingModeOption > > 4) Update references > > > > Review and comments are welcome. > > > > BR, > > Ning Zong > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B49=E6=9C=8819=E6=97=A5 15:32 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: ZongNing > > =E6=8A=84=E9=80=81: zhangyunfei@chinamobile.com; Johnson = Jiang(Xingfeng); > even.roni@huawei.com; ZongNing > > =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zong-p2psip-drr-01.txt > > > > A new version of I-D, draft-zong-p2psip-drr-01.txt has been > successfully submitted by Ning Zong and posted to the IETF repository. > > > > Filename: draft-zong-p2psip-drr > > Revision: 01 > > Title: An extension to RELOAD to support Direct Response > Routing > > Creation date: 2011-09-19 > > WG ID: Individual Submission > > Number of pages: 18 > > > > Abstract: > > This document proposes an optional extension to RELOAD to support > > direct response routing mode. RELOAD recommends symmetric > recursive > > routing for routing messages. The new optional extension = provides > a > > shorter route for responses reducing the overhead on intermediary > > peers and describes the potential cases where this extension can > be > > used. > > >=20 > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk53Yp8ACgkQ9RoMZyVa61cFmACfSEHVxJs1sDwMMKKk8s6z6NRj > nCEAn1ybcoEAHZITmEr3uMwxBA0MZmPM > =3Dhkhi > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Mon Sep 19 14:40:25 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE85021F8C35 for ; Mon, 19 Sep 2011 14:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNSv2jTNYJNu for ; Mon, 19 Sep 2011 14:40:25 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0921F8C2A for ; Mon, 19 Sep 2011 14:40:25 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8CEB520375; Mon, 19 Sep 2011 21:36:50 +0000 (UTC) Message-ID: <4E77B756.1040006@acm.org> Date: Mon, 19 Sep 2011 14:42:46 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: Roni Even References: <4E7762A0.3020800@acm.org> <01dc01cc7713$2b4507d0$81cf1770$%roni@huawei.com> In-Reply-To: <01dc01cc7713$2b4507d0$81cf1770$%roni@huawei.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-zong-p2psip-drr-01=2Etxt?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 21:40:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/19/2011 02:28 PM, Roni Even wrote: > These is from the notes from Quebec sent by David to the list > > "Additionally, the chairs would like to solicit the list to confirm the following consensus reached by hum at the IETF-81 meeting. > > 1) Hum that the RELOAD base draft (-17) is ready for publication (hum indicated strong consensus) > > 2) Hum that draft-zong-p2psip-drr-00 and draft-zong-p2psip-rpr-00 be adopted as WG items to address milestones for direct and recursive routing (hum indicated consensus) > > Again, please send any comments to the list." I support the adoption of draft-zong-p2psip-drr and draft-zong-p2psip-rpr as WG documents. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk53t1IACgkQ9RoMZyVa61dStgCgjLKLr2fPCrKK6l5s3eB69XYf e6sAn2suyCEB74IgggusRUHtOBJSeXlx =RB36 -----END PGP SIGNATURE----- From michaelc@IDSSOFTWARE.COM Wed Sep 21 17:43:10 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8D521F8CE5 for ; Wed, 21 Sep 2011 17:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2GRLROfylgi for ; Wed, 21 Sep 2011 17:43:10 -0700 (PDT) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by ietfa.amsl.com (Postfix) with SMTP id E7B2921F8CEA for ; Wed, 21 Sep 2011 17:43:09 -0700 (PDT) Received: (qmail 25872 invoked from network); 22 Sep 2011 00:45:38 -0000 Received: from unknown (HELO gem-wbe14.prod.mesa1.secureserver.net) (64.202.189.101) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 22 Sep 2011 00:45:38 -0000 Received: (qmail 436 invoked by uid 99); 22 Sep 2011 00:45:38 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.6.01 Message-Id: <20110921174537.61e8c06078a3b23a733c71e914c0b9df.1a37e85eb1.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Wed, 21 Sep 2011 17:45:37 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Base section 10.4 clarification X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 00:43:10 -0000 Hi,=0A=0AA discussion with Marc Petit-Huguenin brings up the issue of "nake= d=0APing" described in section 10.4 of the base draft:=0A=0A If no cached= bootstrap nodes are available and the configuration file=0A has an multi= cast-bootstrap element, then the node SHOULD send a Ping=0A request over = UDP to the address and port found to each multicast-=0A bootstrap element= found in the configuration document. This MAY be a=0A multicast, broadc= ast, or anycast address. The Ping should use the=0A wildcard Node-ID as = the destination Node-ID.=0A=0AIt should be clarified that this Ping message= , wrapped the Frame Header=0Ais sent via UDP without DTLS, thus the term na= ked Ping. Further=0Aimplication is that a RELOAD application that supports = UDP must=0Amultiplex among three protocols: STUN, DTLS and framed_naked_Pin= g.=0A=0AMarc also raised the issue of anycast, and I'll let him jump in fro= m=0Ahere.=0A=0AThanks=0A=0AMichael Chen=0A From petithug@acm.org Thu Sep 22 09:29:25 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F7021F8BA9 for ; Thu, 22 Sep 2011 09:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3KI7rcdnh+8 for ; Thu, 22 Sep 2011 09:29:25 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 24A3821F8B7C for ; Thu, 22 Sep 2011 09:29:25 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 99D102025D; Thu, 22 Sep 2011 16:25:47 +0000 (UTC) Message-ID: <4E7B62FA.9000300@acm.org> Date: Thu, 22 Sep 2011 09:31:54 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: p2psip@ietf.org References: <20110921174537.61e8c06078a3b23a733c71e914c0b9df.1a37e85eb1.wbe@email00.secureserver.net> In-Reply-To: <20110921174537.61e8c06078a3b23a733c71e914c0b9df.1a37e85eb1.wbe@email00.secureserver.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Base section 10.4 clarification X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 16:29:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/21/2011 05:45 PM, Michael Chen wrote: > Hi, > > A discussion with Marc Petit-Huguenin brings up the issue of "naked > Ping" described in section 10.4 of the base draft: > > If no cached bootstrap nodes are available and the configuration file > has an multicast-bootstrap element, then the node SHOULD send a Ping > request over UDP to the address and port found to each multicast- > bootstrap element found in the configuration document. This MAY be a > multicast, broadcast, or anycast address. The Ping should use the > wildcard Node-ID as the destination Node-ID. > > It should be clarified that this Ping message, wrapped the Frame Header > is sent via UDP without DTLS, thus the term naked Ping. Further > implication is that a RELOAD application that supports UDP must > multiplex among three protocols: STUN, DTLS and framed_naked_Ping. > > Marc also raised the issue of anycast, and I'll let him jump in from > here. The problem is that it is a bad idea to establish a DTLS connection to an anycast address, as there is no guarantee that the subsequent UDP packets will reach the same host. It is even no guarantee that the ACK for the Ping answer will go to the same host, which is why I also think that Framing should not be used for sending a Ping to an anycast address. But the problem in the case of anycast is NAT traversal. We cannot use the source IP/port of the Ping answer (or Ping request ACK) as an indication of the unicast address to use for subsequent transactions, because the packet will be dropped by symmetrical NATs. The reasonable thing to do would have been to add an IpAddressPort field in the Ping answer, field that contains the IP address/port of a unicast bootstrap server (as if retrieved in the configuration file), but the authors sent a clear message that breaking compatibility is out of the equation. So what do the authors propose to fix this problem? Also I think that the spec should clearly state that a unicast bootstrap server MUST support both DTLS-UDP-SR-NO-ICE and TLS-TCP-FH-NO-ICE on its public IP address/port. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk57YvkACgkQ9RoMZyVa61dMTQCfQsyeIZjxWFekX4v8iArsZyT+ YlgAoKbWdHqoiBsZlTjzm1HaedsBjiwD =QulR -----END PGP SIGNATURE----- From petithug@acm.org Wed Sep 28 14:38:11 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A2811E80D0; Wed, 28 Sep 2011 14:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoKvABzHIEmI; Wed, 28 Sep 2011 14:38:10 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA9E11E80A1; Wed, 28 Sep 2011 14:38:10 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id C2DF2208BA; Wed, 28 Sep 2011 21:34:25 +0000 (UTC) Message-ID: <4E839468.8000500@acm.org> Date: Wed, 28 Sep 2011 14:40:56 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: DISPATCH list X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , P2PSIP Mailing List Subject: [P2PSIP] Fwd: I-D Action: draft-petithuguenin-dispatch-unique-overlay-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: DISPATCH list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:38:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just published a short I-D describing a special kind of peer-to-peer overlay, and listing some of the requirements for a mechanism to find the bootstrap servers for these overlays. The goal is to start a discussion on how to best solve this. Please follow-up in the dispatch mailing-list. Thanks. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-dispatch-unique-overlay-00.txt Date: Wed, 28 Sep 2011 14:33:59 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Infrastructure Overlay Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-dispatch-unique-overlay-00.txt Pages : 5 Date : 2011-09-28 This document provides requirements for infrastructure overlays, a special kind of peer-to-peer overlay whose main purpose would be defeated if more than one instance would exist on the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6DlGAACgkQ9RoMZyVa61dsmQCfeoHjJURinb7fQTqNcAqbSQJh kTkAn0RexWNjy9Dc2a/6XA1EauwfwhL2 =/D29 -----END PGP SIGNATURE-----