From nobody Tue Jul 1 07:45:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938921A03EC for ; Tue, 1 Jul 2014 07:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUU2lvyj_2IB for ; Tue, 1 Jul 2014 07:45:42 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4159E1B280F for ; Tue, 1 Jul 2014 07:45:41 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N8100G8JFO3YO@tid.hi.inet> for tcpm@ietf.org; Tue, 01 Jul 2014 16:45:39 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id B1.19.22923.E14E2B35; Tue, 01 Jul 2014 18:38:54 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N8100GGGFO2YL@tid.hi.inet> for tcpm@ietf.org; Tue, 01 Jul 2014 16:45:39 +0200 (MEST) Received: from EX10-MB1-BCN.hi.inet ([169.254.4.47]) by EX10-HTCAS3-BCN.hi.inet ([fe80::e55b:4382:96ce:7c50%13]) with mapi id 14.03.0158.001; Tue, 01 Jul 2014 16:45:38 +0200 Date: Tue, 01 Jul 2014 14:45:38 +0000 From: "Diego R. Lopez" In-reply-to: <53B19022.4060107@isi.edu> X-Originating-IP: [10.95.100.1] To: Joe Touch Message-id: Content-id: <18761D758EB32648B58DD0564C33700C@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [tcpm] Looking for advice on a draft from the PCE working group Thread-index: AQHPPSQOPWN7uGul1keGON95aVpVwJrb9joAgALQHnD//+MrAICiEkxwgAW9MICAA3/GgIAAbAUAgAF1pIA= X-AuditID: 0a5f4e69-f79d66d00000598b-4e-53b2e41e6cec X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsXCFe9nqCv3ZFOwwfWFJhbbTs5ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs7V3SwFx+Ir/q+bxtTA2BPbxcjJISFgIjF71wM2CFtM4sK9 9UA2F4eQwHZGifkfv7BAOD8YJS78aINyNjJKzO3oBWthEVCVeLdmIZjNBmQ/av7NDmILC/hI XJ7UBxbnFFCXuHjlEVCcA2iFvMTNu6ogYREBWYkHf96wg8xkFtjHKDH5wxVWkASvgKXEq1tL wWxmATOJq4cfQMUFJX5MvscCMocZaOaUKbkQJeISza03WSBsRYlpixoYQWxGoPnv5s9nhdjl K3F871c2CDtFYv+SC6wQHwtILNlznhnCFpV4+fgfK8SPH5kkzm56wTyBUWIWkjNmITljFsIZ s5CcMQvJGQsYWVcxihUnFWWmZ5TkJmbmpBsY6WVk6mXmpZZsYoTEXeYOxuU7VQ4xCnAwKvHw Os7ZGCzEmlhWXJl7iFGCg1lJhHfP/k3BQrwpiZVVqUX58UWlOanFhxilOViUxHmZ3xUFCAmk J5akZqemFqQWwWSZODilGhizZfM/flFgcrMLXpqi9ubNpq4Kzy39HFN4HRbemWSbxORYsVb6 z4tFd9J3XtFy6rSN9ZcN2Z63PWydW7/b0ezFexffTn13dUVV1wLLKzVXTE9V7Oa86WK87ta2 3sfnVh1tZ+f5f2T7ultnFCeHPOH1/bowfG3MSs/rVsIMtlVPmpLCM8/x3ghXYinOSDTUYi4q TgQA2njnALcCAAA= References: <531F918C.2080700@isi.edu> <5321D570.60008@isi.edu> <53AE4617.2000800@isi.edu> <2E9995E5-16AC-4E8E-BF48-D9C3566CE8FE@tid.es> <53B19022.4060107@isi.edu> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0jkn0zViFHtlsTBjuMjydrUc1N4 Cc: "adrian@olddog.co.uk" , "tcpm@ietf.org" , Qin Wu , "draft-ietf-pce-pceps@tools.ietf.org" Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 14:45:48 -0000 T24gMzAgSnVuIDIwMTQsIGF0IDE4OjI4ICwgSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PiB3cm90 ZToNCj4+DQo+PiBXZSBhcmUgbm90IHByb3Bvc2luZyB0byB1c2UgU1RBUlRUTFMgYmVjYXVzZSwg YWZ0ZXIgZGlzY3Vzc2luZyB0aGUNCj4+IGRpZmZlcmVudCBvcHRpb25zIGZvciBkb2luZyBzbyBp biBQQ0VQLCB3ZSBiZWxpZXZlIGluY2x1ZGluZyBpdCB3b3VsZA0KPj4gdHJhbnNsYXRlIGludG8g YSBjaGFuZ2Ugb2YgdGhlIFBDRVAgcHJvdG9jb2w6DQo+PiAoMSkgYWdhaW5zdCB0aGUgb3JpZ2lu YWwgY29tbWl0bWVudCBvZiBub3QgY2hhbmdpbmcgaXQNCj4+ICgyKSB3b3VsZCB0cmFuc2xhdGUg aW50byBhIG11Y2ggbG9uZ2VyIGFkb3B0aW9uIGJ5IGltcGxlbWVudGF0aW9ucw0KPg0KPiBJIGRv bid0IHVuZGVyc3RhbmQgb3IgYWdyZWUgd2l0aCBlaXRoZXIgcG9zaXRpb24uIFNUQVJUVExTIGRv ZXMgbm90IGNoYW5nZSB0aGUgcHJvdG9jb2w7IGl0IHByZWNlZGVzIGl0Lg0KPg0KPiBUaGUgY29t cGxleCBtZWNoYW5pc20gYmVsb3cgaXMsIElNTywgbXVjaCBsZXNzIGxpa2VseSB0byBiZSBzdWNj ZXNzZnVseSBhZG9wdGVkIHRoYW4gU1RBUlRUTFMsIHdoaWNoIGlzIHdpZGVseSB1c2VkLg0KDQpB cyBmYXIgYXMgSSBrbm93IChSRkMgMjU5NSwgUkZDIDMyMDcsIFJGQyA0MjE3LCBSRkMgNjEyMCwg UkZDIDI4MzAsIFJGQyA0NjQyKSBTVEFSVFRMUyBpcyBkaXJlY3RseSBhcHBsaWNhYmxlIHRvIGNv bW11bmljYXRpb24gcHJvdG9jb2xzIGJhc2VkIG9uIHBsYWluLXRleHQgY29tbWFuZC9yZXNwb25z ZSBwcm90b2NvbHMuIFBDRVAgZG9lcyBub3QgZm9sbG93IHRoaXMgbW9kZWwsIHNvIFNUQVJUVExT IHNob3VsZCBiZWNvbWUgYSBuZXcgbWVzc2FnZSBvciBhbiBvYmplY3QgaW4gdGhlIE9wZW4gbWVz c2FnZS4gQm90aCBvcHRpb25zIGltcGx5IGNoYW5nZXMgaW4gdGhlIFBDRVAgcHJvdG9jb2wgdGhh dCBsb29rIG1vcmUgY29tcGxleCB0aGFuIHRoZSBzdWdnZXN0ZWQgbWVjaGFuaXNtIChvciBhIGRl ZGljYXRlZCBwb3J0LCBpZiB5b3UgcGF5IGF0dGVudGlvbiB0byB0aGUgZGlzY3Vzc2lvbiBzaGFy ZWQgaW4gdGhlIG9yaWdpbmFsIG1lc3NhZ2UgYnkgUWluKQ0KDQpCZSBnb29kZSwNCg0KPg0KPiBK b2UNCj4NCj4+DQo+PiBCZSBnb29kZSwNCj4+DQo+PiBPbiAyOCBKdW4gMjAxNCwgYXQgMDY6MzUg LCBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+IHdyb3RlOg0KPj4NCj4+PiBIaSwNCj4+Pg0KPj4+ IE9uIDYvMjQvMjAxNCA0OjAzIEFNLCBRaW4gV3Ugd3JvdGU6DQo+Pj4+IEhpLCBKb2U6DQo+Pj4+ IFNvcnJ5IGZvciBsYXRlIHJlcGx5Lg0KPj4+Pg0KPj4+PiBBdXRob3JzIGhhdmUgYmVlbiBkaXNj dXNzaW5nIGEgbWVjaGFuaXNtIHRvIGVuYWJsZSBzZWN1cmUgUENFUCB2aWENCj4+Pj4gVExTIHdp dGhvdXQgbWFraW5nIGNoYW5nZXMgdG8gdGhlIGN1cnJlbnQgUENFUCBwcm90b2NvbCBvciBzdGF0 ZQ0KPj4+PiBtYWNoaW5lLg0KPj4+Pg0KPj4+PiBTaW5jZSBoYXZpbmcgYSBzZXBhcmF0ZSBwb3J0 IGhhcyBiZWVuIGRpc2NvdXJhZ2VkLCB3ZSBzdWdnZXN0IHRoZQ0KPj4+ID8gZm9sbG93aW5nIGFw cHJvYWNoIGJhc2VkIG9uIGRpc2NvdmVyeSBtZWNoYW5pc21zIG9yIGNvbmZpZ3VyYXRpb24gYW5k DQo+Pj4+IGluaXRpYWwgdHJhbnNwb3J0IHNlY3VyaXR5IGFzc2Vzc21lbnQgYnkgdGhlIHBlZXIu DQo+Pj4+DQo+Pj4+IDEpIEEgUENFIChnaXZlbiBhIGNvbWJpbmF0aW9uIG9mIElQIGFkZHJlc3Mg YW5kIHBvcnQpIG9ubHkgc3VwcG9ydHMNCj4+Pj4gb25lIHR5cGUgb2YgY29ubmVjdGlvbiwgZWl0 aGVyIFRMUyBvciBub3QuDQo+Pj4NCj4+PiBJJ20gbm90IHN1cmUgd2h5IHRoYXQgbmVlZHMgdG8g YmUgdGhlIGNhc2UsIGdpdmVuIFNUQVJUVExTLg0KPj4+DQo+Pj4+IE5vdGUgdGhhdCBhIGRpZmZl cmVudCBJUA0KPj4+PiBhZGRyZXNzIFNIT1VMRCBiZSB1c2VkIGZvciBzdXBwb3J0aW5nIGJvdGgg YW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhcw0KPj4+PiBkaWZmZXJlbnQgUENFcy4NCj4+Pg0KPj4+ IEkgZG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCB0aGlzLiBEaWZmZXJlbnQgSVAgYWRkcmVzc2VzIHNo b3VsZCBiZSBkaWZmZXJlbnQgUENFcyBhbnl3YXkuIElmIHlvdSB3YW50IHRvIHN1cHBvcnQgYm90 aCBlbmNyeXB0ZWQgYW5kIG5vbi1lbmNyeXB0ZWQsIHdoeSBub3QgdXNlIHRoZSBleGlzdGluZyBU TFMgbWVjaGFuaXNtIGZvciB0aGF0IC0gU1RBUlRUTFM/DQo+Pj4NCj4+Pj4gMikgVGhlIFBDQyBN QVkgZGlzY292ZXIgd2hldGhlciB0aGUgUENFIGlzIHdpbGxpbmcgdG8gY29ubmVjdCwNCj4+Pj4g cmVxdWlyZXMgVExTIG9yIG5vdCB2aWEgYW55IG9mIHRoZSBkaXNjb3ZlcnkgbWVjaGFuaXNtcy4N Cj4+Pg0KPj4+IFRoYXQgc2VlbXMgcmVhc29uYWJsZSwgYnV0IGRvZXNuJ3QgYW5zd2VyIHdoeSBh IFBDRSBuZWVkcyB0byBzdXBwb3J0IG9ubHkgb25lIHR5cGUgb2YgY29ubmVjdGlvbi4gVGhlIGRp c2NvdmVyeSBjb3VsZCBpbmRpY2F0ZSAiZWl0aGVyIiBhbmQgbGV0IHRoZSBjbGllbnQgZGVjaWRl LCBlLmcuLCBpZiBib3RoIGFyZSBzdXBwb3J0ZWQgKGFnYWluLCB2aWEgU1RBUlRUTFMpDQo+Pj4N Cj4+Pj4gMykgV2hlbiBjb25uZWN0aW5nIHRvIGEgUENFIHRoYXQgZW5mb3JjZXMgVExTLCB0aGUg UENDIE1VU1Qgc3RhcnQgYQ0KPj4+PiBUTFMgY29ubmVjdGlvbiBwcmlvciB0byBhbnkgZXhjaGFu Z2Ugb2YgUENFUCBtZXNzYWdlcy4NCj4+Pg0KPj4+IElzbid0IHRoYXQgYWxyZWFkeSB3aGF0IGhh cHBlbnMgaWYgVExTLW9ubHkgaXMgdXNlZD8NCj4+Pg0KPj4+PiBBbnkgUENFUCBtZXNzYWdlDQo+ Pj4+IHJlY2VpdmVkIG91dCBvZiBhbiBhcHByb3ByaWF0ZSBUTFMgY29udGV4dCB3aWxsIGJlIHJl amVjdGVkIGJ5IHRoZSBQQ0UNCj4+Pj4gd2l0aCBhIFBDRXJyIChFcnJvci1UeXBlPTEsIEVycm9y LXZhbHVlPTMsIFRMViBpZGVudGlmeWluZyB0aGUgbmVlZCBmb3INCj4+Pj4gVExTKSBtZXNzYWdl LiBbRXhpc3RpbmcgZXJyb3IgbWVzc2FnZSwgbmV3IFRMVl0NCj4+Pg0KPj4+IElmIG5vbi1UTFMg Y29ubmVjdGlvbnMgYXJlIHJlamVjdGVkLCB0aGVuIHRoZXJlIHNob3VsZG4ndCBiZSBhbnkgc3Vj aCBtZXNzYWdlcyBzZWVuIEFGQUlDVC4gSS5lLiwgdGhhdCB3b3VsZCBiZSBhIFRMUyBwb3J0IHRo YXQgaXMgY29uZmlndXJlZCB0byBub3Qgc3VwcG9ydCBTVEFSVFRMUy4NCj4+Pg0KPj4+PiA0KSBJ ZiBhIFBDQyBhdHRlbXB0cyB0byBzdGFydCBhIFRMUyBjb25uZWN0aW9uIHdpdGggYSBQQ0Ugd2l0 aG91dA0KPj4+PiBzdWNjZXNzLCBpdCBNQVkgYXR0ZW1wdCBhIGZ1cnRoZXIgY29ubmVjdGlvbiBh dHRlbXB0IHdpdGhvdXQgVExTIG9uIGENCj4+Pj4gZGlmZmVyZW50IElQIGFkZHJlc3MgaWYga25v d24sIHRob3VnaCB0aGF0IGNvdWxkIGltcGx5IGEgc2VjdXJpdHkNCj4+Pj4gZGVncmFkYXRpb24u DQo+Pj4NCj4+PiBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IGEgZGlmZmVyZW50IGFkZHJlc3Mgd291 bGQgYmUgY29uc2lkZXJlZCBkZWdyYWRlZCBhY2Nlc3MgdG8gdGhlIHNhbWUgUENFLiBUaGF0IHNl ZW1zIGxpa2UgYSBkaWZmZXJlbnQgUENFLCBhcyBub3RlZCBhYm92ZS4NCj4+Pg0KPj4+IElmIHlv dSB3YW50IHRvIHN1cHBvcnQgZGVncmFkZWQgKG5vbi1zZWN1cmUpIGFjY2Vzcywgd2h5IG5vdCBq dXN0IHN1cHBvcnQgU1RBUlRUTFM/DQo+Pj4NCj4+Pj4gU2V2ZXJhbCBmbG93cyBiZWNvbWUgcG9z c2libGUgdGhpcyB3YXksIGFuZCBkaXNjb3ZlcnkgY2FuIGJlIHVzZWQgdG8NCj4+PiBzaW1wbGlm eSB0aGVtIGJ1dCBpdCBpcyBub3QgZXNzZW50aWFsIGZvciB0aGVtIHRvIHdvcmsuIExldCdzIGNv bnNpZGVyIHRoZW0NCj4+Pj4NCj4+Pj4gKiBXaXRoIGRpc2NvdmVyeSAob3IgY29uZmlnKQ0KPj4+ PiAxLi0gUENDIGxlYXJuIHZpYSBkaXNjb3ZlcnkgdGhhdCB0aGUgZGVzaXJlZCBQQ0UgcmVxdWly ZSBUTFMuDQo+Pj4+IDIuLSBQQ0MgaW5pdGlhdGVzIFRDUCBjb25uZWN0aW9uIGFuZCBUTFMgaGFu ZHNoYWtlDQo+Pj4+IDMuLSBQQ0VQIGV4Y2hhbmdlIHdpdGhpbiBUTFMgY29udGV4dA0KPj4+DQo+ Pj4gTWFrZXMgc2Vuc2UuDQo+Pj4NCj4+Pj4gLS0tDQo+Pj4+IDEuLSBQQ0MgbGVhcm4gdmlhIGRp c2NvdmVyeSB0aGF0IHRoZSBkZXNpcmVkIFBDRSBkb2VzIG5vdCB1c2UgVExTLg0KPj4+PiAyLi0g UENDIGluaXRpYXRlcyBUQ1AgY29ubmVjdGlvbg0KPj4+PiAzLi0gUENFUCBleGNoYW5nZSBvdmVy IFRDUA0KPj4+DQo+Pj4gTWFrZXMgc2Vuc2UuDQo+Pj4NCj4+Pj4gKiBXaXRob3V0IGRpc2NvdmVy eSAtIFBDRSByZXF1aXJpbmcgVExTDQo+Pj4+IDEuLSBQQ0MgaW5pdGlhdGVzIFRDUCBjb25uZWN0 aW9uIGFuZCBUTFMgaGFuZHNoYWtlDQo+Pj4NCj4+PiBXb3VsZG4ndCB0aGUgVExTIGhhbmRzaGFr ZSBoZXJlIGZhaWw/IFdoeSB3b3VsZCB0aGUgcmVzdCBvZiB0aGUgZXhjaGFuZ2Ugb2NjdXI/DQo+ Pj4NCj4+Pj4gMi4tIFBDRVAgZXhjaGFuZ2Ugd2l0aGluIFRMUyBjb250ZXh0DQo+Pj4+IC0tLQ0K Pj4+PiAxLi0gUENDIGluaXRpYXRlcyBUQ1AgY29ubmVjdGlvbiBhbmQgYXR0ZW1wdHMgYSBQQ0VQ IE9QRU4gbWVzc2FnZQ0KPj4+PiAyLi0gUENFIHJlamVjdHMgdGhlIG1lc3NhZ2Ugd2l0aCBhIFBD RXJyIG1lc3NhZ2UgKEVycm9yLVR5cGU9MSwgRXJyb3ItdmFsdWU9MywgVExWIGlkZW50aWZ5aW5n IHRoZSBuZWVkIGZvciBUTFMob3B0aW9uYWxseSkpDQo+Pj4+IDMuLSBQQ0MgaW5pdGlhdGVzIFRD UCBjb25uZWN0aW9uIGFuZCBUTFMgaGFuZHNoYWtlDQo+Pj4+IDQuLSBQQ0VQIGV4Y2hhbmdlIHdp dGhpbiBUTFMgY29udGV4dA0KPj4+DQo+Pj4gKHNlZSBpc3N1ZSBhYm92ZSkNCj4+Pg0KPj4+PiAq IFdpdGhvdXQgZGlzY292ZXJ5IC0gUENFIG5vdCByZXF1aXJpbmcgVExTDQo+Pj4+IDEuLSBQQ0Mg aW5pdGlhdGVzIFRDUCBjb25uZWN0aW9uDQo+Pj4+IDIuLSBQQ0VQIGV4Y2hhbmdlIG92ZXIgVENQ DQo+Pj4+IC0tLQ0KPj4+PiAxLi0gUENDIGluaXRpYXRlcyBUQ1AgY29ubmVjdGlvbiBhbmQgVExT IGhhbmRzaGFrZQ0KPj4+DQo+Pj4gV2h5IGlzIHRoaXMgZXZlbiBhdHRlbXB0ZWQ/DQo+Pj4NCj4+ Pj4gMi4tIE5vIFRMUyBjb250ZXh0IGVzdGFibGlzaGVkIHdpdGggUENFIG9yIGVycm9yIG1lc3Nh Z2UgcmVjZWl2ZWQNCj4+Pj4gKG9wdGlvbmFsbHkpDQo+Pj4+IDMuLSBQQ0MgaW5pdGlhdGVzIFRD UCBjb25uZWN0aW9uDQo+Pj4+IDQuLSBQQ0VQIGV4Y2hhbmdlIG92ZXIgVENQDQo+Pj4+DQo+Pj4+ IFdoYXQgZG8geW91IHRoaW5rIG9mIHRoaXMgYXBwcm9hY2g/DQo+Pj4+DQo+Pj4+IEFsc28gd2Ug bGlrZSB0byBwb2ludCBhIHJlbGF0ZWQgZGlzY3Vzc2lvbiBoYXBwZW5lZCBvbiBVVEEgbWFpbGlu ZyBsaXN0Og0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdXRhL2N1 cnJlbnQvbXNnMDA0MjMuaHRtbA0KPj4+DQo+Pj4gVGhvc2UgcG9pbnRzIHdlcmUgcmFpc2VkIG9u IHRoZSBUU1ZXRyBsaXN0IHRvbywgYnV0IGZhaWwgdG8gYWRkcmVzcyB0aGUga2V5IGlzc3VlIC0g aW5zZWN1cmUgcG9ydHMgYXJlIGluc2VjdXJlLiBSZWdhcmRsZXNzIG9mIGhvdyBtYW55IHBvcnRz IHdlIGFsbG9jYXRlLCBpdCdzIG5vIGxvbmdlciBjbGVhciB3ZSBzaG91bGQgY29udGludWUgdG8g ZGVwbG95IG5ldyBpbnNlY3VyZSBzZXJ2aWNlcyBvbiB0aGUgSW50ZXJuZXQuDQo+Pj4NCj4+PiBK b2UNCj4+Pg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+PiBBdXRob3JzDQo+Pj4+IC0tLS0t6YKu 5Lu25Y6f5Lu2LS0tLS0NCj4+Pj4g5Y+R5Lu25Lq6OiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBp c2kuZWR1XQ0KPj4+PiDlj5HpgIHml7bpl7Q6IDIwMTTlubQz5pyIMTPml6UgMjM6NTgNCj4+Pj4g 5pS25Lu25Lq6OiBRaW4gV3U7IERpZWdvIFIuIExvcGV6OyB0Y3BtQGlldGYub3JnDQo+Pj4+IOaK hOmAgTogZHJhZnQtaWV0Zi1wY2UtcGNlcHNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4g5Li76aKYOiBS ZTogW3RjcG1dIExvb2tpbmcgZm9yIGFkdmljZSBvbiBhIGRyYWZ0IGZyb20gdGhlIFBDRSB3b3Jr aW5nIGdyb3VwDQo+Pj4+DQo+Pj4+IEhpLCBRaW4sDQo+Pj4+DQo+Pj4+IE9uIDMvMTMvMjAxNCAz OjM1IEFNLCBRaW4gV3Ugd3JvdGU6DQo+Pj4+PiBIaSwgSm9lOg0KPj4+Pj4NCj4+Pj4+IEl0IGlz IHN0aWxsIG5vdCBjbGVhciB0byBtZSB3aGVuIHdlIGNob29zZSB0aGUgc2FtZSBwb3J0IGFuZCB3 aGVuIHdlDQo+Pj4+PiBjaG9vc2UgdGhlIGRpZmZlcmVudCBwb3J0IGlmIHdlIGFwcGx5IFRMUyB0 byBkaWZmZXJlbnQgcHJvdG9jb2xzLA0KPj4+Pg0KPj4+PiBJdCdzIHNpbXBsZSB0byBkZXRlcm1p bmU6DQo+Pj4+DQo+Pj4+ICAgICAgLSBpZiB5b3UgZGVzaWduZWQgeW91ciBzZXJ2aWNlIGJlZm9y ZSBTVEFSVFRMUywgdGhlbiB5b3UgbmVlZGVkDQo+Pj4+ICAgICAgYSBzZXBhcmF0ZSBwb3J0DQo+ Pj4+DQo+Pj4+ICAgICAgLSBpZiB5b3UgYXJlIGRlc2lnbmluZyB5b3VyIHBvcnQgbm93LCB5b3Ug ZG9uJ3QNCj4+Pj4NCj4+Pj4+IFRha2UgU01UUCwgUE9QMyxJTUFQIGFzIGV4YW1wbGVzOg0KPj4+ PiAuLi4NCj4+Pj4+IEl0IGxvb2tzIHRvIG1lIHdoZW4gd2UgYXBwbHkgU1NMIHRvIFNNVFAsUE9Q MyxJTUFQLCB0aGVuIFNNVFAsIFBPUDMNCj4+Pj4+IGFuZCBJTUFQIHdpdGggU1NMIHN1cHBvcnQo aS5lLixTTVRQUyxQT1AzUyxJTUFQUykNCj4+Pj4+DQo+Pj4+PiBXaWxsIHVzdWFsbHkgY2hvb3Nl IHRoZSBkaWZmZXJlbnQgcG9ydHMuDQo+Pj4+Pg0KPj4+Pj4gVGhlIHNhbWUgcnVsZSBhYm92ZSBp cyBhbHNvIGFwcGxpZWQgdG8gSFRUUCB3aGVuIHdlIGFwcGx5IFNTTCB0bw0KPj4+Pj4gSFRUUChp LmUuLCBIVFRQUykuDQo+Pj4+DQo+Pj4+IEFsbCBvZiB0aGUgYWJvdmUgYXJlIGdvb2QgZXhhbXBs ZXMgb2YgdGhlIGZpcnN0IHBhcnQgb2YgdGhlIHJ1bGUuDQo+Pj4+DQo+Pj4+IE5vdGUgdGhhdCB3 ZSBoYXZlIG90aGVyIGFzc2lnbm1lbnRzIHRoYXQgbm93IHdvdWxkIGJlIGRlY2xpbmVkLCBiZWNh dXNlIHdlJ3ZlIGxlYXJuZWQgdG8gZG8gYmV0dGVyLiBFLmcuLCB0aGVyZSB3b3VsZCBub3QgYmUg YSBQT1AyIG9yIFBPUDMgYmVjYXVzZSB3ZSB3b3VsZCBleHBlY3QgUE9QIHRvIGluZGljYXRlIHRo ZSBwcm90b2NvbCB2ZXJzaW9uIGluLWJhbmQuIFdlIGFsc28gbm8gbG9uZ2VyIGFzc2lnbiBtdWx0 aXBsZSBuYW1lcyBmb3IgdGhlIHNhbWUgc2VydmljZSwgYXMgd2FzIGRvbmUgZm9yIGh0dHAvd3d3 LCBub3IgZG8gd2Ugbm93IGFzc2lnbiBtdWx0aXBsZSBwb3J0cyBmb3IgdGhlIHNhbWUgc2Vydmlj ZSAoODAsIDgwODApLCBub3IgZG8gd2Ugbm93IGFzc2lnbiBwb3J0cyBmb3IgZGV2ZWxvcG1lbnQg cHVycG9zZXMgIChodHRwLWRldikuDQo+Pj4+DQo+Pj4+IFdlJ3ZlIGxlYXJuZWQgdG8gZG8gYmV0 dGVyLg0KPj4+Pg0KPj4+PiBKb2UNCj4+Pj4NCj4+DQo+Pg0KPj4gLS0NCj4+ICJFc3RhIHZleiBu byBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQo+Pg0KPj4gRHIgRGllZ28gUi4gTG9wZXoN Cj4+IFRlbGVmb25pY2EgSStEDQo+PiBodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8N Cj4+DQo+PiBlLW1haWw6IGRpZWdvQHRpZC5lcw0KPj4gVGVsOiAgICArMzQgOTEzIDEyOSAwNDEN Cj4+IE1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4NCj4+IEVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBk ZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8g eSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8g bcOhcyBhYmFqby4NCj4+IFRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3Ig aXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNp cyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCj4+IGh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lO QVMvZGlzY2xhaW1lci5hc3B4DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4+IHRjcG1AaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPj4NCg0KDQotLQ0K IkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4g TG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8N Cg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6 ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUg c2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0 YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxl Y3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2Ug aXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBh bmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpo dHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From nobody Tue Jul 1 11:40:14 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762A11A0118 for ; Tue, 1 Jul 2014 11:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebEiFiIFoVNj for ; Tue, 1 Jul 2014 11:40:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF49D1A03C9 for ; Tue, 1 Jul 2014 11:40:08 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s61IdW94015647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Jul 2014 11:39:32 -0700 (PDT) Message-ID: <53B30064.6070306@isi.edu> Date: Tue, 01 Jul 2014 11:39:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Diego R. Lopez" References: <531F918C.2080700@isi.edu> <5321D570.60008@isi.edu> <53AE4617.2000800@isi.edu> <2E9995E5-16AC-4E8E-BF48-D9C3566CE8FE@tid.es> <53B19022.4060107@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uqX2E4IgnJ5ceUgI5ieuZrV8Y3c Cc: "adrian@olddog.co.uk" , "tcpm@ietf.org" , Qin Wu , "draft-ietf-pce-pceps@tools.ietf.org" Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:40:11 -0000 On 7/1/2014 7:45 AM, Diego R. Lopez wrote: > On 30 Jun 2014, at 18:28 , Joe Touch wrote: >>> >>> We are not proposing to use STARTTLS because, after discussing the >>> different options for doing so in PCEP, we believe including it would >>> translate into a change of the PCEP protocol: >>> (1) against the original commitment of not changing it >>> (2) would translate into a much longer adoption by implementations >> >> I don't understand or agree with either position. STARTTLS does not change the protocol; it precedes it. >> >> The complex mechanism below is, IMO, much less likely to be successfuly adopted than STARTTLS, which is widely used. > > As far as I know (RFC 2595, RFC 3207, RFC 4217, RFC 6120, RFC 2830, > RFC 4642) RFC4217 doesn't appear to use STARTTLS. RFC6120 just refers completely back to RFC2595. Section 2.1 of RFC2830 is a good example of performing STARTTLS in a non-plaintext command/response protocol (LDAP), and how simple it can and should be. I now see your concern, but RFC2830 provides a great example of a very simple way to extend a protocol to address this issue. This further ensures that the security state (secure vs. not) is integrated within the protocol, so the protocol itself can disable commands if needed when security isn't available. FWIW, Section 7 of RFC2595 gives a good summary of reasons why using a separate security port should be discouraged. Joe > STARTTLS is directly applicable to communication protocols > based on plain-text command/response protocols. PCEP does not follow > this model, so STARTTLS should become a new message or an object in the > Open message. Both options imply changes in the PCEP protocol that look > more complex than the suggested mechanism (or a dedicated port, if you > pay attention to the discussion shared in the original message by Qin) > > Be goode, > >> >> Joe >> >>> >>> Be goode, >>> >>> On 28 Jun 2014, at 06:35 , Joe Touch wrote: >>> >>>> Hi, >>>> >>>> On 6/24/2014 4:03 AM, Qin Wu wrote: >>>>> Hi, Joe: >>>>> Sorry for late reply. >>>>> >>>>> Authors have been discussing a mechanism to enable secure PCEP via >>>>> TLS without making changes to the current PCEP protocol or state >>>>> machine. >>>>> >>>>> Since having a separate port has been discouraged, we suggest the >>>> ? following approach based on discovery mechanisms or configuration and >>>>> initial transport security assessment by the peer. >>>>> >>>>> 1) A PCE (given a combination of IP address and port) only supports >>>>> one type of connection, either TLS or not. >>>> >>>> I'm not sure why that needs to be the case, given STARTTLS. >>>> >>>>> Note that a different IP >>>>> address SHOULD be used for supporting both and will be considered as >>>>> different PCEs. >>>> >>>> I don't quite understand this. Different IP addresses should be different PCEs anyway. If you want to support both encrypted and non-encrypted, why not use the existing TLS mechanism for that - STARTTLS? >>>> >>>>> 2) The PCC MAY discover whether the PCE is willing to connect, >>>>> requires TLS or not via any of the discovery mechanisms. >>>> >>>> That seems reasonable, but doesn't answer why a PCE needs to support only one type of connection. The discovery could indicate "either" and let the client decide, e.g., if both are supported (again, via STARTTLS) >>>> >>>>> 3) When connecting to a PCE that enforces TLS, the PCC MUST start a >>>>> TLS connection prior to any exchange of PCEP messages. >>>> >>>> Isn't that already what happens if TLS-only is used? >>>> >>>>> Any PCEP message >>>>> received out of an appropriate TLS context will be rejected by the PCE >>>>> with a PCErr (Error-Type=1, Error-value=3, TLV identifying the need for >>>>> TLS) message. [Existing error message, new TLV] >>>> >>>> If non-TLS connections are rejected, then there shouldn't be any such messages seen AFAICT. I.e., that would be a TLS port that is configured to not support STARTTLS. >>>> >>>>> 4) If a PCC attempts to start a TLS connection with a PCE without >>>>> success, it MAY attempt a further connection attempt without TLS on a >>>>> different IP address if known, though that could imply a security >>>>> degradation. >>>> >>>> I don't understand why a different address would be considered degraded access to the same PCE. That seems like a different PCE, as noted above. >>>> >>>> If you want to support degraded (non-secure) access, why not just support STARTTLS? >>>> >>>>> Several flows become possible this way, and discovery can be used to >>>> simplify them but it is not essential for them to work. Let's consider them >>>>> >>>>> * With discovery (or config) >>>>> 1.- PCC learn via discovery that the desired PCE require TLS. >>>>> 2.- PCC initiates TCP connection and TLS handshake >>>>> 3.- PCEP exchange within TLS context >>>> >>>> Makes sense. >>>> >>>>> --- >>>>> 1.- PCC learn via discovery that the desired PCE does not use TLS. >>>>> 2.- PCC initiates TCP connection >>>>> 3.- PCEP exchange over TCP >>>> >>>> Makes sense. >>>> >>>>> * Without discovery - PCE requiring TLS >>>>> 1.- PCC initiates TCP connection and TLS handshake >>>> >>>> Wouldn't the TLS handshake here fail? Why would the rest of the exchange occur? >>>> >>>>> 2.- PCEP exchange within TLS context >>>>> --- >>>>> 1.- PCC initiates TCP connection and attempts a PCEP OPEN message >>>>> 2.- PCE rejects the message with a PCErr message (Error-Type=1, Error-value=3, TLV identifying the need for TLS(optionally)) >>>>> 3.- PCC initiates TCP connection and TLS handshake >>>>> 4.- PCEP exchange within TLS context >>>> >>>> (see issue above) >>>> >>>>> * Without discovery - PCE not requiring TLS >>>>> 1.- PCC initiates TCP connection >>>>> 2.- PCEP exchange over TCP >>>>> --- >>>>> 1.- PCC initiates TCP connection and TLS handshake >>>> >>>> Why is this even attempted? >>>> >>>>> 2.- No TLS context established with PCE or error message received >>>>> (optionally) >>>>> 3.- PCC initiates TCP connection >>>>> 4.- PCEP exchange over TCP >>>>> >>>>> What do you think of this approach? >>>>> >>>>> Also we like to point a related discussion happened on UTA mailing list: >>>>> http://www.ietf.org/mail-archive/web/uta/current/msg00423.html >>>> >>>> Those points were raised on the TSVWG list too, but fail to address the key issue - insecure ports are insecure. Regardless of how many ports we allocate, it's no longer clear we should continue to deploy new insecure services on the Internet. >>>> >>>> Joe >>>> >>>>> >>>>> Regards, >>>>> Authors >>>>> -----邮件原件----- >>>>> 发件人: Joe Touch [mailto:touch@isi.edu] >>>>> 发送时间: 2014年3月13日 23:58 >>>>> 收件人: Qin Wu; Diego R. Lopez; tcpm@ietf.org >>>>> 抄送: draft-ietf-pce-pceps@tools.ietf.org >>>>> 主题: Re: [tcpm] Looking for advice on a draft from the PCE working group >>>>> >>>>> Hi, Qin, >>>>> >>>>> On 3/13/2014 3:35 AM, Qin Wu wrote: >>>>>> Hi, Joe: >>>>>> >>>>>> It is still not clear to me when we choose the same port and when we >>>>>> choose the different port if we apply TLS to different protocols, >>>>> >>>>> It's simple to determine: >>>>> >>>>> - if you designed your service before STARTTLS, then you needed >>>>> a separate port >>>>> >>>>> - if you are designing your port now, you don't >>>>> >>>>>> Take SMTP, POP3,IMAP as examples: >>>>> ... >>>>>> It looks to me when we apply SSL to SMTP,POP3,IMAP, then SMTP, POP3 >>>>>> and IMAP with SSL support(i.e.,SMTPS,POP3S,IMAPS) >>>>>> >>>>>> Will usually choose the different ports. >>>>>> >>>>>> The same rule above is also applied to HTTP when we apply SSL to >>>>>> HTTP(i.e., HTTPS). >>>>> >>>>> All of the above are good examples of the first part of the rule. >>>>> >>>>> Note that we have other assignments that now would be declined, because we've learned to do better. E.g., there would not be a POP2 or POP3 because we would expect POP to indicate the protocol version in-band. We also no longer assign multiple names for the same service, as was done for http/www, nor do we now assign multiple ports for the same service (80, 8080), nor do we now assign ports for development purposes (http-dev). >>>>> >>>>> We've learned to do better. >>>>> >>>>> Joe >>>>> >>> >>> >>> -- >>> "Esta vez no fallaremos, Doctor Infierno" >>> >>> Dr Diego R. Lopez >>> Telefonica I+D >>> http://people.tid.es/diego.lopez/ >>> >>> e-mail: diego@tid.es >>> Tel: +34 913 129 041 >>> Mobile: +34 682 051 091 >>> ----------------------------------------- >>> >>> >>> ________________________________ >>> >>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. >>> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > From nobody Tue Jul 1 13:59:21 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610F51A041F; Tue, 1 Jul 2014 13:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA8spwhkKYGy; Tue, 1 Jul 2014 13:59:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D64A61A0A84; Tue, 1 Jul 2014 13:59:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701205912.26153.32395.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 13:59:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5CSjs4WCROnMWUyel8hZLZn1Unc Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 20:59:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Fast Open Authors : Yuchung Cheng Jerry Chu Sivasankar Radhakrishnan Arvind Jain Filename : draft-ietf-tcpm-fastopen-09.txt Pages : 26 Date : 2014-07-01 Abstract: This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 2 08:16:49 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1A61B28F5 for ; Wed, 2 Jul 2014 08:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgdo1se2hSIc for ; Wed, 2 Jul 2014 08:16:29 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFBA1B2905 for ; Wed, 2 Jul 2014 08:16:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,588,1400050800"; d="asc'?scan'208";a="173621729" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 02 Jul 2014 08:16:28 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 2 Jul 2014 08:16:28 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 2 Jul 2014 08:16:27 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::91be:43ec:d314:b11d%21]) with mapi id 15.00.0847.030; Wed, 2 Jul 2014 08:16:27 -0700 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: New Version Notification for draft-zimmermann-tcpm-undeployed-00.txt Thread-Index: AQHPlgfyW9+s2I8moU6Iozjd6nLMaw== Date: Wed, 2 Jul 2014 15:16:26 +0000 Message-ID: <290BE231-B31A-40E3-8796-B77D2E4A992F@netapp.com> References: <20140702151132.7133.72265.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_9AC85750-3716-42DE-87AB-4ECB667518C3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RCA6JRd4nUjR8tVNVJ_wezhmAb8 Subject: [tcpm] Fwd: New Version Notification for draft-zimmermann-tcpm-undeployed-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 15:16:31 -0000 --Apple-Mail=_9AC85750-3716-42DE-87AB-4ECB667518C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Anfang der weitergeleiteten Nachricht: > Von: > Betreff: New Version Notification for = draft-zimmermann-tcpm-undeployed-00.txt > Datum: 2. Juli 2014 17:11:32 MESZ > An: Lars Eggert , Lars Eggert , = "Wesley M.Eddy" , Wesley Eddy = , "Alexander Zimmermann" = , Alexander Zimmermann = >=20 >=20 > A new version of I-D, draft-zimmermann-tcpm-undeployed-00.txt > has been successfully submitted by Alexander Zimmermann and posted to = the > IETF repository. >=20 > Name: draft-zimmermann-tcpm-undeployed > Revision: 00 > Title: Moving Undeployed TCP Extensions to Historic and = Informational Status -- An addition to RFC 6247 > Document date: 2014-07-02 > Group: Individual Submission > Pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-zimmermann-tcpm-undeployed-00.tx= t > Status: = https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-undeployed/ > Htmlized: = http://tools.ietf.org/html/draft-zimmermann-tcpm-undeployed-00 >=20 >=20 > Abstract: > This document reclassifies several TCP extensions that have either > been superceded or never seen widespread use to Historic status. = The > affected RFCs are RFC 675, RFC 761, RFC 721, RFC 813, RFC 816, RFC > 879, RFC 896, RFC 6013. Additionally, it reclassifies RFC 814, RFC > 817, RFC 872, RFC 964, RFC 1078 to Informational status. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_9AC85750-3716-42DE-87AB-4ECB667518C3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlO0IkoACgkQdyiq39b9uS5mVQCfYkWvmO8iMNc2UHyytHpug4LJ +6oAnikz32kqiDfnslWz4frqLhrjtV7C =2+0u -----END PGP SIGNATURE----- --Apple-Mail=_9AC85750-3716-42DE-87AB-4ECB667518C3-- From nobody Wed Jul 2 17:02:02 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590EA1A0646 for ; Wed, 2 Jul 2014 17:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D17qjwEh6HV0 for ; Wed, 2 Jul 2014 17:01:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10141A04A3 for ; Wed, 2 Jul 2014 17:01:59 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s6301RGC028836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 17:01:27 -0700 (PDT) Message-ID: <53B49D57.70102@isi.edu> Date: Wed, 02 Jul 2014 17:01:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> In-Reply-To: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UGwJKf09fQPwCRVhRbWZmsQMkZI Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 00:02:01 -0000 Hi, all, This is an updated version of the Extended Data Offset option. The changes are, broadly: - more clear about the immediate potential need for non-SYN DO extension - more clear about the issue with SYN extension points off to a currently pending doc with the SYN approach Briscoe and I discussed on the list - includes a discussion of the issues with specific prior approaches - reorganized to get to the actual extension earlier The core proposal hasn't changed. I'd like to suggest this version be the topic of discussion for inclusion as a WG doc, intended for (preferably) PS or at least Experimental. The SYN DO extension is intended to be considered separately, and would be focused at Experimental (whether in the WG or individual). I won't be in Toronto, but will provide a slideset summarizing the changes as well. Joe -------- Original Message -------- Subject: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt Date: Wed, 02 Jul 2014 16:10:48 -0700 From: internet-drafts@ietf.org To: Wesley M. Eddy , Dr. Joseph D. Touch , Joe Touch , Wesley Eddy A new version of I-D, draft-touch-tcpm-tcp-edo-03.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcpm-tcp-edo Revision: 03 Title: TCP Extended Data Offset Option Document date: 2014-07-02 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-03.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-03 Abstract: TCP segments include a Data Offset field to indicate space for TCP options, but the size of the field can limit the space available for complex options that have evolved. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options such as SACK with either TCP Multipath or TCP AO. It also explains why the initial SYN of a connection cannot be extending as a single segment. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 3 01:32:36 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4389F1A0B07; Thu, 3 Jul 2014 01:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk9B7RZ821UG; Thu, 3 Jul 2014 01:32:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 018E11A0077; Thu, 3 Jul 2014 01:32:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703083231.16104.22151.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 01:32:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5KcrXrIXUWSfp6K4Y2mNIh5OqJw Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 08:32:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : A Roadmap for Transmission Control Protocol (TCP) Specification Documents Authors : Martin Duke Robert Braden Wesley M. Eddy Ethan Blanton Alexander Zimmermann Filename : draft-ietf-tcpm-tcp-rfc4614bis-06.txt Pages : 52 Date : 2014-07-03 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-rfc4614bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 03:14:02 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D417A1A0AAF; Thu, 3 Jul 2014 03:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-d03KDoCnPR; Thu, 3 Jul 2014 03:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AE11A8BAF; Thu, 3 Jul 2014 03:13:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703101357.13795.32368.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 03:13:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5CK0WeYNx41sWGhb5ReFNR7HJkU Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 10:13:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : A Roadmap for Transmission Control Protocol (TCP) Specification Documents Authors : Martin Duke Robert Braden Wesley M. Eddy Ethan Blanton Alexander Zimmermann Filename : draft-ietf-tcpm-tcp-rfc4614bis-07.txt Pages : 52 Date : 2014-07-03 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-rfc4614bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 06:10:53 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA011B2955 for ; Thu, 3 Jul 2014 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLf7lKzaWXyX for ; Thu, 3 Jul 2014 06:10:48 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCBF1A007C for ; Thu, 3 Jul 2014 06:10:47 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 14:10:44 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 14:10:45 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Thu, 3 Jul 2014 14:10:37 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.13.232]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s63DAYvO019201; Thu, 3 Jul 2014 14:10:34 +0100 Message-ID: <201407031310.s63DAYvO019201@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 3 Jul 2014 14:10:34 +0100 To: From: Bob Briscoe In-Reply-To: <531AF534.6050209@erg.abdn.ac.uk> References: <531AF534.6050209@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/8hJY0BJYymn8F9xYyabB8ZTzs84 Cc: draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org, tcpm@ietf.org Subject: Re: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:10:50 -0000 Gorry, I wanted to respond to your dislike of our argument against the nonce and a couple of other points... (sorry I didn't notice your email back in March). We don't need to have this argument in the accecn-reqs doc, so we've taken it out. But we do need to have the argument on the list. inline... At 11:47 08/03/2014, Gorry Fairhurst wrote: >Section 2: > >Disagree with text: "However, as the ECN Nonce is a separate >extension to ECN, even if a sender tries to protect itself with the >ECN Nonce, any receiver wishing to conceal marked packets only has >to pretend not to support the ECN Nonce and simply does not provide >any nonce sum feedback." >- To me this argument is ridiculous (and I have said so), and I >think we should not perpetuate this argument! >[[Here is why: if a sender were to require a NS, then a receiver >would need to provide that or expect the sender would not continue >use of ECN, or at least limit is trust of ECN. So the wording could >be improved, but RFC3540 says: "If the receiver has never sent a >non-zero nonce sum, the sender can infer that the receiver does not >understand the nonce, and rate limit the connection, place it in a >lower-priority queue, or cease setting ECT in outgoing segments."]] >- Saying the nonce sum has a second problem in that it only works if >it is deployed and actually used seems obvious. I believe our argument is correct. 1) First, let's allow an assumption that the nonce is only for protection against ECN cheating (it isn't)... One person saying they don't support the nonce is not a suspicious sign of potential malice when a majority of users don't support it either, or even a minority. Here's a scenario: I'll be generous and assume that nonce support has been deployed unilaterally by one (or two) large mobile device vendors. Then imagine that you are running a Web server. Millions of clients ask you for ECN TCP connections. You support ECN because you have determined that it improves performance. You also want to get the client to use the nonce if supported, so you set the flags accordingly. The client responds with ECN support, but nonce sum =0. By your argument you (the server) decline to use ECN further or you negate the performance benefits. Certainly you want to decline ECN for the one or two malicious users who use the device from the above vendor(s) but have hacked it to say it doesn't support the nonce. However, you also cannot help but decline to use ECN (or negate any performance benefits) for the millions of users who don't use those devices that support it. Are you really likely to have gone to all the hassle of deploying ECN then you decline to use it or you limit performance for 99.999% of users because the other 0.001% might be malicious? No. The whole point of the nonce is to identify precisely which users are cheating. If you still have to use judgement and heuristics anyway, the nonce is not a solution. 2) Now, let's assume you are having trouble with clients mounting one of the attacks described in RFC3540 that supresses loss feedback (not ECN). Any client that wants to mount these attacks just doesn't ask for ECN support. What are you going to do as a server. Reset every connection that doesn't ask for ECN? Again, you would have to punish large numbers of your customers in case a few might be cheating. It's not helpful to say this argument is ridiculous. If I'm missing something, please describe a believable scenario where the nonce would be useful. >It speaks of [...] Conex (specified for a specific domain). I need to correct this misconception: ConEx is an e2e mechanism added to IP using transport feedback of loss or ECN where available. ConEx policing would certainly be applied in individual network domains, but the ConEx signal is e2e and defined in updates to e2e transport specs (starting with TCP). >Section 4: > >Usage of RFC 2119: Personally, I really do not like use of RFC2119 >keywords in this way: "This leads to the following requirements, >which MUST be discussed for any proposed more accurate ECN feedback >scheme:" - Mandating discussion is not helpful. > >(point 2 above): If we have requirements as the title suggests, then >I personally would encourage you to list them as requirements using >RFC 2119 language - but I don't mind seeing no RFC 2119 keywords if >the WG wants this, as long as I can see the relative importance of >each topic. At the moment I can't see this. I recall that relative priority of requirements was already discussed in tcpm, and the general opinion (I think) was that this would be hard to do in abstract terms without a particular mechanism in mind that makes particular trade-offs. I strongly support that view - otherwise we will be having circular arguments for ever. I also think mandating discussion is helpful. accecn-reqs is a checklist of things that need to be aired in any candidate spec. What's wrong with that? Bob ________________________________________________________________ Bob Briscoe, BT From nobody Thu Jul 3 07:55:38 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BD71A01AD for ; Thu, 3 Jul 2014 07:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jasVDd99C9ES for ; Thu, 3 Jul 2014 07:55:29 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCB91A0194 for ; Thu, 3 Jul 2014 07:55:28 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 15:55:26 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 15:55:25 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Thu, 3 Jul 2014 15:55:23 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.13.232]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s63EtLAb019563; Thu, 3 Jul 2014 15:55:22 +0100 Message-ID: <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 3 Jul 2014 15:55:21 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <53B49D57.70102@isi.edu> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yr-hfW6BUnB7RYFgiL7OFHXJm-Y Cc: "tcpm@ietf.org" Subject: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:55:36 -0000 Joe, Thanks for updating this. EDO is a useful separation of the problem space into easy and hard, which I fully support. Comments from a rapid scan: Section 5.4 The roster of possible TCP options probably ought to include TFO. I notice TFO was also overlooked during the timstamp options thread in late May / early Jun. Section 7.7 " Legacy endpoints are required to drop TCP segments where those bits are not zero, making it difficult to assume backward downgrade. " Please don't say this. The spec [793] doesn't say anything about drop, so please quote the spec precisely, and don't attempt to interpret it. This is your interpretation of an ambiguous sentence written a long time ago, when the recognised understanding of terms could have been different. It is dangerous to translate it using context that has become common more recently. It would be unfortunate if it were considered as law by other developers. Nits S4. s/byte rder/byte order/ Bob At 01:01 03/07/2014, Joe Touch wrote: >Hi, all, > >This is an updated version of the Extended Data Offset option. > >The changes are, broadly: > > - more clear about the immediate potential need for > non-SYN DO extension > > - more clear about the issue with SYN extension > points off to a currently pending doc with the > SYN approach Briscoe and I discussed on the list > > - includes a discussion of the issues with > specific prior approaches > > - reorganized to get to the actual extension > earlier > >The core proposal hasn't changed. > >I'd like to suggest this version be the topic of discussion for >inclusion as a WG doc, intended for (preferably) PS or at least Experimental. > >The SYN DO extension is intended to be considered separately, and >would be focused at Experimental (whether in the WG or individual). > >I won't be in Toronto, but will provide a slideset summarizing the >changes as well. > >Joe > > >-------- Original Message -------- >Subject: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt >Date: Wed, 02 Jul 2014 16:10:48 -0700 >From: internet-drafts@ietf.org >To: Wesley M. Eddy , Dr. Joseph D. Touch >, Joe Touch , Wesley Eddy > > > >A new version of I-D, draft-touch-tcpm-tcp-edo-03.txt >has been successfully submitted by Joe Touch and posted to the >IETF repository. > >Name: draft-touch-tcpm-tcp-edo >Revision: 03 >Title: TCP Extended Data Offset Option >Document date: 2014-07-02 >Group: Individual Submission >Pages: 16 >URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-03.txt >Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ >Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-03 >Diff: http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-03 > >Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options, but the size of the field can limit the space available for > complex options that have evolved. This document updates RFC 793 > with an optional TCP extension to that space to support the use of > multiple large options such as SACK with either TCP Multipath or TCP > AO. It also explains why the initial SYN of a connection cannot be > extending as a single segment. > > > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm ________________________________________________________________ Bob Briscoe, BT From nobody Thu Jul 3 08:59:44 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41991B2801 for ; Thu, 3 Jul 2014 08:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF06wsrDQ6Vu for ; Thu, 3 Jul 2014 08:59:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69F71B2908 for ; Thu, 3 Jul 2014 08:59:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s63Fw0Qq013035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 08:58:00 -0700 (PDT) Message-ID: <53B57D88.9090706@isi.edu> Date: Thu, 03 Jul 2014 08:58:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> In-Reply-To: <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EBeBzUC19r7vV3PNjEiBu7VaEXw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 15:59:40 -0000 Hi, Bob, On 7/3/2014 7:55 AM, Bob Briscoe wrote: > Joe, > > Thanks for updating this. EDO is a useful separation of the problem > space into easy and hard, which I fully support. > > Comments from a rapid scan: > > Section 5.4 > The roster of possible TCP options probably ought to include TFO. > I notice TFO was also overlooked during the timstamp options thread in > late May / early Jun. Sure. > Section 7.7 > " Legacy endpoints are required > to drop TCP segments where those bits are not zero, making it > difficult to assume backward downgrade. > " > Please don't say this. The spec [793] doesn't say anything about drop, > so please quote the spec precisely, and don't attempt to interpret it. > > This is your interpretation of an ambiguous sentence written a long time > ago, when the recognised understanding of terms could have been > different. It is dangerous to translate it using context that has become > common more recently. It would be unfortunate if it were considered as > law by other developers. I'll wait to see what the WG thinks about this too. 793 says these bits "Must be zero." - it could easily have said "must be ignored", but it doesn't, so I continue to disagree it's ambiguous, but it's certainly useful to raise this as a consensus issue. > Nits > S4. s/byte rder/byte order/ Thanks. I don't think it's worth issuing a quick update based only on these points; I'd like to get more WG feedback, but will certainly include this in the summary for the WG update. Joe > > > Bob > > At 01:01 03/07/2014, Joe Touch wrote: >> Hi, all, >> >> This is an updated version of the Extended Data Offset option. >> >> The changes are, broadly: >> >> - more clear about the immediate potential need for >> non-SYN DO extension >> >> - more clear about the issue with SYN extension >> points off to a currently pending doc with the >> SYN approach Briscoe and I discussed on the list >> >> - includes a discussion of the issues with >> specific prior approaches >> >> - reorganized to get to the actual extension >> earlier >> >> The core proposal hasn't changed. >> >> I'd like to suggest this version be the topic of discussion for >> inclusion as a WG doc, intended for (preferably) PS or at least >> Experimental. >> >> The SYN DO extension is intended to be considered separately, and >> would be focused at Experimental (whether in the WG or individual). >> >> I won't be in Toronto, but will provide a slideset summarizing the >> changes as well. >> >> Joe >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt >> Date: Wed, 02 Jul 2014 16:10:48 -0700 >> From: internet-drafts@ietf.org >> To: Wesley M. Eddy , Dr. Joseph D. Touch >> , Joe Touch , Wesley Eddy >> >> >> >> A new version of I-D, draft-touch-tcpm-tcp-edo-03.txt >> has been successfully submitted by Joe Touch and posted to the >> IETF repository. >> >> Name: draft-touch-tcpm-tcp-edo >> Revision: 03 >> Title: TCP Extended Data Offset Option >> Document date: 2014-07-02 >> Group: Individual Submission >> Pages: 16 >> URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-03.txt >> Status: >> https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ >> Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-03 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-03 >> >> Abstract: >> TCP segments include a Data Offset field to indicate space for TCP >> options, but the size of the field can limit the space available for >> complex options that have evolved. This document updates RFC 793 >> with an optional TCP extension to that space to support the use of >> multiple large options such as SACK with either TCP Multipath or TCP >> AO. It also explains why the initial SYN of a connection cannot be >> extending as a single segment. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > ________________________________________________________________ > Bob Briscoe, BT From nobody Thu Jul 3 09:32:55 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A2B1B2808; Thu, 3 Jul 2014 09:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id surw_ywPomjs; Thu, 3 Jul 2014 09:32:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3408B1B2AAF; Thu, 3 Jul 2014 09:32:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703163251.29107.29681.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 09:32:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZIO9DWQvC9kLDzUS3nEroFWHnCE Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:32:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Problem Statement and Requirements for a More Accurate ECN Feedback Authors : Mirja Kuehlewind Richard Scheffenegger Bob Briscoe Filename : draft-ietf-tcpm-accecn-reqs-06.txt Pages : 16 Date : 2014-07-03 Abstract: Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like ConEx or DCTCP) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accecn-reqs-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 10:39:04 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36C61A0021 for ; Thu, 3 Jul 2014 10:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDV2tpodcLAm for ; Thu, 3 Jul 2014 10:38:59 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDA21A016F for ; Thu, 3 Jul 2014 10:38:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,596,1400050800"; d="asc'?scan'208";a="132305857" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 03 Jul 2014 10:38:59 -0700 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 3 Jul 2014 10:38:59 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 3 Jul 2014 10:38:57 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::91be:43ec:d314:b11d%21]) with mapi id 15.00.0847.030; Thu, 3 Jul 2014 10:38:52 -0700 From: "Zimmermann, Alexander" To: Joe Touch Thread-Topic: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt Thread-Index: AQHPls7eerXiyvjB6E+k1XdCOvLUwZuO9tsAgAAcAIA= Date: Thu, 3 Jul 2014 17:38:51 +0000 Message-ID: <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> In-Reply-To: <53B57D88.9090706@isi.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_1433E06F-38EE-4F16-BC58-C058FA75C6A2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_xNwBbEOSSf7VujFuACxolLKTFM Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 17:39:01 -0000 --Apple-Mail=_1433E06F-38EE-4F16-BC58-C058FA75C6A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Joe, Am 03.07.2014 um 17:58 schrieb Joe Touch : > Hi, Bob, >=20 > On 7/3/2014 7:55 AM, Bob Briscoe wrote: >> Joe, >>=20 >> Thanks for updating this. EDO is a useful separation of the problem >> space into easy and hard, which I fully support. >>=20 >> Comments from a rapid scan: >>=20 >> Section 5.4 >> The roster of possible TCP options probably ought to include TFO. >> I notice TFO was also overlooked during the timstamp options thread = in >> late May / early Jun. >=20 > Sure. >=20 >> Section 7.7 >> " Legacy endpoints are required >> to drop TCP segments where those bits are not zero, making it >> difficult to assume backward downgrade. >> " >> Please don't say this. The spec [793] doesn't say anything about = drop, >> so please quote the spec precisely, and don't attempt to interpret = it. >>=20 >> This is your interpretation of an ambiguous sentence written a long = time >> ago, when the recognised understanding of terms could have been >> different. It is dangerous to translate it using context that has = become >> common more recently. It would be unfortunate if it were considered = as >> law by other developers. >=20 > I=92ll wait to see what the WG thinks about this too. 793 says these = bits "Must be zero." - it could easily have said "must be ignored", but = it doesn't, so I continue to disagree it's ambiguous, but it's certainly = useful to raise this as a consensus issue. Despite our interoperation of RFC 793, IMO, it also make sense to check the src code of current OSes to see how they interoperate this. Alex >=20 >> Nits >> S4. s/byte rder/byte order/ >=20 > Thanks. >=20 > I don't think it's worth issuing a quick update based only on these = points; I'd like to get more WG feedback, but will certainly include = this in the summary for the WG update. >=20 > Joe >=20 >>=20 >>=20 >> Bob >>=20 >> At 01:01 03/07/2014, Joe Touch wrote: >>> Hi, all, >>>=20 >>> This is an updated version of the Extended Data Offset option. >>>=20 >>> The changes are, broadly: >>>=20 >>> - more clear about the immediate potential need for >>> non-SYN DO extension >>>=20 >>> - more clear about the issue with SYN extension >>> points off to a currently pending doc with the >>> SYN approach Briscoe and I discussed on the list >>>=20 >>> - includes a discussion of the issues with >>> specific prior approaches >>>=20 >>> - reorganized to get to the actual extension >>> earlier >>>=20 >>> The core proposal hasn't changed. >>>=20 >>> I'd like to suggest this version be the topic of discussion for >>> inclusion as a WG doc, intended for (preferably) PS or at least >>> Experimental. >>>=20 >>> The SYN DO extension is intended to be considered separately, and >>> would be focused at Experimental (whether in the WG or individual). >>>=20 >>> I won't be in Toronto, but will provide a slideset summarizing the >>> changes as well. >>>=20 >>> Joe >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for = draft-touch-tcpm-tcp-edo-03.txt >>> Date: Wed, 02 Jul 2014 16:10:48 -0700 >>> From: internet-drafts@ietf.org >>> To: Wesley M. Eddy , Dr. Joseph D. Touch >>> , Joe Touch , Wesley Eddy >>> >>>=20 >>>=20 >>> A new version of I-D, draft-touch-tcpm-tcp-edo-03.txt >>> has been successfully submitted by Joe Touch and posted to the >>> IETF repository. >>>=20 >>> Name: draft-touch-tcpm-tcp-edo >>> Revision: 03 >>> Title: TCP Extended Data Offset Option >>> Document date: 2014-07-02 >>> Group: Individual Submission >>> Pages: 16 >>> URL: = http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-03.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ >>> Htmlized: = http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-03 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tcpm-tcp-edo-03 >>>=20 >>> Abstract: >>> TCP segments include a Data Offset field to indicate space for TCP >>> options, but the size of the field can limit the space available = for >>> complex options that have evolved. This document updates RFC 793 >>> with an optional TCP extension to that space to support the use of >>> multiple large options such as SACK with either TCP Multipath or = TCP >>> AO. It also explains why the initial SYN of a connection cannot be >>> extending as a single segment. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> ________________________________________________________________ >> Bob Briscoe, BT >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_1433E06F-38EE-4F16-BC58-C058FA75C6A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlO1lQUACgkQdyiq39b9uS7N6gCcChon22TwOeHcLGLsUp+g7KBw f4AAoPaLuqtGY1bAKy2zNJxW+nE6tVIX =V2Xb -----END PGP SIGNATURE----- --Apple-Mail=_1433E06F-38EE-4F16-BC58-C058FA75C6A2-- From nobody Thu Jul 3 11:43:34 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEBC1A0359 for ; Thu, 3 Jul 2014 11:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyY5pm7VPrSD for ; Thu, 3 Jul 2014 11:43:30 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8FE1A034E for ; Thu, 3 Jul 2014 11:43:29 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 3 Jul 2014 19:43:27 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 19:43:27 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Thu, 3 Jul 2014 19:43:27 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.13.232]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s63IhNU2020277; Thu, 3 Jul 2014 19:43:23 +0100 Message-ID: <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 3 Jul 2014 19:43:21 +0100 To: "Zimmermann, Alexander" , Joe Touch From: Bob Briscoe In-Reply-To: <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6bw30Qwyia3H7QHFceQlfXsbJ60 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 18:43:33 -0000 Joe, Alex, At 18:38 03/07/2014, Zimmermann, Alexander wrote: >Hi Joe, > >Am 03.07.2014 um 17:58 schrieb Joe Touch : > > > Hi, Bob, > > > > On 7/3/2014 7:55 AM, Bob Briscoe wrote: > >> Joe, > >> Section 7.7 > >> " Legacy endpoints are required > >> to drop TCP segments where those bits are not zero, making it > >> difficult to assume backward downgrade. > >> " > >> Please don't say this. The spec [793] doesn't say anything about drop, > >> so please quote the spec precisely, and don't attempt to interpret it. > >> > >> This is your interpretation of an ambiguous sentence written a long time > >> ago, when the recognised understanding of terms could have been > >> different. It is dangerous to translate it using context that has become > >> common more recently. It would be unfortunate if it were considered as > >> law by other developers. > > > > I'll wait to see what the WG thinks about this too. 793 says > these bits "Must be zero." - it could easily have said "must be > ignored", but it doesn't, so I continue to disagree it's ambiguous, > but it's certainly useful to raise this as a consensus issue. > >Despite our interoperation of RFC 793, IMO, it also make sense to >check the src code of current OSes to see how they interoperate >this. That's not my concern. I just don't want the IETF to publish text that confirms an interpretation of this sentence in RFC793 that prevents any future use of these flags. All I'm asking Joe to do is repeat what the spec says verbatim, rather than interpreting it in any particular way. I'm not even asking him to interpret it in a different way. You (Joe) are interpreting the verb to 'be' as if it is from the the viewpoint of an external observer anywhere on the path. The authors probably simply meant 'be' from the sender's perspective when creating the header, and didn't even consider any other perspective. If a spec says bits must be zero, that does not allow anyone to unequivocally infer the action for a receiver or a forwarder to take if they are not zero. It could have meant any of: - drop the packet - clear them to zero - ignore and forward unchanged - ignore and mask them to zero when doing calculations over the header but don't change them You and I can certainly argue in hindsight that some of these alternatives are more practical than others. But if this question had been raised at the time, the authors and Jon Postel might have simply changed the text, realising that they didn't actually intend to mean any bits "must be zero" for all time anyway. Can you really imagine that Jon or the co-authors of RFC793 would have mandated that certain bits must always be zero and the packet should be dropped if they are not? Bob >Alex > > > > >> Nits > >> S4. s/byte rder/byte order/ > > > > Thanks. > > > > I don't think it's worth issuing a quick update based only on > these points; I'd like to get more WG feedback, but will certainly > include this in the summary for the WG update. > > > > Joe > > > >> > >> > >> Bob > >> > >> At 01:01 03/07/2014, Joe Touch wrote: > >>> Hi, all, > >>> > >>> This is an updated version of the Extended Data Offset option. > >>> > >>> The changes are, broadly: > >>> > >>> - more clear about the immediate potential need for > >>> non-SYN DO extension > >>> > >>> - more clear about the issue with SYN extension > >>> points off to a currently pending doc with the > >>> SYN approach Briscoe and I discussed on the list > >>> > >>> - includes a discussion of the issues with > >>> specific prior approaches > >>> > >>> - reorganized to get to the actual extension > >>> earlier > >>> > >>> The core proposal hasn't changed. > >>> > >>> I'd like to suggest this version be the topic of discussion for > >>> inclusion as a WG doc, intended for (preferably) PS or at least > >>> Experimental. > >>> > >>> The SYN DO extension is intended to be considered separately, and > >>> would be focused at Experimental (whether in the WG or individual). > >>> > >>> I won't be in Toronto, but will provide a slideset summarizing the > >>> changes as well. > >>> > >>> Joe > >>> > >>> > >>> -------- Original Message -------- > >>> Subject: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt > >>> Date: Wed, 02 Jul 2014 16:10:48 -0700 > >>> From: internet-drafts@ietf.org > >>> To: Wesley M. Eddy , Dr. Joseph D. Touch > >>> , Joe Touch , Wesley Eddy > >>> > >>> > >>> > >>> A new version of I-D, draft-touch-tcpm-tcp-edo-03.txt > >>> has been successfully submitted by Joe Touch and posted to the > >>> IETF repository. > >>> > >>> Name: draft-touch-tcpm-tcp-edo > >>> Revision: 03 > >>> Title: TCP Extended Data Offset Option > >>> Document date: 2014-07-02 > >>> Group: Individual Submission > >>> Pages: 16 > >>> URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-03.txt > >>> Status: > >>> https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ > >>> Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-03 > >>> Diff: > >>> http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-03 > >>> > >>> Abstract: > >>> TCP segments include a Data Offset field to indicate space for TCP > >>> options, but the size of the field can limit the space available for > >>> complex options that have evolved. This document updates RFC 793 > >>> with an optional TCP extension to that space to support the use of > >>> multiple large options such as SACK with either TCP Multipath or TCP > >>> AO. It also explains why the initial SYN of a connection cannot be > >>> extending as a single segment. > >>> > >>> > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission > >>> until the htmlized version and diff are available at tools.ietf.org. > >>> > >>> The IETF Secretariat > >>> > >>> > >>> _______________________________________________ > >>> tcpm mailing list > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >> > >> ________________________________________________________________ > >> Bob Briscoe, BT > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > ________________________________________________________________ Bob Briscoe, BT From nobody Thu Jul 3 12:32:31 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDFE1B2B79 for ; Thu, 3 Jul 2014 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdcWZdYdWObN for ; Thu, 3 Jul 2014 12:32:29 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB511B2B75 for ; Thu, 3 Jul 2014 12:32:29 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6748CC94BF; Thu, 3 Jul 2014 15:32:26 -0400 (EDT) Date: Thu, 3 Jul 2014 15:32:26 -0400 From: John Leslie To: Joe Touch , "tcpm@ietf.org" Message-ID: <20140703193226.GK85889@verdi> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7tE5IVLwM-3h8jVBnRyuY5EfmPg Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:32:31 -0000 Bob Briscoe wrote: > > All I'm asking Joe to do is repeat what the spec says verbatim, > rather than interpreting it in any particular way. I'm not even > asking him to interpret it in a different way. I'd like to support Bob here. It's best to say "RFC793 says..." and leave it at that. > You (Joe) are interpreting the verb to 'be' as if it is from the the > viewpoint of an external observer anywhere on the path. The authors > probably simply meant 'be' from the sender's perspective when > creating the header, and didn't even consider any other perspective. As I read 793, this specifies how the bits should be set by the sending TCP stack. I find no intent that the receiving TCP stack should be able to depend on them being zero. This doesn't mean, of course, that 793 authorizes middleboxes to do anything to these bits; but IMHO it states an expectation that some meaning might be attached to these in the future: thus a receiving TCP stack may at some future date attach a meaning to them (to be defined in an update to 793) without necessarily having negotiated that meaning with the sending stack. (If, in fact, there is some _other_ document which says packets must be dropped if these bits are not zero, please cite it. If you mean that common implementations drop such packets, the wording needs to be quite different...) -- John Leslie From nobody Thu Jul 3 13:14:08 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A609C1B2B48 for ; Thu, 3 Jul 2014 13:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1ZiTw0T-awQ for ; Thu, 3 Jul 2014 13:14:05 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8526B1B2A68 for ; Thu, 3 Jul 2014 13:14:05 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s63KDZHO028561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 13:13:35 -0700 (PDT) Message-ID: <53B5B96F.1020304@isi.edu> Date: Thu, 03 Jul 2014 13:13:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe , "Zimmermann, Alexander" References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> In-Reply-To: <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/b9jkJH31pRwQepidq5-zgDSuZbI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:14:06 -0000 Hi, all, Regarding the reserved bits, I hope the following pending revision will resolve this thread: --- The Reserved TCP header bits cannot be redefined easily, even though three of the six total bits have already been redefined (ECE/CWR [RFC3168] and NS [RFC3540]). Legacy endpoints have been known to reflect received values in these fields; this was safely dealt with for ECN but would be difficult here [RFC3168]. --- I will note that, in a general sense, the ambiguity in RFC 793 has two parts: - what should an endpoint that receives non-zero Reserved bits do? IMO an endpoint that drops them would be compliant as written, though I agree the current text also allows them to be ignored on receipt. This needs to be fixed in RFC793-bis, and I'll send a separate note on that shortly. - even if legacy recipients of non-zero Reserved bits ignore them, there's still the issue of what emitters do RFC3168 notes that one implementation (at the time) reflected those bits when creating a segment in response to an arrival. It notes that ECN's use of those bits is tolerant of that behavior, but using those bits to signal EDO wouldn't be as forgiving (thus the text above). I'm currently reviewing FreeBSD and Linux code, but so far I do not see that these bits are actively zeroed on transmission. That's clearly non-compliant, and needs to be addressed as well. I.e., a reflected segment (as RFC3168 notes) or even non-zero bits in newly-obtained buffers could cause a problem in that case. Joe From nobody Thu Jul 3 13:22:20 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCD51B2B65 for ; Thu, 3 Jul 2014 13:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOzndEnnVUeN for ; Thu, 3 Jul 2014 13:22:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9261B2A5F for ; Thu, 3 Jul 2014 13:22:16 -0700 (PDT) Received: from vim.isi.edu (vim.isi.edu [128.9.168.184]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s63KLfp4000289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 13:21:41 -0700 (PDT) Message-ID: <53B5BB4B.5080606@isi.edu> Date: Thu, 03 Jul 2014 13:21:31 -0700 From: Ted Faber User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <20140703193226.GK85889@verdi> In-Reply-To: <20140703193226.GK85889@verdi> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="akiAJoPKPwUDNahs3tn2srpoKGbheNUv2" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eCRTMRl4P3sCumlFNDirxn1lIAI Cc: faber@isi.edu Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:22:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --akiAJoPKPwUDNahs3tn2srpoKGbheNUv2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/03/14 12:32, John Leslie wrote: > Bob Briscoe wrote: >> >> All I'm asking Joe to do is repeat what the spec says verbatim,=20 >> rather than interpreting it in any particular way. I'm not even=20 >> asking him to interpret it in a different way. >=20 > I'd like to support Bob here. >=20 > It's best to say "RFC793 says..." and leave it at that. >=20 >> You (Joe) are interpreting the verb to 'be' as if it is from the the=20 >> viewpoint of an external observer anywhere on the path. The authors=20 >> probably simply meant 'be' from the sender's perspective when=20 >> creating the header, and didn't even consider any other perspective. >=20 > As I read 793, this specifies how the bits should be set by the > sending TCP stack. I find no intent that the receiving TCP stack should= > be able to depend on them being zero. >=20 > This doesn't mean, of course, that 793 authorizes middleboxes to > do anything to these bits; but IMHO it states an expectation that some > meaning might be attached to these in the future: thus a receiving > TCP stack may at some future date attach a meaning to them (to be > defined in an update to 793) without necessarily having negotiated > that meaning with the sending stack. This is also my interpretation. Well put. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --akiAJoPKPwUDNahs3tn2srpoKGbheNUv2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO1u0sACgkQaUz3f+Zf+XtCWgCg7hhcCuPC8rFsldASiZxjXJiV CSYAoN9u7IaGFBKDVH2Lvo+RFupKZgfd =yrJn -----END PGP SIGNATURE----- --akiAJoPKPwUDNahs3tn2srpoKGbheNUv2-- From nobody Thu Jul 3 13:25:17 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F3C1B282C for ; Thu, 3 Jul 2014 13:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCunfIlJ8TLN for ; Thu, 3 Jul 2014 13:25:14 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B1A1A049F for ; Thu, 3 Jul 2014 13:25:13 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s63KOjuP000617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 13:24:45 -0700 (PDT) Message-ID: <53B5BC0D.7050906@isi.edu> Date: Thu, 03 Jul 2014 13:24:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9eLawK-5gOT-eSLgPNbhHLXdRHo Subject: [tcpm] 793bis item - reserved bit behavior X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:25:15 -0000 Hi, all, As per the discussion of EDO, I'd like to suggest that 793bis should be more clear in the description of Reserved bits as follows: MUST be set as zero on outgoing segments. This is superseded only when the bit is otherwise defined in the future through an update to this document. MUST be ignored on receipt on incoming segments, except as already integrated in checksums and security mechanisms (e.g., TCP-AO). This is superseded only when the bit is otherwise defined in the future through an update to this document. Joe From nobody Thu Jul 3 13:27:06 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF991B2B48 for ; Thu, 3 Jul 2014 13:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Atx3KfmbfNwl for ; Thu, 3 Jul 2014 13:26:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33261B2B65 for ; Thu, 3 Jul 2014 13:26:53 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s63KQYIH001137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 13:26:34 -0700 (PDT) Message-ID: <53B5BC7A.6060105@isi.edu> Date: Thu, 03 Jul 2014 13:26:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Faber , tcpm@ietf.org References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <20140703193226.GK85889@verdi> <53B5BB4B.5080606@isi.edu> In-Reply-To: <53B5BB4B.5080606@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ju_nAncbdfR84jFjMsLRtbytYuw Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:26:58 -0000 On 7/3/2014 1:21 PM, Ted Faber wrote: > On 07/03/14 12:32, John Leslie wrote: >> Bob Briscoe wrote: >>> >>> All I'm asking Joe to do is repeat what the spec says verbatim, >>> rather than interpreting it in any particular way. I'm not even >>> asking him to interpret it in a different way. >> >> I'd like to support Bob here. >> >> It's best to say "RFC793 says..." and leave it at that. >> >>> You (Joe) are interpreting the verb to 'be' as if it is from the the >>> viewpoint of an external observer anywhere on the path. The authors >>> probably simply meant 'be' from the sender's perspective when >>> creating the header, and didn't even consider any other perspective. >> >> As I read 793, this specifies how the bits should be set by the >> sending TCP stack. I find no intent that the receiving TCP stack should >> be able to depend on them being zero. >> >> This doesn't mean, of course, that 793 authorizes middleboxes to >> do anything to these bits; but IMHO it states an expectation that some >> meaning might be attached to these in the future: thus a receiving >> TCP stack may at some future date attach a meaning to them (to be >> defined in an update to 793) without necessarily having negotiated >> that meaning with the sending stack. > > This is also my interpretation. Well put. FWIW, middleboxes shouldn't be altering these bits; although Reserved, they're already included in the TCP checksum as well any TCP or 'lower' protocol security (TCP-AO or IPsec, e.g.). Changing those bits en-route will currently cause the packet to be dropped as a result. Joe From nobody Thu Jul 3 13:30:55 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31121B289A for ; Thu, 3 Jul 2014 13:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwnUazGTW6rh for ; Thu, 3 Jul 2014 13:30:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885A01B2895 for ; Thu, 3 Jul 2014 13:30:52 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s63KUBIY001698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 13:30:11 -0700 (PDT) Message-ID: <53B5BD53.4090300@isi.edu> Date: Thu, 03 Jul 2014 13:30:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> In-Reply-To: <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/OKbr31YpwYxfayd4B9xvg_uvQW8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:30:53 -0000 Going back to the other suggestions: On 7/3/2014 7:55 AM, Bob Briscoe wrote: > Joe, > > Thanks for updating this. EDO is a useful separation of the problem > space into easy and hard, which I fully support. > > Comments from a rapid scan: > > Section 5.4 > The roster of possible TCP options probably ought to include TFO. > I notice TFO was also overlooked during the timstamp options thread in > late May / early Jun. The current roster is defined as those that are currently in widespread use. I don't think that applies to TFO, so I'm not as convinced it's worth addressing this in specific. > Section 7.7 > " Legacy endpoints are required > to drop TCP segments where those bits are not zero, making it > difficult to assume backward downgrade. > " > Please don't say this. Fixed as of the next version, as noted in my other post. > Nits > S4. s/byte rder/byte order/ Fixed. Joe From nobody Thu Jul 3 13:32:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7748F1B2A5A for ; Thu, 3 Jul 2014 13:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OhBM53sGgEH for ; Thu, 3 Jul 2014 13:32:19 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0461B2A26 for ; Thu, 3 Jul 2014 13:32:19 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s63KVXjo002034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 13:31:33 -0700 (PDT) Message-ID: <53B5BDA5.9050009@isi.edu> Date: Thu, 03 Jul 2014 13:31:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <53B5BC0D.7050906@isi.edu> In-Reply-To: <53B5BC0D.7050906@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/saHApcNJt2-O6AJMBG6ccSaG1jE Subject: Re: [tcpm] 793bis item - reserved bit behavior X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:32:20 -0000 On 7/3/2014 1:24 PM, Joe Touch wrote: > Hi, all, > > As per the discussion of EDO, I'd like to suggest that 793bis should be > more clear in the description of Reserved bits as follows: > > MUST be set as zero on outgoing segments. This is superseded only when > the bit is otherwise defined in the future through an update to this > document. > > MUST be ignored on receipt on incoming segments, except as already > integrated in checksums and security mechanisms (e.g., TCP-AO). This is > superseded only when the bit is otherwise defined in the future through > an update to this document. Also: MUST NOT be modified except at the packet source, because it is already included in the TCP checksum and TCP-AO. Joe From nobody Thu Jul 3 13:48:18 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434211B28B2 for ; Thu, 3 Jul 2014 13:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpNErWKblNdx for ; Thu, 3 Jul 2014 13:48:14 -0700 (PDT) Received: from atl4mhob01.myregisteredsite.com (atl4mhob01.myregisteredsite.com [209.17.115.39]) by ietfa.amsl.com (Postfix) with ESMTP id C58B11B282C for ; Thu, 3 Jul 2014 13:48:14 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s63KmCJR000883 for ; Thu, 3 Jul 2014 16:48:13 -0400 Received: (qmail 31408 invoked by uid 0); 3 Jul 2014 20:48:12 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 3 Jul 2014 20:48:12 -0000 Message-ID: <53B5C173.6030005@mti-systems.com> Date: Thu, 03 Jul 2014 16:47:47 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch References: <53B5BC0D.7050906@isi.edu> In-Reply-To: <53B5BC0D.7050906@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/T1thm3aHe7seGLlFGUQHga46kWw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis item - reserved bit behavior X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:48:16 -0000 On 7/3/2014 4:24 PM, Joe Touch wrote: > Hi, all, > > As per the discussion of EDO, I'd like to suggest that 793bis should be > more clear in the description of Reserved bits as follows: > > MUST be set as zero on outgoing segments. This is superseded only when > the bit is otherwise defined in the future through an update to this > document. > > MUST be ignored on receipt on incoming segments, except as already > integrated in checksums and security mechanisms (e.g., TCP-AO). This is > superseded only when the bit is otherwise defined in the future through > an update to this document. > I fully agree. I don't recall if any of the BEHAVE documents, or others, capture it, but there may also need to be a sentence begging middleboxes not to filter on these bits or pervert them in-transit. -- Wes Eddy MTI Systems From nobody Thu Jul 3 14:09:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0671A033E for ; Thu, 3 Jul 2014 14:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hILHRwy79d-m for ; Thu, 3 Jul 2014 14:09:19 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CFC1A03D1 for ; Thu, 3 Jul 2014 14:09:18 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s63L8d5U012383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 14:08:39 -0700 (PDT) Message-ID: <53B5C656.3090203@isi.edu> Date: Thu, 03 Jul 2014 14:08:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Wesley Eddy References: <53B5BC0D.7050906@isi.edu> <53B5C173.6030005@mti-systems.com> In-Reply-To: <53B5C173.6030005@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/QQBnjTRlKw0SY3a9vr8BNTyW80M Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis item - reserved bit behavior X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 21:09:20 -0000 On 7/3/2014 1:47 PM, Wesley Eddy wrote: > On 7/3/2014 4:24 PM, Joe Touch wrote: >> Hi, all, >> >> As per the discussion of EDO, I'd like to suggest that 793bis should be >> more clear in the description of Reserved bits as follows: >> >> MUST be set as zero on outgoing segments. This is superseded only when >> the bit is otherwise defined in the future through an update to this >> document. >> >> MUST be ignored on receipt on incoming segments, except as already >> integrated in checksums and security mechanisms (e.g., TCP-AO). This is >> superseded only when the bit is otherwise defined in the future through >> an update to this document. >> > > > I fully agree. > > I don't recall if any of the BEHAVE documents, or others, capture it, > but there may also need to be a sentence begging middleboxes not to > filter on these bits or pervert them in-transit. Yup - I sent that in a followup. Joe From nobody Thu Jul 3 15:32:20 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B5C1A063F for ; Thu, 3 Jul 2014 15:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9cDPb1NdOjr for ; Thu, 3 Jul 2014 15:32:16 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CE41A05CB for ; Thu, 3 Jul 2014 15:32:15 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 23:32:12 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 23:32:13 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Thu, 3 Jul 2014 23:32:11 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.73.6]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s63MW8M2020910; Thu, 3 Jul 2014 23:32:09 +0100 Message-ID: <201407032232.s63MW8M2020910@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 3 Jul 2014 23:25:21 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <53B5B96F.1020304@isi.edu> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nnrJXM2Dw4lXVz4Qhu3fzTpLkR8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:32:19 -0000 Joe, At 21:13 03/07/2014, Joe Touch wrote: >Hi, all, > >Regarding the reserved bits, I hope the following pending revision >will resolve this thread: > >--- >The Reserved TCP header bits cannot be redefined easily, even though >three of the six total bits have already been redefined (ECE/CWR >[RFC3168] and NS [RFC3540]). Legacy endpoints have been known to >reflect received values in these fields; this was safely dealt with >for ECN but would be difficult here [RFC3168]. >--- THat's good. Thx. >I will note that, in a general sense, the ambiguity in RFC 793 has two parts: > >- what should an endpoint that receives non-zero Reserved bits do? > IMO an endpoint that drops them would be compliant > as written, though I agree the current text also allows > them to be ignored on receipt. > > This needs to be fixed in RFC793-bis, and I'll send a > separate note on that shortly. Again, thx. You will see in draft-kuehlewind-accurate-ecn-03 (just posted), we had to design the capability negotiation around this reflection problem, much as ECN had to: You may also be interested to note that accurate-ecn reserves bits in the Urgent Pointer for use when URG=0. Richard Scheffenegger has been testing this and his initial findings are that a non-zero Urgent Pointer when URG=0 is more likely to get through than a non-zero ECN field on the paths he tested. He discovered that earlier versions of Windows did not actively zero the Urgent Pointer, so the hypothesis is that middlebox designers found it easiest to ignore a non-zero Urgent Pointer, which is fortunate for us now. >- even if legacy recipients of non-zero Reserved bits ignore them, >there's still the issue of what emitters do > > RFC3168 notes that one implementation (at the time) > reflected those bits when creating a segment in > response to an arrival. It notes that ECN's use > of those bits is tolerant of that behavior, but > using those bits to signal EDO wouldn't be as > forgiving (thus the text above). > > I'm currently reviewing FreeBSD and Linux code, > but so far I do not see that these bits are > actively zeroed on transmission. That's clearly > non-compliant, and needs to be addressed as well. > I.e., a reflected segment (as RFC3168 notes) > or even non-zero bits in newly-obtained buffers > could cause a problem in that case. Do you know which implementation RFC3168 was talking about that reflects the flags? And is there evidence that others have appeared since that do this? Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Thu Jul 3 15:45:15 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506901B28B7 for ; Thu, 3 Jul 2014 15:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck1G1SxMFJ_b for ; Thu, 3 Jul 2014 15:45:12 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BF31A0496 for ; Thu, 3 Jul 2014 15:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2333; q=dns/txt; s=iport; t=1404427511; x=1405637111; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bxkm509djCWv9yWDzN3IEEMbIiiBxxTMrJuRzXElRQU=; b=S/O6Tc0iUjs7PuHhakJYuV/QJkhxVrBbe+UGiad/nKuVWZu2jp0eMOKf SRt2GkyEf0kR8OrS2UG6rBRcSli3BiQRjc5cqN//fCt86CNHbu2q6pM5S UBDhxFrd4SQu3kcbqzHcV+hwdJlXrJ4SdEvZZlXgX4C7ACZ+azjHDY8mA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIjctVOtJA2J/2dsb2JhbABagw1SvzuHPwGBDhZ1hAMBAQEDAQEBATc0CwULCw4KLicwBhOIOggNyRITBI5vMweDLYEWBYpRkCWHD4x8g2Md X-IronPort-AV: E=Sophos;i="5.01,597,1400025600"; d="scan'208";a="58201322" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 03 Jul 2014 22:45:11 +0000 Received: from [10.21.102.98] ([10.21.102.98]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s63Mj8IM017963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2014 22:45:10 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dan Wing In-Reply-To: <53B5C173.6030005@mti-systems.com> Date: Thu, 3 Jul 2014 15:45:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2CF985EA-F3FF-474B-983F-F0088602DB91@cisco.com> References: <53B5BC0D.7050906@isi.edu> <53B5C173.6030005@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/I_XaOnvmj1OY21Jzdwpv9xZhZls Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] 793bis item - reserved bit behavior X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:45:13 -0000 On Jul 3, 2014, at 1:47 PM, Wesley Eddy wrote: > On 7/3/2014 4:24 PM, Joe Touch wrote: >> Hi, all, >>=20 >> As per the discussion of EDO, I'd like to suggest that 793bis should = be >> more clear in the description of Reserved bits as follows: >>=20 >> MUST be set as zero on outgoing segments. This is superseded only = when >> the bit is otherwise defined in the future through an update to this >> document. >>=20 >> MUST be ignored on receipt on incoming segments, except as already >> integrated in checksums and security mechanisms (e.g., TCP-AO). This = is >> superseded only when the bit is otherwise defined in the future = through >> an update to this document. >>=20 >=20 >=20 > I fully agree. >=20 > I don't recall if any of the BEHAVE documents, or others, capture it, > but there may also need to be a sentence begging middleboxes not to > filter on these bits or pervert them in-transit. BEHAVE was scoped to not discuss firewall-ish behavior like filtering. As for firewalls interfering with those bits, that is the sort of = protocol conformance performed by many firewalls to prevent protocol = attacks (TCP christmas tree, overlapping segments, out of window RST, = etc.). We would not be successful in changing firewall behavior with an = RFC saying they are mis-guided to interfere with packets with Reserved = bits set, especially that we don't have any documented reason those bits = would be set. It might be useful to encourage nerd knobs for the = Reserved bits, and allow market forces will cause the vendors to allow = those Reserved bits by default. I suggest something like "So that the = Reserved bits can be used in the future, and to allow deployment of = TCP-AO, a network security function (e.g., host firewall or network = firewall) SHOULD NOT interfere (that is, block or modify such packets) = with TCP packets that have any of the Reserved bits set. If a network = security function does interfere with those TCP packets, the security = device SHOULD provide a configuration to avoid interfering with those = TCP packets." -d >=20 > --=20 > Wes Eddy > MTI Systems >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jul 3 15:51:23 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D671B2A75 for ; Thu, 3 Jul 2014 15:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYTnHhOZbhH3 for ; Thu, 3 Jul 2014 15:51:20 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91E01B2A4D for ; Thu, 3 Jul 2014 15:51:19 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 23:51:17 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 3 Jul 2014 23:51:17 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Thu, 3 Jul 2014 23:51:16 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.73.6]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s63MpFYn020959; Thu, 3 Jul 2014 23:51:15 +0100 Message-ID: <201407032251.s63MpFYn020959@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 3 Jul 2014 23:51:14 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <53B5BD53.4090300@isi.edu> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B5BD53.4090300@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/vyL3kRXM7KxAIuL17WS0M4Q_tkw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:51:22 -0000 Joe, At 21:30 03/07/2014, Joe Touch wrote: >Going back to the other suggestions: > >On 7/3/2014 7:55 AM, Bob Briscoe wrote: >>Joe, >>Section 5.4 >>The roster of possible TCP options probably ought to include TFO. >>I notice TFO was also overlooked during the timstamp options thread in >>late May / early Jun. > >The current roster is defined as those that are currently in >widespread use. I don't think that applies to TFO, so I'm not as >convinced it's worth addressing this in specific. TFO was became on by default in Linux 3.13 (Jan 2014), and it is supported by Firefox, Chrome and probably other browsers. It has to be explicitly enabled from the app for each connection, so I don't know how frequently it is actually enabled. But I think it is safe to assume that it has as much right to appear in your roster as MPTCP (they are both experimental status at the IETF, but both starting to be deployed). Bob ________________________________________________________________ Bob Briscoe, BT From nobody Fri Jul 4 04:26:53 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2F1B2D15 for ; Fri, 4 Jul 2014 04:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGhAl6-QZEOL for ; Fri, 4 Jul 2014 04:26:50 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A453E1B2D14 for ; Fri, 4 Jul 2014 04:26:50 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s64BQmMh022342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Jul 2014 06:26:49 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s64BQlU1014074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Jul 2014 13:26:47 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.218]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 4 Jul 2014 13:26:48 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WG acceptance of draft-touch-tcpm-tcp-edo-03 Thread-Index: Ac+XetbEr4xgY8sSShGExyTjIBjmjA== Date: Fri, 4 Jul 2014 11:26:47 +0000 Message-ID: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/PBkTLJgj0I_4grw2GYGyy8Pwq40 Subject: [tcpm] WG acceptance of draft-touch-tcpm-tcp-edo-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:26:52 -0000 Hi all, Given the recent list discussions on extending the TCP option space, this e= -mail starts a WG acceptance call for draft-touch-tcpm-tcp-edo-03. The call= will run on the mailing list until Friday July 18, 2014. The chairs would like to confirm that the TCPM community agrees to * adopt the document draft-touch-tcpm-tcp-edo-03 as a TCPM working group it= em, heading towards publication on standards track, and * add a corresponding milestone to the TCPM charter. The suggested charter item will exclude solutions to extend the TCP option = space in an initial SYN segment. This can possibly be addressed by a separa= te document (discussion on such solutions are obviously welcome). As usual = in the IETF, WG acceptance does not imply that the current text in the draf= t is final. If you agree that TCPM should work on a solution for extending the option s= pace and if you support the adoption of this document, please respond to th= is e-mail. Given the required update of RFC 793, even a simple "+1" respons= e would be useful feedback. If you have any suggestions or concerns regarding the adoption, please feel= free to post your thoughts to the list until July 18. Thanks Michael, Pasi, Yoshifumi (TCPM chairs) From nobody Fri Jul 4 04:35:07 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656C51B2D3D for ; Fri, 4 Jul 2014 04:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I0XgSCubrz2 for ; Fri, 4 Jul 2014 04:35:05 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197B11B2D40 for ; Fri, 4 Jul 2014 04:35:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,600,1400050800"; d="asc'?scan'208";a="132440393" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 04 Jul 2014 04:35:03 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Jul 2014 04:35:03 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 4 Jul 2014 04:35:02 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::91be:43ec:d314:b11d%21]) with mapi id 15.00.0847.030; Fri, 4 Jul 2014 04:34:43 -0700 From: "Zimmermann, Alexander" To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] WG acceptance of draft-touch-tcpm-tcp-edo-03 Thread-Index: Ac+XetbEr4xgY8sSShGExyTjIBjmjAAO8f4A Date: Fri, 4 Jul 2014 11:34:43 +0000 Message-ID: <4E7F7AF6-7DDE-4793-95B3-99365B126856@netapp.com> References: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_C36F8BF5-98CC-4499-8A0D-FEC8BB0D2BD2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SbRi3Bi1b_Hs4JmOjo0-0nT7Qu8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-touch-tcpm-tcp-edo-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:35:06 -0000 --Apple-Mail=_C36F8BF5-98CC-4499-8A0D-FEC8BB0D2BD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Am 04.07.2014 um 13:26 schrieb Scharf, Michael (Michael) = : > Hi all, >=20 > Given the recent list discussions on extending the TCP option space, = this e-mail starts a WG acceptance call for draft-touch-tcpm-tcp-edo-03. = The call will run on the mailing list until Friday July 18, 2014. >=20 > The chairs would like to confirm that the TCPM community agrees to >=20 > * adopt the document draft-touch-tcpm-tcp-edo-03 as a TCPM working = group item, heading towards publication on standards track, and >=20 > * add a corresponding milestone to the TCPM charter. >=20 > The suggested charter item will exclude solutions to extend the TCP = option space in an initial SYN segment. This can possibly be addressed = by a separate document (discussion on such solutions are obviously = welcome). As usual in the IETF, WG acceptance does not imply that the = current text in the draft is final. >=20 > If you agree that TCPM should work on a solution for extending the = option space and if you support the adoption of this document, please = respond to this e-mail. Given the required update of RFC 793, even a = simple "+1" response would be useful feedback. >=20 > If you have any suggestions or concerns regarding the adoption, please = feel free to post your thoughts to the list until July 18. >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi > (TCPM chairs) >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_C36F8BF5-98CC-4499-8A0D-FEC8BB0D2BD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlO2kVIACgkQdyiq39b9uS5bXACg/gNrbn20DYjueX+UWYrRIocs OFYAoPoICDNA0gzp118D605PgBq76TCx =JUvW -----END PGP SIGNATURE----- --Apple-Mail=_C36F8BF5-98CC-4499-8A0D-FEC8BB0D2BD2-- From nobody Fri Jul 4 05:02:46 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D959B1B2D49; Fri, 4 Jul 2014 05:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkubfXSeel2c; Fri, 4 Jul 2014 05:02:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1AE1B28A2; Fri, 4 Jul 2014 05:02:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704120243.14835.59374.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 05:02:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/dbTiMILwdkeZ8-VVydGHXJxNr58 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 12:02:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP and SCTP RTO Restart Authors : Per Hurtig Anna Brunstrom Andreas Petlund Michael Welzl Filename : draft-ietf-tcpm-rtorestart-03.txt Pages : 13 Date : 2014-07-04 Abstract: This document describes a modified algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 05:10:43 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A64F1B2D63 for ; Fri, 4 Jul 2014 05:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfY5sA6fwa1h for ; Fri, 4 Jul 2014 05:10:37 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E1A1B286A for ; Fri, 4 Jul 2014 05:10:37 -0700 (PDT) X-Spam-Processed: mail.kau.se, Fri, 04 Jul 2014 14:10:11 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: perhurt@kau.se X-MDRemoteIP: 78.72.167.165 X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se X-MDaemon-Deliver-To: tcpm@ietf.org Message-ID: <53B699B4.8000203@kau.se> Date: Fri, 04 Jul 2014 14:10:28 +0200 From: Per Hurtig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org Extensions" References: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> In-Reply-To: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_NtBMuccLcdIYSoNlr13YTgnTT4 Subject: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 12:10:39 -0000 Hi all, the newest version of the RTO restart (RTOR) draft address the issues pointed out in Alexander's review. A summary of changes is shown below. We've also performed a series of experiments to assess RTOR's performance. Results from these experiments can be found at: http://riteproject.eu/resources/rto-restart/#the-benefits o Updated the document to use "RTOR" instead of "RTO Restart" when refering to the modified algorithm. o Moved document terminology to a section of its own. o Introduced the rrthresh variable in the terminology section. o Added a section to generalize the tracking of outstanding segments. o Updated the algorithm to work when the number of outstanding segments is less than four and one segment is ready for transmission, by restarting the timer when new data has been sent. o Clarified the relationship between fast retransmit and RTOR. o Improved the wording throughout the document. Cheers, Per -------- Original Message -------- Subject: New Version Notification for draft-ietf-tcpm-rtorestart-03.txt Date: Fri, 04 Jul 2014 05:02:44 -0700 From: internet-drafts@ietf.org To: Andreas Petlund , "Andreas Petlund" , "Michael Welzl" , Per Hurtig , Michael Welzl , "Per Hurtig" , Anna Brunstrom , "Anna Brunstrom" A new version of I-D, draft-ietf-tcpm-rtorestart-03.txt has been successfully submitted by Per Hurtig and posted to the IETF repository. Name: draft-ietf-tcpm-rtorestart Revision: 03 Title: TCP and SCTP RTO Restart Document date: 2014-07-04 Group: tcpm Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rtorestart-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ Htmlized: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-03 Abstract: This document describes a modified algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jul 4 07:26:49 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436AB1B29C7 for ; Fri, 4 Jul 2014 07:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2cPp0vPPehm for ; Fri, 4 Jul 2014 07:26:45 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 985711B29B3 for ; Fri, 4 Jul 2014 07:26:45 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6CF40C94C3; Fri, 4 Jul 2014 10:26:43 -0400 (EDT) Date: Fri, 4 Jul 2014 10:26:43 -0400 From: John Leslie To: "Scharf, Michael (Michael)" Message-ID: <20140704142643.GL85889@verdi> References: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/vg5PtuYMvs160GV8AQ2LMXPWr98 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-touch-tcpm-tcp-edo-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:26:47 -0000 Scharf, Michael (Michael) wrote: > > The chairs would like to confirm that the TCPM community agrees to > > * adopt the document draft-touch-tcpm-tcp-edo-03 as a TCPM working group > item, heading towards publication on standards track, and > > * add a corresponding milestone to the TCPM charter. Yes. (I promise to participate in the discussion.) -- John Leslie From nobody Fri Jul 4 10:51:24 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502131A04B8 for ; Fri, 4 Jul 2014 10:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27sRf3DiK3eJ for ; Fri, 4 Jul 2014 10:51:18 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4707B1A0021 for ; Fri, 4 Jul 2014 10:51:18 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s64Homh0026495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Jul 2014 10:50:52 -0700 (PDT) Message-ID: <53B6E978.8050607@isi.edu> Date: Fri, 04 Jul 2014 10:50:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/-4s89FoS3w6hiLiXlwxCB3TpWno Subject: Re: [tcpm] WG acceptance of draft-touch-tcpm-tcp-edo-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 17:51:19 -0000 On 7/4/2014 4:26 AM, Scharf, Michael (Michael) wrote: ... > The suggested charter item will exclude solutions to extend the TCP > option space in an initial SYN segment. This can possibly be addressed > by a separate document (discussion on such solutions are obviously > welcome). ... FYI, Bob Briscoe, Ted Faber, and I are working on that document already, and it's already cited in this doc but has not yet been submitted. Joe From nobody Sat Jul 5 04:52:36 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F105E1A04A3 for ; Sat, 5 Jul 2014 04:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcMBMHtBKPnt for ; Sat, 5 Jul 2014 04:52:33 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.231]) by ietfa.amsl.com (Postfix) with ESMTP id 1581C1A0495 for ; Sat, 5 Jul 2014 04:52:32 -0700 (PDT) Received: from pasisarahtismbp.lan (80.223.92.46) by kirsi1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 53B153320061ADE7 for tcpm@ietf.org; Sat, 5 Jul 2014 14:52:31 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <575349AE-0FAE-4616-B6A8-451491C25C0E@iki.fi> Date: Sat, 5 Jul 2014 14:52:20 +0300 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/AkFKcsjitygiSkeBpRFJIiJhe7g Subject: [tcpm] WGLC for draft-ietf-tcpm-accecn-reqs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 11:52:35 -0000 Hi, This Email starts the working group last call for = draft-ietf-tcpm-accecn-reqs-06 ("Problem Statement and Requirements for = a More Accurate ECN Feedback"), to be submitted as Informational RFC. = The WGLC ends on Monday, July 21st (which is the scheduled date for the = TCPM meeting in Toronto). Please send any comments to the TCPM mailing = list by then. Statements supporting publication of the current version = are also welcome. Datatracker link to the document is = https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ - Pasi, on behalf of the TCPM chairs From nobody Sun Jul 6 22:59:15 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB9F1A0AFA for ; Sun, 6 Jul 2014 22:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF0EQLUwtKkW for ; Sun, 6 Jul 2014 22:59:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C131A0AFB for ; Sun, 6 Jul 2014 22:59:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR77308; Mon, 07 Jul 2014 05:59:09 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 06:59:09 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 13:59:01 +0800 From: "Huangyihong (Rachel)" To: "tcpm@ietf.org" Thread-Topic: [tcpm] FW: New Version Notification for draft-huang-tsvwg-tr-tcp-ps-00.txt Thread-Index: AQHPmaiMTYSKIa2LSkmF7x4uYTVLXg== Date: Mon, 7 Jul 2014 05:59:00 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB861E9D62@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/AELf02xpR-dKTGNbti-OYYqCMCs Subject: [tcpm] FW: New Version Notification for draft-huang-tsvwg-tr-tcp-ps-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 05:59:13 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgYSBkcmFmdCBpbiB0c3Z3ZyB0byBkaXNjdXNzIHRoZSBwcm9i bGVtIHRoYXQgdHJhZGl0aW9uYWwgVENQIGlzIG5vdCBmbGV4aWJsZSBlbm91Z2ggdG8gZGVhbCB3 aXRoIHNvbWUgc2NlbmFyaW9zLCBlLmcuLCBkaWZmZXJlbnQgdXNlIGNhc2VzIG1heSBuZWVkIGRp ZmZlcmVudCBjb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtcywgb3IgVENQIHBhcmFtZXRlcnMu IFdlIGhvcGUgdGhhdCBleHBlcnRzIGluIFRDUE0gY291bGQgcmV2aWV3IGFuZCBjb21tZW50cyB0 aGlzIGRyYWZ0LCBzbyB0aGF0IHdlIGNhbiBtYWtlIHN1cmUgd2hldGhlciB0aGUgcHJvYmxlbSBt YXR0ZXJzLiBZb3VyIHJldmlldyBhbmQgY29tbWVudHMgYXJlIGhpZ2hseSBhcHByZWNpYXRlZC4g DQoNCkJSLA0KUmFjaGVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogVHVlc2RheSwgSnVseSAwMSwgMjAxNCAyOjU2IFBNDQpUbzogWW91amlhbmppZTsgSHVh bmd5aWhvbmcgKFJhY2hlbCk7IEh1YW5neWlob25nIChSYWNoZWwpOyBZb3VqaWFuamllDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1YW5nLXRzdndnLXRyLXRj cC1wcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHVhbmctdHN2d2ct dHItdGNwLXBzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSYWNo ZWwgSHVhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJh ZnQtaHVhbmctdHN2d2ctdHItdGNwLXBzDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJVHJhZGl0aW9u YWwgVENQIFByb2JsZW0gU3RhdGVtZW50DQpEb2N1bWVudCBkYXRlOgkyMDE0LTA3LTAxDQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk4DQpVUkw6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVhbmctdHN2d2ctdHItdGNw LXBzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWh1YW5nLXRzdndnLXRyLXRjcC1wcy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWFuZy10c3Z3Zy10ci10Y3AtcHMtMDANCg0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgZGlzY3Vzc2VzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBh bmQgY29uc2lkZXJhdGlvbiBmb3INCiAgIGV4aXN0aW5nIFRDUC4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Jul 7 13:14:44 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3AD1A0515 for ; Mon, 7 Jul 2014 13:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.974 X-Spam-Level: ** X-Spam-Status: No, score=2.974 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLuTR9IobnvZ for ; Mon, 7 Jul 2014 13:14:37 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626A61B28AB for ; Mon, 7 Jul 2014 13:14:35 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 69F5427828E for ; Tue, 8 Jul 2014 05:14:33 +0900 (JST) Received: by mail-lb0-f178.google.com with SMTP id 10so3298234lbg.9 for ; Mon, 07 Jul 2014 13:14:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.30.2 with SMTP id o2mr24578531lah.31.1404764070518; Mon, 07 Jul 2014 13:14:30 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Mon, 7 Jul 2014 13:14:30 -0700 (PDT) Date: Mon, 7 Jul 2014 13:14:30 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=089e0160a5c06aa56b04fda01f06 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HEqzHrV9-DTAS_qpSyal3fFI9EU Subject: [tcpm] draft agenda for Toronto meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:14:38 -0000 --089e0160a5c06aa56b04fda01f06 Content-Type: text/plain; charset=UTF-8 Hi folks, We've uploaded the current draft agenda for Toronto meeting. You can check it on http://tools.ietf.org/wg/tcpm/agenda Regards, -- Yoshi & Pasi & Michael --089e0160a5c06aa56b04fda01f06 Content-Type: text/html; charset=UTF-8
Hi folks,

We've uploaded the current draft agenda for Toronto meeting.

Regards,
--
Yoshi & Pasi & Michael
--089e0160a5c06aa56b04fda01f06-- From nobody Mon Jul 7 16:01:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B061B28C8 for ; Mon, 7 Jul 2014 16:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAKzLPwDNQqD for ; Mon, 7 Jul 2014 16:01:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7401B28A5 for ; Mon, 7 Jul 2014 16:01:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s67N0rak007273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Jul 2014 16:00:54 -0700 (PDT) Message-ID: <53BB26A5.8030201@isi.edu> Date: Mon, 07 Jul 2014 16:00:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> <201407032232.s63MW8M2020910@bagheera.jungle.bt.co.uk> In-Reply-To: <201407032232.s63MW8M2020910@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/OK9VG2SPgX2dfUTHZF5UJOVQsN0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 23:01:48 -0000 On 7/3/2014 3:25 PM, Bob Briscoe wrote: > Joe, > > At 21:13 03/07/2014, Joe Touch wrote: >> Hi, all, >> >> Regarding the reserved bits, I hope the following pending revision >> will resolve this thread: >> >> --- >> The Reserved TCP header bits cannot be redefined easily, even though >> three of the six total bits have already been redefined (ECE/CWR >> [RFC3168] and NS [RFC3540]). Legacy endpoints have been known to >> reflect received values in these fields; this was safely dealt with >> for ECN but would be difficult here [RFC3168]. >> --- > > THat's good. Thx. > > >> I will note that, in a general sense, the ambiguity in RFC 793 has two >> parts: >> >> - what should an endpoint that receives non-zero Reserved bits do? >> IMO an endpoint that drops them would be compliant >> as written, though I agree the current text also allows >> them to be ignored on receipt. >> >> This needs to be fixed in RFC793-bis, and I'll send a >> separate note on that shortly. > > Again, thx. > > You will see in draft-kuehlewind-accurate-ecn-03 (just posted), we had > to design the capability negotiation around this reflection problem, > much as ECN had to: > > > > You may also be interested to note that accurate-ecn reserves bits in > the Urgent Pointer for use when URG=0. Richard Scheffenegger has been > testing this and his initial findings are that a non-zero Urgent Pointer > when URG=0 is more likely to get through than a non-zero ECN field on > the paths he tested. > > He discovered that earlier versions of Windows did not actively zero the > Urgent Pointer, so the hypothesis is that middlebox designers found it > easiest to ignore a non-zero Urgent Pointer, which is fortunate for us now. > > >> - even if legacy recipients of non-zero Reserved bits ignore them, >> there's still the issue of what emitters do >> >> RFC3168 notes that one implementation (at the time) >> reflected those bits when creating a segment in >> response to an arrival. It notes that ECN's use >> of those bits is tolerant of that behavior, but >> using those bits to signal EDO wouldn't be as >> forgiving (thus the text above). >> >> I'm currently reviewing FreeBSD and Linux code, >> but so far I do not see that these bits are >> actively zeroed on transmission. That's clearly >> non-compliant, and needs to be addressed as well. >> I.e., a reflected segment (as RFC3168 notes) >> or even non-zero bits in newly-obtained buffers >> could cause a problem in that case. > > Do you know which implementation RFC3168 was talking about that reflects > the flags? And is there evidence that others have appeared since that do > this? No idea - just the info that's already in RFC3168. Joe From nobody Mon Jul 7 17:00:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030D71B2998 for ; Mon, 7 Jul 2014 17:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DVNfb7ViOB3 for ; Mon, 7 Jul 2014 17:00:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE891B2992 for ; Mon, 7 Jul 2014 17:00:51 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s6800ZRL016815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Jul 2014 17:00:35 -0700 (PDT) Message-ID: <53BB34A3.6090909@isi.edu> Date: Mon, 07 Jul 2014 17:00:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B5BD53.4090300@isi.edu> <201407032251.s63MpFYn020959@bagheera.jungle.bt.co.uk> In-Reply-To: <201407032251.s63MpFYn020959@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YpQAcwMW-de8dVRlyySwOL_KXbQ Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 00:00:55 -0000 On 7/3/2014 3:51 PM, Bob Briscoe wrote: > Joe, > > At 21:30 03/07/2014, Joe Touch wrote: >> Going back to the other suggestions: >> >> On 7/3/2014 7:55 AM, Bob Briscoe wrote: >>> Joe, > >>> Section 5.4 >>> The roster of possible TCP options probably ought to include TFO. >>> I notice TFO was also overlooked during the timstamp options thread in >>> late May / early Jun. >> >> The current roster is defined as those that are currently in >> widespread use. I don't think that applies to TFO, so I'm not as >> convinced it's worth addressing this in specific. > > TFO was became on by default in Linux 3.13 (Jan 2014), and it is > supported by Firefox, Chrome and probably other browsers. I'm interested to know whether those apps follow the applicability statement in the TFO spec, e.g., turning this feature off for POSTs vs GETs. > It has to be > explicitly enabled from the app for each connection, so I don't know how > frequently it is actually enabled. But I think it is safe to assume that > it has as much right to appear in your roster as MPTCP (they are both > experimental status at the IETF, but both starting to be deployed). Sure. FYI, TFO doesn't appear to be all that big. It can be as large as 16 bytes but the typical appears to be 8 bytes. NB: TFO is only 2 bytes in the SYN, so doesn't need to be mentioned in the other SYN-extension variant doc under development. I did expand the discussion in the EDO document on this, though. Joe From nobody Mon Jul 7 17:30:53 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698021B299D for ; Mon, 7 Jul 2014 17:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB_rN0-Rlcy7 for ; Mon, 7 Jul 2014 17:30:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7321B2991 for ; Mon, 7 Jul 2014 17:30:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s680UHlP021179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Jul 2014 17:30:17 -0700 (PDT) Message-ID: <53BB3B99.9010005@isi.edu> Date: Mon, 07 Jul 2014 17:30:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dan Wing , Wesley Eddy References: <53B5BC0D.7050906@isi.edu> <53B5C173.6030005@mti-systems.com> <2CF985EA-F3FF-474B-983F-F0088602DB91@cisco.com> In-Reply-To: <2CF985EA-F3FF-474B-983F-F0088602DB91@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/f5FPwwzM9YeHhu9kPrNwy0Mybrc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis item - reserved bit behavior X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 00:30:51 -0000 On 7/3/2014 3:45 PM, Dan Wing wrote: > > On Jul 3, 2014, at 1:47 PM, Wesley Eddy wrote: > >> On 7/3/2014 4:24 PM, Joe Touch wrote: >>> Hi, all, >>> >>> As per the discussion of EDO, I'd like to suggest that 793bis should be >>> more clear in the description of Reserved bits as follows: >>> >>> MUST be set as zero on outgoing segments. This is superseded only when >>> the bit is otherwise defined in the future through an update to this >>> document. >>> >>> MUST be ignored on receipt on incoming segments, except as already >>> integrated in checksums and security mechanisms (e.g., TCP-AO). This is >>> superseded only when the bit is otherwise defined in the future through >>> an update to this document. >>> >> >> >> I fully agree. >> >> I don't recall if any of the BEHAVE documents, or others, capture it, >> but there may also need to be a sentence begging middleboxes not to >> filter on these bits or pervert them in-transit. > > BEHAVE was scoped to not discuss firewall-ish behavior like filtering. > > As for firewalls interfering with those bits, that is the sort of > protocol conformance performed by many firewalls to prevent protocol > attacks (TCP christmas tree, overlapping segments, out of window RST, > etc.). They have confused "something they didn't expect" with "an attack". I've seen that faulty logic before. > We would not be successful in changing firewall behavior with an > RFC saying they are mis-guided to interfere with packets with Reserved > bits set, especially that we don't have any documented reason those bits > would be set. IMO, anything that modifies a TCP header is acting as a host, and ought to be following RFC1122. When that's not the case, it's less a "middlebox" and more a "meddlebox" (i.e., it meddles where it ought not). We shouldn't need documented reasons not to meddle. > It might be useful to encourage nerd knobs for the > Reserved bits, and allow market forces will cause the vendors to allow > those Reserved bits by default. Uh, no. That just makes things worse. > I suggest something like "So that the > Reserved bits can be used in the future, and to allow deployment of > TCP-AO, a network security function (e.g., host firewall or network > firewall) SHOULD NOT interfere (that is, block or modify such packets) > with TCP packets that have any of the Reserved bits set. TCP-AO is very clear. If you change anything in the header, it will fail because *that's the kind of attack it's designed to detect*. The exceptions fpr TCP-AO are: a) TCP options, which can be ignored on a per-connection basis if desired b) A given IP address and TCP port, to allow NAT traversal Exceptions for other TCP options may vary, e.g., if we have (another) alternate TCP checksum. > If a network > security function does interfere with those TCP packets, the security > device SHOULD provide a configuration to avoid interfering with those > TCP packets." This is more than a security issue. Middleboxes SHOULD provide a way to change its understanding of protocols they attempt to validate or modify to avoid their configuration from limiting that of a valid endpoint. Joe From nobody Mon Jul 7 17:59:14 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B631B29A8 for ; Mon, 7 Jul 2014 17:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LzQ9lWnDxz5 for ; Mon, 7 Jul 2014 17:59:07 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9051B29A4 for ; Mon, 7 Jul 2014 17:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4548; q=dns/txt; s=iport; t=1404781146; x=1405990746; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nv2aOPG4t5wrLNzsKZLciZzJrjgCNYKX+kzcjt1Eckk=; b=VEdvzM1oq9JEsJ95oJK92QBeGKXPjy5AeUqeW1QVs+cmLyjVhpm/4IsX ycFqJ1vf/3Jiaf7oJrpBpNmkOlmpWI9czp9KQHCm1A8kEF1pE9kP5ttMQ hM1rDzRsJU3Urk2j1xsdzYZRAIK7ka122iZz567Go7bxH0+/D56f++yPM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPlAu1OtJV2Z/2dsb2JhbABZDoMAx1MBgRYWdYQDAQEBAwFvCgULCxguVwYTiDoIySwXjm8zB4MtgRYFilGQJZQMgwFiHYEzJA X-IronPort-AV: E=Sophos;i="5.01,622,1400025600"; d="scan'208";a="58988218" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 08 Jul 2014 00:59:05 +0000 Received: from sjc-vpn1-1285.cisco.com (sjc-vpn1-1285.cisco.com [10.21.101.5]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s680x3n5014195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 00:59:05 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dan Wing In-Reply-To: <53BB3B99.9010005@isi.edu> Date: Mon, 7 Jul 2014 17:59:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53B5BC0D.7050906@isi.edu> <53B5C173.6030005@mti-systems.com> <2CF985EA-F3FF-474B-983F-F0088602DB91@cisco.com> <53BB3B99.9010005@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yp0C09n85HQuEWv0URwsLN0lYfU Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis item - reserved bit behavior X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 00:59:11 -0000 On Jul 7, 2014, at 5:30 PM, Joe Touch wrote: >=20 >=20 > On 7/3/2014 3:45 PM, Dan Wing wrote: >>=20 >> On Jul 3, 2014, at 1:47 PM, Wesley Eddy wrote: >>=20 >>> On 7/3/2014 4:24 PM, Joe Touch wrote: >>>> Hi, all, >>>>=20 >>>> As per the discussion of EDO, I'd like to suggest that 793bis = should be >>>> more clear in the description of Reserved bits as follows: >>>>=20 >>>> MUST be set as zero on outgoing segments. This is superseded only = when >>>> the bit is otherwise defined in the future through an update to = this >>>> document. >>>>=20 >>>> MUST be ignored on receipt on incoming segments, except as already >>>> integrated in checksums and security mechanisms (e.g., TCP-AO). = This is >>>> superseded only when the bit is otherwise defined in the future = through >>>> an update to this document. >>>>=20 >>>=20 >>>=20 >>> I fully agree. >>>=20 >>> I don't recall if any of the BEHAVE documents, or others, capture = it, >>> but there may also need to be a sentence begging middleboxes not to >>> filter on these bits or pervert them in-transit. >>=20 >> BEHAVE was scoped to not discuss firewall-ish behavior like = filtering. >>=20 >> As for firewalls interfering with those bits, that is the sort of >> protocol conformance performed by many firewalls to prevent protocol >> attacks (TCP christmas tree, overlapping segments, out of window RST, >> etc.). >=20 > They have confused "something they didn't expect" with "an attack". = I've seen that faulty logic before. I don't disagree. My statement above is a result of an hour discussion = with marketing about MPTCP and why our products do what they do. >=20 >> We would not be successful in changing firewall behavior with an >> RFC saying they are mis-guided to interfere with packets with = Reserved >> bits set, especially that we don't have any documented reason those = bits >> would be set. >=20 > IMO, anything that modifies a TCP header is acting as a host, and = ought to be following RFC1122. Yes, I recall the similar argument about modifying IP header that = resulted in RFC6864 (specifically around IPID). > When that's not the case, it's less a "middlebox" and more a = "meddlebox" (i.e., it meddles where it ought not). We shouldn't need = documented reasons not to meddle. >=20 >> It might be useful to encourage nerd knobs for the >> Reserved bits, and allow market forces will cause the vendors to = allow >> those Reserved bits by default. >=20 > Uh, no. That just makes things worse. Yes, I understand and agree with the desire to change the default = behavior of a firewall box that is doing protocol validation. I am = pointing out that products have a different philosophy, and even if = Cisco or another couple of vendors changed default behavior this month = it would still be years away from becoming common default behavior on = networks -- if at all -- as (for example) some network operators think = host-generated TCP ISN are the path to ruin, and want network devices to = (re?) randomize ISNs, even though it was a decade ago that = host-generated ISNs were predictable, and even though steganographic = communications can be achieved using a million other techniques. > > I suggest something like "So that the >> Reserved bits can be used in the future, and to allow deployment of >> TCP-AO, a network security function (e.g., host firewall or network >> firewall) SHOULD NOT interfere (that is, block or modify such = packets) >> with TCP packets that have any of the Reserved bits set. >=20 > TCP-AO is very clear. If you change anything in the header, it will = fail because *that's the kind of attack it's designed to detect*. >=20 > The exceptions fpr TCP-AO are: > a) TCP options, which can be ignored on a per-connection basis > if desired >=20 > b) A given IP address and TCP port, to allow NAT traversal >=20 > Exceptions for other TCP options may vary, e.g., if we have (another) = alternate TCP checksum. >=20 >> If a network >> security function does interfere with those TCP packets, the security >> device SHOULD provide a configuration to avoid interfering with those >> TCP packets." >=20 > This is more than a security issue. Middleboxes SHOULD provide a way = to change its understanding of protocols they attempt to validate or = modify to avoid their configuration from limiting that of a valid = endpoint. That's the nerd knob I described above. -d From nobody Tue Jul 8 07:41:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52191A00F6 for ; Tue, 8 Jul 2014 07:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9-smBBE7-qn for ; Tue, 8 Jul 2014 07:41:31 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A565A1A0092 for ; Tue, 8 Jul 2014 07:41:30 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 8 Jul 2014 15:41:25 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 8 Jul 2014 15:41:28 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 8 Jul 2014 15:41:23 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.171.11]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s68EfLZ8010712; Tue, 8 Jul 2014 15:41:22 +0100 Message-ID: <201407081441.s68EfLZ8010712@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 8 Jul 2014 15:41:20 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <53BB34A3.6090909@isi.edu> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B5BD53.4090300@isi.edu> <201407032251.s63MpFYn020959@bagheera.jungle.bt.co.uk> <53BB34A3.6090909@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TTmTt3ql94f5xA22s7KJ6iIYBa8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:41:33 -0000 Joe, At 01:00 08/07/2014, Joe Touch wrote: >On 7/3/2014 3:51 PM, Bob Briscoe wrote: >>Joe, >> >>At 21:30 03/07/2014, Joe Touch wrote: >>>Going back to the other suggestions: >>> >>>On 7/3/2014 7:55 AM, Bob Briscoe wrote: >>>>Joe, >> >>>>Section 5.4 >>>>The roster of possible TCP options probably ought to include TFO. >>>>I notice TFO was also overlooked during the timstamp options thread in >>>>late May / early Jun. >>> >>>The current roster is defined as those that are currently in >>>widespread use. I don't think that applies to TFO, so I'm not as >>>convinced it's worth addressing this in specific. >> >>TFO was became on by default in Linux 3.13 (Jan 2014), and it is >>supported by Firefox, Chrome and probably other browsers. > >I'm interested to know whether those apps follow the applicability >statement in the TFO spec, e.g., turning this feature off for POSTs vs GETs. Dunno. >>It has to be >>explicitly enabled from the app for each connection, so I don't know how >>frequently it is actually enabled. But I think it is safe to assume that >>it has as much right to appear in your roster as MPTCP (they are both >>experimental status at the IETF, but both starting to be deployed). > >Sure. FYI, TFO doesn't appear to be all that big. It can be as large >as 16 bytes but the typical appears to be 8 bytes. > >NB: TFO is only 2 bytes in the SYN, so doesn't need to be mentioned >in the other SYN-extension variant doc under development. I did >expand the discussion in the EDO document on this, though. Not correct. TFO is 2B only for the cookie request on the first SYN between two hosts. Then 6-18B on subsequent SYNs that use the cookie. Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Tue Jul 8 07:48:56 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C501B2AEB for ; Tue, 8 Jul 2014 07:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siCYiAIIiNuL for ; Tue, 8 Jul 2014 07:48:42 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5761A00F6 for ; Tue, 8 Jul 2014 07:48:40 -0700 (PDT) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id s68EjliK003106; Tue, 8 Jul 2014 07:48:35 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0b-000ceb01.pphosted.com with ESMTP id 1n031c8s12-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Jul 2014 07:48:35 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 08:47:48 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 08:48:32 -0600 From: David Borman To: Joe Touch Thread-Topic: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt Thread-Index: AQHPmruv4MiLQ8oFtU2nxzVIUYA4rw== Date: Tue, 8 Jul 2014 14:48:30 +0000 Message-ID: <0C29294E-7C2D-4653-A706-DE5FF44EF4AF@quantum.com> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> In-Reply-To: <53B5B96F.1020304@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-08_04:2014-07-08,2014-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=1.11022302462516e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.0569325878121234 urlsuspect_oldscore=0.0569325878121234 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.0569325878121234 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407080165 Content-Type: text/plain; charset="Windows-1252" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Yqydsne-6SI-BLJ81gA3D_tzgi4 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:48:48 -0000 On Jul 3, 2014, at 3:13 PM, Joe Touch wrote: > Hi, all, >=20 > Regarding the reserved bits, I hope the following pending revision will r= esolve this thread: >=20 > --- > The Reserved TCP header bits cannot be redefined easily, even though thre= e of the six total bits have already been redefined (ECE/CWR [RFC3168] and = NS [RFC3540]). Legacy endpoints have been known to reflect received values = in these fields; this was safely dealt with for ECN but would be difficult = here [RFC3168]. > --- >=20 > I will note that, in a general sense, the ambiguity in RFC 793 has two pa= rts: >=20 > - what should an endpoint that receives non-zero Reserved bits do? > IMO an endpoint that drops them would be compliant > as written, though I agree the current text also allows > them to be ignored on receipt. >=20 > This needs to be fixed in RFC793-bis, and I'll send a > separate note on that shortly. It says "Reserved for future use. Must be zero.=94 The underlying princip= al has always been be conservative in what you send, and liberal in what yo= u accept. Sending packets with garbage in the reserved bits makes them use= less for future use, =93Must be zero=94 applies to sending, so that the bit= s *can* be used in the future. Being liberal in what you accept means you = ignore the reserved bits on input, not drop the packet if the reserved bits= are non-zero. While RFC 793 doesn=92t explicitly say the Reserved bits sh= ould be ignored on input, it also doesn=92t explicitly say anywhere that yo= u should even look at those bits on input. Arguing that dropping packets w= ith non-zero Reserved bits is compliant ignores the spirit of be liberal in= what you accept. > - even if legacy recipients of non-zero Reserved bits ignore them, there'= s still the issue of what emitters do I see no issue for emitters, RFC 793 is quite clear on that, "Reserved for = future use. Must be zero.=94 Any implementation that has not implemented = future use of those bits is not in compliance with RFC 793 if it puts non-z= ero values into the reserved bits. >=20 > RFC3168 notes that one implementation (at the time) > reflected those bits when creating a segment in > response to an arrival. It notes that ECN's use > of those bits is tolerant of that behavior, but > using those bits to signal EDO wouldn't be as > forgiving (thus the text above). >=20 > I'm currently reviewing FreeBSD and Linux code, > but so far I do not see that these bits are > actively zeroed on transmission. That's clearly The reserved bits have always been zeroed in BSD code. Not directly in tcp= _output(), but in the template header. In older BSD code this happened in = tcp_template(), in the current FreeBSD code it=92s in tcpip_fillheaders(); = in both cases look for th_x2 and you=92ll see where it gets cleared. The t= h_x2 field is the top 4 reserved bits, the bottom 2 reserved bits get clear= ed when th_flags is initialized to zero. -David Borman > non-compliant, and needs to be addressed as well. > I.e., a reflected segment (as RFC3168 notes) > or even non-zero bits in newly-obtained buffers > could cause a problem in that case. >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From nobody Tue Jul 8 10:10:55 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635C91B2BC9 for ; Tue, 8 Jul 2014 10:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPcZktkOL3nd for ; Tue, 8 Jul 2014 10:10:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39A61B2BC7 for ; Tue, 8 Jul 2014 10:10:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s68HA3XV013649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 10:10:08 -0700 (PDT) Message-ID: <53BC25EB.8070301@isi.edu> Date: Tue, 08 Jul 2014 10:10:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Borman References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> <0C29294E-7C2D-4653-A706-DE5FF44EF4AF@quantum.com> In-Reply-To: <0C29294E-7C2D-4653-A706-DE5FF44EF4AF@quantum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/kfdlS-SQ-GCki5HZVmETveCTMOg Cc: "tcpm@ietf.org" Subject: [tcpm] TCP reserved bits and793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:10:54 -0000 Changing the thread on this, because IMO it's more related to the 793bis than EDO... On 7/8/2014 7:48 AM, David Borman wrote: > > On Jul 3, 2014, at 3:13 PM, Joe Touch wrote: ... >> This needs to be fixed in RFC793-bis, and I'll send a >> separate note on that shortly. > > It says "Reserved for future use. Must be zero. The underlying > principal has always been be conservative in what you send, and liberal > in what you accept. Sending packets with garbage in the reserved bits > makes them useless for future use, Must be zero applies to sending, so > that the bits *can* be used in the future. I agree that's a reasonable interpretation. > Being liberal in what you > accept means you ignore the reserved bits on input, not drop the packet > if the reserved bits are non-zero. There are two interpretations of "Must be zero": a) current implementations should drop segments with those bits set b) current implementations should ignore those bits > While RFC 793 doesnt explicitly say > the Reserved bits should be ignored on input, it also doesnt explicitly > say anywhere that you should even look at those bits on input. It says "Must be zero." That can easily be interpreted as requiring that when the bits are set the segment is invalid. > Arguing > that dropping packets with non-zero Reserved bits is compliant ignores > the spirit of be liberal in what you accept. While I agree with the general principle, the current text is ambiguous. "Must be zero" can be taken as a directive to validate those bits on receipt. Note that RFC793 doesn't define what to do when the Data Offset is smaller than 5 - so does that mean you should be liberal and process such segments, or drop them? I agree that "liberal" means that, in either case, you MUST NOT generate a response segment, ICMP message, or user error. But it's not as clear *from the current text*. The point of all this is that 793bis needs to be updated to make this direct and explicit, though. >> - even if legacy recipients of non-zero Reserved bits ignore them, there's still the issue of what emitters do > > I see no issue for emitters, RFC 793 is quite clear on that, > "Reservedfor future use. Must be zero. Any implementation that has not > implemented future use of those bits is not in compliance with RFC 793 > if it puts non-zero values into the reserved bits. I agree, but we don't have evidence as to whether this is the case or not. >> RFC3168 notes that one implementation (at the time) >> reflected those bits when creating a segment in >> response to an arrival. It notes that ECN's use >> of those bits is tolerant of that behavior, but >> using those bits to signal EDO wouldn't be as >> forgiving (thus the text above). >> >> I'm currently reviewing FreeBSD and Linux code, >> but so far I do not see that these bits are >> actively zeroed on transmission. That's clearly > > The reserved bits have always been zeroed in BSD code. Not directly > in tcp_output(), but in the template header. In older BSD code this > happened in tcp_template(), in the current FreeBSD code its in > tcpip_fillheaders(); in both cases look for th_x2 and youll see > where it gets cleared. The th_x2 field is the top 4 reserved bits, > the bottom 2 reserved bits get cleared when th_flags is initialized > to zero. I found that after I posted the message above; I have not been able to as directly find the evidence in the Linux code, though. Joe From nobody Tue Jul 8 10:15:56 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFC61B2BD2 for ; Tue, 8 Jul 2014 10:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpZN5yUoxghw for ; Tue, 8 Jul 2014 10:15:49 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A201A0386 for ; Tue, 8 Jul 2014 10:15:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s68HFTvq015209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 10:15:29 -0700 (PDT) Message-ID: <53BC2731.6090306@isi.edu> Date: Tue, 08 Jul 2014 10:15:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B5BD53.4090300@isi.edu> <201407032251.s63MpFYn020959@bagheera.jungle.bt.co.uk> <53BB34A3.6090909@isi.edu> <201407081441.s68EfLZ8010712@bagheera.jungle.bt.co.uk> In-Reply-To: <201407081441.s68EfLZ8010712@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_-IJwUbBgPA1qh_Ant0q-Tz0k6o Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:15:52 -0000 On 7/8/2014 7:41 AM, Bob Briscoe wrote: > Joe, > > At 01:00 08/07/2014, Joe Touch wrote: ... >> NB: TFO is only 2 bytes in the SYN, so doesn't need to be mentioned in >> the other SYN-extension variant doc under development. I did expand >> the discussion in the EDO document on this, though. > > Not correct. TFO is 2B only for the cookie request on the first SYN > between two hosts. Then 6-18B on subsequent SYNs that use the cookie. Ahh, got it; I'll add it to the SYN-EDO draft in process. Joe From nobody Tue Jul 8 10:34:03 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF531B2B74 for ; Tue, 8 Jul 2014 10:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njaBwp6CQUMV for ; Tue, 8 Jul 2014 10:34:00 -0700 (PDT) Received: from atl4mhob01.myregisteredsite.com (atl4mhob01.myregisteredsite.com [209.17.115.39]) by ietfa.amsl.com (Postfix) with ESMTP id 939851A0344 for ; Tue, 8 Jul 2014 10:34:00 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s68HXw8B016997 for ; Tue, 8 Jul 2014 13:33:58 -0400 Received: (qmail 598 invoked by uid 0); 8 Jul 2014 17:33:58 -0000 X-TCPREMOTEIP: 107.48.162.132 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.48.162.132) by 0 with ESMTPA; 8 Jul 2014 17:33:58 -0000 Message-ID: <53BC2B81.4060500@mti-systems.com> Date: Tue, 08 Jul 2014 13:33:53 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , David Borman References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> <0C29294E-7C2D-4653-A706-DE5FF44EF4AF@quantum.com> <53BC25EB.8070301@isi.edu> In-Reply-To: <53BC25EB.8070301@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/30-YeB5Ps4QQNI0zvvhI_mWDl4I Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP reserved bits and793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:34:02 -0000 On 7/8/2014 1:10 PM, Joe Touch wrote: > There are two interpretations of "Must be zero": > a) current implementations should drop segments with those bits > set > > b) current implementations should ignore those bits It's worth noting that interpretation b also implies that future uses of those bits should be done in a way that doesn't cause them to override processing of other parts of the standard header. In other words, ignoring them when set limits the possible semantics that they can be used for. -- Wes Eddy MTI Systems From nobody Tue Jul 8 10:48:29 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE62E1A03DF for ; Tue, 8 Jul 2014 10:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZWVH21KOlUA for ; Tue, 8 Jul 2014 10:48:25 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7C71A036D for ; Tue, 8 Jul 2014 10:48:25 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s68Hlx5N021458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 10:47:59 -0700 (PDT) Message-ID: <53BC2ECF.9090802@isi.edu> Date: Tue, 08 Jul 2014 10:47:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Wesley Eddy , David Borman References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> <0C29294E-7C2D-4653-A706-DE5FF44EF4AF@quantum.com> <53BC25EB.8070301@isi.edu> <53BC2B81.4060500@mti-systems.com> In-Reply-To: <53BC2B81.4060500@mti-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/dhi3NsffcWmQfwb3lIgIaUKkIBM Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP reserved bits and793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:48:26 -0000 On 7/8/2014 10:33 AM, Wesley Eddy wrote: > On 7/8/2014 1:10 PM, Joe Touch wrote: >> There are two interpretations of "Must be zero": >> a) current implementations should drop segments with those bits >> set >> >> b) current implementations should ignore those bits > > It's worth noting that interpretation b also implies that future uses > of those bits should be done in a way that doesn't cause them to > override processing of other parts of the standard header. In other > words, ignoring them when set limits the possible semantics that they > can be used for. Ignoring them when set limits their semantics. Not ignoring them when set limits their semantics. I.e., either way something is compromised. We have no "drop if you don't understand it" bits or fields in TCP per se. Nothing says to drop DO<5. We do drop sequence numbers outside the window, but by interpreting those fields. NOTE: *nothing* in 793 says to ignore options you don't understand; it actually says that options are option in a given segment but that all TCPs must implement all options. That can easily be interpreted as "if you see an option you don't understand, drop the segment". It wasn't until RFC1122 that we decided to declare otherwise, that both IP and TCP must silently ignore options not undersood. Joe From nobody Tue Jul 8 10:49:04 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DDF1A0401 for ; Tue, 8 Jul 2014 10:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRT92C6keajC for ; Tue, 8 Jul 2014 10:49:00 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79D81A0376 for ; Tue, 8 Jul 2014 10:49:00 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id s68HkdXZ020947; Tue, 8 Jul 2014 10:49:00 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1n0bv994fs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Jul 2014 10:49:00 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 11:48:18 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 11:48:59 -0600 From: David Borman To: "Wesley M. Eddy" Thread-Topic: [tcpm] TCP reserved bits and793bis Thread-Index: AQHPms+T/8VHtJfggUmfyoIXPgqLB5uW1IiAgAAEOgA= Date: Tue, 8 Jul 2014 17:48:57 +0000 Message-ID: <8D6B0065-827E-481C-BCE9-22F86E48B3D9@quantum.com> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> <0C29294E-7C2D-4653-A706-DE5FF44EF4AF@quantum.com> <53BC25EB.8070301@isi.edu> <53BC2B81.4060500@mti-systems.com> In-Reply-To: <53BC2B81.4060500@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-ID: <0D2300E48E53EE4A946C9E8881AC5D96@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-08_05:2014-07-08,2014-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=2.76889622341514e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.00984168481858689 urlsuspect_oldscore=0.00984168481858689 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.00984168481858689 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407080198 Content-Type: text/plain; charset="Windows-1252" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eDFg9BU1BQTqdYpFV-OOWaMQkuE Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] TCP reserved bits and793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:49:01 -0000 On Jul 8, 2014, at 12:33 PM, Wesley Eddy wrote: > On 7/8/2014 1:10 PM, Joe Touch wrote: >> There are two interpretations of "Must be zero": >> a) current implementations should drop segments with those bits >> set >>=20 >> b) current implementations should ignore those bits >=20 >=20 > It's worth noting that interpretation b also implies that future uses > of those bits should be done in a way that doesn't cause them to > override processing of other parts of the standard header. In other > words, ignoring them when set limits the possible semantics that they > can be used for. To some degree, yes, but only in the initial SYN packet, just like for TCP = options, e.g. WSopt does change processing of the standard header, but only= after both sides mutually agree to support it. If a bit is going to chang= e the processing of the standard header, it can=92t apply to the initial SY= N, and mutual support has to be negotiated via some mechanism. -David >=20 > --=20 > Wes Eddy > MTI Systems ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From nobody Tue Jul 8 15:39:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555B31A0169 for ; Tue, 8 Jul 2014 15:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Y1kMwAgb-F for ; Tue, 8 Jul 2014 15:39:32 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810291A015B for ; Tue, 8 Jul 2014 15:39:32 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id a108so5689320qge.18 for ; Tue, 08 Jul 2014 15:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e3z1HVbD1MQZQKf3bfT4WYNrnbqGuH/A/a+uenuQ+T4=; b=WruEwSCOH5QglaOENcgClxU8xQY3F9mWUNeOy5EYS7eZ8nYB0o4gYjpDaGTQyS29wc LrYMqMtibeIGgJLmE9UoBOP/mrr9toOyiwVCz/qQ66tIT/fhq4Lnfwv0QMt3m9KlYojo 0uvXnxyR76wY40DTLm0wb7OAhAnAr7BBDloI+5QUrSGYeSEih4ocF9bvfdnIX4ZMNIhW 8VhbcM/tBbmoYL4H5WLLO8wKd6nQawQmB0yWSQWDG6IwCfPkPVWbJEDn0rLrgy4JicU8 ht1YsfWL+NkKg2qfSmLturbpF8QKkSs2mAtMcipZ4Js/l3Dxsg1HQW+nUpDWm/2M7dVB pluQ== MIME-Version: 1.0 X-Received: by 10.140.101.115 with SMTP id t106mr59549912qge.91.1404859171562; Tue, 08 Jul 2014 15:39:31 -0700 (PDT) Received: by 10.140.80.115 with HTTP; Tue, 8 Jul 2014 15:39:31 -0700 (PDT) In-Reply-To: <201405312234.s4VMYwGW004526@bagheera.jungle.bt.co.uk> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <201405311819.s4VIJt2V003823@bagheera.jungle.bt.co.uk> <538A2B96.3030900@isi.edu> <201405312234.s4VMYwGW004526@bagheera.jungle.bt.co.uk> Date: Tue, 8 Jul 2014 15:39:31 -0700 Message-ID: From: Martin Duke To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a11c1721ee1738204fdb6434c Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Rszo9dEPOeyjmgSVZgbiiMFdLYI Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] More TCP option space on SYNs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 22:39:38 -0000 --001a11c1721ee1738204fdb6434c Content-Type: text/plain; charset=UTF-8 Gentlemen, I think we're throwing out the idea of extended space on SYN a little too quickly. From the EDO draft: A new TCP option cannot extend the Data Offset of a TCP initial SYN. All TCP segments, including the initial SYN, may include user data in the payload data [RFC793 ], and this can be useful for some proposed features such as TCP Fast Open [Ch14 ]. Legacy endpoints that ignore the new option would process the payload contents as user data and send an ACK. Once ACK'd, this data cannot be removed from the user stream. The TFO option issue seems addressable by specifying that if a SYN contains both EDO and TFO Cookie, the TFO Cookie MUST be entirely in the extended option space.* This eliminates the possibility that a server with TFO but not EDO will misinterpret extended options as data. TFO aside, I hesitate to throw out EDO with SYN for the benefit of listening TCP servers that accept unvalidated data appended to the SYN. Even if technically permitted, this is obviously unsafe behavior in the open internet -- or else no one would have invented TFO. Before discarding the architecturally simple solution I would prefer to see (1) evidence that real servers actually accept and deliver unvalidated data attached to a SYN packet, and (2) an argument that this is behavior that the standard should support. -Martin * In principle, the TFO Cookie need only partially be in the extended space, but this would offer less protection to servers that aren't properly validating their TFO cookies. On Sat, May 31, 2014 at 3:34 PM, Bob Briscoe wrote: > Joe, > > > At 20:20 31/05/2014, Joe Touch wrote: > >> Hi, Bob, >> >> On 5/31/2014 11:19 AM, Bob Briscoe wrote: >> >>> Joe, >>> >>> Thx for consolidating this thread. I've given it a new subject line. >>> >>> 1) You've silently made an important alteration to the proposed >>> protocol. You've put the extra-options directly in the TCP option space >>> of the C-SYN, not within the payload. >>> >> >> I hadn't assumed that; I was describing only which SYN carried which >> options, not where they were. As you do, I was assuming the C-SYN options >> were in the data space. >> > > OK. > > > > To be clear, in my variant - using data outside the sync'd connection >> (with ACK clear), the option space is similarly in the data portion of the >> 'extra' segment. >> > > Yup, that was understood already. > > > > Yes, your altered proposal is cleaner. However, don't imagine I didn't >>> think of this. I did and I deliberately didn't do it this way.We have a >>> choice: >>> clean and vulnerable vs. messy but robust. >>> >>> I'm not wedded to using port 80 and http headers, but this is perhaps >>> the most pragmatic approach. >>> >> >> That's fraught with a whole slew of other problems, notably the >> middleboxes that currently try to translate, proxy, or otherwise modify >> anything they see as port 80. >> >> Further, that would limit the number of pending connections. >> >> It will be really unorthodox to define such >>> a protocol I know. We would have to say something like >>> >>> "The dst port of the C-SYN MUST be 80, and the payload MUST >>> start >>> with the constant magic_token, where >>> magic_token = 'PUT / HTTP/1.1Connection : DSO' >>> " >>> >>> I'm sorry if even thinking about this makes you feel dirty :| >>> >>> Other suggestions for inner protocols are welcome, including tunnelled >>> protocols, as long as middleboxes widely forward them, given their dst >>> port. >>> >> >> I don't see what this gets us other than potential interactions. There's >> no reason to use HTTP to format TCP options, and it would necessitate new >> encodings and new processing for existing options that might end up in the >> extended space. >> > > To be clear, I would put the general requirement as : > > " Pick a port number, then make sure the app-layer headers at the > start of the TCP payload appear valid for that port number, so that > middleboxes will forward it, then include the extra TCP options as the body > of this faked up app-layer protocol. > " > > Then the dilemma becomes: pick a number, any number as long as it's 80. > The alternative is often to be blocked. Particularly if you connect from > inside a company that has bought one of those myopic Web gateways, or you > connect to a cellular network, or... you just connect to the Internet via a > box from a vendor beginning with a letter in the alphabet,... or a digit. > > > > 2) The main problem with your notation is it doesn't say /where/ the >>> info is placed. >>> >> >> EDO says the options are at the head of the data segment, just with a >> longer pointer - the same way as current options. >> >> For extending the SYN using a separate segment - whether a C-SYN or >> unsync'd data segment - the data similarly comes at the head of the data, >> just that there's no user data permitted after it. >> > > I understood all this. I just meant that the notation you introduced in > your email didn't have the facility to specify at which layer fields were > placed. > > > > I've added notation as follows: >>> TCP(base header [TCP options [APP(header[payload])]]) >>> >>> And for the record I've made the if-else logic clearer. >>> >>> Where I've made more than clarifying edits inline, I've described them >>> and tagged them with [BB]. >>> >>> At 21:34 30/05/2014, Joe Touch wrote: >>> >>>> Hi, Bob, >>>> >>>> Let's get back to the core, in a simpler fashion, so other can follow >>>> it. >>>> >>>> I stand by my "there's no way to extend the space in the initial SYN", >>>> but you've convinced me there *might* be a way to provide extended >>>> space that can occur during the first phase of the TWHS. I think the >>>> dual-SYN approach still isn't viable, but I've outlined an alternative >>>> below that's similar but doesn't have the same baggage, IMO. >>>> >>>> Again, I'm still concerned by what midboxes might do to this... >>>> >>>> What do others think?? >>>> >>>> Joe >>>> >>>> For quick review, here's what I understand: >>>> >>>> dso = dual-syn option >>>> dso-D = data >>>> dso-C = control >>>> conn_id = identifier to link the two SYNs together >>>> extra_opt = options that didn't fit in legacy SYN >>>> fit_opt = options that do fit in the legacy SYN >>>> >>> new client endpoint sends >>> TCP(port A SYN [dso-D(conn_id) + fit_opt] ) >>> TCP(port B SYN [dso-C [APP(headers [conn_id + >>> extra_opt] ) ] ] ) >>> >> >> IMO, the conn_ID in the C-SYN should similarly be in the regular option >> space, but I don't think it matters. >> >> [BB]: i/APP(headers...)/ >>> >>> if (legacy server endpoint) { sends back two >>> connections: >>> TCP(port A SYN-ACK [fit_opt] ) >>> TCP(port B SYN-ACK [??] ) >>> >>>> (it's interpretation of extra_opt) >>>> >>> >> I'm assuming EDO after the SYN, which means the SYN-ACK has as much space >> as it wants for options, as would every other segment. >> >> new client endpoint responds: >>> TCP(port A ACK) (established) >>> TCP(port B RST) >>> >>> Notes about legacy servers: >>>> - they do twice the work on SYNs >>>> - they might keep twice the state >>>> (if not using cookies) >>>> - they might clean state if the RST >>>> is received, but that state might >>>> persist indefinitely (until the next >>>> connection, depending on timeouts, etc.) >>>> >>>> ----- >>>> >>> } elif (new server endpoint) { sends back one >>> connection: >>> TCP(port A SYN-ACK [edo + fit_opt + >>> extra_opt] ) >>> >>> [BB]: s/dso-d/edo/ >>> >> >> Sure. At this point we're basically in EDO-land. >> >> new client endpoint responds: >>> TCP(port A ACK) (established) >>> >>> >>>> Notes: >>>> - can stall when dso-D SYN arrives >>>> before dso-C SYN, up to some limit >>>> - twice the work on SYNs (or more) >>>> >>> } >>> >>> Here's what I was assuming, though admittedly it's not documented (yet): >>>> >>>> - no significant impact on TCP connection rate for >>>> legacy servers >>>> >>>> - no significant impact on TCP connection rate for >>>> legacy clients >>>> >>>> - impact dominated by processing the extended option space >>>> for extended clients >>>> >>>> - impact dominated by processing the extended option space >>>> for extended servers >>>> >>>> - compatible with typical TCP processing optimizations, >>>> notably SYN cookies >>>> you did provide a potential way forward for these >>>> >>>> - capable of successfully traversing typical NATs >>>> >>>> Your approach has the following properties: >>>> >>> >>> The 3 bullets below are not useful ways to describe performance impact. >>> They selectively describe whichever gives the most pessimistic picture >>> out of: >>> a) either the instantaneous performance change at the moment of >>> connection >>> b) or the worst-case long-run performance impact >>> >>> They don't describe the average long-run performance impact, which is >>> important for sizing machines. >>> >>> Worse, the instantaneous performance impact is only significant when a >>> machine's SYN processing time is large relative to the e2e delay, which >>> would be a highly unusual scenario on public networks (even in scenarios >>> such as intra-data-centre, it's hard to reduce e2e delay to approach SYN >>> processing time, but you could for intra-machine connections). >>> >> >> SYN processing is a known load - and potential overload - on machines. >> That's why it's reasonable to focus on it. >> > > But we should primarily think in terms of SYN cookie processing for legacy > hosts, and the equivalent for upgraded hosts. We should design thia as the > norm, not the exception. Possibly the /only/ way to implement this new form > of SYN processing. > > Then, for the dual-SYN scheme, the upgraded host doesn't have a normal SYN > cookie processing load with a C-SYN, so we can no longer rely on known-load > formulae. > > > > - halves the server connection rate for updated servers >>>> from legacy clients when this option is in use >>>> >>> >>> Eh? The long-run server connection rate will be fractionally decreased >>> due to updated clients using extra options (which is your third case >>> below), but the instantaneous server connection rate seen by a legacy >>> client is unchanged, because it only sends one SYN. >>> >> >> Agreed. I was doing too many of these at once... >> >> - lowers (to some extent, if not halves) the client >>>> connection rate of updated clients to all servers >>>> when this option is in use >>>> >>>> - halves (roughly) the server rate for all servers >>>> when this option is in use >>>> >>> >>> Nope. All long-run server rates are reduced by 1/(1+e), where e is the >>> fraction of connections using extra options. >>> >> >> the rate for connections when this option is in use is halved - I didn't >> see that the sentence above could be parsed the other way. the overall rate >> depends on the fraction of connections using the option. >> >> It also: >>>> >>>> - doubles the number of SYNs in the network >>>> >>> >>> Nope. The number of SYNs in the network is inflated by e where e is the >>> fraction of connections using extra options. >>> >> >> You keep bringing this up - I don't like a solution that should be used >> only a little. If it works, we should assume it works everywhere all the >> time. >> > > It doesn't make sense to predict that all connections will always use MSS, > timestamp, SACK, window-scale, MPTCP, TCP-AO, new option X, new option y, > etc etc. > > For a start, less than 1% of connections contain enough packets to make > MPTCP worth starting. > > The word option means optional. > > > - susceptible to lack of fate-sharing problems, e.g., >>>> if the two SYNs experience different firewall configurations >>>> >>> >>> Nope. It's fairer to say it's potentially susceptible to second-order >>> fate-sharing problems like your firewall example (the first-order fate >>> sharing problems have been addressed). >>> >> >> I have no idea why you think firewalls are a second-order fate-sharing, >> or what that even means. Fate sharing means fate is shared. When fate is >> not shared by the SYNs, this method has problems. There's no mechanism to >> recover the missing D-SYN or C-SYN. >> > > What I mean by first-order fate-sharing problems is those obvious cases > (reordering, drop) that we have addressed by resynthesising fate sharing. > > There is certainly a possibility that two SYNs between the same endpoints > will pass through different firewalls, but it is small in the Internet as a > whole. There is a further possibility that these two firewalls will be > configured differently, but it is small. There is a further possibility > that the differences in configuration will be significant enough to > distinguish the behaviour wrt the two SYNs, but it is small. When three > small probabilities are multiplied together, you get a really small > probability. This is what I call a second-order fate-sharing problem. > > You must surely see that it is inconsistent to say: > * "this method has problems" about the DSO idea, based on such a corner > case > * "no problem with fate-sharing" about the ASO idea, when all you mean is > that the FBP will follow the same path as the SYN, and they will therefore > likely pass through the same devices. > > In the ASO proposal, splitting the options on a SYN over two packets, one > of which is considered invalid by TCP, will cause the FBP to be discarded > by numerous TCP normalisers and stateful firewalls. That is a fate sharing > problem of the first order. Likely to be on a much larger scale than the > 'second-order' firewall problem above. > > > > - reduces the space available for fit_opt due to the need >>>> for the conn_id even in the fall-back D-SYN, which means >>>> less option space in the SYNs for fall-back connections >>>> >>> >>> Yup. >>> >>> >>> the conn_id which may need to be very large because it >>>> needs to be unique per source port and source IP address >>>> because that information is lost during NAT translation >>>> >>> >>> Given many NATs will typically make the src IPs of both SYNs the same, I >>> suggest a larger conn_id should be a fall-back option for the client, >>> not a default. >>> >> >> Multiple NATs are quite common - carrier grade NATs in the net, and user >> NATs at the home WIFI point. >> >> Any multiple-NAT, or any path through even a single carrier-grade NAT >> will end up potentially un-doing or over-doing source IP overlap, creating >> false positives and false negatives that break this mechanism. >> >> That's really the crux - fate sharing and the need to bind the two SYNs - >> that make this untenable, IMO. >> >> Even if the src IPs of both SYNs are different once they reach the >>> server, the high end bits will invariably be the same. >>> >> >> You can't know this - the two SYNs could have gone through different >> numbers of NATs or different NATs entirely, so the bits could change >> arbitrarily. >> > > That's what 'invariably' means. I'm not claiming this works 100%. I am > saying I expect it to work sufficiently to be worth trying it out to see if > I'm right. If it doesn't work, on some paths, the fall-back has been > described - the client has to rely on the TCP options it can fit in a > single SYN. > > > > So the max size >>> of the contents of the DSO TCP option can be 6B, and the server can take >>> the rest of conn_id from the higher bits of the src IP addr of each SYN. >>> This is a variant of the idea in . >>> >> >> FWIW, you're now in the land where we would have to start explaining the >> privacy and tracking implications of those bits. I'd really like to avoid >> that. >> > > Nope. I think you're reading this the wrong way round. I'm not revealing > private IDs in TCP option fields. I'm reducing the size of the (random) > conn_id in cases where the /public/ src port or the upper bits of the > /public/ src IP have sufficient entropy to be used to construct the rest of > the conn_id. > > I was acknowledging Dan Wing 'cos he gave us the idea. But it's a > /variant/ that doesn't reveal anything private. > > I'm going offline, possibly until Tue now. > > Regards > > > Bob > > > > In fact, the server doesn't even need a small conn_id for clients that >>> know they are not behind a NAT and that want more option space in the >>> D-SYN - then the server could use the src port & src IP for the conn_id. >>> >>> To summarise, these options could be distinguished by the length field >>> of the dual-syn option. >>> Length = 2B => conn_id = src netaddr + src >>> port >>> Length = 6B = 2B +4B conn_id_short => conn_id = src netaddr + >>> conn_id_short >>> Length = 8B = 2B +6B conn_id_long => conn_id = hsb(src netaddr) + >>> conn_id_long >>> >>> Given there have been numerous other attempts to reveal a connection ID >>> that is preserved through middleboxes [RFC6967], rather than defining a >>> dual-syn option that carries a conn_id, we might want to design a TCP >>> connection ID option with a flag to say whether it is also part of a >>> dual SYN pair or not. >>> >>> Where >>> * hsb(src netaddr) is the netaddr with the lowest 16 bits truncated >>> * src netaddr is the network address (IPv4, IPv6, or any other network >>> protocol) >>> >>> To reduce latency, a host could use the default short_conn_id for all >>> connections at first, then: >>> - if it finds that DSO persistently doesn't work it falls back to the >>> long_conn_id for all connections >>> - it occasionally tests the short and zero options to see if it can use >>> shorter DSO options. >>> >>> >>> - requires the ISNs to be related (see RFC6528 - if there's >>>> a rule to generate it, there will be code to validate that >>>> rule, and eventually a BCP to encourage that validation - >>>> typically from the same RFC author) >>>> >>> >>> Eh? The ISNs can and should be independent. To be robust against >>> middleboxes that rewrite sequence numbers, we must not required ISNs to >>> be related. >>> >>> >>> I agree that you have proposed potentially viable ways to deal with >>>> the SYN cookie, and that RST state is not an issue. >>>> >>> >>> A feature that I think it's fair to add: >>> - Good chance of passing through app-layer middleboxes that >>> forward >>> unrecognised TCP options unchanged, but not those that discard >>> them. >>> >>> >>> However, there are too many problems with this, IMO, to call it viable. >>>> >>> >>> Once your over-pessimistic analyses of the performance impact are >>> corrected, and my ideas to reduce the size of the conn_id are taken into >>> account, it's a different story. >>> >>> But it's up to the WG to decide whether this is worth taking further. >>> Not just you or I. >>> >> >> Agreed. >> >> Here's another trick that might clean up the above a little: >>>> >>> >>> >> with ACK=0> >>> >>> Cheers >>> >>> >>> Bob >>> >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT >>> >> >> ________________________________________________________________ >> Bob Briscoe, BT >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a11c1721ee1738204fdb6434c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gentlemen,

I think we're throwing o= ut the idea of extended space on SYN a little too quickly. From the EDO dra= ft:

A new TCP option cannot extend the Data Offset of a TCP initial SYN.
   All TCP segments, including the initial SYN, may include user data
   in the payload data [RFC793=
], and this can be useful for some

   proposed features such as TCP Fast Open [Ch14]. Legacy endpoints
   that ignore the new option would process the payload contents as
   user data and send an ACK. Once ACK'd, this data cannot be removed
   from the user stream.

The TFO optio=
n issue seems addressable by specifying that if a SYN contains both EDO and=
 TFO Cookie, the TFO Cookie MUST be entirely in the extended option space.*=
 This eliminates the possibility that a server with TFO but not EDO will mi=
sinterpret extended options as data.

TFO aside, I hesitate to throw out EDO with SYN for the benef=
it of listening TCP servers that accept unvalidated data appended to the SY=
N. Even if technically permitted, this is obviously unsafe behavior in the =
open internet -- or else no one would have invented TFO. Before discarding =
the architecturally simple solution I would prefer to see (1) evidence that=
 real servers actually accept and deliver unvalidated data attached to a SY=
N packet, and (2) an argument that this is behavior that the standard shoul=
d support.



=
-Martin

* In principle, the TFO Cookie need only partially be in the =
extended space, but this would offer less protection to servers that aren&#=
39;t properly validating their TFO cookies.


O= n Sat, May 31, 2014 at 3:34 PM, Bob Briscoe <bob.briscoe@bt.com>= wrote:
Joe,


At 20:20 31/05/2014, Joe Touch wrote:
Hi, Bob,

On 5/31/2014 11:19 AM, Bob Briscoe wrote:
Joe,

Thx for consolidating this thread. I've given it a new subject line.
1) You've silently made an important alteration to the proposed
protocol. You've put the extra-options directly in the TCP option space=
of the C-SYN, not within the payload.

I hadn't assumed that; I was describing only which SYN carried which op= tions, not where they were. As you do, I was assuming the C-SYN options wer= e in the data space.

OK.



To be clear, in my variant - using data outside the sync'd connection (= with ACK clear), the option space is similarly in the data portion of the &= #39;extra' segment.

Yup, that was understood already.



Yes, your altered proposal is cleaner. However, don't imagine I didn= 9;t
think of this. I did and I deliberately didn't do it this way.We have a=
choice:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clean and vulnerable vs. messy but robust= .

I'm not wedded to using port 80 and http headers, but this is perhaps the most pragmatic approach.

That's fraught with a whole slew of other problems, notably the middleb= oxes that currently try to translate, proxy, or otherwise modify anything t= hey see as port 80.

Further, that would limit the number of pending connections.

It will be really unorthodox to define such
a protocol I know. We would have to say something like

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The dst port of the C-SYN MUST be 8= 0, and the payload MUST start
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the constant magic_token, where
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0magic_token =3D 'PUT / HTTP/1.1<CR= LF>Connection : DSO<CRLF><CRLF>'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"

I'm sorry if even thinking about this makes you feel dirty :|

Other suggestions for inner protocols are welcome, including tunnelled
protocols, as long as middleboxes widely forward them, given their dst
port.

I don't see what this gets us other than potential interactions. There&= #39;s no reason to use HTTP to format TCP options, and it would necessitate= new encodings and new processing for existing options that might end up in= the extended space.

To be clear, I would put the general requirement as :

" =C2=A0 =C2=A0 =C2=A0 Pick a port number, then make sure the app-laye= r headers at the start of the TCP payload appear valid for that port number= , so that middleboxes will forward it, then include the extra TCP options a= s the body of this faked up app-layer protocol.
"

Then the dilemma becomes: pick a number, any number as long as it's 80.= The alternative is often to be blocked. Particularly if you connect from i= nside a company that has bought one of those myopic Web gateways, or you co= nnect to a cellular network, or... you just connect to the Internet via a b= ox from a vendor beginning with a letter in the alphabet,... or a digit.


2) The main problem with your notation is it doesn't say /where/ the info is placed.

EDO says the options are at the head of the data segment, just with a longe= r pointer - the same way as current options.

For extending the SYN using a separate segment - whether a C-SYN or unsync&= #39;d data segment - the data similarly comes at the head of the data, just= that there's no user data permitted after it.

I understood all this. I just meant that the notation you introduced in you= r email didn't have the facility to specify at which layer fields were = placed.



I've added notation as follows:
TCP(base header [TCP options [APP(header[payload])]])

And for the record I've made the if-else logic clearer.

Where I've made more than clarifying edits inline, I've described t= hem
and tagged them with [BB].

At 21:34 30/05/2014, Joe Touch wrote:
Hi, Bob,

Let's get back to the core, in a simpler fashion, so other can follow i= t.

I stand by my "there's no way to extend the space in the initial S= YN",
but you've convinced me there *might* be a way to provide extended
space that can occur during the first phase of the TWHS. I think the
dual-SYN approach still isn't viable, but I've outlined an alternat= ive
below that's similar but doesn't have the same baggage, IMO.

Again, I'm still concerned by what midboxes might do to this...

What do others think??

Joe

For quick review, here's what I understand:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dso =3D dual-syn op= tion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 dso-D =3D data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 dso-C =3D control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conn_id =3D identif= ier to link the two SYNs together
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 extra_opt =3D optio= ns that didn't fit in legacy SYN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fit_opt =3D options= that do fit in the legacy SYN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0new client endpoint sends
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TCP(port A SY= N [dso-D(conn_id) + fit_opt] )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TCP(port B SY= N [dso-C [APP(headers [conn_id +
extra_opt] ) ] ] )

IMO, the conn_ID in the C-SYN should similarly be in the regular option spa= ce, but I don't think it matters.

[BB]: i/APP(headers...)/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0if (legacy server endpoint) { sends back two
connections:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TCP(port A SYN-ACK [fit_opt] )=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TCP(port B SYN-ACK [??] )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (it's interpretation of extra_op= t)

I'm assuming EDO after the SYN, which means the SYN-ACK has as much spa= ce as it wants for options, as would every other segment.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ne= w client endpoint responds:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TC= P(port A ACK) (established)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TC= P(port B RST)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Notes about legacy servers:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - they do twice the work on SYNs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - they might keep twice the state =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if not using cookies)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - they might clean state if the RST<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is received, but that state might =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 persist indefinitely (until the next=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connection, depending on timeouts, e= tc.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0} elif (new server endpoint) { sends back one
connection:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TCP(port A SYN-ACK [edo + fit_= opt +
extra_opt] )

[BB]: s/dso-d/edo/

Sure. At this point we're basically in EDO-land.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ne= w client endpoint responds:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TC= P(port A ACK) (established)


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Notes:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - can stall when dso-D SYN arrives =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 before dso-C SYN, up to some limit =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - twice the work on SYNs (or more)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0}

Here's what I was assuming, though admittedly it's not documented (= yet):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - no significant impact on TCP connection rate = for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 legacy servers

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - no significant impact on TCP connection rate = for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 legacy clients

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - impact dominated by processing the extended o= ption space
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for extended clients

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - impact dominated by processing the extended o= ption space
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for extended servers

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - compatible with typical TCP processing optimi= zations,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 notably SYN cookies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 you did provide a p= otential way forward for these

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - capable of successfully traversing typical NA= Ts

Your approach has the following properties:

The 3 bullets below are not useful ways to describe performance impact.
They selectively describe whichever gives the most pessimistic picture
out of:
a) either the instantaneous performance change at the moment of connection<= br> b) or the worst-case long-run performance impact

They don't describe the average long-run performance impact, which is important for sizing machines.

Worse, the instantaneous performance impact is only significant when a
machine's SYN processing time is large relative to the e2e delay, which=
would be a highly unusual scenario on public networks (even in scenarios such as intra-data-centre, it's hard to reduce e2e delay to approach SY= N
processing time, but you could for intra-machine connections).

SYN processing is a known load - and potential overload - on machines. That= 's why it's reasonable to focus on it.

But we should primarily think in terms of SYN cookie processing for legacy = hosts, and the equivalent for upgraded hosts. We should design thia as the = norm, not the exception. Possibly the /only/ way to implement this new form= of SYN processing.

Then, for the dual-SYN scheme, the upgraded host doesn't have a normal = SYN cookie processing load with a C-SYN, so we can no longer rely on known-= load formulae.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 - halves the server connection rate for updated= servers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 from legacy clients when this option is in use<= br>

Eh? The long-run server connection rate will be fractionally decreased
due to updated clients using extra options (which is your third case
below), but the instantaneous server connection rate seen by a legacy
client is unchanged, because it only sends one SYN.

Agreed. I was doing too many of these at once...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - lowers (to some extent, if not halves) the cl= ient
=C2=A0 =C2=A0 =C2=A0 =C2=A0 connection rate of updated clients to all serve= rs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 when this option is in use

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - halves (roughly) the server rate for all serv= ers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 when this option is in use

Nope. All long-run server rates are reduced by 1/(1+e), where e is the
fraction of connections using extra options.

the rate for connections when this option is in use is halved - I didn'= t see that the sentence above could be parsed the other way. the overall ra= te depends on the fraction of connections using the option.

It also:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - doubles the number of SYNs in the network

Nope. The number of SYNs in the network is inflated by e where e is the
fraction of connections using extra options.

You keep bringing this up - I don't like a solution that should be used= only a little. If it works, we should assume it works everywhere all the t= ime.

It doesn't make sense to predict that all connections will always use M= SS, timestamp, SACK, window-scale, MPTCP, TCP-AO, new option X, new option = y, etc etc.

For a start, less than 1% of connections contain enough packets to make MPT= CP worth starting.

The word option means optional.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 - susceptible to lack of fate-sharing problems,= e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if the two SYNs experience different firewall c= onfigurations

Nope. It's fairer to say it's potentially susceptible to second-ord= er
fate-sharing problems like your firewall example (the first-order fate
sharing problems have been addressed).

I have no idea why you think firewalls are a second-order fate-sharing, or = what that even means. Fate sharing means fate is shared. When fate is not s= hared by the SYNs, this method has problems. There's no mechanism to re= cover the missing D-SYN or C-SYN.

What I mean by first-order fate-sharing problems is those obvious cases (re= ordering, drop) that we have addressed by resynthesising fate sharing.

There is certainly a possibility that two SYNs between the same endpoints w= ill pass through different firewalls, but it is small in the Internet as a = whole. There is a further possibility that these two firewalls will be conf= igured differently, but it is small. There is a further possibility that th= e differences in configuration will be significant enough to distinguish th= e behaviour wrt the two SYNs, but it is small. When three small probabiliti= es are multiplied together, you get a really small probability. This is wha= t I call a second-order fate-sharing problem.

You must surely see that it is inconsistent to say:
* "this method has problems" about the DSO idea, based on such a = corner case
* "no problem with fate-sharing" about the ASO idea, when all you= mean is that the FBP will follow the same path as the SYN, and they will t= herefore likely pass through the same devices.

In the ASO proposal, splitting the options on a SYN over two packets, one o= f which is considered invalid by TCP, will cause the FBP to be discarded by= numerous TCP normalisers and stateful firewalls. That is a fate sharing pr= oblem of the first order. Likely to be on a much larger scale than the '= ;second-order' firewall problem above.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 - reduces the space available for fit_opt due t= o the need
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for the conn_id even in the fall-back D-SYN, wh= ich means
=C2=A0 =C2=A0 =C2=A0 =C2=A0 less option space in the SYNs for fall-back con= nections

Yup.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 the conn_id which may need to be very large bec= ause it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 needs to be unique per source port and source I= P address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 because that information is lost during NAT tra= nslation

Given many NATs will typically make the src IPs of both SYNs the same, I suggest a larger conn_id should be a fall-back option for the client,
not a default.

Multiple NATs are quite common - carrier grade NATs in the net, and user NA= Ts at the home WIFI point.

Any multiple-NAT, or any path through even a single carrier-grade NAT will = end up potentially un-doing or over-doing source IP overlap, creating false= positives and false negatives that break this mechanism.

That's really the crux - fate sharing and the need to bind the two SYNs= - that make this untenable, IMO.

Even if the src IPs of both SYNs are different once they reach the
server, the high end bits will invariably be the same.

You can't know this - the two SYNs could have gone through different nu= mbers of NATs or different NATs entirely, so the bits could change arbitrar= ily.

That's what 'invariably' means. I'm not claiming this works= 100%. I am saying I expect it to work sufficiently to be worth trying it o= ut to see if I'm right. If it doesn't work, on some paths, the fall= -back has been described - the client has to rely on the TCP options it can= fit in a single SYN.



So the max size
of the contents of the DSO TCP option can be 6B, and the server can take the rest of conn_id from the higher bits of the src IP addr of each SYN. This is a variant of the idea in <draft-wing-nat-reveal-option>.

FWIW, you're now in the land where we would have to start explaining th= e privacy and tracking implications of those bits. I'd really like to a= void that.

Nope. I think you're reading this the wrong way round. I'm not reve= aling private IDs in TCP option fields. I'm reducing the size of the (r= andom) conn_id in cases where the /public/ src port or the upper bits of th= e /public/ src IP have sufficient entropy to be used to construct the rest = of the conn_id.

I was acknowledging Dan Wing 'cos he gave us the idea. But it's a /= variant/ that doesn't reveal anything private.

I'm going offline, possibly until Tue now.

Regards


Bob



In fact, the server doesn't even need a small conn_id for clients that<= br> know they are not behind a NAT and that want more option space in the
D-SYN - then the server could use the src port & src IP for the conn_id= .

To summarise, these options could be distinguished by the length field
of the dual-syn option.
Length =3D 2B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D> conn_id =3D src netaddr + sr= c port
Length =3D 6B =3D 2B +4B conn_id_short =C2=A0 =C2=A0 =C2=A0=3D> conn_id = =3D src netaddr +
conn_id_short
Length =3D 8B =3D 2B +6B conn_id_long =C2=A0 =C2=A0 =C2=A0 =3D> conn_id = =3D hsb(src netaddr) +
conn_id_long

Given there have been numerous other attempts to reveal a connection ID
that is preserved through middleboxes [RFC6967], rather than defining a
dual-syn option that carries a conn_id, we might want to design a TCP
connection ID option with a flag to say whether it is also part of a
dual SYN pair or not.

Where
* hsb(src netaddr) is the netaddr with the lowest 16 bits truncated
* src netaddr is the network address (IPv4, IPv6, or any other network
protocol)

To reduce latency, a host could use the default short_conn_id for all
connections at first, then:
- if it finds that DSO persistently doesn't work it falls back to the long_conn_id for all connections
- it occasionally tests the short and zero options to see if it can use
shorter DSO options.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 - requires the ISNs to be related (see RFC6528 = - if there's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a rule to generate it, there will be code to va= lidate that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rule, and eventually a BCP to encourage that va= lidation -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 typically from the same RFC author)

Eh? The ISNs can and should be independent. To be robust against
middleboxes that rewrite sequence numbers, we must not required ISNs to
be related.


I agree that you have proposed potentially viable ways to deal with
the SYN cookie, and that RST state is not an issue.

A feature that I think it's fair to add:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Good chance of passing through app-laye= r middleboxes that
forward
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unrecognised TCP options unchanged, but n= ot those that discard
them.


However, there are too many problems with this, IMO, to call it viable.

Once your over-pessimistic analyses of the performance impact are
corrected, and my ideas to reduce the size of the conn_id are taken into account, it's a different story.

But it's up to the WG to decide whether this is worth taking further. Not just you or I.

Agreed.

Here's another trick that might clean up the above a little:

<snip - I'll respond separately to your later updates on this ASO id= ea,
with ACK=3D0>

Cheers


Bob


_____________________________________________________________= ___
Bob Briscoe, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BT

_____________________________________________________________= ___
Bob Briscoe, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BT

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

--001a11c1721ee1738204fdb6434c-- From nobody Tue Jul 8 16:17:59 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1483D1A017D for ; Tue, 8 Jul 2014 16:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_22=0.6, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_Surq8N_w9C for ; Tue, 8 Jul 2014 16:17:54 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849F41A0179 for ; Tue, 8 Jul 2014 16:17:54 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s68NH5Xd028911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 16:17:05 -0700 (PDT) Message-ID: <53BC7BF1.9040806@isi.edu> Date: Tue, 08 Jul 2014 16:17:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Duke , Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <201405311819.s4VIJt2V003823@bagheera.jungle.bt.co.uk> <538A2B96.3030900@isi.edu> <201405312234.s4VMYwGW004526@bagheera.jungle.bt.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0SGOZRyy6HjRiWwpR3zI_uD2Zag Cc: "tcpm@ietf.org" Subject: Re: [tcpm] More TCP option space on SYNs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 23:17:58 -0000 Hi, Martin, On 7/8/2014 3:39 PM, Martin Duke wrote: > Gentlemen, > > I think we're throwing out the idea of extended space on SYN a little > too quickly. Bob, Ted Faber, and I are working on a draft to do that which uses multiple segments, as has been noted on the list. > From the EDO draft: > > A new TCP option cannot extend the Data Offset of a TCP initial SYN. > All TCP segments, including the initial SYN, may include user data > in the payload data [RFC793 ], and this can be useful for some > > proposed features such as TCP Fast Open [Ch14 ]. Legacy endpoints > that ignore the new option would process the payload contents as > user data and send an ACK. Once ACK'd, this data cannot be removed > from the user stream. > > The TFO option issue seems addressable by specifying that if a SYN > contains both EDO and TFO Cookie, the TFO Cookie MUST be entirely in the > extended option space.* This eliminates the possibility that a server > with TFO but not EDO will misinterpret extended options as data. You have not addressed servers that support neither TFO nor EDO. They will silently ignore EDO and interpret the TFO cookie as user data - which cannot be undone. The only solution is to abort the connection, and that's thus not considered a viable backward-compatible approach. Approaches that are not backward compatible are trivial, but the cost of aborting undesired connections to legacy servers is considered unacceptable. > TFO aside, I hesitate to throw out EDO with SYN for the benefit of > listening TCP servers that accept unvalidated data appended to the SYN. > Even if technically permitted, this is obviously unsafe behavior in the > open internet -- or else no one would have invented TFO. You're confusing TFO with the validity of data in the initial SYN. TFO lets that data go to the application immediately, without needing to wait for the completion of the three-way handshake. However, data in the initial SYN has always been valid - it just waits for the handshake to complete to be passed to the user. Although many existing servers simply discard data in the initial SYN (to reduce the potential for a DOS attack), that's not a requirement, and there are lots of devices that aren't "servers" to the rest of the world but act like servers in the context of a TCP connection. Data in the initial SYN cannot be 'undone' - even if it's resent with different content (i.e., using the same sequence number), the receiver has no obligation to overwrite it. > Before > discarding the architecturally simple solution I would prefer to see (1) > evidence that real servers actually accept and deliver unvalidated data > attached to a SYN packet, The process works the other way around; the only way to deprecate an existing feature is to have evidence it's very widely NOT used and thus that deprecation would not cause harm. That's very difficult to do - it's not a matter of what the few main OS'es do, it depends on a lot of legacy equipment. > and (2) an argument that this is behavior that > the standard should support. See above; whether it should or not, you don't know that it doesn't. Joe > -Martin > > > * In principle, the TFO Cookie need only partially be in the > extendedspace, but this would offer less protection to servers that aren't > properly validating their TFO cookies. > > > > On Sat, May 31, 2014 at 3:34 PM, Bob Briscoe > wrote: > > Joe, > > > At 20:20 31/05/2014, Joe Touch wrote: > > Hi, Bob, > > On 5/31/2014 11:19 AM, Bob Briscoe wrote: > > Joe, > > Thx for consolidating this thread. I've given it a new > subject line. > > 1) You've silently made an important alteration to the proposed > protocol. You've put the extra-options directly in the TCP > option space > of the C-SYN, not within the payload. > > > I hadn't assumed that; I was describing only which SYN carried > which options, not where they were. As you do, I was assuming > the C-SYN options were in the data space. > > > OK. > > > > To be clear, in my variant - using data outside the sync'd > connection (with ACK clear), the option space is similarly in > the data portion of the 'extra' segment. > > > Yup, that was understood already. > > > > Yes, your altered proposal is cleaner. However, don't > imagine I didn't > think of this. I did and I deliberately didn't do it this > way.We have a > choice: > clean and vulnerable vs. messy but robust. > > I'm not wedded to using port 80 and http headers, but this > is perhaps > the most pragmatic approach. > > > That's fraught with a whole slew of other problems, notably the > middleboxes that currently try to translate, proxy, or otherwise > modify anything they see as port 80. > > Further, that would limit the number of pending connections. > > It will be really unorthodox to define such > a protocol I know. We would have to say something like > > "The dst port of the C-SYN MUST be 80, and the > payload MUST start > with the constant magic_token, where > magic_token = 'PUT / HTTP/1.1Connection : > DSO' > " > > I'm sorry if even thinking about this makes you feel dirty :| > > Other suggestions for inner protocols are welcome, including > tunnelled > protocols, as long as middleboxes widely forward them, given > their dst > port. > > > I don't see what this gets us other than potential interactions. > There's no reason to use HTTP to format TCP options, and it > would necessitate new encodings and new processing for existing > options that might end up in the extended space. > > > To be clear, I would put the general requirement as : > > " Pick a port number, then make sure the app-layer headers at > the start of the TCP payload appear valid for that port number, so > that middleboxes will forward it, then include the extra TCP options > as the body of this faked up app-layer protocol. > " > > Then the dilemma becomes: pick a number, any number as long as it's > 80. The alternative is often to be blocked. Particularly if you > connect from inside a company that has bought one of those myopic > Web gateways, or you connect to a cellular network, or... you just > connect to the Internet via a box from a vendor beginning with a > letter in the alphabet,... or a digit. > > > > 2) The main problem with your notation is it doesn't say > /where/ the > info is placed. > > > EDO says the options are at the head of the data segment, just > with a longer pointer - the same way as current options. > > For extending the SYN using a separate segment - whether a C-SYN > or unsync'd data segment - the data similarly comes at the head > of the data, just that there's no user data permitted after it. > > > I understood all this. I just meant that the notation you introduced > in your email didn't have the facility to specify at which layer > fields were placed. > > > > I've added notation as follows: > TCP(base header [TCP options [APP(header[payload])]]) > > And for the record I've made the if-else logic clearer. > > Where I've made more than clarifying edits inline, I've > described them > and tagged them with [BB]. > > At 21:34 30/05/2014, Joe Touch wrote: > > Hi, Bob, > > Let's get back to the core, in a simpler fashion, so > other can follow it. > > I stand by my "there's no way to extend the space in the > initial SYN", > but you've convinced me there *might* be a way to > provide extended > space that can occur during the first phase of the TWHS. > I think the > dual-SYN approach still isn't viable, but I've outlined > an alternative > below that's similar but doesn't have the same baggage, IMO. > > Again, I'm still concerned by what midboxes might do to > this... > > What do others think?? > > Joe > > For quick review, here's what I understand: > > dso = dual-syn option > dso-D = data > dso-C = control > conn_id = identifier to link the two > SYNs together > extra_opt = options that didn't fit in > legacy SYN > fit_opt = options that do fit in the > legacy SYN > > new client endpoint sends > TCP(port A SYN [dso-D(conn_id) + fit_opt] ) > TCP(port B SYN [dso-C [APP(headers [conn_id + > extra_opt] ) ] ] ) > > > IMO, the conn_ID in the C-SYN should similarly be in the regular > option space, but I don't think it matters. > > [BB]: i/APP(headers...)/ > > if (legacy server endpoint) { > sends back two > connections: > TCP(port A SYN-ACK [fit_opt] ) > TCP(port B SYN-ACK [??] ) > > (it's interpretation of > extra_opt) > > > I'm assuming EDO after the SYN, which means the SYN-ACK has as > much space as it wants for options, as would every other segment. > > new client > endpoint responds: > TCP(port A ACK) > (established) > TCP(port B RST) > > Notes about legacy servers: > - they do twice the > work on SYNs > - they might keep twice > the state > (if not using cookies) > - they might clean > state if the RST > is received, but that > state might > persist indefinitely > (until the next > connection, depending > on timeouts, etc.) > > ----- > > } elif (new server endpoint) { > sends back one > connection: > TCP(port A SYN-ACK [edo + > fit_opt + > extra_opt] ) > > [BB]: s/dso-d/edo/ > > > Sure. At this point we're basically in EDO-land. > > new client > endpoint responds: > TCP(port A ACK) > (established) > > > Notes: > - can stall when dso-D > SYN arrives > before dso-C SYN, up to > some limit > - twice the work on > SYNs (or more) > > } > > Here's what I was assuming, though admittedly it's not > documented (yet): > > - no significant impact on TCP connection rate for > legacy servers > > - no significant impact on TCP connection rate for > legacy clients > > - impact dominated by processing the extended > option space > for extended clients > > - impact dominated by processing the extended > option space > for extended servers > > - compatible with typical TCP processing > optimizations, > notably SYN cookies > you did provide a potential way forward > for these > > - capable of successfully traversing typical NATs > > Your approach has the following properties: > > > The 3 bullets below are not useful ways to describe > performance impact. > They selectively describe whichever gives the most > pessimistic picture > out of: > a) either the instantaneous performance change at the moment > of connection > b) or the worst-case long-run performance impact > > They don't describe the average long-run performance impact, > which is > important for sizing machines. > > Worse, the instantaneous performance impact is only > significant when a > machine's SYN processing time is large relative to the e2e > delay, which > would be a highly unusual scenario on public networks (even > in scenarios > such as intra-data-centre, it's hard to reduce e2e delay to > approach SYN > processing time, but you could for intra-machine connections). > > > SYN processing is a known load - and potential overload - on > machines. That's why it's reasonable to focus on it. > > > But we should primarily think in terms of SYN cookie processing for > legacy hosts, and the equivalent for upgraded hosts. We should > design thia as the norm, not the exception. Possibly the /only/ way > to implement this new form of SYN processing. > > Then, for the dual-SYN scheme, the upgraded host doesn't have a > normal SYN cookie processing load with a C-SYN, so we can no longer > rely on known-load formulae. > > > > - halves the server connection rate for updated > servers > from legacy clients when this option is in use > > > Eh? The long-run server connection rate will be fractionally > decreased > due to updated clients using extra options (which is your > third case > below), but the instantaneous server connection rate seen by > a legacy > client is unchanged, because it only sends one SYN. > > > Agreed. I was doing too many of these at once... > > - lowers (to some extent, if not halves) the client > connection rate of updated clients to all servers > when this option is in use > > - halves (roughly) the server rate for all servers > when this option is in use > > > Nope. All long-run server rates are reduced by 1/(1+e), > where e is the > fraction of connections using extra options. > > > the rate for connections when this option is in use is halved - > I didn't see that the sentence above could be parsed the other > way. the overall rate depends on the fraction of connections > using the option. > > It also: > > - doubles the number of SYNs in the network > > > Nope. The number of SYNs in the network is inflated by e > where e is the > fraction of connections using extra options. > > > You keep bringing this up - I don't like a solution that should > be used only a little. If it works, we should assume it works > everywhere all the time. > > > It doesn't make sense to predict that all connections will always > use MSS, timestamp, SACK, window-scale, MPTCP, TCP-AO, new option X, > new option y, etc etc. > > For a start, less than 1% of connections contain enough packets to > make MPTCP worth starting. > > The word option means optional. > > > - susceptible to lack of fate-sharing problems, > e.g., > if the two SYNs experience different firewall > configurations > > > Nope. It's fairer to say it's potentially susceptible to > second-order > fate-sharing problems like your firewall example (the > first-order fate > sharing problems have been addressed). > > > I have no idea why you think firewalls are a second-order > fate-sharing, or what that even means. Fate sharing means fate > is shared. When fate is not shared by the SYNs, this method has > problems. There's no mechanism to recover the missing D-SYN or > C-SYN. > > > What I mean by first-order fate-sharing problems is those obvious > cases (reordering, drop) that we have addressed by resynthesising > fate sharing. > > There is certainly a possibility that two SYNs between the same > endpoints will pass through different firewalls, but it is small in > the Internet as a whole. There is a further possibility that these > two firewalls will be configured differently, but it is small. There > is a further possibility that the differences in configuration will > be significant enough to distinguish the behaviour wrt the two SYNs, > but it is small. When three small probabilities are multiplied > together, you get a really small probability. This is what I call a > second-order fate-sharing problem. > > You must surely see that it is inconsistent to say: > * "this method has problems" about the DSO idea, based on such a > corner case > * "no problem with fate-sharing" about the ASO idea, when all you > mean is that the FBP will follow the same path as the SYN, and they > will therefore likely pass through the same devices. > > In the ASO proposal, splitting the options on a SYN over two > packets, one of which is considered invalid by TCP, will cause the > FBP to be discarded by numerous TCP normalisers and stateful > firewalls. That is a fate sharing problem of the first order. Likely > to be on a much larger scale than the 'second-order' firewall > problem above. > > > > - reduces the space available for fit_opt due > to the need > for the conn_id even in the fall-back D-SYN, > which means > less option space in the SYNs for fall-back > connections > > > Yup. > > > the conn_id which may need to be very large > because it > needs to be unique per source port and source > IP address > because that information is lost during NAT > translation > > > Given many NATs will typically make the src IPs of both SYNs > the same, I > suggest a larger conn_id should be a fall-back option for > the client, > not a default. > > > Multiple NATs are quite common - carrier grade NATs in the net, > and user NATs at the home WIFI point. > > Any multiple-NAT, or any path through even a single > carrier-grade NAT will end up potentially un-doing or over-doing > source IP overlap, creating false positives and false negatives > that break this mechanism. > > That's really the crux - fate sharing and the need to bind the > two SYNs - that make this untenable, IMO. > > Even if the src IPs of both SYNs are different once they > reach the > server, the high end bits will invariably be the same. > > > You can't know this - the two SYNs could have gone through > different numbers of NATs or different NATs entirely, so the > bits could change arbitrarily. > > > That's what 'invariably' means. I'm not claiming this works 100%. I > am saying I expect it to work sufficiently to be worth trying it out > to see if I'm right. If it doesn't work, on some paths, the > fall-back has been described - the client has to rely on the TCP > options it can fit in a single SYN. > > > > So the max size > of the contents of the DSO TCP option can be 6B, and the > server can take > the rest of conn_id from the higher bits of the src IP addr > of each SYN. > This is a variant of the idea in > __. > > > FWIW, you're now in the land where we would have to start > explaining the privacy and tracking implications of those bits. > I'd really like to avoid that. > > > Nope. I think you're reading this the wrong way round. I'm not > revealing private IDs in TCP option fields. I'm reducing the size of > the (random) conn_id in cases where the /public/ src port or the > upper bits of the /public/ src IP have sufficient entropy to be used > to construct the rest of the conn_id. > > I was acknowledging Dan Wing 'cos he gave us the idea. But it's a > /variant/ that doesn't reveal anything private. > > I'm going offline, possibly until Tue now. > > Regards > > > Bob > > > > In fact, the server doesn't even need a small conn_id for > clients that > know they are not behind a NAT and that want more option > space in the > D-SYN - then the server could use the src port & src IP for > the conn_id. > > To summarise, these options could be distinguished by the > length field > of the dual-syn option. > Length = 2B => conn_id = src > netaddr + src port > Length = 6B = 2B +4B conn_id_short => conn_id = src > netaddr + > conn_id_short > Length = 8B = 2B +6B conn_id_long => conn_id = hsb(src > netaddr) + > conn_id_long > > Given there have been numerous other attempts to reveal a > connection ID > that is preserved through middleboxes [RFC6967], rather than > defining a > dual-syn option that carries a conn_id, we might want to > design a TCP > connection ID option with a flag to say whether it is also > part of a > dual SYN pair or not. > > Where > * hsb(src netaddr) is the netaddr with the lowest 16 bits > truncated > * src netaddr is the network address (IPv4, IPv6, or any > other network > protocol) > > To reduce latency, a host could use the default > short_conn_id for all > connections at first, then: > - if it finds that DSO persistently doesn't work it falls > back to the > long_conn_id for all connections > - it occasionally tests the short and zero options to see if > it can use > shorter DSO options. > > > - requires the ISNs to be related (see RFC6528 > - if there's > a rule to generate it, there will be code to > validate that > rule, and eventually a BCP to encourage that > validation - > typically from the same RFC author) > > > Eh? The ISNs can and should be independent. To be robust against > middleboxes that rewrite sequence numbers, we must not > required ISNs to > be related. > > > I agree that you have proposed potentially viable ways > to deal with > the SYN cookie, and that RST state is not an issue. > > > A feature that I think it's fair to add: > - Good chance of passing through app-layer > middleboxes that > forward > unrecognised TCP options unchanged, but not those > that discard > them. > > > However, there are too many problems with this, IMO, to > call it viable. > > > Once your over-pessimistic analyses of the performance > impact are > corrected, and my ideas to reduce the size of the conn_id > are taken into > account, it's a different story. > > But it's up to the WG to decide whether this is worth taking > further. > Not just you or I. > > > Agreed. > > Here's another trick that might clean up the above a little: > > > this ASO idea, > with ACK=0> > > Cheers > > > Bob > > > ____________________________________________________________________ > Bob Briscoe, BT > > > ____________________________________________________________________ > Bob Briscoe, BT > > > _________________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/__listinfo/tcpm > > > From nobody Wed Jul 9 04:09:34 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AED1A03F1 for ; Wed, 9 Jul 2014 04:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHbIYt9rRJQ0 for ; Wed, 9 Jul 2014 04:09:27 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3801A03F2 for ; Wed, 9 Jul 2014 04:09:27 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B38B8C94BD; Wed, 9 Jul 2014 07:09:20 -0400 (EDT) Date: Wed, 9 Jul 2014 07:09:20 -0400 From: John Leslie To: Joe Touch Message-ID: <20140709110920.GC4461@verdi> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> <0C29294E-7C2D-4653-A706-DE5FF44EF4AF@quantum.com> <53BC25EB.8070301@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53BC25EB.8070301@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/QBelcxpfrGR0MW2vhPcY8l6k5s4 Cc: "tcpm@ietf.org" , David Borman Subject: Re: [tcpm] TCP reserved bits and793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 11:09:30 -0000 Joe Touch wrote: > > There are two interpretations of "Must be zero": > a) current implementations should drop segments with those bits set > > b) current implementations should ignore those bits Indeed, we must work around endpoints which do either of these. > It says "Must be zero." That can easily be interpreted as requiring that > when the bits are set the segment is invalid. But only so interpreted by an endpoint. No middlebox is entitled to do that. (Of course, a middlebox _is_ entitled to drop an IP packet for any reason whatsoever.) Our problem is that currently-deployed "middleboxes" do a bunch of things which really qualify as "damage". Accept that, but don't argue that it's a reasonable interpretation of 793. > Note that RFC793 doesn't define what to do when the Data Offset is > smaller than 5 - so does that mean you should be liberal and process > such segments, or drop them? That's a good question. Let me at least nibble around the edges. If the two endpoints have agreed on a meaning, of course the receiver should process it. If a receiver _hasn't_ agreed on a meaning, it should own up to having no clue whether there are any options and/or any data. If the checksum validates, it's probably time to give up and close the connection; otherwise it could discard the packet. If a middlebox sees Data Offset less than five, it similarly should probably admit it has no clue whether there are any options or any data. If all it wants to do is rewrite source IP and port, it should probably do that and pass everything else unchanged, adjusting the checksum. If a middlebox wants to do something with options or data, it probably needs to drop the packet -- because it can't do what it is designed to do. Now we get into the really messy area: if a middlebox sees that something like EDO has been negotiated (which _is_ possible when it intercepts in both directions), should it process according to that option? IMHO, there's no fully satisfactory answer to that. Myself, I'd prefer it didn't. A middlebox wanting to meddle that much should act as an endpoint. (But of course, we can't enforce that.) > I agree that "liberal" means that, in either case, you MUST NOT generate > a response segment, ICMP message, or user error. But it's not as clear > *from the current text*. > > The point of all this is that 793bis needs to be updated to make this > direct and explicit, though. Alas, that won't fix the problem. At best, it might change new middlebox designs. There's no way it could fix deployed middleboxes. (But it would _feel_ better to have an unambiguous statement that this is damage!) -- John Leslie From nobody Wed Jul 9 05:39:15 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560A11A04D2; Wed, 9 Jul 2014 05:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 170Qggc6jcTO; Wed, 9 Jul 2014 05:38:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE141A0527; Wed, 9 Jul 2014 05:38:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140709123859.28906.60683.idtracker@ietfa.amsl.com> Date: Wed, 09 Jul 2014 05:38:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/p_X7hG2ZDx0lPMhIawbIph4Dqjk Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (TCP Fast Open) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:39:06 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Fast Open' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jul 9 08:30:01 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0C31A0AF4 for ; Wed, 9 Jul 2014 08:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CITxyNdC2g8 for ; Wed, 9 Jul 2014 08:29:58 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E551A0AF2 for ; Wed, 9 Jul 2014 08:29:58 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s69FTSel022399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Jul 2014 08:29:33 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <20140709110920.GC4461@verdi> Date: Wed, 9 Jul 2014 08:29:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3124FE3C-F4D9-456F-A22E-B2B691388CDF@isi.edu> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B57D88.9090706@isi.edu> <6FC2D64C-65F7-423D-A3A2-35258796C3DA@netapp.com> <201407031843.s63IhNU2020277@bagheera.jungle.bt.co.uk> <53B5B96F.1020304@isi.edu> <0C29294E-7C2D-4653-A706-DE5FF44EF4AF@quantum.com> <53BC25EB.8070301@isi.edu> <20140709110920.GC4461@verdi> To: John Leslie X-Mailer: Apple Mail (2.1878.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/-LoyKc0qp5t5crpwU2t26qir-90 Cc: "tcpm@ietf.org" , David Borman Subject: Re: [tcpm] TCP reserved bits and793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:29:59 -0000 Hi, John, On Jul 9, 2014, at 4:09 AM, John Leslie wrote: > Joe Touch wrote: >>=20 >> There are two interpretations of "Must be zero": >> a) current implementations should drop segments with those bits set >>=20 >> b) current implementations should ignore those bits >=20 > Indeed, we must work around endpoints which do either of these. >=20 >> It says "Must be zero." That can easily be interpreted as requiring = that=20 >> when the bits are set the segment is invalid. >=20 > But only so interpreted by an endpoint. No middlebox is entitled to > do that. Right - my claim has always been that there are no such things as = middleboxes; there are hosts and there are routers. Routers ought to = look no further than L3; everything else is acting like a host, and = breaks what we expect when we think of an Internet. That's especially = true for boxes that modify L3 or L4 beyond what RFC1812 permits (HBH = options, hopcount, IP checksum). > (Of course, a middlebox _is_ entitled to drop an IP packet for any > reason whatsoever.) Anything that is visibly indistinguishable from a link is a link (or a = part of a link). The same applies to routers and hosts, to me at least. = Intent and mechanism aren't relevant; externally visible behavior is. > Our problem is that currently-deployed "middleboxes" do a bunch of > things which really qualify as "damage". Accept that, but don't argue > that it's a reasonable interpretation of 793. Agreed. >> Note that RFC793 doesn't define what to do when the Data Offset is=20 >> smaller than 5 - so does that mean you should be liberal and process=20= >> such segments, or drop them? >=20 > That's a good question. Let me at least nibble around the edges. >=20 > If the two endpoints have agreed on a meaning, of course the = receiver > should process it. That's true for any property. It doesn't mean they're running TCP = anymore, though. > If a receiver _hasn't_ agreed on a meaning, it should own up to > having no clue whether there are any options and/or any data. If > the checksum validates, it's probably time to give up and close the > connection; otherwise it could discard the packet. I don't think a single invalid segment should ever affect a connection = or connection in progress. I would say "silent drop" to any packet that = can't be understood. > If a middlebox sees Data Offset less than five, it similarly > should probably admit it has no clue whether there are any options > or any data. If all it wants to do is rewrite source IP and port, > it should probably do that and pass everything else unchanged, > adjusting the checksum. I disagree; a middlebox that modifies the IP address and/or TCP ports is = acting as a host to the downstream components, and should be expected to = follow host requirements. In this case, if a host MUST silently drop = nonsense packets then so should a box that looks like a host. > If a middlebox wants to do something with options or data, it > probably needs to drop the packet -- because it can't do what it is > designed to do. I think it has to have already dropped it. > Now we get into the really messy area: if a middlebox sees that > something like EDO has been negotiated (which _is_ possible when > it intercepts in both directions), should it process according to > that option? >=20 > IMHO, there's no fully satisfactory answer to that. Myself, I'd > prefer it didn't. A middlebox wanting to meddle that much should > act as an endpoint. (But of course, we can't enforce that.) See above; I've been saying as much for a long time. Actually NAT boxes = are a little more complex: - to the upstream (the devices "behind") them, they MUST act = like a router (including decreasing the hopcount, etc.) - to the downstream, they MUST act like a host So they get twice the requirements. >> I agree that "liberal" means that, in either case, you MUST NOT = generate=20 >> a response segment, ICMP message, or user error. But it's not as = clear=20 >> *from the current text*. >>=20 >> The point of all this is that 793bis needs to be updated to make this=20= >> direct and explicit, though. >=20 > Alas, that won't fix the problem. At best, it might change new > middlebox designs. There's no way it could fix deployed middleboxes. > (But it would _feel_ better to have an unambiguous statement that > this is damage!) Sometimes that's the best we can do; sometimes it's better to declare = what's deployed "broken" than to try to find a way to accommodate it. Joe= From nobody Wed Jul 9 10:42:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA741A8BB1 for ; Wed, 9 Jul 2014 10:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m85BpsEWGSKd for ; Wed, 9 Jul 2014 10:42:46 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C1A1D1AD6B0 for ; Wed, 9 Jul 2014 10:42:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id DE249C94BE; Wed, 9 Jul 2014 13:42:33 -0400 (EDT) Date: Wed, 9 Jul 2014 13:42:33 -0400 From: John Leslie To: tcpm@ietf.org Message-ID: <20140709174233.GD4461@verdi> References: <20140709123859.28906.60683.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140709123859.28906.60683.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/1vXItDC-_5CBSgJYDRZNbZi5VIw Subject: Re: [tcpm] Last Call: (TCP Fast Open) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 17:42:49 -0000 The IESG wrote: > > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > - 'TCP Fast Open' > as Experimental RFC Have we actually settled how this would interact with EDO? (Just asking...) -- John Leslie From nobody Wed Jul 9 11:26:49 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BAE1A038F for ; Wed, 9 Jul 2014 11:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vaq-IIjQcJn for ; Wed, 9 Jul 2014 11:26:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A05B1A0379 for ; Wed, 9 Jul 2014 11:26:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s69IQHIq002688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 Jul 2014 11:26:17 -0700 (PDT) Message-ID: <53BD8949.7030300@isi.edu> Date: Wed, 09 Jul 2014 11:26:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie , tcpm@ietf.org References: <20140709123859.28906.60683.idtracker@ietfa.amsl.com> <20140709174233.GD4461@verdi> In-Reply-To: <20140709174233.GD4461@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/-OeFPbsgD4skToOk5NrSLG-tnDk Subject: Re: [tcpm] Last Call: (TCP Fast Open) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 18:26:47 -0000 On 7/9/2014 10:42 AM, John Leslie wrote: > The IESG wrote: >> >> The IESG has received a request from the TCP Maintenance and Minor >> Extensions WG (tcpm) to consider the following document: >> - 'TCP Fast Open' >> as Experimental RFC > > Have we actually settled how this would interact with EDO? EDO currently does not change its behavior depending on other options. The only options that might require interpreting EDO would be TCP-AO (to include or omit options in the HMAC calculation) or any alternate checksums (there was one, but it's been obsoleted). Otherwise, I don't think there is - or should be - any interaction at all. The only proposal I saw to link them involved SYN-EDO, not EDO (i.e., to deal with the initial SYN). I already responded as to why I don't think the proposed approach is useful, but the SYN-EDO doc hasn't even been posted yet. Joe From nobody Thu Jul 10 01:43:15 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A651A02F7 for ; Thu, 10 Jul 2014 01:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FACzHMclkFV for ; Thu, 10 Jul 2014 01:43:11 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7B61A03A9 for ; Thu, 10 Jul 2014 01:43:11 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 019452B44C5; Thu, 10 Jul 2014 09:43:09 +0100 (BST) Received: from Gorrys-MacBook-Air.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id A3BD42B4271; Thu, 10 Jul 2014 09:43:06 +0100 (BST) Message-ID: <53BE521C.5090003@erg.abdn.ac.uk> Date: Thu, 10 Jul 2014 09:43:08 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ApsazcjfPkkL5hFh0CG4J-BGq8E Subject: [tcpm] WGLC for draft-ietf-tcpm-accecn-reqs (06) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 08:43:13 -0000 I have read this and previous versions of this document and think this is a useful document and the present document should be published. I'd finally note that I think this document clearly captures the scope of the planned work to define the new mechanism - I don't see a need for RFC2119 language to achieve this goal in this case. Detailed comments below. Gorry --- Datatracker link to the document is https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ --- Para 1, Section 1:: - This introduces the term "more accurate" in the first instance, perhaps the ID should clarify that it is "more accurate than the method proposed in RFC 3819" - to explain the "more". (I know it's also explained at the end, but this early explanation wouldn't be hard to add.) --- Section 1: /or document deviations./ - I think the meaning is that if an implementation does not adhere, it needs to document deviations, but this form of words (using "or") could be confused by a non-native reader. --- Section 1: / ECN feedback for SCTP [I-D.stewart-tsvwg-sctpecn] delivers a counter for the number of CE marked segments between CWR chunks, but also comes at the cost of increased overhead./ - Can we avoid endorsing this individual draft? I'm very supportive of the idea of adding ECN to SCTP, but the specific method proposed in sctpecn is technically only a proposal, and I think we should be careful not to endorse the method. Could this be written as: / ECN feedback for SCTP has been proposed in [I-D.stewart-tsvwg-sctpecn]. This delivers a counter for the number of CE marked segments between CWR chunks, but also comes at the cost of increased overhead./ - publication of the accecn draft may finally provide the environment in which SCTP ECN becomes important to progress? --- Last para, section 1: /simply called ACK/ ^ - insert /an/ --- Section 4: /Nagle's Algorithm/ - Insert (RFC896)? --- Section 4: /Given there are known problems with the ECN Nonce (as identified above)/ - Oh I've just seen an email from Bob (sorry) that I need to reply on-list about this, but if I understand correctly, the txt "above" in "(as identified above)" was removed to avoid a rathole that wasn't needed for this draft. Should the text in brackets be updated or removed? --- Section 5: /5. Design Approaches/ - Given an RFC lasts forever, it could be worth preceding the text in this section to say the information is intended as an input to future work in the IETF to standardise a method and that it does not endorse any of these methods! --- Section 5.2. Using Other Header Bits - It may be useful to note that assignment of the bits requires IETF action (again to prevent the text being cited in the future by someone wishing to advocat a new scheme). --- Section 8: /ECN feedback information should only be used if the other information contained in a received TCP segment indicates that the congestion was on-path/ - I agree in this addition, but I'm not sure what off-path congestion would be :-), maybe we could write something like: /ECN feedback information must only be used if the other information contained in a received TCP segment indicates that the segment was on-path/ --- You could consider refering (informative) to draft-welzl-ecn-benefits, in the introduction, esepecially if this ID happens to be adopted by a WG before accecn is published. --- From nobody Thu Jul 10 05:28:08 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC921B28C1 for ; Thu, 10 Jul 2014 05:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu9qQTtOXcTb for ; Thu, 10 Jul 2014 05:28:05 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id 275F91B28BE for ; Thu, 10 Jul 2014 05:28:05 -0700 (PDT) Received: from pasisarahtismbp.lan (80.223.92.46) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 53A17F6001A9BE29; Thu, 10 Jul 2014 15:28:03 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Pasi Sarolahti In-Reply-To: <9563_1404981809_53BE5230_9563_5892_4_53BE521C.5090003@erg.abdn.ac.uk> Date: Thu, 10 Jul 2014 15:28:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8ADA545F-C83D-4C27-8E01-F86085EC227F@iki.fi> References: <9563_1404981809_53BE5230_9563_5892_4_53BE521C.5090003@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nNXW7Y3CtWISq8zsPdpH4VZJRp8 Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-accecn-reqs (06) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:28:07 -0000 On 10 Jul 2014, at 11:43, Gorry Fairhurst wrote: > I have read this and previous versions of this document and think this = is a useful document and the present document should be published. Thanks! > I'd finally note that I think this document clearly captures the scope = of the planned work to define the new mechanism - I don't see a need for = RFC2119 language to achieve this goal in this case. Right. I didn't see any use of RFC2119 language in the document text, so = the boilerplate in the beginning of section 1.1 could be removed as = unnecessary. - Pasi From nobody Thu Jul 10 22:26:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1259E1A0AA6 for ; Thu, 10 Jul 2014 22:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMUY-SMiyqsv for ; Thu, 10 Jul 2014 22:26:46 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F901A0AA4 for ; Thu, 10 Jul 2014 22:26:46 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8BF9427819C for ; Fri, 11 Jul 2014 14:26:44 +0900 (JST) Received: by mail-qc0-f170.google.com with SMTP id c9so570890qcz.1 for ; Thu, 10 Jul 2014 22:26:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.95.215 with SMTP id i81mr80894177qge.6.1405056402646; Thu, 10 Jul 2014 22:26:42 -0700 (PDT) Received: by 10.96.201.133 with HTTP; Thu, 10 Jul 2014 22:26:42 -0700 (PDT) Date: Thu, 10 Jul 2014 22:26:42 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a11c15de6c514b304fde42f51 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uCwt45tpGOyNKE7TuhbTAzjCRyM Subject: [tcpm] a comment on draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 05:26:48 -0000 --001a11c15de6c514b304fde42f51 Content-Type: text/plain; charset=UTF-8 (as individual) Hi, I basically support this draft, but I am wondering how to react to EDO-unfriendly middleboxes. When we find EDO-unfriendly middleboxes by using TCP-AO or EDO-checksum, how we should react? Shall we terminate the connection? Or, is there any way to fallback safely? Or just re-transmit the segments? I think this point should be clarified in the draft. Thanks, -- Yoshi --001a11c15de6c514b304fde42f51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(as individual)
Hi,
I basically support this draft,= but I am wondering how to react to EDO-unfriendly middleboxes.
When we= find EDO-unfriendly middleboxes by using TCP-AO or EDO-checksum, how we sh= ould react? Shall we terminate the connection? Or, is there any way to fall= back safely? Or just re-transmit the segments? I think this point should be= clarified in the draft.

Thanks,
--
Yoshi

--001a11c15de6c514b304fde42f51-- From nobody Fri Jul 11 00:32:31 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6E01B27A2 for ; Fri, 11 Jul 2014 00:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHPGLTSEBZMn for ; Fri, 11 Jul 2014 00:32:27 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 127271A02ED for ; Fri, 11 Jul 2014 00:32:27 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 0B0B02B44C6; Fri, 11 Jul 2014 08:32:25 +0100 (BST) Received: from Gorry-2.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0104E2B40E1; Fri, 11 Jul 2014 08:32:23 +0100 (BST) Message-ID: <53BF9307.9080806@erg.abdn.ac.uk> Date: Fri, 11 Jul 2014 08:32:23 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <531AF534.6050209@erg.abdn.ac.uk> <201407031310.s63DAYvO019201@bagheera.jungle.bt.co.uk> In-Reply-To: <201407031310.s63DAYvO019201@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/GVN1949dOhxfoesYA_ivH2_BYog Cc: draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org, tcpm@ietf.org Subject: Re: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 07:32:29 -0000 Sorry for the long delay in response, please see below comments as an individual: On 03/07/2014 14:10, Bob Briscoe wrote: > Gorry, > > I wanted to respond to your dislike of our argument against the nonce > and a couple of other points... (sorry I didn't notice your email back > in March). > > We don't need to have this argument in the accecn-reqs doc, so we've > taken it out. But we do need to have the argument on the list. inline... > I saw this. > At 11:47 08/03/2014, Gorry Fairhurst wrote: >> Section 2: >> >> Disagree with text: "However, as the ECN Nonce is a separate extension >> to ECN, even if a sender tries to protect itself with the ECN Nonce, >> any receiver wishing to conceal marked packets only has to pretend not >> to support the ECN Nonce and simply does not provide any nonce sum >> feedback." >> - To me this argument is ridiculous (and I have said so), and I think >> we should not perpetuate this argument! >> [[Here is why: if a sender were to require a NS, then a receiver >> would need to provide that or expect the sender would not continue use >> of ECN, or at least limit is trust of ECN. So the wording could be >> improved, but RFC3540 says: "If the receiver has never sent a >> non-zero nonce sum, the sender can infer that the receiver does not >> understand the nonce, and rate limit the connection, place it in a >> lower-priority queue, or cease setting ECT in outgoing segments."]] >> - Saying the nonce sum has a second problem in that it only works if >> it is deployed and actually used seems obvious. > > I believe our argument is correct. > > 1) First, let's allow an assumption that the nonce is only for > protection against ECN cheating (it isn't)... > > One person saying they don't support the nonce is not a suspicious sign > of potential malice when a majority of users don't support it either, or > even a minority. > This is a deployment problem, not a protocol problem. If a sender accepts ECN feedback from a receiver that isn't NS capable, then it can not take advantage of the NS. You could be more conservative if you knew the NS was not implemented, or something else. > Here's a scenario: I'll be generous and assume that nonce support has > been deployed unilaterally by one (or two) large mobile device vendors. > Then imagine that you are running a Web server. Millions of clients ask > you for ECN TCP connections. You support ECN because you have determined > that it improves performance. You also want to get the client to use the > nonce if supported, so you set the flags accordingly. The client > responds with ECN support, but nonce sum =0. > > By your argument you (the server) decline to use ECN further or you > negate the performance benefits. Certainly you want to decline ECN for > the one or two malicious users who use the device from the above > vendor(s) but have hacked it to say it doesn't support the nonce. > However, you also cannot help but decline to use ECN (or negate any > performance benefits) for the millions of users who don't use those > devices that support it. Are you really likely to have gone to all the > hassle of deploying ECN then you decline to use it or you limit > performance for 99.999% of users because the other 0.001% might be > malicious? No. > > The whole point of the nonce is to identify precisely which users are > cheating. If you still have to use judgement and heuristics anyway, the > nonce is not a solution. > If implemented as a part of ECN support, I think the mechanism works - albeit you have to decide what to do about a client that chooses not to return a NS. > 2) Now, let's assume you are having trouble with clients mounting one of > the attacks described in RFC3540 that supresses loss feedback (not ECN). > > Any client that wants to mount these attacks just doesn't ask for ECN > support. What are you going to do as a server. Reset every connection > that doesn't ask for ECN? Again, you would have to punish large numbers > of your customers in case a few might be cheating. > > It's not helpful to say this argument is ridiculous. If I'm missing > something, please describe a believable scenario where the nonce would > be useful. > I see some (potentially useful outcomes, we could agree upon?: The problem that was intended to be addressed by the NS mechanism is a useful function that still should be addressed. The NS mechanism was not (widely) deployed. Other uses are permitted in the RFC-series, for ECT(1) - e.g. in combination with alternate DSCPs. Perhaps more important, there may be mechanisms that can be still deployed to achieve the same goals, but with a better overall characteristic. >> It speaks of [...] Conex (specified for a specific domain). > > I need to correct this misconception: ConEx is an e2e mechanism added to > IP using transport feedback of loss or ECN where available. ConEx > policing would certainly be applied in individual network domains, but > the ConEx signal is e2e and defined in updates to e2e transport specs > (starting with TCP). > I agree with what you say. >> Section 4: >> >> Usage of RFC 2119: Personally, I really do not like use of RFC2119 >> keywords in this way: "This leads to the following requirements, which >> MUST be discussed for any proposed more accurate ECN feedback scheme:" >> - Mandating discussion is not helpful. >> >> (point 2 above): If we have requirements as the title suggests, then I >> personally would encourage you to list them as requirements using RFC >> 2119 language - but I don't mind seeing no RFC 2119 keywords if the WG >> wants this, as long as I can see the relative importance of each >> topic. At the moment I can't see this. > > I recall that relative priority of requirements was already discussed in > tcpm, and the general opinion (I think) was that this would be hard to > do in abstract terms without a particular mechanism in mind that makes > particular trade-offs. I strongly support that view - otherwise we will > be having circular arguments for ever. > > I also think mandating discussion is helpful. accecn-reqs is a checklist > of things that need to be aired in any candidate spec. What's wrong with > that? > I read the latest version and said on-list that I *was* indeed happy with this aspect of the version being WGLC'ed. > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT Gorry From nobody Fri Jul 11 03:33:44 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D581F1B27FE for ; Fri, 11 Jul 2014 03:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN8AAMiDOgdD for ; Fri, 11 Jul 2014 03:33:40 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3432A1B27EF for ; Fri, 11 Jul 2014 03:33:40 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 11 Jul 2014 11:33:38 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 11 Jul 2014 11:33:35 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Fri, 11 Jul 2014 11:33:32 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6BAXTHT030093; Fri, 11 Jul 2014 11:33:29 +0100 Message-ID: <201407111033.s6BAXTHT030093@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Jul 2014 11:33:26 +0100 To: From: Bob Briscoe In-Reply-To: <53BE521C.5090003@erg.abdn.ac.uk> References: <53BE521C.5090003@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LGyMxHtuWkBULz4y_M0tcl5_EcA Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-accecn-reqs (06) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 10:33:43 -0000 Gorry, Thx. I agree with all your points and with your suggested rewording where provided. Assuming my co-authors also agree, we'll make sure your points get dealt with as soon as the WGLC ends. I've answered your questions inline... At 09:43 10/07/2014, Gorry Fairhurst wrote: >I have read this and previous versions of this document and think >this is a useful document and the present document should be published. > >I'd finally note that I think this document clearly captures the >scope of the planned work to define the new mechanism - I don't see >a need for RFC2119 language to achieve this goal in this case. > >Detailed comments below. > >Gorry > >--- >Datatracker link to the document is >https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ >--- >Para 1, Section 1:: >- This introduces the term "more accurate" in the first instance, >perhaps the ID should clarify that it is "more accurate than the >method proposed in RFC 3819" - to explain the "more". (I know it's >also explained at the end, but this early explanation wouldn't be hard to add.) >--- >Section 1: >/or document deviations./ >- I think the meaning is that if an implementation does not adhere, >it needs to document deviations, but this form of words (using >"or") could be confused by a non-native reader. >--- >Section 1: >/ ECN feedback for SCTP > [I-D.stewart-tsvwg-sctpecn] delivers a counter for the number of CE > marked segments between CWR chunks, but also comes at the cost of > increased overhead./ >- Can we avoid endorsing this individual draft? I'm very supportive >of the idea of adding ECN to SCTP, but the specific method proposed >in sctpecn is technically only a proposal, and I think we should be >careful not to endorse the method. Could this be written as: >/ ECN feedback for SCTP has been proposed in > [I-D.stewart-tsvwg-sctpecn]. This delivers a counter for the number > of CE > marked segments between CWR chunks, but also comes at the cost of > increased overhead./ >- publication of the accecn draft may finally provide the >environment in which SCTP ECN becomes important to progress? >--- >Last para, section 1: >/simply called ACK/ > ^ >- insert /an/ >--- >Section 4: >/Nagle's Algorithm/ >- Insert (RFC896)? >--- >Section 4: >/Given there are known problems with the ECN Nonce (as > identified above)/ >- Oh I've just seen an email from Bob (sorry) that I need to reply >on-list about this, but if I understand correctly, the txt "above" >in "(as identified above)" was removed to avoid a rathole that >wasn't needed for this draft. Should the text in brackets be updated >or removed? CURRENT: Given there are known problems with the ECN Nonce (as identified above), SUGGESTED: Given there are known problems with ECN Nonce deployment (as identified above), Also, on reflection, CURRENT: this document only requires that the integrity of the more accurate ECN feedback can be assured as an inherent part of the new more accurate ECN feedback protocol; SUGGESTED: this document only requires that the integrity of the more accurate ECN feedback protocol can be assured; REASONING: Integrity protection could be provided by an independent generic approach (e.g. draft-moncaster-tcpm-rcv-cheat); it doesn't have to be an inherent part of the AccECN protocol. >--- >Section 5: >/5. Design Approaches/ >- Given an RFC lasts forever, it could be worth preceding the text >in this section to say the information is intended as an input to >future work in the IETF to standardise a method and that it does not >endorse any of these methods! >--- >Section 5.2. Using Other Header Bits >- It may be useful to note that assignment of the bits requires IETF >action (again to prevent the text being cited in the future by >someone wishing to advocat a new scheme). >--- >Section 8: >/ECN feedback information should only be used if the other information >contained in a received TCP segment indicates that the congestion was >on-path/ >- I agree in this addition, but I'm not sure what off-path >congestion would be :-), maybe we could write something like: >/ECN feedback information must only be used if the other information >contained in a received TCP segment indicates that the segment was >on-path/ SUGGESTED: ECN feedback information should only be used if the other information contained in a received TCP segment indicates that it was genuinely part of the flow and not spoofed - i.e. [...] >--- >You could consider refering (informative) to >draft-welzl-ecn-benefits, in the introduction, esepecially if this >ID happens to be adopted by a WG before accecn is published. >--- Thx Bob >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm ________________________________________________________________ Bob Briscoe, BT From nobody Fri Jul 11 03:35:58 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663CB1B280A for ; Fri, 11 Jul 2014 03:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtPyjzEm6J8I for ; Fri, 11 Jul 2014 03:35:54 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id BA99F1B27EF for ; Fri, 11 Jul 2014 03:35:53 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7DC0E2B40E1; Fri, 11 Jul 2014 11:35:52 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 11 Jul 2014 11:35:52 +0100 Message-ID: <2a497be2e3269f05c5402ca2f074ab09.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <201407111033.s6BAXTHT030093@bagheera.jungle.bt.co.uk> References: <53BE521C.5090003@erg.abdn.ac.uk> <201407111033.s6BAXTHT030093@bagheera.jungle.bt.co.uk> Date: Fri, 11 Jul 2014 11:35:52 +0100 From: gorry@erg.abdn.ac.uk To: "Bob Briscoe" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9I39nFgZwowqyfUz-VeTu6sC8eU Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-accecn-reqs (06) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 10:35:57 -0000 These changes work for me. Gorry > Gorry, > > Thx. I agree with all your points and with your suggested rewording > where provided. Assuming my co-authors also agree, we'll make sure > your points get dealt with as soon as the WGLC ends. > > I've answered your questions inline... > > At 09:43 10/07/2014, Gorry Fairhurst wrote: > >>I have read this and previous versions of this document and think >>this is a useful document and the present document should be published. >> >>I'd finally note that I think this document clearly captures the >>scope of the planned work to define the new mechanism - I don't see >>a need for RFC2119 language to achieve this goal in this case. >> >>Detailed comments below. >> >>Gorry >> >>--- >>Datatracker link to the document is >>https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ >>--- >>Para 1, Section 1:: >>- This introduces the term "more accurate" in the first instance, >>perhaps the ID should clarify that it is "more accurate than the >>method proposed in RFC 3819" - to explain the "more". (I know it's >>also explained at the end, but this early explanation wouldn't be hard to >> add.) >>--- >>Section 1: >>/or document deviations./ >>- I think the meaning is that if an implementation does not adhere, >>it needs to document deviations, but this form of words (using >>"or") could be confused by a non-native reader. >>--- >>Section 1: >>/ ECN feedback for SCTP >> [I-D.stewart-tsvwg-sctpecn] delivers a counter for the number of CE >> marked segments between CWR chunks, but also comes at the cost of >> increased overhead./ >>- Can we avoid endorsing this individual draft? I'm very supportive >>of the idea of adding ECN to SCTP, but the specific method proposed >>in sctpecn is technically only a proposal, and I think we should be >>careful not to endorse the method. Could this be written as: >>/ ECN feedback for SCTP has been proposed in >> [I-D.stewart-tsvwg-sctpecn]. This delivers a counter for the number >> of CE >> marked segments between CWR chunks, but also comes at the cost of >> increased overhead./ >>- publication of the accecn draft may finally provide the >>environment in which SCTP ECN becomes important to progress? >>--- >>Last para, section 1: >>/simply called ACK/ >> ^ >>- insert /an/ >>--- >>Section 4: >>/Nagle's Algorithm/ >>- Insert (RFC896)? >>--- >>Section 4: >>/Given there are known problems with the ECN Nonce (as >> identified above)/ >>- Oh I've just seen an email from Bob (sorry) that I need to reply >>on-list about this, but if I understand correctly, the txt "above" >>in "(as identified above)" was removed to avoid a rathole that >>wasn't needed for this draft. Should the text in brackets be updated >>or removed? > > CURRENT: > Given there are known problems with the ECN Nonce (as > identified above), > SUGGESTED: > Given there are known problems with ECN Nonce deployment (as > identified above), > > Also, on reflection, > > CURRENT: > this document only requires that the > integrity of the more accurate ECN feedback can be assured as > an inherent part of the new more accurate ECN feedback > protocol; > SUGGESTED: > this document only requires that the > integrity of the more accurate ECN feedback protocol can > be assured; > REASONING: > Integrity protection could be provided by an independent generic > approach (e.g. draft-moncaster-tcpm-rcv-cheat); it doesn't have to be > an inherent part of the AccECN protocol. > >>--- >>Section 5: >>/5. Design Approaches/ >>- Given an RFC lasts forever, it could be worth preceding the text >>in this section to say the information is intended as an input to >>future work in the IETF to standardise a method and that it does not >>endorse any of these methods! >>--- >>Section 5.2. Using Other Header Bits >>- It may be useful to note that assignment of the bits requires IETF >>action (again to prevent the text being cited in the future by >>someone wishing to advocat a new scheme). >>--- >>Section 8: >>/ECN feedback information should only be used if the other information >>contained in a received TCP segment indicates that the congestion was >>on-path/ >>- I agree in this addition, but I'm not sure what off-path >>congestion would be :-), maybe we could write something like: >>/ECN feedback information must only be used if the other information >>contained in a received TCP segment indicates that the segment was >>on-path/ > > SUGGESTED: > ECN feedback information should only be used if the other information > contained in a received TCP segment indicates that it was genuinely > part of the flow and not spoofed - i.e. [...] > >>--- >>You could consider refering (informative) to >>draft-welzl-ecn-benefits, in the introduction, esepecially if this >>ID happens to be adopted by a WG before accecn is published. >>--- > > Thx > > > Bob > > >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www.ietf.org/mailman/listinfo/tcpm > > ________________________________________________________________ > Bob Briscoe, BT > From nobody Fri Jul 11 03:36:56 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E42F1B2840 for ; Fri, 11 Jul 2014 03:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvmb-TRoNL1b for ; Fri, 11 Jul 2014 03:36:51 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6C91B282C for ; Fri, 11 Jul 2014 03:36:51 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 11 Jul 2014 11:36:50 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 11 Jul 2014 11:36:48 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Fri, 11 Jul 2014 11:36:47 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6BAalKM030112; Fri, 11 Jul 2014 11:36:47 +0100 Message-ID: <201407111036.s6BAalKM030112@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Jul 2014 11:36:46 +0100 To: Pasi Sarolahti From: Bob Briscoe In-Reply-To: <8ADA545F-C83D-4C27-8E01-F86085EC227F@iki.fi> References: <9563_1404981809_53BE5230_9563_5892_4_53BE521C.5090003@erg.abdn.ac.uk> <8ADA545F-C83D-4C27-8E01-F86085EC227F@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/PpbZhPKvl1ey3TjwmcqfXFr52jQ Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-accecn-reqs (06) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 10:36:53 -0000 Pasi, You're right. We'll remove the 2119 boilerplate text. Bob At 13:28 10/07/2014, Pasi Sarolahti wrote: >On 10 Jul 2014, at 11:43, Gorry Fairhurst wrote: > > > I'd finally note that I think this document clearly captures the > scope of the planned work to define the new mechanism - I don't see > a need for RFC2119 language to achieve this goal in this case. > >Right. I didn't see any use of RFC2119 language in the document >text, so the boilerplate in the beginning of section 1.1 could be >removed as unnecessary. > >- Pasi > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm ________________________________________________________________ Bob Briscoe, BT From nobody Fri Jul 11 03:51:20 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6241B2840 for ; Fri, 11 Jul 2014 03:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH04__4z_wnS for ; Fri, 11 Jul 2014 03:51:15 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D7B1B284B for ; Fri, 11 Jul 2014 03:51:14 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 11 Jul 2014 11:51:13 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 11 Jul 2014 11:51:11 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Fri, 11 Jul 2014 11:51:07 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6BAp6va030163; Fri, 11 Jul 2014 11:51:06 +0100 Message-ID: <201407111051.s6BAp6va030163@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Jul 2014 11:51:05 +0100 To: tcpm IETF list From: Bob Briscoe In-Reply-To: <20140703154625.7093.69881.idtracker@ietfa.amsl.com> References: <20140703154625.7093.69881.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/gH8SfbPiNRnaHHaFu2pQpHB2MSM Subject: [tcpm] Questions for TCP experts regarding draft-kuehlewind-tcpm-accurate-ecn-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 10:51:18 -0000 TCPM folks, We are hoping draft-kuehlewind-tcpm-accurate-ecn this will be adopted as a candidate solution to the chartered requirements currently in WGLC . draft-kuehlewind-tcpm-accurate-ecn-03 is a major revision (from 14pp to 55pp!). It is an extremely interesting exercise in middlebox traversal. It also fits as much feedback information as possible in zero extra bits :| We had a number of alternative design choices. We'd like the opinion of the TCP experts in the WG on whether we chose the right set. Appendix B lists alternatives that we did not include, but the WG might disagree: Appendix C enumerates open design issues: A couple (1 & 5) are very thought-provoking. Bob At 16:46 03/07/2014, internet-drafts@ietf.org wrote: >A new version of I-D, draft-kuehlewind-tcpm-accurate-ecn-03.txt >has been successfully submitted by Bob Briscoe and posted to the >IETF repository. > >Name: draft-kuehlewind-tcpm-accurate-ecn >Revision: 03 >Title: More Accurate ECN Feedback in TCP >Document date: 2014-07-02 >Group: Individual Submission >Pages: 55 >URL: >http://www.ietf.org/internet-drafts/draft-kuehlewind-tcpm-accurate-ecn-03.txt >Status: >https://datatracker.ietf.org/doc/draft-kuehlewind-tcpm-accurate-ecn/ >Htmlized: >http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-kuehlewind-tcpm-accurate-ecn-03 > >Abstract: > Explicit Congestion Notification (ECN) is a mechanism where network > nodes can mark IP packets instead of dropping them to indicate > incipient congestion to the end-points. Receivers with an ECN- > capable transport protocol feed back this information to the sender. > ECN is specified for TCP in such a way that only one feedback signal > can be transmitted per Round-Trip Time (RTT). Recently, new TCP > mechanisms like Congestion Exposure (ConEx) or Data Center TCP > (DCTCP) need more accurate ECN feedback information whenever more > than one marking is received in one RTT. This document specifies an > experimental scheme to provide more than one feedback signal per RTT > in the TCP header. Given TCP header space is scarce, it overloads > the three existing ECN-related flags in the TCP header. Also, to > improve robustness it uses 15 more bits if available. For initial > experiments it places these in a TCP option. However, if the Urgent > flag is cleared, zero header overhead could be achieved by reusing > the Urgent Pointer opportunistically. Therefore this document > reserves space in the Urgent Pointer to be used if the protocol > progresses to the standards track. > > > > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat ________________________________________________________________ Bob Briscoe, BT From nobody Fri Jul 11 06:12:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821751B27F3 for ; Fri, 11 Jul 2014 06:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oWZblQfPNN7 for ; Fri, 11 Jul 2014 06:12:46 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 306BD1B27AB for ; Fri, 11 Jul 2014 06:12:43 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 59FD42B40E1; Fri, 11 Jul 2014 14:12:42 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 11 Jul 2014 14:12:42 +0100 Message-ID: <2a0b3dd1a9d78db4bf7f9bec9eb76514.squirrel@www.erg.abdn.ac.uk> Date: Fri, 11 Jul 2014 14:12:42 +0100 From: gorry@erg.abdn.ac.uk To: michawe@ifi.uio.no User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20140711141242_74262" X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/WFm0JHIj-D3HVOmxBFz3Cw4bHyo Cc: tcpm@ietf.org Subject: [tcpm] Our ECN slides for tsvwg? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 13:12:48 -0000 ------=_20140711141242_74262 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit We agreed to a 3-minute talk in tsvwg to make sure people have seen this. Would these slides work for us? Gorry ------=_20140711141242_74262 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="ECN-motivation-slides-jul2014.pptx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ECN-motivation-slides-jul2014.pptx" UEsDBBQABgAIAAAAIQDPvu+q6wEAAEEOAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM l9ty2jAQhu8zk3fw6DaDZdLm0A4mFz1cNQ0zJA+g2AuolSWNtNDw9l3bhHgYGtdgD76BkcXu/+1v vNaO7l4yFazAeWl0zIZhxALQiUmlnsfs6fH74JYFHoVOhTIaYrYGz+7G52ejx7UFH1C09jFbINrP nPtkAZnwobGgaWdmXCaQlm7OrUh+iznwyyi65onRCBoHmOdg49FXmImlwuDbC10uSSicBV/K3+VS MRPWKpkIJFCe7/K9cb8szHcCZZYLFxv7Y56l3gmpaq10ulPQwMxmMoHUJMuMygitA0/fBVqmaCmp PDcFRHLR/wPUgfLNVG1pYUiRhZRfSOsvNlY80D10MoVgIhz+FBkZxq1FXmUL3zf1gELf6g4zIXUd jFdEeC88ueN5ZTFsm6yS+7+YNjTdcDQhuOzEiSYEH05O8PEkBPmDMnHG+rbVt4nr7sJKwp9OCLaJ 6wiQ2jfw4vP4R6FIU6sonhVMca2gdd/xLXUdRdEufoi1WeKmE5SL402otl96NVSEDmXqpkOU9R7K 1E3POI6pmy5yHNNV272lhf/TdQ+ZbnrIdNtDpk89ZBpGfYQ6VSenGaF4pdPI46C5Ma9H/jx6YOl0 Ag4lvHvo3yrSDNNccGeygXwgSyHdo82LAXD8FwAA//8DAFBLAwQUAAYACAAAACEAo+yCJg0BAADi AgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySwU7DMAyG70i8Q+T7mm4ghNDSXRDSbgiVBzCJ2wba JEo8tL09YYeVSqOaBMfY8Z/vz+/1Zj/04pNist4pWBYlCHLaG+taBa/10+IeRGJ0BnvvSMGBEmyq 66v1C/XIeSh1NiSRVVxS0DGHBymT7mjAVPhALncaHwfkfIytDKg/sCW5Kss7GX9qQDXRFFujIG7N DYj6EPLLf9GWAzEaZJTaR1qEmMki2+xF1BhbYgXG6+dcTscbRaYGeR7o9nIg3zRW06PXu4Ecn/Es ac/kDJl5JAxhjmj5n0RT5vF/QmAZIqVs5Jj7HNDqcqDf92HMjLvd8ObQ9iPNKa1Tr3gP1H5nJieb WX0BAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTEueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6 nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hy jt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5POb CsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAA ADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9 iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0Izugt DsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0Hwx xdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA //8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUz LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiP g3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLL EMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8 c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAA AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgie RD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgO zXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sG cZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsD BBQABgAIAAAAIQA07v1tSgEAAAIGAAAfAAgBcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVs cyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyUz27CMAzG75P2DlXua2hh7I8o XKZJHCZNgz1AaE0brU2ixGPj7WcVBKWC7BJxieQvifOTY3+T2W9TRxuwTmqVsSQesAhUrgupyox9 Ll/vHlnkUKhC1FpBxrbg2Gx6ezP5gFogXXKVNC6iLMplrEI0z5y7vIJGuFgbULSz1rYRSKEtuRH5 lyiBp4PBmNtuDjY9yRnNi4zZeTFk0XJr6OX/c+v1WubwovPvBhSeeYK7WhZACYUtATPWhm6npjGR Mn4eYnQliKEP4v5KECMfxDgkhLFSIdgFIFK/uePH9DZ4L07ilVSX/uohLCG4d6vNCdte8pWJpiZc 124k/PQgDpIP4ikkBNJId0anDXm7Jj6GhAwlXCVQrGpY4LYmFzpMcUf0koQEaZ3jTTjq3iNIR9yb yu6Et0BpcKwe0B7lAMFPnHv6BwAA//8DAFBLAwQUAAYACAAAACEA6Bn0pWMCAAD5DAAAFAAAAHBw dC9wcmVzZW50YXRpb24ueG1s7JbratswFMe/D/YORl9H6kt8J05hG4FCBmFJH0C1TxJTWTaSkiV9 +h3Jau0lDPoA/mbp6Nx++kvW4vHSMOcMQtYtL4j/4BEHeNlWNT8U5Hm3mqXEkYryirKWQ0GuIMnj 8uuXRZd3AiRwRRW6OhiGy5wW5KhUl7uuLI/QUPnQdsDRtm9FQxUOxcGtBP2D4RvmBp4Xuw2tObH+ 4jP+7X5fl/CzLU8Npu+DCGCmDnmsO/kerftMtHEX/5Yk6Rm2pxcJatVyJZEOWWLbklW/qFQgnqq1 VDczTl0VJPDDJEznWYQwRa5ncK1P3OXC/Y/7ONRT1QeJ4pF3oL2N84c5GZnn92bct4/c4b05G5mj obRxIds3p7wUJPPD0POwlfJakDiNUjNQ1w7VIEsBwMOLzc9bBdK6JZ7voV/vlgVZrAemiQr29MTU Di5qq64Mlgua49xmI+zX741wGNUCBD573prqxkvYmfkdrmmoWBcEU1B2QPEy4mCYHX3Zvr1XjU0q ZpYAXfPv4lVvIsZWNbdD9D5iKtTj5sRL1W+ySaarkBjJx4aJ8wpCnw9ULIqA5rJldbWqGTMDrXX4 wYRzpphNXfq9vlllsjqa256WyO5bw2dM6eZoDvTGALQ3lPLGUMoBB1aIkqK55aED4WcwoAmjRBc8 8TFQLJ/5wKeX9sTnzDQUyycc+PjzxI8nAelTpalYQNEIUBqk5nqYbiBNxQKKB0BBkKKApisIFaSp WEDJCFASzqc72vy4NBULKB0AaTrmHTEdMU3FAspGgOIomS5poyBNxTyy75+Y+PIev/SXfwEAAP// AwBQSwMEFAAGAAgAAAAhADYRi7yNAwAAJwwAABUAAABwcHQvc2xpZGVzL3NsaWRlMi54bWzMVlFu 2zgQ/d4F9g4Dfa8j23HTRIhd1E5SLJCmQZMegCZHFrEUSZC0Y6NYoHfoBXqWHqUn6ZCS0jpN0GTb IoUBWqKGjzNvhsN3+GxdK1ih89LocTbY6WeAmhsh9WKcvbk86e1n4APTgimjcZxt0GfPJn/9eWgL rwTQau0LNs6qEGyR555XWDO/Yyxq+lYaV7NAr26RC8euCLVW+bDf38trJnXWrnf3WW/KUnI8MnxZ ow4NiEPFAnnuK2l9h2bvg2YdeoJJq7dcmlBk/EKJ+O/tpUOMT3r1wtkLe+7S57PVuQMpiK8MNKuJ lixvP7Rm6VWTGT3kN5YvOiRWrEtXTw5ZQbHBepwR+Zs40iJW4DoAbyb5l1levbrFllfHt1jn3Qbk wfWmMaomom/DGXbhXMqgEAbXUTWmjJaeGv6vB20ozhh+Ex4/W3VgMeYIbysIG0vMhAjV2jUfEx+d vSdOE1lhPTViEwOf03+aZIXy4SJsFCZCyG1WEDgNRL9isUJR995cZCCkC4kj8HWYKWRUyy2NYXLk WBlgYZjyh0RJoIy0OKjFOXPs9Z1wMTxW0Mbkc+cgPTYM3s3jbsfjzOhAVQbninGsjBLoYPhjrEpB NdER/xMIJf6hZu6UQAej3T6VoNSCfI4Epmwsz+jgt0TE3H43BylZYfIiEl7Axw9/bLHe8JlIpeFX bU7bwqd370G07QIW1G48mBKOZ2eP6ZDUXC0FelDoyZ/5Spqlb7x7TLdqtqG8J9dAoFVmE5sseI6a OWk8BANSqaUPjgWEOWosZfi5Ht//NP7q6qGK76V+UTxi6W5t/d1Dd1vjk4Hqn0pNmwAOuakppwIe htseZqY34MwyoMsJwxpJxfEwIEBH13xqXLEHz7FisfbdDZTfpwgAoAdfU3jD0/9xEwk6NBofSFyb AY1XUCOvmJa+3r7IfrSl/j6c70D8SQ2+Mi78fT+m5rGsQKbxWgi0rGUMXhJjJXpqYKRG2+ZGOjRe BNlWSu+66dOF3wlBUmWnniSETfps6Wjbt9Ppwd5wtj/tTQejk97o6OBp7/nJ3pPeyZPd0Wg23X8+ 2z3+jy5TOxgV3GHSnP902pkmv9GrteTOeFOGHTq0eSN8c2uu0KWTR9p30G8F9IqpcTbsH/RH/YP9 p0nzkL/kZdIsnbc01WlartxLZl+tUvmSVKcjPUtTlkgh1qLpF5MYO2nhzwAAAP//AwBQSwMEFAAG AAgAAAAhAC8x5Jz3AwAAUwwAABUAAABwcHQvc2xpZGVzL3NsaWRlMS54bWy0Vttu2zgQfW6B/gOh pxZYR5IlO4kRu7BdO+iiuWDtoM80RUdCKZIgacfuYoH9hP3G/ZIdUqLTKF5ADdIXXSjOcObM0Zm5 +LgrGdpSpQvBh0F8EgWIciKygt8Pg7vlvHMWIG0wzzATnA6DPdXBx9G7txdyoFmGwJrrAR4GuTFy EIaa5LTE+kRIyuHbWqgSG3hV92Gm8AN4LVnYjaJ+WOKCB7W9amMv1uuC0E+CbErKTeVEUYYNRK7z QmrvTbbxJhXV4MZZPwlpBJmRBcvsXculotQ+8e2lkgt5q9zn6+2tQkUGeAWI4xJgCcL6Q73NvXLY Bg9hw/zee8KD3VqVows8gNzQbhgA+Ht7BSM8oDuDSLVIHldJfnNkL8lnR3aH/gCI4HCozarK6Hk6 XZ/OsjCMoviQVbUVg+kXQb5pxAXkadOv0iPXW+/M5mzdyxyZvQRkiFHOW721+u4g8SYaYHV4md1E ZHub+wrubhEPmDYLs2fUYQKR4wH4hwtUgGFLUso7dwsg6fdhkACzApQVyjwCZkbLnKIJ5XRdGI2M QGMpWUEq3iCxRhsNtESznV0tDLoA2AxUzR/U9jSkSzNlFMNvVFfQjKaC31NtGYquhSmAwO7YF5/h QDCj97Pp9WuG+aHhbNUa4mbSgFpt3Ba2KiW4esDbH14Z/eR5zYhtsUGa1ubfv/9pwNAeBapAwkAM jlDggbLv7MWOjzj8RXFSwl85ylX9zzXctq9vE84DuSjPbrHCf7TTADAD3QDJ8foCj5UG/r8SJl4J F5uVcWLYfQ0x1JtVJYbQPUDavX7+MlFsSuFVQXJMWTv9ORijmt61+nxtzeiDh9oSvb/jhRs2zN4q 741m4sObJ/yoiuUq5gW4WeWm10uh1B7NcaHyjdLmTeOQ8YqqjFJ+9KCfY0XqWbGE5jwRO5Q8IQWy BPNltU3/sf3/2OusMjYaf7+bxNEpjFrQt3pnyWkvSq3nxyGgG6W9NIbz7Shw3k2SxPUYQMt7kpD6 JRUlsg/DQFFiAusBb79oUyml32KXuZgXjNl1+zNUPdv/H77/ogeFoctzGPwCpAybCmZ7mzXXcrwx 4KL2XPVr+6Ftu24W8TwyOfo8W87RFaUGGvLLadGg61IowYURT2jWllu/od83bI+6UZweC+g5fRyc fmoElgD4dhyyw9xGFcPgz8nkvN+dnk06kzidd9JP56ed8bzf68x7SZpOJ2fjaTL7CzCWcTogirp5 4bMftGHx2XBbFkQJLdbmhIgyrKbkUIoHqqQo3KAcR/W0vcVQwDiO+mmaJH3LMAgXQvN3Fyws+fmX MHWF5c3WNUIY6w1VU7ckoUCV9Q9bbOowN/8HAAD//wMAUEsDBBQABgAIAAAAIQCMyvJaIAQAAIkQ AAAVAAAAcHB0L3NsaWRlcy9zbGlkZTQueG1s3Fhdb9s2FH0fsP/A6WkD6sh23HwIsYPYTYoCSeo2 KfpMU9cWEYokSPoLw/77LinJgR01k1NjwPaiyBJ5dM/huZe8ubhc5YIswFiuZD/qHLUjApKplMtZ P/r2eNM6i4h1VKZUKAn9aA02uhz8+suFTqxICc6WNqH9KHNOJ3FsWQY5tUdKg8R3U2Vy6vCnmcWp oUtEzUXcbbdP4pxyGZXzTZP5ajrlDD4oNs9BugLEgKAOI7cZ17ZC003QtAGLMGH2VkgDZMYeROr/ Wv1oAPydXHw0+kGPTXh9vxgbwlPUKyKS5ihLFJcvymHhp8RheBPvTJ9VSDRZTU0+uKAJciOrfoTi r/0VJ9EEVo6w4iF7fsqyzzVjWXZdMzquPoARbD7qWRWMXtLpVnQeuRNAOhtWxVCKU28Ve7JEKuTp 6Rf02P2iAvOcPbzOiFtrVMZ5qHJc8TLoUY23qGkQy62GKl174hP8Gx7SRFj34NYCgiAYNk0QHC8o v6DeoSBb3x4iknLjgkbE5m4kgKKXSxnd4A6dRu7AWjqDC9TE4ZKUQCDTMTX06w/xPD+a4Jcx6CpC vC0k/LGQx5WQIyUd2oyMBWWQKZGCId2fk5WnaIpK+QMoigtAcmpuEbTTO26jB7lMMWavYFiO+T1m fimEX9w3LcIYlEZL2UzNsWzsLEP9ok5CfvFw3SxwcIIbMCWnfDY3QDJlna9Q3paNYHehsLY1m/ha PBLcUpknksICi1TDSGoB6xzsFBZlOkH9GjGsxS2Fux7dNwPZlalFJsDo3DaMYTO9jg93zWKoSeYl FwLt+gTEZbibNFT61Wgm4ByYRspucEo1f9uaVVSKUC7wsn9aNa9Gb//G/ql2pbXgLGyU3t4gcG83 ++pe6lWk/zuyzABTd0u8N1UVrazlmBfv9sQqw/FudoZKq5VxFh1FXZVoPk+eLY9e25dxne+fzbsf 9TLcAzv+jaItucMi3jCDNwlTJ4cu9gQJ4I+bBKucgaXhDgjV2v5fcutVCb4XdezJVzNL0vJwS/Ae vTmdi39ZhN1V+tmKVl9tNoqUvt4zeXeD9Ce6FvlkCZVrPKmQsFGimTIQGmUk1DjO5tgoeK2BzPA4 aC+3EvA/RHNEJVnCZgdEduT7R4I5k5Pf8Zi7ReufSyoYE45XNRuts4vlbE+4GhiiTFD96svdAYM7 RGR/HNYDzTfvl61E6CiqVhP7vluLPYoOHeDc4AH4z+Hw/KQ7Ohu2hp3eTav34fy0dXVz8r518/64 1xsNz65Gx9d/RTin00uYgbBZf6q6c3z4oiPOOTPKqqk7YiqPi9Y61moJRiseuutOu2zRF1T0o27n 9Pj0/KRzfla2chhlaIqqaJFC1TUzYe6o/rwIyY//DMDD1Sg80ljlMeX90Ochnjt2238DAAD//wMA UEsDBBQABgAIAAAAIQCfEb1eigUAADgZAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTMueG1szFnNbhs3 ED6nQN+B2FMLRNGPZVkWbAeWYiUBXMewnV6CHqhdSiLCJVmSki0UBfIIfYbe8xJ5lDxJP3J37aws x1r/xNVhJe2Sw5lvvhlyZndeXqSCzJmxXMndqPmiEREmY5VwOdmN3p8Na92IWEdlQoWSbDdaMBu9 3Pv5px3dsyIhmC1tj+5GU+d0r1638ZSl1L5Qmkk8GyuTUoe/ZlJPDD2H1FTUW41Gp55SLqN8vlln vhqPecxeqXiWMukyIYYJ6qC5nXJtC2l6HWnaMAsxYXZJpT1YFp+KxH9bfWYY87/k/LXRp/rYhMdH 82NDeAK8IiJpCliiev4gHxb+SgzDj/rS9EkhifYuxibd26E92EYudiOAv/BXTKI9duFInN2Mr+7G 03crxsbTgxWj68UC0OByUW9VZtF1c1qFOWfcCUaal1ZlQymmHqr4oyVSwU5vfmZefDQvhHmbvXg9 JW6hgYzzovJx2cOARzHeAtMAlrvoq2ThDR/hO9ykPWHdqVsIFgCB2rQH4bgAfkE9Q5msvT+NSMKN u8LI7R0MjghN5hQOnjBLLGMpUaM5VzP7bAewOHgllzW6XSKGZqOYTI6poSffWx6DoShsLAzCzwzx m3HfKHAfKOnASnIsaMymSiTMkNb9vMATcKhw1A0O8JguUbG9udXc3g58bHYaDYSsV+OKlVtbncZ2 aysinpvtLiI6GwHzM0nB7IwLBRKFa70cicywP3NqzJ3n0LePrjsdHCEpNYcwpNnewEKEywQ4+Vjx wkazIySnTE6I0Vt5QmzqBoJR5LxMhFWCJ0MuhJdnzWQ0EIbMqdiNhsMGPoHBeHI1DDqDh3642/v6 6V/iOQclER1cWsdoQtSYLJFtNddGIZHwcL1k8gNrmBilNdLvWgo9lhIeo1pMNR0hu2gaf2TOlhTK gidEEC6P6/VAZ7f3bH89J11iks8zLGYcG2fF2SW35qImgKGAozJ5lvUSSln4mThsxOTDyXDQ6nbb JZCrBUeu4x8lEU/hpzfqnAHvkh63mpJr//wBvKTGSM1kzM5JrCR2FX/uqCg218bHoq04dRVvPtwJ C1Bio9PerjZ31fIPS4lb99ZlFX4kB8OmcJX677hD9PnE86ai5++/9gRH7YqLlsC+vwYxlWTE7h44 99cABwYeh9P+ekis3JPvr8Y5d1M1W5MCK3V4YM8IZS3BXqaQWhelnPAj4ytPjASfkg435ffbkckl nrBkFrOEvMF57O6Sc2G1L5/V+Mvnr5/+OeSSkb5ALeS32rUEL+/TKI0rTix5PleJy5oyvkpwhkqr lfmxB6rCb9UQWGXIo3leGzWiIy64W6yH90pu5YbiRO94ytaO4GWn/3Jy9o4cXGhuFr+WC9EniLZn tfUAWTbC2xArIai2qK0rup4Zk5ejvm6Kz+V6Ybmsw3PiMymxfCI52kIo9MkIFVdFZb4tAouASlGX uJKcR3bN/ziGTlXK1sP0e0FDtRb53mtJotA8cthxQsJKuSPYgVxR/ZRwvyn5L3Ph6QPpbKFhoBBr ZphlA35Xb4+fo/BzzIB7KCrJnCdMVS5ayrFlGBU+Wd0JU5JQR58e2Bo5Yiy5a5JZtc/4886Xz1Pu G9zVkFklbb3gWPZ3yuIpldym5ebHrXxfpQF4EzIWGgjMhI5E1SyY558/Z9TvkSVMssx3vZcZentF axx96kOLhqoOHeuZQR/rr35/u9MadPu1frM9rLVfbW/V9oedzdpwc6PdHvS7+4ONg7/RutPNdi8G UX0t/bZ4m4Cb1zr4KY+NsijBX8QqrWevAuoaHQGjFQIHbwOajfyVQmjatZqtzWaj3e2Evl1QLTRl C2VhQdHkj4X5jep389Cbw7sLRCF6f7jl22UAxw+9GuJNx8uB/wAAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwu cmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK7 4DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhd SBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrK GqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhADTNuc4fAQAAxwcAACwAAABwcHQv c2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TV3WrDIBgG4PPB7kG+88WY tukPNT0Zg8KORncBEr/8sESD2rHc/aQwSGBzFAKeCBp8ffIe6PH01XfkE41tteLAkhQIqlLLVtUc 3i8vTzsg1gklRacVchjRwql4fDi+YSec32SbdrDEpyjLoXFuOFBqywZ7YRM9oPJfKm164fzU1HQQ 5YeokWZpmlMzzYBilknOkoM5S8aAXMbBH/1/uK6qtsRnXV57VO6XM6jtWomvYtRX52OFqdFxSJLp up1OGEv8DwD9w5YtaXO+NJypbiv0NoYdSzLurijU0KIF3SvLQrJVzM5WIdk6pmwdkm1iyjYhWR5T lodk25iybUjmb/Z4F+suJNvHlO1DMubfx3ilsfTHRmfPb/ENAAD//wMAUEsDBBQABgAIAAAAIQDZ 7MOHmAkAAGM3AAAhAAAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7FtrbuPIEf4f IHcgmJ8LrcSnKGHkhR+jyQDeiTH2HqBFtiyuKVIhW157gwBzltxi9zhzknzVD4rUwyvHY8dKPD9k qlld3V311bM17364m2fWLS+rtMhHtvN9z7Z4HhdJml+P7J+uxp3ItirB8oRlRc5H9j2v7B+O/vyn d4thlSU/skrw0gKPvBqykT0TYjHsdqt4xues+r5Y8BzvpkU5ZwJfy+tuUrJfwHuedd1eL+zOWZrb en65z/xiOk1jflbEyznPhWJS8owJ7L+apYvKcFvsw21R8gps5OzWlo5wvvgyS+jv5Fp9fuZTK03u IKVez7WP3rGhPCc/zUrrlmUje3Lt2N2jd12aAmL9RJOrxVXJOT3ltx/KxeXioqQv8afbixI8wdK2 cjaHfImBfKHJ5NccZIpxa/q14cSGd9NyTjuCeCzsEFq8p09MYkN+J6xYDcar0Xj2ty208ez9Fuqu WQBHqxelU6kTbR7HNce5SkXGrYuMxXxWZAmwIkUkT6imQYqL8yK+qay8wJlJFOqoEI5hTOenpRYz S9wvICVBbDWdeomd5TV9JeVrNl1LxQ/6AJ0Ujdv3Qy9qy6cf4i29Jyk5ju/RF9rLitGirMQHXswt ehjZJY+FBAK7Pa+EIjUkUvtqI4uhuDspkntSxgR/oXNYHObPivJX28o+5tXIHji+j7WF/CJ3altl 882k9UZkpwUghxksj8FnZMeilHvJi+OlKKap3o9akJbOKnEp7jMuQQHVsSGEig9sJ2Nk7jzvfDiB uc/FacYZ3IEGkDg6zdL4xhKFxZNUWNrqpRLgHMCSZCSkpCRLnicXrGSfm5x/urStJC2FQSBmYA9Q m5ENHhWgdsPKq2FFmG6iyiVFPRVVJCpbm/hTwOWEcBAKOyvra6HLj+D8DgFdBJAc7ntvSMHyrOxW IlPi7IkQIz1LhFUtiCnwSAThwywpPccjUH3J4yJPrIzf8mwP9hJjj2B/NUvL/bl7yhntLa9xsSzF bO/N+49ln063cgegn8m4+8a4P8Orwh8hboQtq5YW3gyFJjzscPeRH0TG36+FwjAKYIHK06vnJ3l6 xLAiS5NxmmVkMGtpgbiTyAFmW1RZroyLZuFoeE0j0guqaCdxTzRZXqceW/MOFsdIYhxbrj1jCVfp SCCjmWJdb0kvJNMTNpxi7Zq3ZkC52yqnMbwVG01PC/HpFHqqJ/fU6g9NrmfQ9GmRrybPU/iYbQwy nEqvrOiVgCjkkLs3oaMOq+X2sAgW28IfOQ6WXSPQUeyURDvArfbw6HiF3FlldStI978ZpAM/Cv31 KLMJbC0/kyCa9GSvDGYNsTWIFL7a0HjDtrSG/xtshwbbl/B83Pq0nE+Q3TdzsqAFdRLMf5Dpo8gE aySlv47svy9ZiXJTp2gyosFd7p//R4Hn9CMYJXLQIPSjQbgWFpRJqbDgDUIXCbmy/B3WMylZfMPF BUuV95JlAB30OtGGz5KfbWs6z1Abo0S0nP7AH2iemphSGV1VSC+VW7+g+hj0Au1RW4GlvJ7U1eZY /tPMGta3GUg23ORm9VFXHnhQVQceVMVBI3u4Vbn528xpO1UaTfiUKgHSoENRl8Ya+8WXPY+lGKkI plZSz7quIb6yrJlmiSyq/xG+d8/cE++kE0Xu+47fG3udY88dd8Kzs8AJB07Q8/1/ouaSNWVFOM6B NeLTKoqodNkoinBOGTHE0dcvv/3l65ffVxkk1iceO2LJk6ugwFjeuCio+9K0OWkUT62DpoiGWwxO Zqh/bHBWWaC0dVQxrbStuxL9IILQgSfYn9/zo/66/ble2Hcj9EKoAvfCQBMA0TsM8NUV4BISptAm EKAWapiEchNNg6AElejaBtFOoybXWxJICGVfe3guIPoGiGdMtJs8EipPhWEiFApnLJtqn6/k8Ic+ /yEIBo4XAGEAmBP6wcBdCwGu70XeYPC/C8FMwu2lIVi7ZM/tn4SOd9pxjs/6HX9w5sE5B2edcRj4 p8Hp2cnxcVi75AS4Eumcq8rkMT7Zcbq9PrrDjv9N3bKszlQrF4+mQRxn5Y9sYaH9O7KpYrHEHZ6S GzzBdGkM/VBUgTSGJ503j2yTQOsRvFcjNY1nRtD4Uq98MwLbUyOBGUFYUCOhGUGKNsvS/AaNRvqD RKTI/qoGzBOlD7KTf87ui6X4mKCPuTYiQ6nr+H0fhkGmUw6pY11+THQrFymamd2mxTlqWmm5rZXa tDhhTau9x06+OHtNqwPeTlpIpabVCelOWsirptWth5206FbUtLqm20mLjLOmlT3nB+QAz1PTykxx Ny2i54oWYXVdlS0Bhy3FmR57Y8ta8bOphUGk3LK3PEvQWMYyyAjk3wSRXS8k7i6pDK9kHU7tePl1 M+RlaPvy6RWbXCL/k01ulVBKfpyd5yclAIrd0R1Orr+CZIYWEC6KLpZ5jEV1b2IRn9C9ClUS8UUs VB1qknSM6beT5SdcVslY3HB0PnVcrRte0kWXbAzFDPcNOUgRaBbxyO7gZgc2yyoOK8E1gwrN2xs1 D4fsHT0f1QKBqFWeQCeW2ecU9yMj+7v5z51MkB6RPLK1F5ypF3G19iKu6MWudABNkoZycDOFHveG puasPEfC5bsDOn+aIw+GzDuuG0mRqR7J8ysSOsH66jBNZaLkkTpvZ0XK2Zn+0GSpqSbLMVpFDRkd lynD3hepiGdjNk8zyi3hQuIZKytuAI0W0vIUI3J4ZH/98i8l7gZ+XImZBn7kplr1WXuHCAPmNE0q CfTGBr+b57vUnnd2qD3vPKh2mXe6VIop1VKjKDo01Zqk9yVUS8BruobXqFrSJ+0LJYW3Ui1cVhDR zeFBma2qJaXRKeN+PrOVPYfXrltSqNat39CtG/VwmXhgulWNuZfR7XpIf412SwrVug0aug0CH9fA B6ZbmUIj13gBn+zQ5UbTbjcSs4d6Jv+N2Eva1YoOG4rue32vZcRO5Eak+be8SjWFD07RpF2t6H5D 0Wgm0ZXBKhIfgqJfMMvasOjX6K1JoVq30Uq3rtPzUDMemG5fMstaN+LXqFtSqNbtoKFbWeYemm5f Mss6BN2SQuWvQxodjsWwEDNe1v0OFPMXCgG6rK9/94grvrqJoknMzY2qoJ8lXDeaCwdRpdBNlraf RnPB/Kz226czhyaf7RW6aXq+yWdHlev16Rezz5EPHxqAdpSKsl54ExA88vYSSzWq3wQEAW0vTfDf HTzZvX7zQdvze5KOzHLeBLQ9SVa/xnkzMZhYnWk2k0v8HGB1I0o/EzD/Oe7o3wAAAP//AwBQSwME FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0OS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBv dpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnF ZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6d pTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc4SPwQrCMBBE 74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/h dj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTW VbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj 5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgA AAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54 bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrF kxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZI vjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSw mHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc4SPwQrCMBBE74L/EPZu 0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4 o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A 9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEA AP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxz L3NsaWRlTGF5b3V0NC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo 35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUW heJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQ zGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXR kvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVs c4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXU sgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPm IlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc 33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZe RPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a 3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZD OtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQ SwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0MTAueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB 4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQ c9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/ VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQAFd255yAMA ACQMAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbKxW247bNhB9L9B/INhn RRdL8gVrB77mJdksaqfvXIleCaFIlaRdu0WB/FbzOfmSDCnRu+t1UDvrF11nDmfOmRny5u2uYmhL pSoFH+LwTYAR5ZnIS/4wxJ9WC6+HkdKE54QJTod4TxV+O/r1l5t6oFj+nuzFRiPA4GpAhrjQuh74 vsoKWhH1RtSUw7+1kBXR8Cof/FySvwC7Yn4UBKlfkZLj1l+e4y/W6zKjM5FtKsp1AyIpIxriV0VZ K4dWn4NWS6oAxno/D0nva8gWiNGrUjM65vlqh5G1l1v4E+IRUJAtWY44qeDDH2BaZoQha4+AMbSi O23NVL2SlBoHvn0n62V9J6337fZOojI3aC0K9tsfrZl95WAGD/6R+4NDIoPdWlajGzIAdtBuiEHE vbmCExlAEChrPmaPX7Pi4wnbrJifsPbdAhDBYVHQv24yeplO5NI5IiU8pNf4EMB4L7LPCnEBCRse mjyz261DNcmbdeoCNZpoowdGQpagXCNR69WYWpqct7JUu/gPBKVp1I+DhqaoG6ed3nOuwm4Spea/ YSzpJWESJXYRhwSLNND1QO8mIt8bpu/hDoKaohliSkzyGAohKwSU9r17nGp4a7VhSi/1nlErFNBJ BpArXACFEdOBlHvvJtCBlZ4ySqBDW0c9mrIy+4y0QDQvNfpAlKYSWW6gXwHyBlTTUDQtJOX5HZHk 96fIn5YY5aXUrirAFmKA1FxKNktD/o+l7ryU2hTcHSMZLQTLIajIMAe94jT9KdUNt0eiQ+dAWbuS OV/8OOnC7LEtckr7NAj7vatob1V9KTGUJGJbdtDylZIbuq3i6pnkjZhWUbi4JS1bF1TZkmYCJhmj W8rOgLdSXwC/Kkp5PnqnadKz+VqIjdTF2cHHl8KX65PoMHJPN5uZbT/RYrFrsRnR9FlnWUJe21k5 DCn1N+yWhK1x21N2ythBaoavfXg6UW0/uyHh5t4Pqn0NO6TZ4v4Zjyf9JFn0vV44H3txd5p4vSDp e/15Mo0mcac77Qb/4nbI55CqLitqttmjeWim1ot5CAVu19ejMPSDLpwLwvixXiEGA3NdWRIny0II M3ufjjxbSq8VZq1lo8yfGyJhBSfO/0y8S8S5LiOpY2TJypyi2011f8SL3URfywucOwH6JDV2/ly5 btN5NIsmnYnX60VzLw4WHW/ciRZeOpslYdoPkyCOD3WrTOYcoru0bL99+e+3b1++XqFm7abdnDfh 0ZxQ7e7L5AdSf9za4Qlnc6inqf1Uw2kcSsaYPpoYDHe6H30HAAD//wMAUEsDBBQABgAIAAAAIQDS yA3SKAQAANARAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1s7FjLcts2FN13 pv+AYdcKHyIpiWMpEz2YTWJ7KuUDYBI02YAEC0CylE5n8lvt5+RLegESsiVLkZR41fFGD/Lg4N5z H7jk1dt1SdGKcFGwami5bxwLkSphaVHdD61Pi7jTt5CQuEoxZRUZWhsirLejX3+5qiNB0w94w5YS AUclIjy0cinryLZFkpMSizesJhXcyxgvsYS//N5OOX4A7pLanuOEdomLymrX83PWsywrEjJlybIk lWxIOKFYgv0iL2ph2Opz2GpOBNDo1bsmyU0N3soHdnP3h4U0jq/gimuNwPVkTlNU4RIuLB4YmrBK Ao2+JeoFJ0SBqtV7Xs/rW65XXK9uOSpSxdCutOz2RgvTfyuAwQ97b/m9YcLROuPl6ApHoARaDy0I 2EZ9wiIckbVESXMxebya5DcHsEk+O4C2zQZgwXZTiHXdePTcHc+4sygkJcjdetVAMSz9wJLPAlUM /FTuN+4l1ytDpnxW9HWOWtkVVYtrbmo9DF6AplosuR6zdKMcv4NvfRFHVMi53FCiBQGzcQTk8AHy U6yymlSd92PI6lJOKMGQ9a14cjShRfIZSYZIWkj0EQtJOJLaL6Eor0AdCcFpKUmV3mKOf3/K/Gmu 7cYR7AxGGwvhZyPhcSG7Rsg2m9AtxQnJGU3BCE+xQt4Z0S6UVXyBasA0syADIT1MDI5oq+TayzI/ 6EG96lRzg27oDrRBjwnXDYNeqAAq7fxg4Hj9fitEw6QFaMJsNDkYNbU3XVFXlw2OUpIpeZX9Xh/4 Ve7sAADrHcD6T7EGANjuAazzFGsAgPWfY90dGwwAsMEprAEANjyFNQDA9k5hDQCw/VNYAwDs4BS2 ASit23JSgdHVBCsRMGzL5ierS7UsXVxip7pg52Y3va/ZUifuBQU9JwmrUkTJitAz6NukPtujRV7w 89m7KnsvMD5mSy7zs433L6UvsoPsUNSH+xpKCy7NqdLE57IO53+vw2l1XqzD6UiCdRd0ON8d6A4G Hr62ONNmX1vcRSV7eIB4bXHHBq7/XYsLTIubYkl2Jjjdnn+8vzWDcSphbt2b5Zqh6Gir03Pjd0cu fSrpwzaDpxr1iPLXOJzNuo4z6YTxJOj48aTbeRe77zpOL5j5ceCEnjP922qn9RRclUVJ1KPR3pwN 0/DzORsGCL2lHLmu7fTgGc71Hw9nsEHRHDmDYOGPnDyhCUvMmJrpn47WgTo3fzYwmeRNZP5cYg47 mEH7xKStdz4zOC+rSM8oMqdFStD1srzb0yV8CV3gHQFQH5TmxBF9iTTbvA1n3tQbd8edft+bdXwn hrztenEnnE4DNxy4geP727wVyvMKrLs0bb99/ee3b1//fYGc1U9FzfsC+KneKuhUpPwjrm9Weg6F 9yiQTxN9qYY3J6oCAPoIURzmTczoPwAAAP//AwBQSwMEFAAGAAgAAAAhAJC23+lJAwAA6goAACEA AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWysVlty2jAU/e9M96Bxv11j80o8QCYY yE8eTCELUGwRu5ElVxIutNOZbKtdTlbSK9kiLzoDhR8/5Kuje889PlLvbJVTVBIhM876jv+54SDC Yp5k7L7v3M4n7omDpMIswZQz0nfWRDpng48fekUoaXKJ13ypEGAwGeK+kypVhJ4n45TkWH7mBWHw bcFFjhW8insvEfg7YOfUCxqNjpfjjDn1fLHLfL5YZDEZ8XiZE6YqEEEoVpC/TLNCWrRiF7RCEAkw ZvbrlNS6gGr53VcHmSBRwqvvDKDueEYTxHAOA/NMUYKAHRRxpgDJBMhiLgjRoay8EMWsmAoz77qc CpQlGqee73j1hzrMvDIIgwfvzfR7i4TD1ULkgx4OgQy06jvQs7W+wiQckpVCcTUYP4/G6c2W2Dgd b4n27AKQwWZRaHdRVfS+nMCWU9Hhb6qqQjFMveTxg0SMQ526/Kq8+Lq0YLpmDV+kqGJeaWbruOqj 4cPGS+DUkKVWQ56sdeF3cDeDOKRSzdSaEkMIpI1DAIcL0E+xFjZh7sUQhJ2riBIMwq/JU4OIZvED UhyRJFPoCktFBDLJwG8AkD1gR0FzakjCkikW+MtL5NuZyRuHsDIkbTOEx4rCfxPZtETWakJTimOS cppAEoFGBfVZ0vakNUtAFJb5IzAKDUC0pBvqDmRYy9YQLF8xDDyb/lUXu6QpY4+mzkjM4R+lpCR0 B3jD9B7w8zQTu6M3dR/3QJ/wpVDpzsm39oXPFlvRwUmOqu2W1fYIK/JK2IaQ/xd25ReJgt/5B3g+ pgsHTFaL3fzUxja0uRzkHwuwfO3cP/1oPOk0ukP3vNUdu60giNzT4Xji+vAUjYbdqB10fjm1iSVQ qspyovcN6Pgbk3hvP5WpaYPxfa/Rhd3Nbz3rFXLQMMdtS9u2ZcK5trqXjmOkdGhjFkpUnfm2xAJW sM05ohUdl5GOZWRGs4Sg62V+94aX9mFOXAkWTk8AvZUa4z9H1m1nHIyCYXPonpwEoNvGpOmeN4OJ 2xmN2n7n1G83Wq2NbqWunEF2+8r26fH3p6fHP0fQrNktq2MUPOojl9n8qLjCxU1pNhs4YYKeIjNU wJkSbFWHPodoDHtGHfwFAAD//wMAUEsDBBQABgAIAAAAIQCo0zlHkAQAADsRAAAhAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1szFjbkto4EH3fqv0HlfeZYBvfoAZSMAx5mUymwuQD hC0GV2TZawsWdmur8lu7n5Mv2e6WBcwlmdnJVIoXMHKrdfr0aanF2dttIdlG1E1eqqHjvXEdJlRa Zrm6HTqfbmadxGGN5irjslRi6OxE47wd/frLWTVoZHbJd+VaM/ChmgEfOiutq0G326QrUfDmTVkJ Be+WZV1wDT/r225W8z/AdyG7vutG3YLnymnn18+ZXy6XeSqmZbouhNLGSS0k14C/WeVVY71Vz/FW 1aIBNzT7LiS9qyBanWspHEZm9QYGPGcEkadzmTHFCxi4QQs2l3km6FVT3dRCoJHavKureXVd04yr zXXN8gw9tDOdbvuiNaOfCszgoXtv+q31xAfbZV2MzvgAiGDboQP52uEnTOIDsdUsNYPpYTRdfXjE Nl1dPGLdtQsAgv2ikOrKRPQwHN+GY4jw9lEZUw5TL8v0c8NUCXFi+Ca89GpjnWHM6L5aMcN6qmvy 1pqa90SJndIQrRbrnowoCRPXMOL13dCF5zu8xGHQIwNkxw/7vX4c0iLWEyxiXFcDvZ2U2Q5ZXcA3 JI+rdFWCRhfGp2z0XO8kpJoP5EZ6LaJMLD+CcfPn0IkiWJ9eK/xU5SyXEqOHCTTSlCAbHMTXVDPi XNZswyUob+u3yI6sYKbxb5zYVdHhERrIFR8Ao/ABSCTHShaq824ClVzocyk4VHrLjB6dyzz9zHTJ RJZr9p43WtRMk6objA/halqPXAqVXfOaY4x7z5/mDsvyWlvJwQzAAFxaDolWTPG3ddSzOpqvF2Z1 ih9qzQrlRVJq1gsjJag9KAyrvhdJKghj2LPuSSoKIi+OQHMoKc+NItSXSbKp1OdISpNMFGyT47Uu l7k2DozwMJHH6W3FxgpeX1L95yqDPYweubyF3Epyt1hfwY5N+j8SJUVAevuu+HCfg7znShs5xraY ILd7pZIqnpYn1YcP9dFCNjw67AFuqPvHkf8svAiS6N7I3gFv3wsCSOoJ4kWQLd7ggNfrxR5uPScI GFG2gMMjwImf0LZ8eopAlC3g6ADY9xMg+CQZRpQt4PgIcBz0oPJPURKIsgWcHAAj2hMtOkTZAu4f AY5COAZOkmFEaRqG120S4Gz9+X1CYPuEKdeCXUueilUpM+hZenjs/mi/kGlokqB3W3G5hGqhnsGc 59iRE4/4MCdKTbNIq9pOx3aLdOzaU5t+UFe2hHsDXgL+coPxLIiiWWcyHQedYOYlnf55POnMZu64 P/Ym7kXi/u20/XAGoeq8EOZQvtPUYev1oKkDcLSkHnle143hkuQFhzYOMKB8v9HIwcSXtG+hTcus LLGBPE5M8BqJWUJvQJn5fc1rWMEm54mODsI5tKFPJOd1GYksI3Q3ZFfrYnGPF7p6/Khg4RIOrh+l xlwgXle30YU/9Se9SSdJ/ItO4M56nXHPn3Wi6TT0or4XukGw122Dt2IF6FBv/0e2X7/889vXL/8+ V7PPunxQH27u5vCIN3jaLWT9nlcfNrSjw18WoCy4gsFQBX9SYC2A6cEEfdg/PUb/AQAA//8DAFBL AwQUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVM YXlvdXQxMS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj 7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz 3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39U KB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAGN8tZPQBQAA VRwAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54bWzsWd1y2kYUvu9M30GjXhOQ EAgY44wBk5vE8RTyAGtpMWpWWlVaCE6nM3mt9nHyJD3nrFYSGGKg7kwvuLGFdPbb8/vp6OzV200s rDXP8kgmQ9t507ItngQyjJLHof1pPm30bCtXLAmZkAkf2k88t99e//zTVTrIRfiePcmVsgAjyQds aC+VSgfNZh4seczyNzLlCTxbyCxmCn5mj80wY18AOxZNt9XqNmMWJXaxPjtmvVwsooBPZLCKeaI0 SMYFU6B/vozS3KClx6ClGc8BhlZvq6SeUrBWfZHzzfyL/Pjwm22RcLaG2459DfYHMxFaCYvhxljG KcuiXCb0JE/nGecok6zfZeksvc9owd36PrOiEAGKhXazeFCI0c8ExOCiubP80SCxwWaRxddXbADe sDZDG4L2hH9hERvwjbICfTOo7gbLj3tkg+XtHumm2QA0KDeFeKfaoufmuMaceaQEt5zSKi3KYOl7 GXzOrUSCnWi+Ni+4WxswtBnh06VVuB6hCjn9kPxh5HPwKTlLbUYyfELDH+A/3WQDkauZehIQArhe C4cCwAYhX/yqXVu7DdbWxcFINgBV4A8ESzCsA5403o2gDmI1FpxBnRSuVtdjEQWfLSUtHkbK+sBy xTNLkRdyVOAK0BWEsoDkSXjPMgZKVMifZmQlG8DOYKKxBy61ww+7vV26HWN+L1jAl1KEoIGLkJCh xr9nRQD9aUO6Qi6ZgB0IBHprJyW9jg8FTnnpdNodx2mjSlV2trsdv4sCmKPddt/vks711MMQoxXG IybCFkuCpQS2eLARMZE3KyUXkcKcMjL4oB7VIgmsmGXvqV6iJITCp0smHiGkgcoI7mF1B0RHuup0 sfKvQxtsAV0fdOmDN6WIwmkkBO5DbMfHIrPWTABnbIwlNSlQTKORjrWUhEsX7CwUM16rtMMNXlRJ W15Akelr0a5Q+47nofrHoDq90tASFaEKVK9Cddq+QxE8CpYkyX8lLGIVsJ0abM/tkQ7nwiJWAdut YF23Byoc64Q92iJWAevXYH2vTXl+rraIVcD2KljEPD5ke7RFrAK2X4M1RXeutoilM7hGsMSYuAkk YEmNtPv5DIqERgSabzEolNHJLOkZlhzLREHNbxElsdL5RInUsGRiUdCkLnx8bZOb8GJGHkMu1wE5 TJOu43s9v/MDmmz3Ow4UR/G60Ej0mkDo5zxJHLaHBDEv6tSGiVYWpXlV1sikLoslVMoicRVJZiii JktMUsoaAcA1dV+XxRQuZY0AyJpiPihrBEDWVOhBWSMAsqbsDsoaAZA1tXRQ1giArC6QLf8SSZa2 /T8qiMoI/piipff7CW3PjAcyCS3B11zsKdBdeKqLE+Dnyyg7Hr3oLI5mnKlcZWp5tPIeJuYJyk+j xV506H32d39WGGXKdOrnMFzHMNx8tw8k3c+nN92J6z4Qqe73FcugwS3YjvxOTfnRbOc5fXpZgbWX rpBepJpULl1hSZA75F80xs6lKxzal67w9brCruHMfV0hNWHn0+ZzqiQePpsqL52h4ccdctjpZLc7 rUtneGA69cNvq93W7dIZ4jBQd2W7vvnPO0P9Ujz5i9c33DZhim997naxlz2f2HQ/GCoYhW5/+Dr6 6+3gly/tujvHg5vVkI5+0CRhAVN1nJH/Me20Jm6/M2l4N77f8Ca3o8ao5Y0b/ann9tyb3mjc8v60 i3FxCKaqKOY4modmfWfA+nx0C58+tKW6dpxmy4eDBMervmRAB4Q50LDDwnPadDhJ0acFUylxTFwf 2PqvEZgFjDApMtt9uvPC9BbMeWF4UAXndT3SNx6ZwTiVW3er+GHHLzTs+LcJCwdVAL3XNS9MbE5x TZm33Vt34o7ao0av5942vNa03bhpu9NGdzLpON2+02l5Vd7maHkC2p2att+//fXL929/v0LO0ghJ H1jBJZ5qEUeI7ANLP67psxoO8yBjYcQNt1I4vsMKANFKBDHMceD1PwAAAP//AwBQSwMEFAAGAAgA AAAhAB0QSKKoBAAAwRAAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWzMWNtu 4zYQfS/QfyDUZ6+tuyzEXsSxvX3IZoM6+wG0RMfCUpdStGu3KLC/1X7OfklnSNFSnAT1JoGxL4ku w+GZMzOcI1+83+WcbJmos7IYWfa7gUVYkZRpVtyPrM93815kkVrSIqW8LNjI2rPaej/++aeLKq55 ek335UYS8FHUMR1ZaymruN+vkzXLaf2urFgB71alyKmEW3HfTwX9A3znvO8MBkE/p1lhNevFKevL 1SpL2LRMNjkrpHYiGKcS8NfrrKqNt+oUb5VgNbhRqx9CkvsKoq1Z8iujqUWUodjCI9saQ+zJgqek oDk8WLAENydoyIR6W1d3gjG0K7YfRLWoboVadLO9FSRL0Umz2Oo3LxozdVuAGVz0j5bfG0803q1E Pr6gMbBBdiMLkrbHv7CIxmwnSaIfJu3TZP3pCdtkPXvCum82AASHTSHflY7ocTiOCecuk5wR+xCV NqWw9LpMvtSkKCFODF+Hl9xsjTOMGd1Xa6Kpl+iqsdMvFR/GvlacGqAHJkLHcW1X0eF7UeANjkgJ A38YRKFFkBrbDqLGohuydl3Fcjcp0z1SuoT/kDlaJOsSqlRqonktF3LPIc805ltuAyJC+T20EYcq oHHKVr/Bo/rPkeUGAIQsVaYSCgxQzlVsh5WQbrjueASyaQyUwB9wwin2Iyt6HybQj7m84ozCRk10 cnzFs+QLkSVhaSbJR1pLJoiiELoXMKJ3qfZQLlmR3lJBEd7B8+eFRdJMSFMzsAIwAOmGB7jUJfB8 IQDzuinusApvOU3YuuTQFsTBcKFvTMZfVBOYBwsaCKrblNCLSsONfCcKXJ1G0y+B7fptaQSu67tR kyPdbip+XaWGkkelsdQ+u4k0pZFTca0KICtSOHPwErO73NzAwao6t1MwcDjq13XJs3SecY626lxl V1yQLeVQhzs8jCCxWSH1k9DHddhcHWN91/qBd3on9aKBh37g0sEi1kg9PwQUQPcJcO3ojHARYwPX beEObQ97+TS42I6K0JaVDmFvyy5ibOB6LVzbDW11KJxEL0Z2LrwIssHrd/BGToRJPo3fc+JFkA3e oMXrQINjL/x4eBFkgzfs4A099/R2Oye/CLLBG7V4Eezp/XZOvAiywTvs4A388MfsNwSpT+Lj6Y/o 4Uw+jHkV1svVAA46JQbqB2rgJXPeM3N+SiV7MOfVUH3tnE8liByQTWvKV9DBat7rsYaSWNGFFwvF HKoSpZdbpWLGspqqZharG6WqVqDdUYX/FbiXw8vwatKbzGZBz5sPh71oGM16Q9udD4JZNLMd/2+r EaQphCqznOmZ+yANKJ0eiTINCmWXbfcHIXyq2F5LPGDAIn1GiOkJ/t3yyzdpmZclCsCuAPNQFrw2 MSspdGZ+31ABO5jk/I8aUzsfayaVj8fJeYaRV0vTwHCzAEHFyM0mXx4x5L8FQ/BRDK6fJElJYPUR 84YVPHOmzsSd9KLImfW8wdztXbrOvBdMp74dDG1/4HmHCq4x8gLQYeV9TwF/+/rPL9++/vsG1as0 tP44hkv8ilZFycVHWn3aqgMOfjiAygKRC48q+KkAewFMWxP0YX56GP8HAAD//wMAUEsDBBQABgAI AAAAIQB6oVl1ogIAALsGAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1srFVb btswEPwv0DsQ7Leihx9xBNuBZVv9SROjTg6wkahYCEWqJO3aLQrkWu1xcpIuKStp3RRIUf/Y1Gp3 uDOzpIbn24qTDVO6lGJEw5OAEiYymZfibkRvrlNvQIk2IHLgUrAR3TFNz8dv3wzrWPP8AnZybQhi CB3DiK6MqWPf19mKVaBPZM0EviukqsDgo7rzcwWfEbvifhQEfb+CUtB9vXpNvSyKMmMzma0rJkwD ohgHg/3rVVnrFq1+DVqtmEYYV/17S2ZXI9tbDuKeEpemNhgI6RiZZ0ueEwEVBhKXYYO6vlaM2ZXY vFf1sl4ol3u5WShS5rZ2X0P9/Yt9mnsUmIYL/6D8rkWCeFuoajyEGCUg2xFFp3b2F4sgZltDsiaY PUez1dULudlq/kK2326AHTxtalk1jP6kE7V0ZmAYWXDI2ErynCkSPhFsqgBRLmR2r4mQSNkq0TDN LjctrqVvd6pXpJE+Nzh4X9BE4AVF/ZBc6Mg6hWyyW7T1GuV2OpptIvOd1eQW/10QYq7N0uw4c1oh I4gLdNCa8jWdpVHUnwbe2WDQ87rJ5MxLknTiTXrRNEnnSXJ62vtG26aQqikrZscAYoXGov14UJjw bpbYb2WmnAEepL0tTVMQm3EY+sEpjmvYHaLSBrt3PTjvRL4ABR8P0KxEEGOzyLMlhcvGkL/b0mlt SaU0aMavxkTHMKYwqnHm0xoU7tCa05raOPlf5rCjKtJtFVnyMmfkcl3dHujSOYYueB0i9IvSON2d Iseb2/48mkVJJ/EGg2judYO04006Uer1Z7Ne2D8Le0G3+zS32jIX2N2/ju3jw/d3jw8/jjCzbnSb GxKX9gZ1lyBXH6C+2uBxhhg/GThPUxeq8SOxvySeUyxG+9EZ/wQAAP//AwBQSwMEFAAGAAgAAAAh AEaUT3BkAwAAIQsAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1srFbbctMw FHxnhn/QmGfXl1yaepowpEl4aUuHpLwLW6k9yJaRlJDAMMNvwef0S1jJUa9hJqF5cRz5aHXOntVK p29XJSdLJlUhqr4XHYUeYVUqsqK66XvXs4nf84jStMooFxXre2umvLeD169O60Tx7JyuxUITYFQq oX0v17pOgkClOSupOhI1q/BtLmRJNf7KmyCT9BuwSx7EYdgNSlpU3ma+3GW+mM+LlI1EuihZpRsQ yTjVyF/lRa0cWr0LWi2ZAoyd/Tglva5RLYjRs5VHbJxcYiTyBig9nfKMVLTEwKzQnBEQRD4huEgp JzO20jZM1TPJmJlQLd/LelpfSTv7cnklSZEZtA2KF2w+bMLs3wpheAmeTL9xSDRZzWU5OKUJWCGr vofmrc0Tk2iCJEjaDKb3o2n+YUtsmo+3RAduAWRwtyj6XjcVPS8nduU0pER3VTWhFFPPRfpFkUqg TlN+U156uXRgpmYDX+ekaYE2/G7imo+WDxevwKklS6+GIlubwj/j1w7ShCs91WvOLCFImyYAxwP0 c2oUzir//RAKL/UZZxQ7YEOeHpzxIv1CtCAsKzS5oEozSWwy2A+APAU7Gs3ZQLIqu6KSfnyIfD21 edMEKyNplyFeGwr/TWTLEflIU+SK05TlgmdIJTbYUKKj7r/INVR5RMgCm6BRuwddQjSuM/swbmwE KIyapE122/hHuwhf8juiX9gPI3LbDvWoH+iK7XbzcEvaovaQwJSlAvuasyXjO8DbjuwBP8sLuTt6 q2F0Z74mYiF1vnPy7X3hi/lWdPjOQXdC2+2EEdXs0QawhLx0A2Qam/87jgrK50761gKsyRgrepHb zHFMGJ//0elNhu34JPS7nTj221HrxO914rEfdoajk/HxJBzF45/exvIylKqLkpmz5olZwVKem1Vj gcaOoigIj3EoRu17vSIHA3PYtnRcWyZCGGN86ExWSi9tzFzLpjNfF1RiBdec/zGmf1jRYRnpOkam vMgYuVyUn5/w0jmEY+PSBeit1Fj/ObBuu+N4FA9bQ7/Xg1rb4aTlv2vFE787GnWi7knUCdvtO90q U3mF7PaV7e2v329uf/05gGbt2dpcuvBqrmn2kOTygtYfltY8cTGFns7sUI2rKNRhQu9DDIa72g7+ AgAA//8DAFBLAwQUAAYACAAAACEACGf47d4CAAANCAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQ2LnhtbKxVW27bMBD8L9A7EOq3qodl1xFsB5UU5ycPo04OwEhUJIQiVZJ27RYFcq32 ODlJl5SYpEkKpK1+bIrcHe7MLMnZ4a6haEuErDmbO8F730GE5byo2fXcubxYulMHSYVZgSlnZO7s iXQOF2/fzNpY0uIE7/lGIcBgMsZzp1KqjT1P5hVpsHzPW8JgreSiwQo+xbVXCPwFsBvqhb4/8Rpc M6fPF6/J52VZ5yTj+aYhTHUgglCsoH5Z1a20aO1r0FpBJMCY7N9LUvsW2KpaUXLO6N5BJlRsYTJw FsA+X9MCMdzAxIWOQiZMr8j2QhCiR2x7LNp1uxIm4Wy7EqguNECf6Hj9Qh9mPhmEwcB7kn5tkXC8 K0WzmOEYtEC7uQOW7fUvJOGY7BTKu8n8YTavzl+IzaujF6I9uwFUcL+pZtUxek4ntHQ6HYJ7Vl0o htQTnt9IxDjw1PQ7evnZ1oJpzhq+rdAj4fu4btHoYeMlaGrEUruEF3tN/Ar+zSSOqVRrtafECAJl 4xjA4Qfkp1j3NWHucQJ93aiUEgx934unFimt8xukOCJFrdAplooIZLoATgFAzkAdBeb0kIQVKyzw p8fIl2tTN45hZyjaVgjDTsI/CzmyQmZYEbSiOCcVpwVUEGpI6Dmr2D9pWiig/BWOBaalA40IXRIY 4kZabcB/aVzCedDd/c0Pk3A6mY7dKPNTNwqzsTv1g5GbjA/8KM2CZZqk353e6AKoqroh+lA9sQiE fG5RZ7w2IQg8/wNcAEH0YArUoGGGtSWytiw51+3w2JjREMaUSnTOfN5gATtYc+xBGeAADKvI2Cqy pnVB0NmmuXqiSzSELvDAAPSL0pgDMXDfTo7CLExGiTudhkdu5C9H7sdRuHQnWTYOJgfB2I+i+76V mjmD6v62be9uf7y7u/05QM+aG6V7amCo3yNzR1Bxitvzrbny4BGGfkrNVAvPbn/xPoRoDPuML34B AAD//wMAUEsDBBQABgAIAAAAIQAcU9cEEAUAAI8SAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDkueG1svFjdcto4FL7fmX0Hjfeagv8NE+gECL1J00yTPoCwRfBU/llZUOjOzvS1dh+n T9JzJAvshGwoYXuTGPno0/n9zpEv3m4yTtZMVGmRDy37Tc8iLI+LJM0fhtan+1knskglaZ5QXuRs aG1ZZb0d/f7bRTmoeHJNt8VKEsDIqwEdWkspy0G3W8VLltHqTVGyHN4tCpFRCT/FQzcR9AtgZ7zr 9HpBN6NpbtX7xTH7i8Uijdm0iFcZy6UGEYxTCfpXy7SsDFp5DFopWAUwandbJbktwdoyje83FlFi Yg0LtjUCy+M7npCcZrBwm8ZyJRj5ksolmdAS9VAyVXkvGEPpfP1OlHflrVBbb9a3gqQJQtUQVrd+ UYupnzmIwUP30fYHg0QHm4XIRhd0AB4hm6EFgdviX9hEB2wjSawX4/1qvPxwQDZeXh2Q7poDQIPd oRDzUlv01BzHmHOfSs6IvbNKi1LYel3EnyuSF2Anmq/Ni2/WBgxtRvhySbT7JULVcvql8oeRr5RP jaI7T7g9O/RBHTDc9/q+E0Ztp4Rh6Hg98Be6xu97gROoMwwQnKGRy4HcjItkix6dw38IHM3jZQGJ OteQvJJ3csshzHTA19wGhQjlD1BJsRSQBnSQsMVHWKy+Di0HMt4ic51EIJ/j+7yYpZyjK8xKVfA0 wUV8rSqJTbgga8qHltw4taoNKdipT9EgWg393FAPAkcH4F74A/pwivXN8s67MdR3JiecUdC6Th85 mvA0/kxkQViSSvKeVpIJosIBbAAGo7pSnaEgWZ7cUkHR0h3ypzuLJKmQJv9gB+gAzjVOVX7GeD+f VK5JKlNmt5zGbFnwBNRRroBiNAl0UopBhVtQjlArJiGPT7SDJRd5fqQCrbLLiwJMNR1fXbH/kV6q dg/lVEbFtSrxNE+Ar/ARIzlf3QApq12NPHPx+DqjTDKo9HQwPTWU54dKyWPwnKiJhyB4NqS7u8fr 254qqaPw9h6pQWo8b49nu6EdYLkcBdhrKogoNaDfAIycCO04ARBRasBgD+g4ESh4EiCi1IBhAzD0 VORO0BBRasBoD4hoxwel5UNEqQH7DcDAD08MCqK8kpKmgj4QKFfVboGZygYVFILEirHSuMiRtmiS /CKK8gxF3WPTbfKTi0X4Wn7CvgMMDe1jSfmipirdBHA0UF7Fh+N7YtDrq8RVtGEGhVZPDGwn8FTT BM5+kbQwT3KY8C5XslikUhOPbpcqhRo9yLTIA3T2qG0eZjZFCWdkNrvFlK9nNrtVREiPdRGdymz9 MxNbC+8MvNbCOwOttfDOwGotvDOQWgvveU5DyoRc381TKg1OH7uwSNXUVbU47ZSBCm5z+t4ypZK1 2Co8B1sl8glX2XoWeZasFEeakdDM2YqbzCCkfqjxdQHXLrw6/eU64Tiw3UnHvpyGHa8/dTtR5E87 s8D3Jv5kOr68DP626ltEAqbKNGN4d3s0/eKM+mT6heipI+XItru9EO6Ytrd3POiAMP/XxNs3AbqD WwAjN6tsDqNus60oYn5tW4G7O0DrYP25ogLGezMGvzAHnxSv4MqZOmN3DFFyrjpeb+Z2Ll1n1gmm U98O+rbf87xdvCq0PAftfjZc37/988f3b//+slhBatfVNCsKvCA1w9Q/Rz0t4Bapmv+jGL0wAPxM jF6TyOoqoz9zwCN+FVEDDxfvaflhrVgPPgOBZ+ACC0slfPgB1VB0L4IY5kPS6AcAAAD//wMAUEsD BBQABgAIAAAAIQAV/Dxd7AQAALsQAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgu eG1svFjbcttGDH3vTP9hh31WxLtIjeWMdctL4ngq5wNW5Mpks7yUXClSOp3Jb7Wfky8pAHJ1s5xK ttsXiSKxZ4GDswCoq7frTLKVqOq0yAeG9cY0mMijIk7zh4Hx6X7aCQxWK57HXBa5GBgbURtvr3/+ 6ars1zJ+zzfFUjHAyOs+HxiJUmW/262jRGS8flOUIodni6LKuIKf1UM3rvgXwM5k1zZNv5vxNDfa 9dU564vFIo3EuIiWmchVA1IJyRX4XydpWWu08hy0shI1wNDqQ5fUpoRoi/lv92uDkVm1ghuWcQ2R RzMZs5xncGNU5AoQ2JdUJWzES/SDbOryvhICrfPVu6qclXcVLb1d3VUsjRGqhTC67YPWjH7mYAYX 3aPlDxqJ99eLKru+4n1ghK0HBiRug5+wiPfFWrGouRnt7kbJxxO2UTI5Yd3VG4AH200h52UT0eNw bB3OfaqkYNY2qsaUw9L3RfS5ZnkBcWL4TXjR7UqDYcwIXyasoV8hVGvXPCQ+tH1NnGpHt0w4phuY wC4E7rmh57nuISm9Xs92TeALqfFC1/GJtf2IG+Syr9bDIt4go3P4hsTxPEoKEOq8gZS1mqmNhDTz vlxJCxxiXD7ASYpUBTLg/VgsfoWb9deBYYPiDTbXoW9XQJbheg8JOOZ9YAI+YKnkeBRF3nk3hKOY qZEUHDZoM62uRzKNPjNVMBGnin3gtRIVI+bg4IJviK5oD4IUeXzHK45ObZE/zQwWp5XSUoEV4ANw reOHyybzT+ff3eYfxXcneSSSQsbgi4NcwaHRiX6WFJB/CB9oTLhcGHCCQN72c7TRC0PShm+GvgkZ OTgwjTZAPKiNxoL20CIjIhqVam60NjBfOVS6m6UqFqlCde8/2k+wlkrGq/d0ctM8hiJCl4fymS9v oeySi3tKssDx1q0WCjeHSxsF2KC6Xo/0toNGmyfw0LJxuAVp8ZwdXmi5dGjOwmt5RV2vJIK0eO4O z3J6FAY7BzDc9w9BWjxvDy+wgwDMLsdDkBbP3+HZdkDyuBwPQVq83h5ez3XOTshBvAjS4gU7PAQ7 OyEHeAjS4oV7eL7XQ1ldHi+CnK5hiA4C2BYr2vb5NQ0LC5W0+qCmPadaebpajbkSB9WKmsVLq1Ws HtUqqzlh2M+JLryYEXNYW6nZ7+qtLhx08HXloB/UGxYwfuAI8cdkOJlYQyfojLzJsOOOfb8TwsHq mDfTSTgaT8aTYPqn0XbTGEJVaSZwhjlqLdgAHrWWxilsHpbVNXswa1nujnjwAWGeaCdNMbm4ifg6 LdOiwDa230Y8rFAvTcwC2jJ1kd+XvIId2kZi6WnkFZLzuoz0NCMzmcaC3S6z+REv/mvwArM8QJ+k 5l+aLCXluBeSVH+gW39ij+2hM+wEgT3puObU6dw49rTjj8ee5YeWZ7ruVrc1Rp6Dd5fK9vu3v375 /u3v/1izME0cvgrsizZ4WXJw3jlSKk1TNAafLCPI0dGbAc3DUNhhonEC64mRB57jyOOGrh24ehho gH4w8zyR5/+z7tOoCh+61dBJvmB8nomoyGMmxUrInVKahkbFtvnQ8HQaLoC/T9LqfHRK7gXo02JZ wXvnuc63L0Jnt+FpujiJ/pyyTypqXonhEt+gqZrL6gMvP67IJfjLAEryiG6V8CcBqAtNdyaIof90 uP4HAAD//wMAUEsDBBQABgAIAAAAIQD96heGvwAAACUBAAAfAAAAcHB0L3RoZW1lL19yZWxzL3Ro ZW1lMS54bWwucmVsc4SPy4oCMRBF94L/EGpvqtuFDNJpNzLgdtAPKJLqdLTzIMkM+vcG3IwwMMu6 l3sONRzufhE/nIuLQUEvOxAcdDQuWAWX8+fmA0SpFAwtMbCCBxc4jOvV8MUL1TYqs0tFNEooCuZa 0x6x6Jk9FRkTh9ZMMXuq7cwWE+kbWcZt1+0w/2bA+MYUJ6Mgn0wP4vxIzfw/O06T03yM+ttzqH8o 0PnmbkDKlqsCKdGzcfTKe3lNbAHHAd+eG58AAAD//wMAUEsDBBQABgAIAAAAIQDQ397XnQYAAAcY AAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWE1vG0UYviPxH0Z7p7GdOImjOpU/G2hdqtht1eN4 d7w78ezOamac1DfUHpGQEAVxoBI3Dgio1Epcyq8JFEGR+hd4Z2bX2fFu0oIqUaHmEO/OPvN+v898 XL5yL2bomAhJedL26pdqHiKJzwOahG3v1mT4wa6HpMJJgBlPSNtbEuld2X//vct4T0UkJgjmJ3IP t71IqXRvY0P6MIzlJZ6SBL7NuIixglcRbgQCn4DcmG00arXtjRjTxEMJjkFsJzjCPiheevu55AED 8YmSesBnYqzlkkp4MK9rkBThtMcEOsas7TWGjW6j5m3sX97AexmAqTJuaP4yXAYI5o2SvO2d5mBr ZyXPAJgq4/rDfq+b4zIA9sG1Ct2dVqe508tkFkD2sSy71esOun0Hb0AWv1myud/odbdd+QZk8Vsl fKvZ2Wy58g3I4pslfG+3NWy6eAOy+O0Svlvv1HZbjv0GFDGazEvofqO5W9/K0CvIjLODSvjuVqtT 62TwMxRkf1U8WsWMJ+qCUorxERdDwGgsw4omSC1TMoPibHs9HE8FxVoH3iO48MUO+bI0pNUh6Qua qrb3UYqh4M/kvXz2w8tnT9Dp/aen938+ffDg9P5PVpAz6wAnYXHWi+8+/+vRJ+jPJ9++ePhlNV4W 8b/9+Omvv3xRDVRF4POvHv/+9PHzrz/74/uHFfCOwNMifEJjItENcoIOeQyOmai4lpOp+GczJhGm xRmdJJQ4wVpLhfyBihz0jSVmWXYcO7rEjeBtQYHPKgReXRw5Bo8jsVC0Angtih3giHPW5aIyCte0 rkLWJ4skrFYuFkXcIcbHVbp7OHHyO1ikwIx5WTqO9yLimHmT4UThkCREIf2Nzwmp8O4upU5cR9QX XPKZQncp6mJaGZIJnTrVdDbpgMaQl2WVz5BvJzaj26jLWZXXfXLsIqErMKswfkKYE8areKFwXCVy gmNWDPh1rKIqI8dL4RdxA6kg0yFhHA0CImXVnI8F+FtI+jUMpFWZ9hFbxi5SKDqvknkdc15E9vm8 F+E4rcKOaRIVsR/KOZQoRje5qoKPuNsh+h3ygJNz032bEifdr2aDWzR0TDorEP1lISpyeZVwp37H SzbDxFAN8LrD1TFNLiJuRoG5rYY3R9xAlc+/eVRh99tK2R1Yvap65mCNqM/DrdNzj4uAvv3s3MeL 5CaBhigvUe/I+R05e/97cj6vn988JZ+xMBC03ovYvbbZeccXbbxnlLGxWjJyXZq9t4TlJxjCoJ5q zpRkdbZLI3jUzQw6XNwrJ2lpsKlX9pDYbNZq+RlxpePfiC3Zor1f84glRf9Ygk7gvN3YAQOQj9O2 N4PjBjzGadD2pF6OMQvhSO4r4ZkYvJZvMsIBsc61cucgSFiNeGCH67V8XEfPHKohmmWnUyFVH8vI zjJhzkLOEm2PdaDR3HpzDpSiiPdez4rN3fp/aAXE0c0tmc2Ir4rZLozo2NlXqHTrceVXM90B6xe+ UESMo+AETdlCHGKolWZtVzsfUAlHzCwftnSmsL0VXN2hKhpHOIUTbM2WUvGiBDpAN4EWjlkaYZvv bTOYJcTCTYms9Ju3lR+FtzW7116tz7rw4BCyGWitPlwACYx0ptseFyriocBpRP2hAP4whoETCLpD 24/gGsr8CnKsf62JVoaWxmAvqQ5piASFCyzY9OlXzmGLHVDR9hS7WGAdYqnDYcXmwmx3nJks080A +WAdX4g70MW1+jZYpj0YYcgPbLLaXjAfBCEx2qbkmLCJ7vesUKNV1qzXcJpg2UEsk2pastCfNiuW +LSbhT6HBrQGw2ixz3Wb5464fV7UoUkAvCknED4U6jJj5WmoKblY2S7/5nRSNDcroiJ9QYINt69V Z91EK5SZslCilMtV0VbJ1qE4o/PWuR6H5hYxF7hjGNCE8TyhhfgCtWSBXAtw/VwiddVlAl5XH6wI lfnczMdLvK3VweAqcCkcZJH+B6sHFT6Ultat16MJPwRmQvp+1EhD0FO2ThA0R2YomuaDNnVaklWQ pU1LmzKa6lqoTKH+mF0Mg9hXXwzz2Yz6pM/9hb7xtbfDgujrN57IiKZw3yH2SDwlQdsTHwa2ToIF V3AlfWFYC7Whw5rvGfKsXzi3UAItTYflyRDzlRHwrL3WEhVlBKl7hqXU0vxIeNvUIYfLdBjJHmcw oe0l4ES+2AM92Zjn4TVxX+860DXLN1MGYG7ii/flfHoEee7DveWCKQkioZnvwa0F0MrYOL9ae8zU /b8BAAD//wMAUEsDBAoAAAAAAAAAIQD+TvG33QoAAN0KAAAVAAAAcHB0L21lZGlhL2ltYWdlMS5q cGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABHAD0D ASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0 NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKj pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QA HwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEE BSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZH SElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDz y48b+JfDvxCd9R1e91ZNJ1OTNvNdOYpCjMp2gkheM4OOM19Ta54otNA8Hz+JLmKWS2igSby4wCx3 YCj82HNeaXP7PGm3+v3Go3uv3ckVxcPPJDHAqk7mLY3ZPr1xXqV14fsrzwtJ4el8xrJ7T7ISzbn2 7doOT/F3z60AePeHf2iDqPiWKy1LREgsbmZYopYZSzxbjgFgeGGSM4xj3rqvi98StQ+H8Glpplnb T3F60hLXIYoqptyMKwOSWHft71i6B8AbTQPGmn6uuq/bNPtWMptriAby4B28g4wDg9O1eheLvAmg +N4bWPW7eSQ2pYwvHKUZN2N3Tg52jr6UAeEW/wC0h4pW4jNzpWjPAGHmLHHKrFe4BMhAPvg1754m 8VWfhzwjc687wsqwGS3jklEfnsVyqA+p9s1w2mfs/eE9P1tb6Wa9vbVOVs7llKE/7RUAkD0/PNdP 8QPh7Z+PPD9vpbXTWDWsgkgkiiDKvG3BXIyMHoCOgoA8jj/aP1yeVYofDdnI7HCosjkk+gA617x4 a1h9e8OWOpy2ktnNPGDLbyoytG44ZcMAcZBwe4wa8Nf4Aaj4fvrbUrHxjaQPbyLIk88JgKMCDkfM wr6Dt7iC7gSe2mjmhcZSSNgysPUEcGgDxL45XXjHw5eWviDS9fmtNJkMdqLaGZlYS4dtxXGCCF65 /Cuk0fxpqtz8A5PFM1yraslnOfO8tf8AWK7IrbenYHpj2rxX4yeLdY1rxpqGj3lwf7O066Zba32B QpwBuJxlifc9+MZr1fQNDuj+zK9h5Un2mbTp50j2/M252kUAe4x+dAHP/BbUvGvi3xPLrF/4imn0 uyYrc20sp/eM6Nt2oBtABwe3TivQvi34Y17xR4US38PXUsd3FMHa3SYRCdcEEEnHTqMnH6V85fDL xbrHhnxbZQabOVt9Qu4IbqDYGEqb8Y5GQcMcEete+/Gbxxr3gjS9Ln0VIALmZ0mlli37cAFQO3Pz f980Aef/AA/8AfEXT/HOmvrK6paaZExa4dNRBUqFJCna5yCwUEDtXqPxUk8cR6DCfBS7pCzC68tV MwXAxs3fjnAJ6YrxSz/aD8ZQ3kUl0LC5gVgZIvI2bh3AIPB96+hNa8baXoXgyPxTdJcPYSRxSIsS gyESY28Egdx3oA+cZ/BfxR8dalZw61aagwRiiXF+uxIQcFie+OB0Br6a8K6GPDXhXTNGEgkNnbrG zgYDN/ER7E5NeTX/AMYfGur3kVx4L8F3Vzo8oCxz3enyuXbOG+aN9gAPHU9OfSvarKWeaxt5bmDy Lh4laWHdu8tiOVz3weM0AcN4u0r4bXXiyxuPE8mnLrACiOOefZ5gz8u9c4Iz03fSu+TYY1Me3Zgb dvTHtXxr8WNTfVvihr0zrtEVybZVznAiATP47c/jXtnhqy1rxJ+ze1gPOhvms5I7baCrSoj5RR7M q7fcGgDptD8O/DseNbrVNFOmSa4hbzI7e5DeUx+8RGDhT1yQPX3rsdQtrG8spINSgt57V+HjuUVk b6huK+P/AAX4U8QJ8StE02S1vdLvftAm3TQvGyonzM3OMjAI9DmvoT4zeEdZ8YeEYLTRMSXEF0Jn gMoQSrtYd+CQSCM+9AHSjwN4PYBl8LaEQRkEafD/APE1H400HQtY8IXFhrkxs9IhCySPE4jEapyO cEAe2K+bPBfw38cnxZZRJa6xocbuRNforRGNMZbDDHUDAHcmvdvjLpmr6t8OLix0e3uLqeSaLzIo V3O6Bsnge4U8elAHNaZ8cvDNte6b4b0HRtRuLZWisrZxsTdyEXCk59OuD9K9mr4XiTWfCPiG1uJb Kez1G0lWaKO6gIO5TkHaw5GRX1/8O9W1vW/BNjqHiC38jUJt7EbNm5Nx2tt7fLj+fegD5h8RvFo3 xo1WfV9LN9AmryzPZscecjOWQdDkEFTjv0r6k8VeJT4X8D3WvW2myXIt4UdLUAoQCQORj5QoOTxw AawvFnxi8KeFZbuze6a81O34NpApPzZxtL42gjvzxj14rsZryyn0CS9uwPsD2pmlEi5HlFcnIHXj PFAHgvhH49eItU8X2Gm6hY2D2uoXscA8pWVoQ7BODuOQCc8j19sejfFf4jXvw+06yex0tbuW8Z1E 0xPlRFccNjkk5OBkdDXN+HdX+E58daVo/hrRLe5upmaRL4RNtgkRS64MnOfl6jpx+Hf+N/Gmg+Dd Ogk15JJYbtzGsUcQk3YGTkE4wOKAPJNL/aUmN9GuraBGtoxw72sxLoPUBuG+mRXpnxG8fHwX4Nh1 uytBePdSpFAHyEG5S25u+MKePXFcvrHwQ8M+MNTPiGw1KW0tL5EmWK0iQRkFR8y+mev1Jr0bV7fw /beHhaa79hGlRoseL9l8vCjjO7jPH1oA8ItP2k9ZW5U3ug2EsH8SwyOjfgSWH6V7r4W8V6T4x0aP U9IuPMiPEkbcPE3dXHY/oe2a8e1rxr8HtK1hLG38K2eowg4murW1jKJ/u5xu/D9a9m0HRtD0qzEm h6ZZ2cNyquTbQLGZB1UtgZP3jjPTNAHg3jn4JeKNY8f6le6VFaNp99I1ys8k4UIzcsrL97OcngEY xznivcfCWn6rZ+DbDTvETwT38UJhnMRyjKCQvYZ+TbnjrmiigDyDwT8D/Efhfx5pmr3N9pstlays 7GGR95G0gfKUAycjv6/j3vxW+Hl18QdLsLezvYbWa0lZ8zKSrAjGOOnSiigDgtO8BfGPwvbw6fo3 iCzayiP7tFmDKgznGJE4HPQcV0nxk8A+I/HFvoQ0oWrG0EpuFeXYNzBMEZ6j5W9+aKKAPLrb9n3x rNOiS/2dBGT80j3GQPwAJr6e0mzfTtGsbGWYTSW1vHC0oXG8qoBbHbOM0UUAf//ZUEsDBAoAAAAA AAAAIQCsqeysAmQAAAJkAAAXAAAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWf/2P/gABBKRklGAAEB AQBIAEgAAP/iBUBJQ0NfUFJPRklMRQABAQAABTBhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQAL ABoAC2Fjc3BBUFBMAAAAAGFwcGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2RzY20AAAEIAAAC8mRl c2MAAAP8AAAAb2dYWVoAAARsAAAAFHd0cHQAAASAAAAAFHJYWVoAAASUAAAAFGJYWVoAAASoAAAA FHJUUkMAAAS8AAAADmNwcnQAAATMAAAAOGNoYWQAAAUEAAAALGdUUkMAAAS8AAAADmJUUkMAAAS8 AAAADm1sdWMAAAAAAAAAEQAAAAxlblVTAAAAJgAAAn5lc0VTAAAAJgAAAYJkYURLAAAALgAAAepk ZURFAAAALAAAAahmaUZJAAAAKAAAANxmckZVAAAAKAAAASppdElUAAAAKAAAAlZubE5MAAAAKAAA AhhuYk5PAAAAJgAAAQRwdEJSAAAAJgAAAYJzdlNFAAAAJgAAAQRqYUpQAAAAGgAAAVJrb0tSAAAA FgAAAkB6aFRXAAAAFgAAAWx6aENOAAAAFgAAAdRydVJVAAAAIgAAAqRwbFBMAAAALAAAAsYAWQBs AGUAaQBuAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGkAbABpAEcAZQBuAGUAcgBpAHMAawAgAFIA RwBCAC0AcAByAG8AZgBpAGwAUAByAG8AZgBpAGwAIABHAOkAbgDpAHIAaQBxAHUAZQAgAFIAVgBC TgCCLAAgAFIARwBCACAw1zDtMNUwoTCkMOuQGnUoACAAUgBHAEIAIIJyX2ljz4/wAFAAZQByAGYA aQBsACAAUgBHAEIAIABHAGUAbgDpAHIAaQBjAG8AQQBsAGwAZwBlAG0AZQBpAG4AZQBzACAAUgBH AEIALQBQAHIAbwBmAGkAbGZukBoAIABSAEcAQgAgY8+P8GWHTvYARwBlAG4AZQByAGUAbAAgAFIA RwBCAC0AYgBlAHMAawByAGkAdgBlAGwAcwBlAEEAbABnAGUAbQBlAGUAbgAgAFIARwBCAC0AcABy AG8AZgBpAGUAbMd8vBgAIABSAEcAQgAg1QS4XNMMx3wAUAByAG8AZgBpAGwAbwAgAFIARwBCACAA RwBlAG4AZQByAGkAYwBvAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUEHgQx BEkEOAQ5ACAEPwRABD4ERAQ4BDsETAAgAFIARwBCAFUAbgBpAHcAZQByAHMAYQBsAG4AeQAgAHAA cgBvAGYAaQBsACAAUgBHAEIAAGRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAA AAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAWnUAAKxzAAAXNFhZWiAAAAAAAADzUgABAAAAARbP WFlaIAAAAAAAAHRNAAA97gAAA9BYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAAB0 ZXh0AAAAAENvcHlyaWdodCAyMDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2ZWQuAHNm MzIAAAAAAAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBs/+EAdEV4aWYAAE1NACoA AAAIAAQBGgAFAAAAAQAAAD4BGwAFAAAAAQAAAEYBKAADAAAAAQACAACHaQAEAAAAAQAAAE4AAAAA AAAASAAAAAEAAABIAAAAAQACoAIABAAAAAEAAAEAoAMABAAAAAEAAADAAAAAAP/bAEMAAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB Af/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAf/AABEIAMABAAMBEQACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2 d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0 4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery 8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoArTx5BPr+Oc9u5/Q4zQBiXEf3uufp2PfqPywPUUAYVxF27nPPX8c9cf5JzQBhXEfX 09uv17jnjPTrnigDBuI+Tnvnnrz37dfXH69wD8XP+C0y7fgB8MfX/hcVp9MHwV4wI7/WvmeKf9yo f9hS/wDTVU9fJ/49X/r1/wC3xP5rq+FPoQoA/wBHCv2A+HCgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAQjIwe9AGZcR8/p2Ge3OD+uPXFAGFcR8/Xp1wMZ5PA/Pp3oAwbmPr nv8AT39T09OTQBg3Mf8AkZ5+vHX1/wAM0Afit/wWsXb+z/8ADDjH/F5LMdMf8yT4y68nnj+dfM8U /wC5UP8AsKX/AKaqnr5P/Hq/9ev/AG+J/NLXwp9CFAH+jhX7AfDhQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFAEMyZUn2/yeo/zk0AYdzHnPrzz9e+euPqKAMG5j6nB6n17 fpz1zx/WgDAuU6n9Tzkk988+nI96APxR/wCC2S7f2fPhefX4zWf/AKhHjL/PavmeKf8AcqH/AGFL /wBNVT18n/j1f+vX/t8T+ZyvhT6EKAP9HCv2A+HCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKAA8/5/z1oAyrmPrkdPrj2PUfnk0AYNzH978frz6Z7fr7HNAGBcp2/LH+Gc Z9efrQB+JX/Bbdcfs+fC44x/xeezHbP/ACJHjLrg9f8A647V8zxT/uVD/sKX/pqqevk/8er/ANev /b4n8y1fCn0IUAf6OFfsB8OFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ AUAFAFadM888/j/Xp9e9AGBcp144+nPHJz25654yPSgDAuU+8fXvjPPXnjj8Pw5oA/Eb/gt4u39n r4Wn/qtFn2/6kfxnz1/p+RzXzPFP+5UP+wpf+mqp6+T/AMer/wBev/b4n8x9fCn0IUAf6OFfsB8O FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFADJBlT379/15/WgDFuU 5P8APPJz1xnt/X1NAHP3KcdPbgnPJ6c8Z+vrQB+If/BcAY/Z5+Fv/ZabP/1BvGnUZPP+c818zxT/ ALlQ/wCwpf8Apqqevk/8er/16/8Ab4n8xFfCn0IUAf6OFfsB8OFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQAUAFABQBl3K9SOx6jv3z39efzNAHP3K9en169fXgn+f5dQD8P /wDguIMfs7/Cz3+NVn6/9CN409ff2z1r5nin/cqH/YUv/TVU9fJ/49X/AK9f+3xP5g6+FPoQoA/0 cK/YD4cKAOT8baz4k0Hw/LqHhLwr/wAJprzar4b0200FtYi8P27W+t+JNJ0XU9Yv9XmstTNppfhj S9QvfE+rG203Ub+fTdHu7bTbC81Ca2tpYqSnGDdOn7SfNBKHMofFOMZScmnZQi3OVk21FqKcmk6i k3aUuVWk72vqotpW7yaUVqld3bSuz5C0D9srVLiP4S6/4x+Fun+Dfh18WfGV74N07xzL8RhqsWn6 jpvhD9oHxLqFudF/4QvTry/1W1vfgXbaX/Zkc1vHew/Ebw1c6Tf6jqlnqegRefHMZfuJVKCp0a9R 01V9tzJNQxU5Ll9km5J4a3L1VaDi3JSibvDr94oz5pwjzOPLunKklrzWSaqt31+CSaSaZ9N23xo+ E163hIWXxD8JXi+O9M8N6z4SmtNZs7q21zSfGck0Pg7UbW7gkktls/F91b3Nj4Unnmhj8Sajb3Gn aK19fQS269qxNB8lq1N+1jCVO0laUat/ZtPa1Rpqm38ck1G70MXTmua8ZLlbUrp3Tj8SfnG95dlq 9NTxP4gftVJ8P/iH408GXngq31Ow8Faj8E9OuJrDxfH/AMJp4jk+N+uz+HNFTwf4Fm8PomvXmh6j Z3tzrOnr4mtrt9Gtzfaal7dF9Nj5a2OVGrVpunzKlLDRbVT95N4mThH2dJx99xkm5LnT5VzK7900 jR54xkpNOXtN4+6vZq75pX0vdJO2717nrurfHz4MaDPqUGs/EvwjpraRqNvpWpSXeqwxW1nfXHiq y8CmCW8Y/ZCLLxtqem+ENXnSdoNE8T6jYaDrEljql5b2svRLF4aHNzVqa5XyyvLZ+0VLfbSq1Tk9 ozajKzaRCpVJbQk767f3ea//AIDeS7q7V1cd/wAL6+DX9iad4jPxJ8Jpomq3HiG2tL+TVYYohJ4R 1ePw/wCLnvUkKzaZbeEtcmg0nxVe6nHaWfhvULm2tdbnsZrmBZD61h+WM/bU+WXPaTlb+HJQqXvr FU5tRqOVlBtKTTYvZ1L25JX00t/Mrx9eZaxtfmWqueB6t+234D8Pal8V7vX9OisvA3wnX4qDVdbh 1i6n8W6lN8GNHj1Px5/Zngq48P2Ntf20NxKlho02keLNXuLz5r7VbPQrN7aS55ZZnSi67nG1Kh7e 8+Z88nh481VRpuCT1do8tSTe8lFWvqsPKSp2+KpyW091Ko2otyu2vO8eujbufR2m/F/4baxrmleG tO8V2Fzr2tOYtP0vyb6K7a6/svVtcjsLpJ7SMabqdzoeg6zrdnpepNaajfaPpl5qtnbT2ED3A7Fi KMpRgqicpaJa3vyylZ3XuycYykoys3GLkk0rmTpzScnF2XX5pX81dpXV1d2ucfon7S/wZ1tPEUn/ AAmFto48M+OvEnw7vv8AhILe50g3PiPwpcaxFrSaSbmPbq1jZ2/h/W9Wub+yaWGy0LS73XNR+xaX byXS5xxmHlzv2ijyVZ0nzpxvOm5c/Lf4klCUm1e0YuUrJXKdGomly3vFT0aekrWb7XbS13bsrs3/ AIsfFiy+G3wq1n4naRpFx8Qmi0/TJfCPh3wzf2bXPjrV/EV1Z2HhfStF1Mmey8nW73UbIjVQLm0t NNefVnWW1tpM3XrqjQlWjF1tF7OEGr1ZTaUFGWqtJyXvapRvLVIVOHPUUG+TV8zlf3UrttrfSz03 voZA/aT+BsVj4Wv9S+JfhbQovGfg7wl4+0Bdd1ODSjeeEPHLpD4a18y3TJappeoXciWP29rj7HBf SQ2txcRy3FuJZ+uYa1NyrQj7SnTqx5pct6dXSErvSzel72T0e6u3RqXkuSTcZSg7a+9Hdd79e/Uy vF/7THwu0TRPiC3hrxZ4S8VeOfAvh34kasvgGTxImh6pqusfC/TL3UfE/hoyyafqN3Z6jp32QDU0 h0jUrzTLOaPVJdPlsGSV5qY2hGNbkqU6lWlCtL2TnyylKgm5w2bTVvetGTSfNZrcjRm5RTjKMZOC 57cySm0lLdJp301V9r3L3hn9oLwTq+ka5rGvX+l+GIdF1vw94da1k1ePVdSutc134Y+Gfii2kQ6T Z2qaw2q2mha/cXkempp8l9f+H9LfxdbwLod0k0bp4unKMpScYcsoRtzc0nKVCFdxUUubmUZ3ta7j H2nwvQlSkmkk3dOV7WVlNwvdu1m1a/8AM1HczvE/7V3wC8L+Gdd8VSfEXRNd0/QPC934wmg8L3Ca 9falolhcaBaX82hxWbGDV59Ou/FXhmDV7e0uXk0R/EGjtrQ0+LULaSRTx2FhCdT20ZRhB1HyPnbi nBScbfFyupDmSd488ea3MrkaFWUkuVpuXLeWiTd2rt7X5ZWvvZ2vY3rH49/Du41HxHa32v6TpVpo mreGNDsbi81Dy9S1vVvFHhqXxVaadb+HJbeHXIL4aRb3eoRWjWk011pNjf6xGq6fY3c0FLFUXKac 4xUZQim370pTg6iSg0pX5U3azbjGUtk7J05pJ2bum9Nkk7N31VrtXfd23Lh+P/wU/tvSvDo+J/g1 9Y11fBkmiWsWtWsyazb/ABGSRvAN9pV5E72Woab4zkia08M6naXM2n61qTRaXp9zPqM8FrI/reG5 lD21Pml7PlXMve9t/CcXtJVNoSTtJ2im20g9lUs5ckrLmvpty/Fdb3j1W6Wr01Oh0D4pfDzxR/wk DaD4v0XUYPC1jDquu3sdz5Wm2Oj3M+t20Gtf2pcLFp91oktz4a8Q2ya1ZXVxpZuND1aH7X5thdLH ca9KfPy1ItQXNJ391RbkubmejjeE1zJuN4y10YnCcbXi05OyXVvTS29/eWm+qPJ/HX7TvgjQ9P8A BA8CX3h3x/4g+I3j63+G/hjTx4hu9K0m28R3ngDxL8TLGTxXqek+HfF2t+HtI1Lwp4aa/wBL1GPw pqv9o2+t+HtStYJNE1RNVTCrjaUFS9m4VZVqvsYLmaipulOsnOUYVJRi4QupKEr88GvdlzFwoSbl zJwUI88na7tzqHupuKk1J6+8rWkm7qx6vN8UfANpqc+h3/irRrTXLPxVoHga/wBMe5fzrPxj4o0e LXvD/h+UvDEVvNZ0qeG90oypEl/BNAYSZJo4239vSUnB1IqanCnKN9VUqR5oRem8o6xva6a7kck7 XUW04uafeMXZy+T37anEN+0X8L7rWfC+l6H4m0fXYfETanctqFpftHFHolh4L8Q+NrbX9FjktT/w l+mavpnh29l0m48OSXsOp6fBqOr6bNe2Wkag0WX1ui5QjGcZKfM7p/ZVOVRTimv3ilGL5eS/MlKS bUZFeynaTaacbK1urko2f8rTavzW1aT1aNDSf2h/ghr2mXWsaH8T/COs2FofCQeTStTTUJ7hvHqy t4JTTrK1E19q0nix7a9t/D0el294+r3un6nY2SzXumahBb1HF4aSco1oSS9ns7t+1/hWSu5OpZqH Km5NSSu4tJOjVTs4STfN0/l+K/a11e+103o0cv40/aM8PaX4V+FHjDwAmgeP9A+LvxC07wB4f12f xRN4Y8Owy6lo3ifVodcm1b/hHddkn0tW8L3NmXt7BjJJcwTQNLFuNZ1MZCMKFSly1Y16ypQk5uEL yjOXM5ck3y+49l1uio0W5VIzvB04ObVrt2aVrXVnrfV/ma3hD9oDwXrVjbReJtU8O+HPFkp0Gd/D ujeJIfG9pdaL468S65oHwr8T6Dr+i2EVvrnh34q2+itrHgu+is7ae8hnl067tLTV9N1Oytahi6cl +8lCFT3XyRn7RONScoUKkZxSUoV+XmpuybvZpSUklKlJPRNrXVrld4xUpxae0qd7SXTe7TTOX8V/ tX/C+08Fal4q+HPiTwj8T9Q0t/BF3P4b03xZFpl9J4c8YePdE8By+IIGXTNXuZbfSL7V5RMo077O dVszoV/faTeT+ZDnUx9BUpVKM6ddx9k3BVOV8lSrGlz/AAydouT+z8S5W4t3TjQm5cs1KC97Vxur xg523W6XfbWzOy079oD4bPpa6nr3ibQtANx4u8c+FbC1fVotSuLg+B/iJcfDW+1C5isYmn0yJfEn 9l6Vq0eowW6+HfEGs2HhnV54dYmhhm1WLo8vNOcYXqVYJc3M37Ks6Lk7K8Vz2UrpckpKEnzNXTpT vZRk/djJ6W+KPP130u0+qTa0Of8AA/7SPw7+IHiPQPBdldyxeLPEfga2+INnZ2QfW9GbQL7W/EWi WuzxNYQnTHvGm8M6lNLayfZ3tkEUUhNxIkTTSxlKrOFNP95OkqqS96PK5TivfWl7wlo7dt9AnRnB OTXuqTjd6O6Sez1+0j2G5XrwPw/LGDwD9euTXWZH4d/8Fxxj9nf4V8Y/4vVZ/wDqDeNPc/5/T5ni n/cqH/YUv/TVU9fJ/wCPV/69f+3xP5gK+FPoQoA/0cK/YD4cKAEbcVbaQGIO0spZQ2OCyhkLAHkq HUkcBhnNAHyN4P8A2ZvEPhbwn+zf4cm+I+i6ldfAH4q+MviZc6knw+vbK38Yr4s8H/GbwcmiQac3 xAvZPDTabbfGG6vTqj6j4i+2XOhWyjTrSO9k+z8EMHOEMHB1oyeFr1Kzfsmvac9PEU+W3tZclvrD fNed+VaK7OiVZSlVlyNe1pxh8fw8sqcr35db+ztbTd6u2vFfDT9itfh9deA7i/8AGHhDxpH4c8J/ Bzw34jg174bawItU1D4HeKvEHinwR4m8I2yfFCSx8IavbXOs2M23WLPxzb6frXh7TPEWhJpWoPeL cZ0cu9k6bdSnUUaeHhNToyak8NOc6c6a9vanK8l8SqpSgpxUW3dzxHPze7KN5VJRtPb2qSkpPlvJ aPblum07o6P4h/sn6h8QPiZ4/wDHM3jvw7peneO7j4JSRxxfDea58f8Ag+P4N6zea4svg74hv47h h0fVvEl1qF3BJqqeEHbSbJ44o7W+nV7qSquAdWtWqurCKqvDWtRvVp/V5OX7ur7X3ZTbfvez91dG 9RQrqMIx5W3H2m8/cl7RJe9Dl1Sttzavsc3N+xUYrC90zSfGPg60S2+Itr448Ka/qXw01rWvGeia XJ+0p4K/aT1/wbqGuy/FO1sdT0nXNb8EaR4fnuNK0Pw1PPb2Gi65rkev6vo4e8h5do4qpT0re0pz lQlOrCLxlPGTpubr2lGUqcYaRg3aMp88o6tYjW7jJ3jyyXPaLfsZUlJLkbulJy1b3aVkwvv2KzqG v63r+o+MfB/iEeI9Z+PMWt6B4q+Gmtat4W1LwF8dfGPh7xjqHha80ez+KWk/a9V0a40S40ybW7u5 m0DxNpmr3UWseCN9rYPbjy685TdSnPnliueFSjOVOVLFVIVHBxWIjeUXBpyb5ZqT5qeiD6xpFcsl yqlZxnaXPTi48yfJone9t4taS3IvGP7FepeN7Pxro+r/ABUsIdD8cXX7V6ahBYfD65h1S10f9p3w fF4UjsrTUrjx/dW39o+BmWbUJNTm0qWDxSskdmuleG2ia7mKmXSqqpGVeKjUeOulRd1HG0/Z2TdV q9PV35bT25YbtxxKi4vkbcVQS9/S9GXNdrl15+11y73kesaL8C/GsHxh0b4w638Q/DcWsQRra+L7 T4feB/E3ge2+JGkReC7/AMO2GheN7G++KnjDQNbt9C8R30fjDw3r15oU/jHQvsFr4V0/xFD4dn1e 21XeGGqLERxE60ObRVFSpTpqtH2bgo1E69SMlGb9pCTj7SNuRTUHJSzdWPs3TUW19lzkpOD5k24N Qi1zK6kr8rvzNOVmudt/2ZfE2j+N28b+HPiToNpdaZ8RPiv468JWetfDvUNah02D402C/wDCcaL4 gNv8RNHj8QGLX7ew1bw1qthbeGrnStPt7nQr6LWYtSubwR9TqRq+1jWgnGtXq01KlKSSxK/exnat HnfMlKDShyq8XzczZXtk48rjLWEIyamlf2b92SvB8rtdNXd3rpsdBbfs2pp/hz9mv4e2HjfVI/ht +zzoFhpB0pl8Qaf4z8Y33hz4czfDjwfrB8feFPGHhe68OvpOnX+r32q2EOjatZ65dX0KqulrYQMb WDtDB0lVl7HCQUeX31UqOFJ0acvawqQceVOTkuWSk30smJ1rutNxXPVbd9HGKlPnkuSUZXu0rNyT Vutz5N0z9j/4iW99rnwAvPG9vP8AC7WP2Wde+DV549i+GOrQfZvBPiH4q+LrvT/AHhe7vPiPqcWl eK/BHw71+Hw7o2v6lPrsc0cGj+In0X7TpN5pt7wxwFZSlhXUToywMsO6vsZK1Odeo1Sg3Wly1KdK ahGbc9oz5bxcXu8RGyq8vvquqvLz7yUIpzlaKupzTbWjV2r2dzsNM/Zl8cfFOD4m2vijxCvgXSdO +PH7Tvin4f2d14Bv5NWubr4rfDjxt8JdJ8Uarqs3jKyj8SeEIfD3xJ8Ta9b6LY6foFzq2pjQ4brW 7P8AsCcanpHB1a6rqc/ZJYrGzpXpPmbr0qlCM5N1Fz01CtOSilByko+8uR80utGDhZc79lRjL39P 3c41GkuV2lzQSveSs27XZ6RoP7KPi3w14gi8aaZ8VPDkni/TfiL4b+IGhXF/8MtVn8PW7ad+zP4c /Zs8Q6Pq2hwfFG2vNUj1jTvD0Pi7SNRstd0W98PahKdHmbXNNe+a/wBY4GpCSqRrw9pGrCrG9GXJ pg4YOcZRVe8uZQVSLUouD933lzc0OvFrlcHyuMou09Xes6yabhpZvlaad1roznfHv7Gvjv4ma14i 1nxh8fZdTk1bwz8aPC2lpL4J16SLQ9O+KqeG7jRILXSp/ipL4WtrXwBqHhTR4raLQ/Deg3vivQ47 m18S6nc+ILn/AISiGa2X1a8pyqYpvmp4mml7OXuqvyONk67hak4Rty04SqRupycnzjjiIwSUaVrS pyfvLVw5r68nM+dSl8TlytprRcp28v7M3jC4+LB+NN18TvDDeM7bxd4Y8W6PbQfDPVovDdrPpvwd 8V/CDxLp+o6bN8Ubq+1G31yz8Uf27o1zaato+oeG7zTYtPnuvEGn32pR3On1Ko6/1l1oe154TivY y5E1h50Jpr2zbUlPni7xlBpK8k5Xn20fZ+z5JctpJvnXNrUjUi17llbls7qSle/utK3HaV+xTqHh /SBoWjfFSzGnwRfsbpZvqvgC41C/jb9kv4vz/GJzc3Ft480y2li+IGsXE2kwWtpZafbeCdLKR2kW v+VGgzWWuMeWNdW/4T7c1Jt3wGI+satVUn7WXu2SXs47cxTxKk7uDu3iG7Ssv39P2f8AK/hWt225 Pe3XtfDf7KjWfw8+Ofwy8SeOVn8H/HHwFf8Agq+8L+CdF1vwn4R8G3viLSPGWkeN/Fngbw7rnjbx wnhO98Zp4qtLvUfDnhy90nwfYX/h611DTtEi1TVtf1DUtIYG1HE0Z1fcxNJ03CnGVOFOU41I1KlK MqtXkdTnTlCLjTTimo80pylLr+/Smo+9Tkpc0mnKdnFxU5JR5uXlspO8mnq7JJOj/Zk8R3HxL8F/ FbWPiVo934m8OfEPwf4w1m2074fXelaFrejeDPgx8VfhFYaHpumnx7evoGrXh+L3iTxFf+JJLrW4 XWy0HQYvD8dpppvJz6lN1qdeVaLnGtTqSSpOMJRp4evQjGMfavkk/bznKd5bRjy2Wq9suSUFB8so Siryu05VIVHJvlV1+7SS03bu72JvGv7NfibxH8TNU8caJ8StH0PRda+Jvwc+KmoeHdR8A3WuaifE Hwn06PQpLO28RQ+OtFt4dJ8QaHaaci27+HprzS9XtpNQN/qNlcNpCupg5zrSqxrRjGVbD13B0nKX PQXLbn9pFKMopfYbjK7u0+UcayUFFwbahUp8ynZWqO+zi9U79dU7aNXOJ8MfseeKPDN74Mmsfivo Vlo3gzxDr3iPSvA2mfD3xGngPQ7zXvg14v8AhTe2ngPQtX+LmtXHgHQLrUPF8/i+fwlo+pTeFbM2 Nvonh7SNClutV1/UcoZfUg6bVeKjTnOcaapT9lFzw9Sg1SjLESdKLdR1PZxk4K3LCMLyk6liFLmv BtySi5Oa52lUjUTm1TXPJKPLzNKTvdt2SXl3jn9lT4i+BdM+GF14X8XWXiWfw94R/ZN+Et7rWm/D DxJJeeCrD9mKy+OesWnxSh0fwz8UYfFmrJ4v1j4k2/hS+8J+F5Z9Q0ew1AT3l3r/AIePiGIY1cDW pKi4VFNwp4Gg5RozbprBLFSVflhX9pL2kqyhKELuKd3zw5y414TdS8XHmlXnZzXvOs6ScLuHKuVR 5uaVk7PZ2PZtP+BHivx/8F/gF4a1Ow8FfCvUPhB8ST4uTwveeEtZ8feG9f0Hwn/wn3hTwmLrS9W8 fafr2l3XjHw7rmkeONYh8Q+JvE+v6Lq15d6Jrd1qmrxXmrHoWGqVsPhYNU6EsPW9pyOnKrCcafta dO8ZVVKPtISjVkpTnKMm4ycpXk8/axhUqyXNP2kOXmUlBpy5XLaLT5WnFWUU9JLTQsWn7Mfjy38Y fC3x9d/FTwJHr3wcvJtK8FWvhz4GL4c8O2Hwr1e58V2/ib4aLoNl8SbpjD/wiuo+CfDfgbXobxbz wQfAKaglhr3/AAmnjOw1hrBVVUoVXXpc+HdqahheSCoNz56PKqz+xKnClO96Xsk7S9pVU17aPLOC hK1TWV6t25rl5Z3cP5lKU1tLntpyxa8P+HX7JPxA8e/B34dTeMvF9t4C8V+F/h9rXgPw7od38Nb8 TeHtO1j48fD34r663jCzk8f2svijUrpPhB4S0bQrixufDVjpkF9rmu/ZdTOswWFhzUsBVq4al7So qVSFKVKMXRd4qWKpV5uovapzk/q8IxacElKc7S5+VazxEI1J8sXOMpqTfPu1SnTVvd0X7yTa1d0k mrH0F8PP2afF/wAM/G9/450H4m+HLrUNf8QfFO48S22qfDfVJ7a58K/Eb43+LPjZaaPoog+Jlu2j eIPD1/428QaBJ4lm/tSw12zfTL+78L2s2lRW0/VSwdSjUdWFeDc513NSoya9nWxM8Sox/fLlnF1J wc3zKacW4Lls8p1oziouEkkoWtNfFCmqbbvDVS5U7aNO6UtST4P/ALNniH4Qax4I1hfiJo3iD+wv hpe/DXxbCfAV9pX/AAkdlF448S+N/DepaBJ/wnupf8IpdaZceKb+w1eLUF8XQ65BFDLanQnBWnhs HPDypy9tGfLRdGovZOLmvazqwcf3suRxc5KV/acytblFUrRqKS5GrzU4vnvZ8kYtP3FzJ8t1bla8 z6Uuh198+/Pp0JHvj19a7zA/Dn/guUMfs7fCrn/mtdn/AOoL4056/wBB+HNfM8U/7lQ/7Cl/6aqn r5P/AB6v/Xr/ANvify+V8KfQhQB/o4V+wHw4UAeL/tEfE3Ufg78F/H/xF0eysdQ1vw/pMEehW2qe f/ZP9u63qlh4e0S41gW0kNw+j2Wq6taXurpBcWssmm290kd3aOwuYubF1pYfDVa0UnKMVyqV+Xml JQi5W15U5Jy12vr1NKUFUqRi72b1tvZJt282k7efc5i/8ZeKvhV4n0LwfrWu+IfjR4j+Jsuq3vgn QYdE8GeFb/Q9O8D+HE1Px5c3WsWr6DpF3pc91caTbeHLS8tW1WLWNe0/S9Q1a40s33iDSYdSpQnG nKUsROs5OlHlpwlFU4c1W8lyxau4qCtzKU0pNq840oxqRcklTULKcryabnK0dNWnvzPayuld2fA+ Gv2z/Cvi7UfDcug+BvFl74J8Uap8DrDT/HIu/D8VpHb/ALQ3hCw8UfDu8utEm1OPW1bz9TsdH8Q2 0NtOdJmuY7uKe/hWdIcoZjCpKHJTm6U5YZKreNrYump0W435t5KMlZ8rd7vVFSw8oqV5R5oqo3H3 r3pStPW1u7TvrbpfXntD/bu8Ia7DY3sXgfXrbTfEekfCvUfCF3Nq+jTSX9/8YdV8dWfhvw34ltrN 7lvB/iTw9pXw48VeJPiHot7Jfaj4V0u2s7WC21rXL6PSVmOZ05WapytONF025Ru3iJVVCE7X9nOK o1J1Yu7hFL4pvlTeGkr3krxc1LfamouTX8ybmlB7N3bcUri6t+2zbSaL4mfw78Nde0/xVonwq8W/ Ee28NfEjUdM8C6vqKeGfCXizXLm60LRdTuFvvHHhLSte8M2/hXxLr/g2bUrjS73XtIv00ybQ7iXW LclmScZ8lGSqQoVKvJWapSfJTqSfLFu9WEZw5JyptuLnF2cHzIWH1jeacXOMHKCc0uaUUrtaRk03 JKVrpProbGiftRarb6/daR4u8LX8PiXW9N/Z7svCHgjSbrRrqxufEPxlPxKlhuE8UPLbyw2MVh4F 1XWdfTULWRtE0XQg+kLrmrai2lmo41qbjUg+eSwip04uLTnifbfbuna1OUp3V4xj7vPJ8onRurxa svauUne9qfJf3f8At5JWeretkrkWq/ts+HbBNXvLT4a+NdT0vwtoHiDxB40uor/wpBdeFYvA3xl8 R/BD4h6deWU2ubdR1Pwx4r8LavdW0ejXWoWmvaVbNcWd7DI9vHcKWZQXM1RqSjCEp1HzQvT9niJ4 asmubWVOpCT91yUlqmur+rPT343bSj8Vpc1NVINO20k1vZpvVbst/G/41+OfhN8bvB8s19an4Et4 Kt0+LA/s+yOreBZPFPi4+F/DnxZsdUkhkkOi+Gdem0fS/G1hqKXWj6d4W1m98aTLbQ+FNQj1J4nE 1aGKp6r6r7L9/oualz1OSFdS/lhPljUUrxUJOo7Km+ZUqcalOW/teZ8m9p2jzOm13kk3F7uS5ftI ofC39q+3ufAfw5m8Zadr2vaofDP7MWmfE7xxZ23h/TtK0z4l/tK2fhW28JabFoyXWnzy2Uuu+LNA XWJ9OshBoNp4o8PtEmqpHr8+iKjjk6VF1FKUuTBRr1VyqMa2MUFTXLdNpznDmaXuqpC3N7/K50Pe nytJc1dwjdtuFFvmd9dbJ2Td3Z7XV/IPFX7ZPxWh+F+p+MYfBlj4a8ST/B39rLxh4Y0y2v8AStd0 O71P4JfErwR8P9M1TVbq8MN/ZT6GvieO/OmQR3dh4oc6uJ30lLbSIrnnnmFf2MqipqE3h8fUgrqU XLDV6dGLk37y5efmsrqfvXtaN7jh4c6jzcy9pQjK907VIyk0raa2td6x031PbPCfx/8AEWk+KfGn wq1DTPFXxF+KGl+OL/QdC8P31x4C0aVrHRfgb8L/AIua4bjxVpFl4a8O3NrbS/EXSPD9nfS+H9Ln l8S65ZafNbr4ds7zxbD0wxU4zqUHGdauqrhCDdKGkcNQrzbqRUItJ1oxT5E3OSTSheoolSTjGacY QcU3Jc71dScF7rvL7Lejdku7sY/xT/bNfwTa/EbRdI8AxzfELwl8NvHfxC0rw9qfjfwPqy/Z/h34 z8C+C/EVv4wh8FeJPEE3haWWX4ieHNf8PWNzdHUda0WS7iv4fDut2N7pVtNfMfZqtGNL99To1ayh KpSl/CqU6c1UVKc+Rv2sJwTd5Rb5lCUXEIYfm5W5PllOMW1GS+OMpJxckub4JRlpZO2rTudfo/7R +oReOfFXgHWPC+rXvji4+NFp8L/C/g+0utASw04wfs8eEPjjrF3N4q8+3S70W10XUr24mv72xTUv +Ek1O38O2djcaZHb6vWkcW/a1KUoSdV4lUYU04WVsJTxMm53V4qMndtc3PJRScfeJdL3YzTXL7Nz lJ3u/wB7Kna2ut7aJ2snJu+hi6X+2r4Y1u50a50n4e+Mrrwrqq/s1y3PiR7zwxA+hL+1B44u/hh4 Ks9Y0V9Za+OsaF8QrY6F4ustIfVrTTrNbjVrTVL9YY7S4lZlCTi40qjg3g7zvBcv12q6NNSjzX5o 1fdmo8ySvJSdrOnh2r3nHmXttLS19jHnk07bODvFu17pW6mN+0R8aviN4W0/9sbUfBfiBfDo/Zr/ AGUv+Fq+Goo9J0TU49d+ImreHPjL4kR/Eg1rTdSkl0LRbX4d+F49P0/SJtIluZNZ8RHU7q8X+yRp 04vE1oLMHTnyfU8D7eHuxlzVZQxE/f5k7xiqMLKPL8UuZv3bFKnB+wUo39tX5JXbVoJ017tmtW5y u32Vut7M3xR+I1n4q+Hngey8UePIo/jF8ZLj4cWGs/E74d+FvDfijwjo/gn4N+N/i14x1zwrFpmk aVonimPxUPDeleHPC9zr3hpU0S6m8SazcWviK00eHTbg9vWU6NJTq/7RiHRU61KnGdONLD1cRUnD lUY1FU5IwpuUPdbnJ83LZnJBxnJxj+7p89oTk1JyqRhFSu21y8zcrS1sldN3OR+Ifxj+M3wO+JN7 pHi/xxbeL/hVpnw38M2Xinxi3hPQNE17wV4x+L/jv4z6L8JfH+o/YbY6RLoenTeBfCnw58ZpLp66 PN4h8Uab44TTfD3h2013TIYq4jEYas41KqqUFRgp1PZxjOnUxFXERoVZNLl5F7KnRqe7y89RVLQg pRKjTp1YXjHlm5y5Y80pKUacabqR73tNzjrzWTjeUrN+v/B/4l+N9Q+IHg/wh4q15vEtj49/Zp8G /GKzubvTdG0++0jxPbalp+ieM7SBtD0zSra40TVx4k8Oajp9tdwT3ul39trCrqFxp9/Y2Olb4etV danTqT51VwdPEJtRTjNSUaiXKo3jLnhJJpuLUves0lnUhFRlJKzjWlT3bvFpuL1vquVp666aXu39 Z13mAUAFABQAUAFABQBFL93P1/X/ADz39KAMG6AOc8fz/EdM/X2oA/Dj/guWMfs7fCr/ALLXZ/X/ AJEbxr79fU/0xXzPFP8AuVD/ALCl/wCmqp6+T/x6v/Xr/wBvify818KfQhQB/o4V+wHw4UAc/wCL PCnhzx14Z1/wZ4v0ey8QeF/FOkX+heINE1GMy2WqaTqdtJaX1lcKGV9k8ErrvjdJomIlhkjlRHWK kIVYTp1IqUJxcZxe0oyVmn11779dxxk4yUotqUWmmt007pnlQ/Zv+FJuP7QnsvGl5rK3kV7b+JNQ +LPxZv8AxXYvF4euvCot9N8VXnjabxFpmnzaDe3Vnfabp+p21hqVxPJqupW93rLHUDh9ToXvao5X upuvXdRWg6do1HUc4xcW04qSTb5neWpftZ/3bWtZU4cr15tY8tm79Wm1stNCq37MfwYgEjaT4Vn0 SRdW+Fuv6db6X4q8bafoelax8E9Lh0j4Vvp3hzTfE9hotjpPhSytbOH/AIRzTrSy0LXVs7Y+ILDU 5YIZoz6lht1TcfeozSVSqoxlh0o0LQU1FRgkvcSUZWXMmP21TrK+k07xi21Ud53k023J9W21rZrU 8d+EP7Ic3hHQdN8J+O/F3iDxB4V0Xwv4S0630Sz+I3xLvhP8QPCV7DdW/wAXPDus6prVt4k+FesT RwNa2/hPwNrP9mWltfXtve6zrUC2cdtz4fAOEVCrUnKEYQXKq1Z3qwd/rEJuSnQk9V7OlLlSb9+S slpUxHM3KMUpOUnfkh8Mt4SVmprq5SV29bJtnus/7PPwqvb62v8AV9I8QeJJLNtQltLbxb8QfiH4 u023u9W8Cal8M9X1KLS/E/irVtPXVdW8DazrHh/VNTFt9u1CHV9VvbyebVNTvr646fqlBtOUZztd r2lWtUScqToyladSS5pUpShKW75pNvmlJvL2s1s0r2u4xjFu0lNK6S0UkmlsrLokZWnfsvfBfTEu hb6B4knuLqy+HtidR1T4m/FHW9YtIfhTf6zqXw+l0nWtZ8Z3+q6Je+GrvxBrJtdR0e8sb+5ttQns NQubuw2WySsFh43tGbbVJc0q1aUl7BydJxlKo5RlBzlaUWm03GTcdBuvUdruOjm9IQSvNJTulFKX NZXvfVX3I9Q/ZX+Bep2GsaZd+EdSWy8QeC7/AOH+tw2njz4h6adU8N6v41vPiNrIvZdO8WWs0+v6 7421HUvEOveMXkPjHXL3UtSXVtevLbULyCYlgcLJSTpytOm6UrVay5oSqOrK7VRNylUbnOp/Em5P mk7sFXqqz5lpJTV4wdmo8iteL0UdFH4VZWSsj0bWfhf4G8R6zq2u6/ojazea94BvvhfrVtqeq6ze 6HqvgbU7uW81HRNQ8M3GoyeG7tr6WeaO71WbSn1qe0lk0+XUWsGNsdpUKU5SnOPM5UnQknKTjKlJ 3cXBy5Hdt3ly8zWnNbQhTkkkna0udNJJqS2albmVu17X1tc4/S/2cfg1ozeGP7N8IPbQeENL+HGk aNp//CR+K5dIe1+EKp/wrGfXNGm12TSfFOq+B5Yba78P634nstX1mx1Cy03UkvzqGmadc2uawmHi 4Wp25FSjFc8+Vqh/Bc483LOVLRwlNSkmk73jFqnVqPmvLWTm27Rvep8dna8VLZqLSabVrN35nWf2 Q/gHr8WpW2qeFfEU1nqlh8TtKuNPt/il8WNO0y30r4y+IdH8WfEvS9K03TfHFpYaJpvijxFoGlar PY6Nb2Frp9xbMujxafDc3UU0Sy/Cz5uaE2pKsmvb11FLETjUrRjFVUoqpOKk1FJJ35bJtFKvVW0l vB6wg7ummoNtxd2k2ru7fW50mofs5/CXUdd1zxRLpHiS08S+IvFNv4y1TxDpPxI+Jeh623iK38Fa R8OTd6fqmjeL7G90W3vfBWgaLoOq6Xos2n6VrEOl2N3qlld6jbRXi3LB0JSnNxmpzmqkpxrVoy5l TjRupRqJxTpxjGUYtRlZOSclcXtqllG6cUuVJwg1bmc9U4u/vNtN3au7PUwj+yZ8BHbWjL4O1SeL X9D+LPhrULO58f8AxHuNOTQ/jl4k07xj8U9P0zTJvFz6foieKvFmkad4kebRrawudH1q1j1Dw/Pp Vzudo+oYV816cnzwrwknVrNcmJmqldJOpaPtKiU7xScZK8HFj9vVdveWjpyXuQvelFxg2+W75Ytr Vu60dzatv2b/AISWt1f6lHpHid9Z1LxjpfxBuPEFz8TPideeJY/GekfD6L4U2viCw8SXfjGfXNKv pvh1EvhLVBpeoWcGt6S00esw38k80slLB0E5NKpzSqRqubrVnP2kaXsFNTdRyi3S/dy5WlKN+ZNt sXtqlrXVlFxtyQtyufO048tmuf3ldOz2sUx+y58DUhe2t/B97Y2jxfBeBbLTPGvj3SrGCL9nrxJ/ wmHwfSzsdO8UWtpYjwh4n/4nY+xwwHXr8mXxOdayQV9Sw2qVNpP6vpGpViv9ln7TD2UZpL2c/e0t zPWfMHt6n8yf8R3cYt/vVy1LtxbfMtNdltYg8Zfs/wCheN/F/wAUrvxG0Ws/D347/CXQ/hH8V/Bc t7r2h3d/pXhuXx99kvtF8R+HNU03VLT+3tJ+ImseG/E9gk1o8+n2ekXWnanZy2+pWmsFTCxq1K7n 71LFUI0K9NucW4w9rZxnCSa541ZQnHS6SakndSI1XGMEtJ06jqQlo1eXJdNNNaOCcXrrdNPRrXu/ 2dPhRfyz3d/pfijUdVk1vw14jttf1L4l/E3U/E2ja14Qstb03w/e+GvE2o+MLrXvCwstO8TeJNPn tPDuoaZY6pYeItfstWtr611rU4bqng6Du3GblzQmputWc4ypqUYOE3Uc4WjOatCSUlOakmpSuvbV Fs0laUbKEEmpNNqSUbSu0n7ydmk1ZpDbL9m/4O2eleMNDk8M6jrGlfEDwVe/D3xtY+KPGnjrxdB4 n8Kalr/jbxPf2Orr4o8S6v8Aary8134jeNb+fXWI15zr09sdT+x29jb2osHh1GpDkco1abo1FOpV qc9OUqk2pc85XblVqNy+L3nrZJJutUbi+ZJxkpRcYxi00oxTXKl0hFW20va972PCnwit/DvxJk8d C4toNN0P4YaB8IPAPhuyF7ONC8KaRqs+r6jealq2oXMtzqeo61NF4ftFgaFRplr4cSRr/VLnVbmS 3IYfkrOrdWjRjh6UFf3YRk5Nyk23KUvcXkoXu3J2UqjcOXq5upJvrJq2iWiS19b9LHtVdJmFABQA UAFABQAUAMk+6f8AP59vzwPegDDuh1x/jn9CR7/j3oA/DX/guZ/ybp8Kv+y2WfH/AHIvjX3/AKD+ efmeKf8AcqH/AGFL/wBNVT18n/j1f+vX/t8T+XivhT6EKAP9HCv2A+HCgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAZJ9w5/z+f+f1oAxLnv8A07+3PGfXPfr2oA/D b/gud/ybr8Kj/wBVssvb/mRfGvJwTz7n8+or5nin/cqH/YUv/TVU9fJ/49X/AK9f+3xP5dq+FPoQ oA/0cK/YD4cKAGu6xqzuyoiKzu7sFVVUEszMSAqqASzEgAAkmgDyHwZ8cvh942vPiJaWOq2+mD4b +OLzwJql7rOq+HItO1m9svAfgj4j3Gs+G77T9c1KDUPD8Xhrx/oUtxd3LWF7Y3aahb6jp1mLZZJu eniqNV1UpJexqulJylC0mqVOs5Qak04clWLbdmnfmStrpKlOKg2r88edWTbScpQtK60d4Pv01NXx 98XPAvw58N6x4m1/W7OW10TVPCehXllp19pk2orrvjzxDpXhTwdpMsd1f2dpp9x4g1/W9MsbO51i 803ToluTfXt9a6fBc3cNVcRSpQlOUk1GVOLScW1KrONOmndpLmlOKvJpK920rsUKc5tJJ3alK7Tt aKcpPzSSbdtfVj/AHxW8GfEbQr/W9D1Wzhk0G5vdN8X6Nd6roNzqfgvXNJkmt9c0PxJNoWr61okV 9ot5a3llf3Wm6zqejPcWV01hqt9bxfaCUq9OtFyjJLlbjUi3FypyjdSjPllKN4tNNqTjdO0nuE4S g7Nb6xdnaSezV0nZ3vqk9djr28R+HktP7QfXtGSwMFndfbW1SxW0+zajPJbWFx9pM4h8i+uYpbez m3+XczxSRQs8iMo054WvzRto78ytaWzvfq9n16E2d7Wd9dLO+mr/AOCcX47+K/hfwCmhvqAu9YOs /ELwT8NrmLQJtHu7jw7rXj7U4dI0K98RW95q+nzWWk/bbq0W7e2S91OOG6jurfS7q2S4lhzq4iFL lveXNWp0XyuLcJVZcsXNOStG7V95Wd1FlQpynzWsrQlPW+qgru2ju7X7LTe+9TxH8Z/BOgXvgiyg vP8AhJz458d6V8PrS48KX+gavBomsa1o/iDWdOu/EIbWra4tdLuIfDeoWyTWFvqV4btoQLE2wubm 2U8TTg6ST9p7WrGknTcJcspRnJOfvJqNoNXSk79LXaapyfM9uWLm+ZNNpNJ20d2rp6206npdzqWn 2dxZWt5f2VrdalK8GnW1zdQQXGoTxRtNLDZQyyLJdSxwq0rxwLI6Rq0jAKCa2bSaTaTk7JN2be9l 3dtdCLN30btv/wAEzZvFfha2vLjT7jxLoEF/ayJDdWM2s6dFeW00ttNeRxXFs9ys0Mklnb3F0iSI rPbQTTqDFE7LLqU02nOCkt05K6bTeqvfZN+ibDllvZ+tmcx8SPidoHw0+HOtfFDUbbUvEHhvQ7Cx 1WdfCx0q+vbvTb68s7Vb7TjqGq6Vpt3bwxXqX8jDUkaayilayS7uWgtp4rV4UaMq7vOEUpPk5ZNp tK6vJJrW++17Xdk6hBzmoJpNtr3r2vrvZN+W2+51zeIdASwOqvrmjppgujZHUW1OyWwF6Lo2RtDe GcW4uheg2hgMnmi6Bt9nm/JWnPC3NzR5b25uZWve1r3te+ne+m5PLK9rO9r2s723v6eY631/Qru9 bTbXWtJudRWS9iawt9Ss5r1ZdMeCPUomtY5mnEmnyXNsl6hTdavcQLOI2ljDCnBuylFyu1ZSTd4/ Fpe91dX7X13Dlla9nbTWztrtr59O5518Q/jV4J+HWm6FfXt1/b954p8Wz+BPDOi+H9T8Mrfa34ut NB8QeJ73QodQ8R6/4e8Nafe2Wg+Fte1C5/tzX9Kij+wG081r+4tLW4xrYmlRjFt87nUdKEYSheVR RnNxvOcYJqMJt8047WvdpO4U5TbS0suZt3sotpXdk21eS2T3LPhv4z/DjxNcRaZB4m0/S/EP/CDe FfiPf+F9eubbS9f0fwl4zTxA+g6lqtpNO0NuJ/8AhFPEQuY4rmc2Q0qea6MVvLazXDhiaM3bnUZ+ yp1nCbUZxp1efklJN215J31duVt6NXTpzWtm1zSgpK7TlG10uv2l63PR7G/sdTtLfUNNvbTULC7j E1pfWNzDd2l1E2dstvcwPJDNG2Dh43ZTg4JrZNSSaaaeqad0/NNbkO6338y3TAKACgAoAKACgAoA KACgAoAZJ90/5/z+JH1oAxLnv7/jn9Cf8DwPcA/Db/gud/ybr8KR/wBVssj/AOWL419z/n8q+Z4p /wByof8AYUv/AE1VPXyf+PV/69f+3xP5dq+FPoQoA/0cK/YD4cKAPHf2gPh5rfxW+D3jn4f+Hb/T 7DWPEWn2kVmdXlu4NE1H7Dq2n6pceHvEE1ja397H4d8UWtjP4b8Qva2N7Oui6rfGKyunxbyc+KpS r4erSg0pTSS5m1F2kpOM2k3yTScJ2TfLJ6M0pTUKkZSTaTd7b6pq6vpzRvzK/VI+UtO/ZW8b6z8T V8T+PPBHwNn8D6n+0j4g+M+veDoNb1bxNZReHNe/ZC8M/AKTRLfSNX+FmlaPrmqN410e61++F/8A 2Tp93pTRalvTVXOmwcCwNWVbnq08M6UsZPETp80qi5J4CnhXHllRjGUvaxcneycfe+LQ3deKhyxl V5vYqmpWSbksRKrdtTbS5XZbu+m2pwet/sg/HbXvEp1u8tPgLHZHV/BdxJoWk303hnQPsPgr9rzw F8fYWstF0D4I20sMuseDNA8T6beQeIdb8YajH4x127mm8S3+n6/q19a5yy/FSnzNYW3NT91Pkjan j6eKuowwys5U4zTU5VH7STbm1KTVLEU1G16t7S1er97Dzpbuo9pSTTSS5UvdTSR9N/Dj9n3VfDOr eObbVb610TwxqHxf8Z/EbRl8C6ykH/Cc6H451RtcvPCPxR8M6j4JjtBpeiXE95pFna6X4k1WHVNN urm4kfSpLhrNeylhJRlVUmoQeIqVo+yn/FjVlzuFeDpaRi242jOXMm3dMxnVUlFq7kqcYPnXwuKt zQkpXu99UrPueH/Df9i7xx4S8R/DeXX/ABR4V1jwl4YtP+Fd+J9KWTWLm+1b4M/BjxN4Q8SfsmaN aS3umpbSa34R1Xwdc6544hu1ispLz4j+OtOsNQ1uH7JqVzzUcuq050XOdOUIL2VSN5Nyw+HqU6mB irxtzU5U3KqnZN1qqTno3pPERkp2i1KXvp6aVKikq7dne0lK0Xv7kW7aozdJ/Y2+IGkW/hZDB4J1 zW/C/wARvAuo3/jHWviX4sM/jjwJoHxrb4ta7PrfhS3+F39m2XjG/kNzNGl3rHiWO613XvEDJ4i0 XT7u5GoqOX1Uqd1TlKnVpN1JV6jdWnHEe3m5w9hZVHdtXnO8pz9+Kbu3iItyd5JShNKPJH3ZSp+z Vpc9+VfKyS91vbU8H/swfGbT5fDF3q+h/BPQNUHxn8B/E7xdq3grxn4qR7LQPD3h74h+DLbwH4F0 2b4SaRY6Z4a+Fng3VfA2j/DbSZDa2+v6mvjjxR4hn0HWNbuDqzp4LELkco4aMvrNKvUlTqT0hCNa mqVJewilChTlTjRi/jl7Wc3CUnzKVam+azqtezlCKlGO7lCXNJ87vKclJzertypXS07jxR+ypr+q fE7SPEV34g1P4meEW8NfDHQb1/H3xH1TQfF/hfU/hv8AFvxP8VbfxRolx4d+H+pw6/c6jqOs+GxJ pyal4HbzPh14Wt73VdQtWL6drPAzdaM3J14clGDdatKNSEqOIqV/aRcKT525ShpzUv4ME5NN2mNd KFl7klKb9yCcZKdNQafNJNWSevvfG3o9+ftf2WfGz6F8KPDGt+EPgtrjfDb4y+HfFes/EDU9c1W8 8X/ETwTY+IvHviHV7zX7Gf4XSCPxVcaj4si1x9An8Sanoeq+I9Q8QXsmvaSphk1CFgavLQhKnhpe xxEKkqspSdStTU6s5Oa9i7TbmpOLnKMpub5lo5V7ePNUkpVFz05RUUkoxk4xStafw6WbtdJLRhL+ yZ8QLr9mbX/hVJ4m02w8U3fhr4g+GNJ8DWXirUJfgf8AYPEfxK8T+LfDp1FJPAFt4hjn0/w9rNho dxJZ6O1rYJp8VnZafeWltHcTn1Cs8FOh7RKo4VYRpqpJ4a0686kG70lO8YSUXaNklZRe7Xt4+2VS za5oycml7S6gov7TWrTeru76swdb/Y68Z6j4k8R+LbbTvh9aaR4o+JnivxTefBLSfGGseGvAVrov in4F+Bfg3eajF4ktvhhq5/4S+6bwlrOpaj9l+H9lZSaV421vTEvptSS41vV5ll9RznUUaKjOtUm8 MqkoUuWeGpYdy51Ql+8fJOT/AHSXLUlG/NeUq+sR5VG87xhGPtHFOTcas6iVnNe77yteT1inboqi /sYePLfVUudFfwB4VmX45+LPF8PjTTPFXibUfiBpvwz1v9irXf2Z9KtodZv/AALFqGqeLdO8b6pY eOptN1HXBpVxFpUepTeILjX5diL+zqqd4ulB/WqlRVFUm6qozy6eDS53S5pVFVkqtnKz5eZycg+s Qtrzy/dxi4uMeVzWIVZu3NaziuS6V9bWsbnhD9kzxh4evvglrDeFvhpb6l8PviZ4V8S+NIW+Ivij XtM17w94O/Z8+Knwa0i58O6fc/CjSbDR9ZW+8d6HcLpL2QU6H4bs1vvFmo3en6Va2twwNSMsNL2d BOlWpzqfvpzUoU8LXw8XBOhFRnerG8bfDBXqSaikpV4v2q5pvnhJRfLFNOVaFR3fO217r1vvJ6K7 b5Lwv+xr8SNB8HeGPDur6D8LvEF2P2cf2T/g/wCIb7SPiR4r8Iav4V8Y/sx+PfHPiu08Z+AvEMXw j1ibVjfL4v0rU9Kg17TNFszqPg3T/D3iPS9X8Oatdva5wy+tGnCMoUJP6ngcPOUa06coVMFVqzVS lP2E+a/tE480Yq9NQnGUJO1SxEHJyTmv3teouaEZKUa0IR5Zr2it8LTau7S5o+8rH3r8HfDHijwb 8NfCvhvxtd+HtQ8W6dZ3X/CQah4W0uw0fR9R1O81K9v7nUEstL0Xw3pp1C+a6+163faf4c8PWeq6 3NqOq22haPDepp1t6mHhUp0YQquDqJPnlCKjGUnJtysowV5XvJqEVKTlJRinZctSUZTk4pqLeik2 2lba7bdlsrttKybe56XWxAUAFABQAUAFABQAUAFABQAyT7hz/n8/8/rQBh3Tdf1PJ/DHTP16/Tmg D8Nf+C5n/Juvwq/7LZZ+n/Qi+NeuD198f/X+Z4p/3Kh/2FL/ANNVT18n/j1f+vX/ALfE/l4r4U+h CgD/AEcK/YD4cKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgCKX 7v8A9c//AF/8/UmgDCuW685znkc8/rj8D+poA/Df/guWc/s6/Cr/ALLXZf8AqC+NeevvxwPw5r5n in/cqH/YUv8A01VPXyf+PV/69f8At8T+XmvhT6EKAP8ARwr9gPhwoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAK9wRt5PUH6/r/P1oAwLlhzn+v8vX69fT0APw5/4L knP7O3wqH/Va7P8A9Qbxp156+px+PSvmeKf9yof9hS/9NVT18n/j1f8Ar1/7fE/l8r4U+hCgD/Rw r9gPhwoA4f4jeL7nwJ4Rv/E1noc/iW6tL7w/YwaHa3X2S61CTXfEek6AI7Sb7LebruP+0/PtbYwb b2eKOzae0Wc3cI/vA8x0f9obRdYvr+Oz0K8v9Mk1q+0vwle6RqFjdTeMLW2f4c2lrq9ouoto+k6f Y6rf+Pmk02a51yS1u9D0611iK8aXWI9MtJ5r/fb8vw13v+Y3/wAOX7P486Gswsda0LXNO1KTxevh qCC3/se/SbT9Q8eeIPAei+J0W31hrs6LLqegzRaq/wBkF9pc0kbS2BtLqwubt3/XbXrb/h+3XzX/ AA/6iaT8c7PX9H8TeJNL8L+ILfRPDnhDRPGn/FR2dx4e1DU9D1FtRvbzUdNt5obtLyzj8P2P9paZ LC7DUb7ztHmewuYZ3gE7q/8Aw4f1/TMjSf2jdLv4mlufB/iZna+s7G307w9by+KNZmfWrfxl4k8P u2m2drbNG198N/C1j47vbcTS3dhb+JdL0qGDULgi4mOb9NvO+v4agdRoHxc/t7VtA0aPw/eQy6jr w0bUdRaezl0i3ebw1478RQQWM8F1NeS6rDF4Ptm1HTdRsdOltbLW9P1BDNa3thLdO+rXb9QMO2+P Vouh2Wv6noMkVnd29vq7xWWoJPqEegX3wp8SfFi0uorO4t7ZLm+Fj4fk0Brc3kFpPqRurqO/jitj asm/n/T/AMvvHa/9edv1NB/j74TtZbhdV03X9LWHUrnRds1raXVwutafrb6HqmkyR6ffXcM17Zta 6vq6ppdzqaXHh/w9r2rRSGOwEU5fvpvv/wAP8/vET2fxz0S7t5rqTwf8QNOtrPTNG1fUptY0TTdK XSrDXtZ1jSdOvNQF7rcTRac0Ohanrl1rKLLodjodv9qvdTguXWzJe6vZ/dr6+fyuBFoXx00XVZrW C90HXNMGp65oXhzRbzOm3llrOra7oXgrX47O18u+S+iubbTvGL6nPBc2MTf2J4c8Q6sjOmnywKX/ AK0/z8/66hbm+MFtd+KtF8J6FoWqXNzqHjGfw3d6jeHS4bGKx0xPiDHrOqWcaav9tlW11X4ca3o6 w3tvYXMrMupWNrqdpEI7gv5Pe356gZ8Xxuih1O2g1Xw3JFpOqXXieHTtS0fVo9VuNPt/CnjCPwdq V/41s7yx0Wz8JWjXk6XEcx1bVkjFvqlpePbXdgI7k/r+v6fnYCDRvjvp2s6f4alTRr2C/wBZj8Ev cCR7Y6Y0nibUfh3pOr2+nXEd0+o+b4evPib4dd21XStOi1OEznTZLmNJJ4hv81+Nv8/zA99pgFAB QAUAFABQAUAFABQAUAFABQBTuWOD+Wee3r259z7Z9QDnrl+pyOnsev4HGevH6nOQD8O/+C45z+zv 8K+f+a1Wfr/0I3jT1P8AQfh0r5nin/cqH/YUv/TVU9fJ/wCPV/69f+3xP5gK+FPoQoA/0cK/YD4c KAMrW9R0jSdOm1HXZraDTraazdpLmPzlN217bx6ZFbwKkstzqM+pvZw6XbWsUt7c6lJaQWMUl5JA jAGGF8Dahpix3FjoA0640xZX07WNLtdPZNKhlsrTbe6Rq1tbXNpbW8+nadavBe2kItp7Gyt5I45L WBIzyAv/AGDwlqNxFmy8O313p9/HLDm30y5uLHVIWvryKSP5JJLa/ie41K6jdNlwjT306kGW4dgD F0HVvAEujHU9Bt9NtNJ1eyvNTVYdBm0qTWtNVftV1qVrpk2nWl9rGnzpefaVvra0urW9W7E0Ms4u AzrTV/pv1+f4gWBN4A1O8vPDuzwxfXVrDpeuXemPa6fPGI0eXS9K1Ao8TW80tmdJNjDLGZJtPW1t YW+zo1oHen+f9fIC15fgjSr241IR+FdO1J2jN1fhNIs753gtrqGEz3WI7hnitGvYovMkJS3N1GmI zKKP1/EBNG0PwZcWOnaloum6Be2M2kPa6VqVrBZ38Unh/U3e8NjYX+Jy2h3JnMkVjBMdOELJHDCs CxooBUTxB4E+23MaXGjre6brNtDM/wBiEbxa3qurz+F4JIJ2tlWa7utb1O90GS7tZJCNQudS0+eZ Zvt0SgEkFj4CWG30y203wuLJjNd21vbabpp0xZdEu3vJHRooDYR3enXt9PerGXS6hmlvbyJAUu5V PX1AfPY+BlvLHU5o/DsF7ouoTXVndpLY2ktrqGlaDq2lTF3iki8yTS/D2taxbtBc+Ymn2N7cSeXC MSKALYah4HfV9QjsJvDsWvbk1fUo0SxtdYk2rqmkwaxco6RXs8Lw6frFlaaqwkhntLW9S2uZLZZa AKXiCX4deHY7/VtftfDVo8moaFqN/K+l2l1qN1qtxqMWj+HL6W2trW41G91B9SuorDSboQzXK3Ep itXU78LT9f1/O/zAo6pffC/TdSv7PU38NWOqaU3ge+1SMQQ21xarc6xJp3gOXU3to03W1trFjjS1 vHe20uS3t7x1tIhbTl/8P/wfwA7t9T01JHifULJZY5LaGSNruBZEmvQTZROjSBllvACbVGAa4GTE HoAoWHifw9qZuBYaxp9yba5urSUpcxhTPZW1reXiwsxVblLW2vrWa4ntmlgiWZQ8gbcAAPu/EehW UC3NxqtkIHOn7XimW5/d6peWVjZXJW2851spbnUbIPfMos7eG4W6uZ4rUPMpfqBtUAFABQAUAFAB QAUAFAB6/wD6vz6/nQBl3L9c+/1/AHsc+5PWgDnrluoyPTjPft1xn6/TvyAfiB/wXEbP7O/wsHHH xqsuwH/MjeNOuCea+Z4p/wByof8AYUv/AE1VPXyf+PV/69f+3xP5g6+FPoQoA/0cK/YD4cKAOf8A FHhy18V6PJo95dXtihvtH1O3vtOa1F7ZajoOsWGvaXdwC/tL+xlNvqWm2sr297ZXdndRK9td209v LJGxuB5LH+zx4M87TJLvVPEWoxaZrOka+lpef8I0bW41PRtVk1O0Ewt/DUE8WkFJpdMPhiyuLTwv BYFJLHRrTVIYNSjTV/8Ag6/ncDotI+Euh6F4y03xVps0kUVlbeLZLjTnjt9moa/4m8San4gtdcme CG3Rbnw9F4o8daRphWIyzaf4x1Bb+W5nggnotZ373v5u9/8AMDBuP2e/Bktl4W0y31PxNpuleE/D dz4cstL0y60ezsL4XnhjxB4Tutb1a3TQyl3r9xp3iS+nlvkEETX8VrN9lEQure6LK1vK36f0wJ7j 4A+CJbexigm1ewuNO0vSNLtdRsTokV8q6Lp3jSws7uWSTQ5Yri6ebxzqurXazQvZ3Wq2unXE1o0K Xtvfll/w2n9X69+oEtp8CvCtokRGq+IprweKbbxZd6rJJoUWqajdw2zWk2m3l1Z6Ba40TUIZrtL/ AE20jtY5kv71I3hSRFifn1A9P8N6Hb+GPD2h+HLW5ubu10LSrDSLa6vRZreXEGn20drDJcjT7Sws vPeOJTKbaztomfJWFAcUAeeRfCLTvt63k2uavHHH4nu/ERs7FdNittTSX4hN8UdPsdYa9sNRu2XR /F1zfSWk2jXeiyXOm3AstQ+1bFkUt+d/xuH9fec//wAM4eABp1npkVz4gt7axtrayh+zXOk28n2N fD/gjwnqlsTFoqqqeI/DHgiPQdceFIpp7DxJ4o+xS2Nzd6bcaSrff3/rvbX1YFmz/Z78EWJ1F47z X57m/s/E1jHe3tzpd7e6fb+KL7w7f3P9n3lxpD3MNxp0nhnT4tJvHllvLWJ7iSW4uL37Nd2xb8b/ AI9f6+d2BU1H9nzw7cWE1pb67rzT3r6FBqN7qb6ZeXV5ptl4r1zW/EEBurfS7K8iu/E3h/xh418H 31xFcrD/AGT4hkkNs97bRXNDXn/wdf8Ah/vYHU6r8HvDOs+KrrxZfXmrvd3eqaPrLWKnR/sEeoaN feBL2KRJH0Z9UeC6/wCFdeHre7sbjU5rHyzfXFrbWuoTw3tsW1v+vp/l+fcDO8Q/A3wv4i1nUPEU 2s+KrLW9T1O11S6urfUdPvrMy2Gp+B9U0+GLQNe0nWfDUEVnL8PPDMEc0OjJqE1vb3Ju764ubqS4 ot169/66AZWkfs4+ANHkhMVz4jvIbX7N9lttR1GzuktVtvCeseEUS3nOmpewj7JrVzqcbR3Sy2us xWtzZSW1rAtkTlX9fd/T38wv/X4me/7MngaX7SbjXPF8j3mn6hYXDw3fh7TI2N/pOpaOl9BY6P4b 07TLPULG11fUWtp7OygFxJcyLqkeo27PAxa/fr+N79PP+tbhr/8ACg/C9raXMWl32pQXt+HtdQ1G 7WwuLm60zUBoVtrts8ttZWVx519Z6NJcWsxuGS01y+m1WSG6Cragt/Xq0399twPdqYBQAUAFABQA UAFABQAxzhfr9f6f59aAMW5fqffqM5P+JI6nP5dwDn7l+vI+vXkn6HHrxxzQB+If/BcBs/s8fCzn P/F6bP8A9Qfxpzz/AIeucZr5nin/AHKh/wBhS/8ATVU9fJ/49X/r1/7fE/mIr4U+hCgD/Rwr9gPh woAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAq3D4BGf54/H/HoR70 AYVy/Xn1/i559/Tr7/XNAHP3Mnv69Cc/l0z6/n64APzX/wCCivhLw1448CeAdG8V6Tba3psHi+81 OKzumlEaX9vo1zaw3P7iWJzJHb313EMsV2zvkE7SPi+N6tSlgMI4ScW8Zra2v7mr3uerlX8Sq768 iXXrL/gH5I/8M9/Bj/on+jf996h/8m1+Z/W8R/z9l+H+R7nM+7+9/wCYf8M9/Bj/AKJ/o3/feof/ ACbR9bxH/P2X4f5BzPu/vf8Amf1u1/QB8cFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAcnJ498DQ376XN4z8JxanHr1l4Wk06TxFo6X8fifUrZ73TvDj2jXguF17ULOOS7stIaMah dWyPPBbyRKzhc0b25le9rXV7vVL1fbdjs+z7/wDBNZNe0OSDVLqPWtJe20NgmtXCajZtBpDtpllr apqkwmMensdG1LTtXC3bRE6Zf2V+B9luoJZC611Wm+u2l9e2jv6O4tThX+N/wXjunspPi98L0vY4 dUuZLR/H/hRbqO30RLmTWrh7dtWEqw6RHZXkmqSsgSwS0uXu2iWCUovaQ/nj1+0um/X1uPlfZ/cz qz4z8IfZpLz/AISrw39kj0bSvEcl1/bmmfZo/D2vS3MGh68832ry10bWZ7O7i0rVCwstRltbmOzn meCVVfMu62T36PZ+j6PqLX+u5evbiOGOWaaVYoo0aSSWRgkcccalnkkdmASNFUszMQqgbmOM0wOb F/a3sTT2V1b3cCz3VqZraeO4iFzY3MtnewNJGzx+faXkE9rdRlg8FzDNBKqSxugL31TuBj3MnU5/ HIPJ554+n9OaAPgH9uds+GPA3Of+Kg1P/wBNyc5z/QfpXw/HX/Ivwf8A2Gf+4ah6uVfxKv8AgX/p R+bFfl57YUAf08V/RB8eFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAfn1a/sy fB34g/GT4keL/CvxV0LVfEOn6/pvhj4meAvD99J4o03wzpA+Jk/xvv8Aw5quhav408Rv4I+IPiXx 3c32ranr2nQaBph0fU9UTTPAVhqup3HiJ8PZQlOUlJN3SlFPmt73O1Zt8sm9W9NG9Lu5fM0lo11v 30tfbVet9ep1/gf9irwn4F8IeKvCemeKby3i8Z/CtvhZ4hm0jRLLRrS+sbT4XfCP4V+HdVfS47u6 gN14Y0r4XXuo6PbSSva2mofEDxj9mFvHfyiYVCKi0nZyjyuystIwitPJR013lLuDm3a/R3382/1L dn+ytoUXhTw58NNc+I+o3baP8OviB4F0D7Fc63p3iCfwZr/if4Oaze36S6n4z1/Vra/8O3Xw/wBB 09r7wjc+G/D2lt4mhGjaB4aZNNgkfslyqDl9mSW97OUHfdvSyV1Za6JBza3t1v8An5efUo/Hb9k3 4e/FPxha654g+IGu+GrrxX8Nbf4Ex6DJf2V8vjLSdFsfiL430mzubnX5bnXfEHiHQPEs+lfFKzuI r6TVlm+GUzX013ous+K47gnSjKV3JpuPJbe9uaWrd22naW9/d31YKTS2vrf0vb7r7fM8hP7Efg/x BZ+KfDNx8V9U8XLY6T8RfAXia115vFPiD7DrfxF+F8Ojrr+qaVffEF9BfxrqGgeKdE8X+OlutGl8 K+OdY/sPxXaeEvCfihX8QTx7BPmXNfSUWndq8o2u05WvaV5dJNp2T1Hzv022tsntt3+fy0PBPin8 H/hJf+BvF7/D/wDar+E9leeIrrx7r9zF4l8d6Dpfw/tvh5L4j8LapqnhZItH1i/k03wL8NLj4W+J 7fQYbLyD4eiv/GSadqvh3UrF9c02JQjyvlrR15nrL3eW6dtHtHlenT3rWauNN31jJ6Lo2/X1d9/z P00s/Evh+91HUvDNhr2hX2v+GrLRZ9f0TS7+0k1DRLbXIbp9EuNQ0iG5uLvSbTWItOvpNH+2BUvI LS4NtJOkErjrTTdrptWbSeuuztvrrbuZ+etnt/w/U/Nz/gpr8T9H+FHw1+H3ifXLHUtRs7rx3NoK QaUto10t1e+H9S1COZxd3VrF5CxaROkhEhkEkkW1GUsyfH8Z4eWIwGFUZRTji7vmv1o1eyZ6uUpu rVX/AE7T18pL/M/F/wD4bW+Hn/Qr+M/+/Oif/Lqvzj+zqv8APT++X/yJ7vI/L73/AJB/w2t8PP8A oV/Gf/fnRP8A5dUf2dV/np/fL/5EOR+X3v8AyP7Qa/eD4wKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoA+ZvHf7K3w/wDiD4sHjDWdZ8W2+on4g6f8SHtbKbwvLYf25pul/B3SraG1 TV/Cuq3elxCH4I+E2GqaReWHiiGPVPF+nWniG30bxHcabFnKlGTu2/i5tLb2iuqbXwLVa762bRXM 0rf536+fn+XXU8ouf+CdvwBuWETv4ni0uLw3P4as9Dtrf4fWulWdtN8I7D4PRXwjg8Ax3V9qOl6V pdj4s8Nvq91qNp4U8dR3Ws+GLPSLHVNW0i+j6vT87Wtb3bfDyfy3fdXbtLVWu0Pnl873vrfe/f5e he1D9gX4OX+t33iObW/GP9sX2qa5qTXUth8Lr1VTX/HPhL4hX9lPbal8NL221lrrXvBeiWur674i h1nxb4u8OpL4b8ceIvE+kLZ21oewhe95Xu39l7yUuse6V27trSTYc7/q/a3f/hnqrHaa7+zRoviD 4b+B/hhrnj3xq+h/Di11nTfCd1pMfhaw1KDS7n4Z+JfhJ4e/tO41Dw5rQ1LVfDHhTxPfX8V/st7X WPFg/tPVdKm0MxeGILdNOKi5O0bpWtezi4K9072Tb83uraC5rNuy19e9316/l56nDeCf2SfCHw5+ Jfh/4iaP4s8WarNpo8Varrdr4gbRJLnxP4y1bwv4U8EeGPEuoXWgaT4eslj8F+FLT4kWml6SuktZ /wBofFrxRfxm2jt9NsrZRpKMlJSk927296TSSbslsuayta835A5N321/DfTVvfT7kcXd/sWeDLiy 1G31L4ofF7VdQ1jQNf0fW/Ed5c/DFdb1jVPEWnfGXS7/AMYX72XwutNLfxMLT49/EpIBFpkHh6Nd T0yE+H2tdA0iC0XsVZpzm2005Plu2+dc3w2v78ulttNA5/Jfj5ed+i8/vZ6Z4G+C3hP4b+MPG/jv RtT8Wal4k+ImleE9O8XXfiHxDPq9vqd34RuvFFzaa3FYtFFaaVqV7/wld3aXdro8Nj4esdM07RNJ 8O6JoemactrLcYKLlJXvJJO7ve19fXX5KyVkhNtq2mnl389/61Py4/4LWNn9n74YDJJ/4XJaHv8A 9CT4xGef8Pyr5zin/cqH/YUv/TVU9bJ/49X/AK9f+3xP5pa+FPoQoA/0cK/YD4cKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgCtNJgYz9efXnt3+px+eaAMO5lznkfp6+2e/B PXpQBh3Mvv16DJwMA8nkfn0NAGFcS/eyefwPvx04P5/iOQDBuJeDz/M+3PUZ+p/SgD8XP+C0z7vg D8MR6fGO09P+hK8Ydcd+fTn8K+Z4p/3Kh/2FL/01VPXyf+PV/wCvX/t8T+a6vhT6EKAP/9lQSwME FAAGAAgAAAAhACo7s16WAQAAZQMAABEAAABwcHQvdmlld1Byb3BzLnhtbIxTyW7CMBC9V+o/WL5D FrUUIgKXqr0gtRK0d9cZgqvEtjwmLF/fycJaDtxmxjPP772xx9NtWbAKHCqjUx71Q85AS5Mpnaf8 a/HWG3KGXuhMFEZDyneAfDp5fBjbpFKw+XSMADQmIuUr720SBChXUArsGwuazpbGlcJT6vIgc2JD wGURxGE4CEqhNO/m3T3zZrlUEl6NXJegfQvioBCeyONKWTyg2XvQrAMkmGb6gtKExOmadvHdSKxz 6vXGQTaDpWe4J6ueB3HIg/OzhbHN0ehpMGiOgv84WKgMTrByXmRtxlALuzDvTmUppy206cfPL0iP dB2vb5JdbyXcXIqC9tHWsU4mY5HgltVrjEacEUwUNjSovLtRJnbdnE2MU7nSbJvyXhTFnO26gPRR W3dtzSBfE/8Z+mPMaJRcJMON23NmDZGNo1Z/194Vh8ODKSeQGvxoQXPXlUHaeMAFbP2ZZ6fwWjfp vaX7snxbN02S6APDo2JqvkEhpy3NrZD0mJkk017oPdNHkYTQhq1vVft8/gAAAP//AwBQSwMEFAAG AAgAAAAhAFycRxROAQAAiQIAABEAAABwcHQvcHJlc1Byb3BzLnhtbLSQzWrDMBCE74W+g9FdkWQ7 dmxiBzt2odBDDu0DCFtOBNYPkvJTSt+9wnFLQy+59LbLMrPfzHpzEWNwYsZyJQtAFhgETHaq53Jf gLfXJ7gCgXVU9nRUkhXgnVmwKR8f1jrXhlkmHXVeujOBN5I2pwU4OKdzhGx3YILahdJM+tugjKDO r2aPekPP/oEYUYhxggTlEsx6c49eDQPvWKO6o/AAVxPDxonEHri23276HrffOW6QSh+SXdyLdfMU HA0vwEebJts2iyuY4GgLYxKHsM7aGiYNiVKMCa7C9BN4DYnzntuOmv5Z0D1re+4a6ugc1Z//4Ane GWXV4BadEuiaE2l1ZkYrPkUleO7rRMcCYIDKNZowbxmbiFQ4CSuYZqsKxlGYwapuGljX1WqZJCFe EvzDyAZ6HN3E2Gj+X3hXzKlNP/5ufWfKLwAAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAA ABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGij EuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQ pmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vliGlI A1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEAaEjcXpECAABqBQAAEAAIAWRv Y1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVM1u2kAQ vlfqO4x8Sg7BkJC2QstGKUmUQ0mQcNLz4h3jbe1da2dDIKc+Qp+xT9KxDQQaVKnlYOZvZ2e++WbF xbIsYIGejLPDqNfpRoA2ddrY+TB6SG5OPkVAQVmtCmdxGK2Qogv5/p2YeFehDwYJOIWlYZSHUA3i mNIcS0Uddlv2ZM6XKrDq57HLMpPilUufSrQhPu12P8S4DGg16pNqmzBqMw4W4X+TapfW9dFjsqq4 YCkSLKtCBZSX+ptKucNVJ+TlUsRbh0hcUEViSpSn52zfauKr85pkr7a2orisqsKkKjBmcmxS78hl AcYqNTY4ymHintFPHGsi3o1l0JC48+bkTQOMvLcnlHpEC9PcPcNRf3B2LOIDgWKivJp7VeUkzz5y yKsqpoXRSLIv4rUk7lxgQ1fErSBujdZo11427+liPB4VpmriN6KYpqrAEaMoM1UQcuqtQdyiqhky UcaTFIswWGAanAcyL8yRfgQzRVhjP4wWyhtlA8+gDmuVRi4qCl4mTBbOzb5Wb8TdsF3Z9GWvCWDh r4FtrqZbSEwokP7hCkaRy3lzRW1s2+S79wFor7jPeCThAB7nu3g0pbVotFVuGblb4hYPxgc+o8XM BILgYIdOBC6DJ+I5wPWyJqQJMHJ2jlQTE3jwhtet4RocXY/ujgG0V1n49ePnMxYvBf9javk72+Q/ WMFVfQbmjklw0M+ZQekFz1jx1UCIJbjZwrgnAjh4YqyMhTES8YHdgD2E/8B05MpK2ZV8sKZ5rcKq 7v5yhl7z7oh44xdfjP1OD1Xirup1X1N33yimufKo+R3a+F8N4pZZ64s6yShXDKbexLx11O/AY/t0 yl6/0+Vfs+8bW73Gm0dS/gYAAP//AwBQSwMEFAAGAAgAAAAhALOzAKKuAQAADQMAABEACAFkb2NQ cm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySwY7TMBCG 70i8g+UTHFLH7bKgKM2KLVsu7AqJIhA3Y09aC8e27Omm3ROPwDPyJNhpG7paDlwS2fPPN79/u77a dYbcQ4ja2Tnlk5ISsNIpbddz+nm1LN5QElFYJYyzMKd7iPSqef6slr6SLsDH4DwE1BBJItlYST+n G0RfMRblBjoRJ0lhU7F1oROYlmHNvJA/xBrYtCwvWQcolEDBMrDwI5EekUqOSL8NZgAoycBABxYj 4xPO/moRQhf/2TBUzpSdxr1PZzraPWcreSiO6l3Uo7Dv+0k/G2wk/5x9vf3waThqoW3OSgJtaiUr 1GigWW2AXIOFVmMk6Mhb742WAlPgkbiWbGPKmtzs8q5GsnB2DTFXyZ1D3R6l5MXN4u4lISqIFn// /NWDeTDpD9Km7/cTv2bj3OxABhDoQvPehbAnS6HDZhsiDqpTLd+kERFv06W3GtT1/qn8qSR3BbjX +d00lzU7X6bJQ9SH8aBICq86RH2qfJkt3q2WtJmW/KIoXxecr/i0unhVlbNv2d2j/hzmYaM7evxP 4qziZYKeEU+AZnD8+AE3fwAAAP//AwBQSwMEFAAGAAgAAAAhADNYpVXtAwAAuiQAACgAAABwcHQv cHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu5FlPb9owFGe7gSbtuiPLHQyUDjql VAyKhkTbqNBJO1Vu4rK0IY4Ss459kX3dPSdxMElI2Q4lpAekxNgv773f+++3pVLpDfzefyiV1LNf C6v6k7ieSe1TpVlvKFVi69Qw7fmpcjMb1brKWa+ifhxeDWbftfOqY5keq2o3XybjQVWpIdR3HIsg NJwNq9pkPJ1VgQZC55dKVfnBmPMZoaenpzrmu+o6XfCNHtJc6hCXrSZArAYH6gYzFPhMQH2DHVg1 TJ31KmX1kax6QCIk5rimzeoanpMRdRcYHi++Utf8TW2GrWviqYjvh2Ph8fTzzNQfCavrLsGMuuJM WfUYkJ9Ln3ugd8FeFYX/VcqZJE1GFn3Xxas1UcxfgSU4KJjaQuN5sTgRYNrqdVoq8h843UyOPIYZ GVl4HnEE+0GJZE7cXkNF4tFnEAkOVSTYVsXa80hcuSYBHBhYlfhYJHLq6UPAIUUornGhtuamBvMC xVTHFphycWCICRQ5Aug/d37wDaKcCQAUKh6lCBWBkMtoJBiOWc7hR6QtgkVo5MQlvOXdLMizDoa8 f2va9/Q2iPjpYUm70LShxvcOqEEu8YKIfVLm/Jc8smtCzwzayYxeVkVu5Co3gjoFHgMyGVLwLWEZ 0W/LFYU4G69zAm3V01L4OgPFcng5StjwtSiLS6u+BrWLmUnn2Nf24Wp6iwySnk2P1vCedR1HdaPM 6xsPS48Rgy9eE50dosn/n4AcJcmR4E3UVHGLzv4rqIe7R3IhACf85ePjk41lySFe3ud2VBPEv4Ib QlzCpCX44NWa3Q3wQky3LHdb4ObrUjCygE5nYzlnFgCqGENehDb2oENx0rSzBMt9fF4zf2PjQgbo nSRM+uWri9DpeoLV4oTo3URM2sKri9GOYxQ3Tm8TTorV++5Z4kkm7I762hg6Yj7KXtfOYZfVaNRb UEzuNrplK0dqOMMz8W/6WZpn7Jnf2kq0o7Yrq0NN8ioawjirWVRkTsX5JKNiRB7nVDCqIn/w3qvw q4E/7wpwLTCk+nIBE+hAYvDVqUOpFVwUCNuI+vUsBeftYmAXwSRH5fcuMH/kc3jkGPeSkfJNaRcq oSulDRq2dWXCjIBiNGWI1lI/ovG7mylhDAbTHqAzoBZ1pytbh4uhe9Mi4+FBg7S7eBwFUUk1WyfQ t4i3fd/mJBByzEO/U8sUaQOJPMOwAmex4CKvYB7ixOXigDB3SZB/YZqjYDUyXY/xIV2hEEhIdRgO McEFxCIulAxFq9nutLtHn9owzMpprvAH2NgumIMkpOKoyFPrdSKPIbNO8dvBiwonTnVvdVlY/L1g byLn5Gfbk78AAAD//wMAUEsBAi0AFAAGAAgAAAAhAM++76rrAQAAQQ4AABMAAAAAAAAAAAAAAAAA AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAo+yCJg0BAADiAgAACwAAAAAA AAAAAAAAAAAkBAAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAA AAAAAAAAAABiBwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAA ACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAABhCAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAABeCQAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAA IAAAAAAAAAAAAAAAAABbCgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHNQSwECLQAU AAYACAAAACEANO79bUoBAAACBgAAHwAAAAAAAAAAAAAAAABYCwAAcHB0L19yZWxzL3ByZXNlbnRh dGlvbi54bWwucmVsc1BLAQItABQABgAIAAAAIQDoGfSlYwIAAPkMAAAUAAAAAAAAAAAAAAAAAOcN AABwcHQvcHJlc2VudGF0aW9uLnhtbFBLAQItABQABgAIAAAAIQA2EYu8jQMAACcMAAAVAAAAAAAA AAAAAAAAAHwQAABwcHQvc2xpZGVzL3NsaWRlMi54bWxQSwECLQAUAAYACAAAACEALzHknPcDAABT DAAAFQAAAAAAAAAAAAAAAAA8FAAAcHB0L3NsaWRlcy9zbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAh AIzK8logBAAAiRAAABUAAAAAAAAAAAAAAAAAZhgAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbFBLAQIt ABQABgAIAAAAIQCfEb1eigUAADgZAAAVAAAAAAAAAAAAAAAAALkcAABwcHQvc2xpZGVzL3NsaWRl My54bWxQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAB2IgAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHNQSwECLQAUAAYACAAAACEANM25 zh8BAADHBwAALAAAAAAAAAAAAAAAAAB+IwAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1h c3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA2ezDh5gJAABjNwAAIQAAAAAAAAAAAAAAAADn JAAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+ AAAANwEAACwAAAAAAAAAAAAAAAAAvi4AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlv dXQ5LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAxi8A AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAzjAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv c2xpZGVMYXlvdXQ3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAA AAAAAAAA1jEAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA3jIAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAAAAAAAAAAAAAAAA5jMAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0Lnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA7jQAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXR kvG+AAAANwEAACwAAAAAAAAAAAAAAAAA9jUAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVM YXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAA /jYAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQA BgAIAAAAIQAFd255yAMAACQMAAAiAAAAAAAAAAAAAAAAAAc4AABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0MTEueG1sUEsBAi0AFAAGAAgAAAAhANLIDdIoBAAA0BEAACEAAAAAAAAAAAAAAAAA DzwAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbFBLAQItABQABgAIAAAAIQCQtt/p SQMAAOoKAAAhAAAAAAAAAAAAAAAAAHZAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54 bWxQSwECLQAUAAYACAAAACEAqNM5R5AEAAA7EQAAIQAAAAAAAAAAAAAAAAD+QwAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAA AAAAAAAAAAAAzUgAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVs c1BLAQItABQABgAIAAAAIQBjfLWT0AUAAFUcAAAhAAAAAAAAAAAAAAAAANZJAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0NS54bWxQSwECLQAUAAYACAAAACEAHRBIoqgEAADBEAAAIQAAAAAA AAAAAAAAAADlTwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsBAi0AFAAGAAgA AAAhAHqhWXWiAgAAuwYAACEAAAAAAAAAAAAAAAAAzFQAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQ3LnhtbFBLAQItABQABgAIAAAAIQBGlE9wZAMAACELAAAiAAAAAAAAAAAAAAAAAK1XAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1sUEsBAi0AFAAGAAgAAAAhAAhn+O3eAgAA DQgAACEAAAAAAAAAAAAAAAAAUVsAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ2LnhtbFBL AQItABQABgAIAAAAIQAcU9cEEAUAAI8SAAAhAAAAAAAAAAAAAAAAAG5eAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0OS54bWxQSwECLQAUAAYACAAAACEAFfw8XewEAAC7EAAAIQAAAAAAAAAA AAAAAAC9YwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1sUEsBAi0AFAAGAAgAAAAh AP3qF4a/AAAAJQEAAB8AAAAAAAAAAAAAAAAA6GgAAHBwdC90aGVtZS9fcmVscy90aGVtZTEueG1s LnJlbHNQSwECLQAUAAYACAAAACEA0N/e150GAAAHGAAAFAAAAAAAAAAAAAAAAADkaQAAcHB0L3Ro ZW1lL3RoZW1lMS54bWxQSwECLQAKAAAAAAAAACEA/k7xt90KAADdCgAAFQAAAAAAAAAAAAAAAACz cAAAcHB0L21lZGlhL2ltYWdlMS5qcGVnUEsBAi0ACgAAAAAAAAAhAKyp7KwCZAAAAmQAABcAAAAA AAAAAAAAAAAAw3sAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVnUEsBAi0AFAAGAAgAAAAhACo7s16W AQAAZQMAABEAAAAAAAAAAAAAAAAA+t8AAHBwdC92aWV3UHJvcHMueG1sUEsBAi0AFAAGAAgAAAAh AFycRxROAQAAiQIAABEAAAAAAAAAAAAAAAAAv+EAAHBwdC9wcmVzUHJvcHMueG1sUEsBAi0AFAAG AAgAAAAhANj9jY+sAAAAtgAAABMAAAAAAAAAAAAAAAAAPOMAAHBwdC90YWJsZVN0eWxlcy54bWxQ SwECLQAUAAYACAAAACEAaEjcXpECAABqBQAAEAAAAAAAAAAAAAAAAAAZ5AAAZG9jUHJvcHMvYXBw LnhtbFBLAQItABQABgAIAAAAIQCzswCirgEAAA0DAAARAAAAAAAAAAAAAAAAAODnAABkb2NQcm9w cy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQAzWKVV7QMAALokAAAoAAAAAAAAAAAAAAAAAMXqAABw cHQvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmluUEsFBgAAAAAuAC4A5g0AAPju AAAAAA== ------=_20140711141242_74262-- From nobody Fri Jul 11 09:02:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BF81B2B4F for ; Fri, 11 Jul 2014 09:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF8mcsNUfAZj for ; Fri, 11 Jul 2014 09:02:47 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102331B2B2A for ; Fri, 11 Jul 2014 09:02:47 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so1086899ier.13 for ; Fri, 11 Jul 2014 09:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FJGcE4bAjXGVmd7LEYoRfFGDlExbf/nySPRnSs9sk3I=; b=lDOqq9ehhA5T8wjrYsVaqcS2i8pbLMSBfrzBsummWpaDl2Ap7DY3zTexmt7No/u/dc v7l08pYYWwbcbCIssU4B/otqXJSUXIxnEe38F38BIHcmdYuZZ28h5inNFzBVGgZ/Qdx7 CMl+W/eYlFHK5ad9g7DiwPmMwKCcOqS9fXi7ds4UvmFvMtRNUovBsofWM7XYUIidpb66 JO5Ou8N7mRneBH6sEMRbzJW2IHJR+MM7ik7uND83q3cGbHu91xRHgjZn0lDQnndKFurU BgbIo9oZHAwIPhjB/Tqw2o6HfaQEDC/AgRzjBuaZ1+kYJUmkLJs6+oJ7+skhzk81vyYr Q7WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FJGcE4bAjXGVmd7LEYoRfFGDlExbf/nySPRnSs9sk3I=; b=O5PABSZUukyx2LJEppA0FaisN+th+ho/NkD182AjOOKYzFwbueObtSfzof4+5ZwuS+ 6eF1ewndP0dHp/PNhxs+20KWqcIfN2YpDmLUCuB1KHDT+cNbHwu1bHbxrYVkbf+mR3qS 2nM75OkTa7pLrA3BfmA86FawajV6luIKafYFx4slOdNBTp1hxVkjIdiRNcA9h5qWDN3n SGpjT71jti5RRyiMC4URueE8Bjzj8wo5ylrYK1RFcBMB6QywDIACD/xk9fLA2k9oKeeW 0XNr7JAJ1VWpB7C2JnnN5jpuMsKBY1v1tJHGELaIaxZ2WBrg8/EM7Dn/ST6xCWFV2qmi Ga5g== X-Gm-Message-State: ALoCoQmV4IMGfjrUofzWqxmVV9WkuWJpqSS3pEox86NV3oW0QU+7H6Te+x/UJhWk+eiQTU27ttlW X-Received: by 10.42.161.132 with SMTP id t4mr5652962icx.34.1405094566016; Fri, 11 Jul 2014 09:02:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.163.74 with HTTP; Fri, 11 Jul 2014 09:02:05 -0700 (PDT) In-Reply-To: <53B49D57.70102@isi.edu> References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> From: Yuchung Cheng Date: Fri, 11 Jul 2014 09:02:05 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UObW_9xMnRgB6esSbIicPfvRPYE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 16:02:49 -0000 overall I like this new draft. but I am not sure why default-on would interfere legacy apps. To me EDO is similar to SACK. We always want to negotiate this capability but only use the feature at times when needed. My primary interests to use EDO is for reporting large number of SACK blocks under high-reordering high-ack-loss high-bw networks. I am not sure if apps should opt-in this case. ">> Implementations can also employ system-wide defaults, however systems SHOULD NOT use this extension by default to avoid interfering with legacy applications." On Wed, Jul 2, 2014 at 5:01 PM, Joe Touch wrote: > Hi, all, > > This is an updated version of the Extended Data Offset option. > > The changes are, broadly: > > - more clear about the immediate potential need for > non-SYN DO extension > > - more clear about the issue with SYN extension > points off to a currently pending doc with the > SYN approach Briscoe and I discussed on the list > > - includes a discussion of the issues with > specific prior approaches > > - reorganized to get to the actual extension > earlier > > The core proposal hasn't changed. > > I'd like to suggest this version be the topic of discussion for inclusion as > a WG doc, intended for (preferably) PS or at least Experimental. > > The SYN DO extension is intended to be considered separately, and would be > focused at Experimental (whether in the WG or individual). > > I won't be in Toronto, but will provide a slideset summarizing the changes > as well. > > Joe > > > -------- Original Message -------- > Subject: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt > Date: Wed, 02 Jul 2014 16:10:48 -0700 > From: internet-drafts@ietf.org > To: Wesley M. Eddy , Dr. Joseph D. Touch > , Joe Touch , Wesley Eddy > > > > A new version of I-D, draft-touch-tcpm-tcp-edo-03.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. > > Name: draft-touch-tcpm-tcp-edo > Revision: 03 > Title: TCP Extended Data Offset Option > Document date: 2014-07-02 > Group: Individual Submission > Pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-03.txt > Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ > Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-03 > > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options, but the size of the field can limit the space available for > complex options that have evolved. This document updates RFC 793 > with an optional TCP extension to that space to support the use of > multiple large options such as SACK with either TCP Multipath or TCP > AO. It also explains why the initial SYN of a connection cannot be > extending as a single segment. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jul 11 09:16:46 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6767F1B2B96 for ; Fri, 11 Jul 2014 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb3Yh0Z6kfw4 for ; Fri, 11 Jul 2014 09:16:42 -0700 (PDT) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id 06D171B2B63 for ; Fri, 11 Jul 2014 09:16:41 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6BGGaJp030739 for ; Fri, 11 Jul 2014 12:16:36 -0400 Received: (qmail 30181 invoked by uid 0); 11 Jul 2014 16:16:36 -0000 X-TCPREMOTEIP: 107.46.170.98 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.170.98) by 0 with ESMTPA; 11 Jul 2014 16:16:35 -0000 Message-ID: <53C00DDA.60501@mti-systems.com> Date: Fri, 11 Jul 2014 12:16:26 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yuchung Cheng , Joe Touch References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/zdnu5BlImrELfP-ojo4U1nA1lEs Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 16:16:43 -0000 On 7/11/2014 12:02 PM, Yuchung Cheng wrote: > overall I like this new draft. but I am not sure why default-on would > interfere legacy apps. To me EDO is similar to SACK. We always want to > negotiate this capability but only use the feature at times when > needed. My primary interests to use EDO is for reporting large number > of SACK blocks under high-reordering high-ack-loss high-bw networks. > I am not sure if apps should opt-in this case. > > ">> Implementations can also employ system-wide defaults, however > systems SHOULD NOT use this extension by default to avoid > interfering with legacy applications." It could cause trouble for the application if middlebox issues are causing corruption / disruption in connections using EDO. It might be possible to work around this similar to ICMP or ECN black holes, if EDO is on by default and "EDO black holes" can be detected, but I think it would take more effort. -- Wes Eddy MTI Systems From nobody Fri Jul 11 10:52:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBEB1B2C52 for ; Fri, 11 Jul 2014 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nop9AXhwUZi6 for ; Fri, 11 Jul 2014 10:52:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4171B2C51 for ; Fri, 11 Jul 2014 10:52:37 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s6BHpmZa010523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Jul 2014 10:51:48 -0700 (PDT) Message-ID: <53C02434.3090500@isi.edu> Date: Fri, 11 Jul 2014 10:51:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Wesley Eddy , Yuchung Cheng References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <53C00DDA.60501@mti-systems.com> In-Reply-To: <53C00DDA.60501@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/npkHPj8EqgyVCAR98Yt1_ApHNDA Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:52:39 -0000 On 7/11/2014 9:16 AM, Wesley Eddy wrote: > On 7/11/2014 12:02 PM, Yuchung Cheng wrote: >> overall I like this new draft. but I am not sure why default-on would >> interfere legacy apps. To me EDO is similar to SACK. We always want to >> negotiate this capability but only use the feature at times when >> needed. My primary interests to use EDO is for reporting large number >> of SACK blocks under high-reordering high-ack-loss high-bw networks. >> I am not sure if apps should opt-in this case. >> >> ">> Implementations can also employ system-wide defaults, however >> systems SHOULD NOT use this extension by default to avoid >> interfering with legacy applications." > > > It could cause trouble for the application if middlebox issues are > causing corruption / disruption in connections using EDO. Yup - the text should be reworded. The issue isn't interference with legacy apps; it is that ANY app (legacy or new) that doesn't actively need the feature should avoid using it - that goes for ALL TCP options, IMO. > It might be possible to work around this similar to ICMP or ECN black > holes, if EDO is on by default and "EDO black holes" can be detected, > but I think it would take more effort. Yup. Joe From nobody Fri Jul 11 11:09:21 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE761B28E1 for ; Fri, 11 Jul 2014 11:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwJ1IKJCUg3e for ; Fri, 11 Jul 2014 11:09:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825FD1A0B08 for ; Fri, 11 Jul 2014 11:09:19 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s6BI8iW0015588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Jul 2014 11:08:44 -0700 (PDT) Message-ID: <53C0282C.7040108@isi.edu> Date: Fri, 11 Jul 2014 11:08:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoshifumi Nishida , "tcpm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/kskXJaOkaqsHtflHmQDtTzUtmNY Subject: Re: [tcpm] a comment on draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 18:09:20 -0000 On 7/10/2014 10:26 PM, Yoshifumi Nishida wrote: > (as individual) > Hi, > I basically support this draft, but I am wondering how to react to > EDO-unfriendly middleboxes. Define "unfriendly". If a middlebox strips the option, it will be disabled for the connection. If a middlebox drops the segment based on the option, the connection won't proceed. If a box reflects the option in a SYN segment without knowing what it is, i.e., for a "transparent proxy", the connection will proceed with corrupt data (NB: that's just a hijacked connection). Both of those happen for any new (or old) option. > When we find EDO-unfriendly middleboxes by using TCP-AO or EDO-checksum, > how we should react? There's no way to find EDO-unfriendly middleboxes per se except with an additional checksum. TCP-AO, or even IPsec won't find boxes that permit those protocols but not EDO. > Shall we terminate the connection? Or, is there any > way to fallback safely? Or just re-transmit the segments? I think this > point should be clarified in the draft. I don't. We cannot write new specifications with the assumption that old specifications aren't being minimally followed. We'd never get anywhere. I think the issue of what happens if these boxes are encountered should be addressed, and blame placed where it lies - with the "meddlebox". Joe From nobody Fri Jul 11 16:09:31 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8BB1B29EF for ; Fri, 11 Jul 2014 16:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N7xP_jVn5zi for ; Fri, 11 Jul 2014 16:09:20 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FD51A0026 for ; Fri, 11 Jul 2014 16:09:19 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 56D66278186 for ; Sat, 12 Jul 2014 08:09:17 +0900 (JST) Received: by mail-lb0-f174.google.com with SMTP id u10so1359006lbd.19 for ; Fri, 11 Jul 2014 16:09:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.87.140 with SMTP id ay12mr1415630lab.89.1405120154413; Fri, 11 Jul 2014 16:09:14 -0700 (PDT) Received: by 10.114.81.40 with HTTP; Fri, 11 Jul 2014 16:09:14 -0700 (PDT) In-Reply-To: <53C0282C.7040108@isi.edu> References: <53C0282C.7040108@isi.edu> Date: Fri, 11 Jul 2014 16:09:14 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c34e0cabb39804fdf30782 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/WnPCLJ3V18bvGuv6M3yCOP2QIZQ Cc: "tcpm@ietf.org" Subject: Re: [tcpm] a comment on draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 23:09:24 -0000 --001a11c34e0cabb39804fdf30782 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Fri, Jul 11, 2014 at 11:08 AM, Joe Touch wrote: > > > On 7/10/2014 10:26 PM, Yoshifumi Nishida wrote: > >> (as individual) >> Hi, >> I basically support this draft, but I am wondering how to react to >> EDO-unfriendly middleboxes. >> > > Define "unfriendly". > > If a middlebox strips the option, it will be disabled for the connection. > If a middlebox drops the segment based on the option, the connection won't > proceed. If a box reflects the option in a SYN segment without knowing what > it is, i.e., for a "transparent proxy", the connection will proceed with > corrupt data (NB: that's just a hijacked connection). > > Both of those happen for any new (or old) option. Sorry, I was not clear enough. What I'm thinking is the following types 1: middleboxes that drop options 2: middleboxes that re-segment (coalesce or split) packets I'm basically fine for 1:, but I'm having a bit concern on 2: as 2: can work with other options (I know this is also tricky for mptcp options, but mptcp uses some tricks to handle this.) > > When we find EDO-unfriendly middleboxes by using TCP-AO or EDO-checksum, >> how we should react? >> > > There's no way to find EDO-unfriendly middleboxes per se except with an > additional checksum. TCP-AO, or even IPsec won't find boxes that permit > those protocols but not EDO. > > > Shall we terminate the connection? Or, is there any > >> way to fallback safely? Or just re-transmit the segments? I think this >> point should be clarified in the draft. >> > > I don't. > > We cannot write new specifications with the assumption that old > specifications aren't being minimally followed. We'd never get anywhere. > > I think the issue of what happens if these boxes are encountered should be > addressed, and blame placed where it lies - with the "meddlebox". This makes sense to me if you claim dealing with middleboxes like 2: is out-of-scope of the draft. But, I thought the reason why you mentioned TCP-AO or checksums in EDO in the draft is to find such middleboxes. My point is if you mentioned integrity checking mechanisms in the draft, why you don't mention the behavior when you find errors. Thanks, -- Yoshi --001a11c34e0cabb39804fdf30782 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Fri, Jul 11, 2014 at 11:08 AM, Joe Touch &= lt;touch@isi.edu>= wrote:


On 7/10/2014 10:26 PM, Yoshifumi Nishida wrote:
(as individual)
Hi,
I basically support this draft, but I am wondering how to react to
EDO-unfriendly middleboxes.

Define "unfriendly".

If a middlebox strips the option, it will be disabled for the connection. I= f a middlebox drops the segment based on the option, the connection won'= ;t proceed. If a box reflects the option in a SYN segment without knowing w= hat it is, i.e., for a "transparent proxy", the connection will p= roceed with corrupt data (NB: that's just a hijacked connection).

Both of those happen for any new (or old) option.

Sorry, I was not clear enough.
What I'm thinking is th= e following types

1: middleboxes that drop options=
2: middleboxes that re-segment (coalesce or split) packets=C2=A0
=
=C2=A0
I'm basically fine for 1:, but I'm having a b= it concern on 2: as 2: can work with other options (I know this is also tri= cky for mptcp options, but mptcp uses some tricks to handle this.)

When we find EDO-unfriendly middleboxes by using TCP-AO or EDO-checksum, how we should react?

There's no way to find EDO-unfriendly middleboxes per se except with an= additional checksum. TCP-AO, or even IPsec won't find boxes that permi= t those protocols but not EDO.

> Shall we terminate the connection? Or, is there any
way to fallback safely? Or just re-transmit the segments? I think this
point should be clarified in the draft.

I don't.

We cannot write new specifications with the assumption that old specificati= ons aren't being minimally followed. We'd never get anywhere.

I think the issue of what happens if these boxes are encountered should be = addressed, and blame placed where it lies - with the "meddlebox".=

This makes sense to me if you claim dealin= g with middleboxes like 2: is out-of-scope of the draft.
But, I thought the reason why you mentioned TCP-AO or checksums in EDO= in the draft is to find such middleboxes.

My poin= t is if you mentioned integrity checking mechanisms in the draft, why you d= on't mention the behavior when you find errors.

Thanks,
--
Yoshi

=C2=A0

--001a11c34e0cabb39804fdf30782-- From nobody Fri Jul 11 16:32:44 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8231A004E for ; Fri, 11 Jul 2014 16:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEN0Dp2fqvqX for ; Fri, 11 Jul 2014 16:32:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8281A005B for ; Fri, 11 Jul 2014 16:32:41 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s6BNW9G7002995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Jul 2014 16:32:09 -0700 (PDT) Message-ID: <53C073F9.60303@isi.edu> Date: Fri, 11 Jul 2014 16:32:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <53C0282C.7040108@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/-QjVjHhFdqkSfuxT6Oh3pu1FjHk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] a comment on draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 23:32:43 -0000 On 7/11/2014 4:09 PM, Yoshifumi Nishida wrote: > Hi Joe, > > On Fri, Jul 11, 2014 at 11:08 AM, Joe Touch > wrote: > > > > On 7/10/2014 10:26 PM, Yoshifumi Nishida wrote: > > (as individual) > Hi, > I basically support this draft, but I am wondering how to react to > EDO-unfriendly middleboxes. > > > Define "unfriendly". > > If a middlebox strips the option, it will be disabled for the > connection. If a middlebox drops the segment based on the option, > the connection won't proceed. If a box reflects the option in a SYN > segment without knowing what it is, i.e., for a "transparent proxy", > the connection will proceed with corrupt data (NB: that's just a > hijacked connection). > > Both of those happen for any new (or old) option. > > > Sorry, I was not clear enough. > What I'm thinking is the following types > > 1: middleboxes that drop options Yes; that's always a concern. > 2: middleboxes that re-segment (coalesce or split) packets > I'm basically fine for 1:, but I'm having a bit concern on 2: as 2: can > work with other options (I know this is also tricky for mptcp options, > but mptcp uses some tricks to handle this.) If you use option space, there is no trick needed - that's why I was against mptcp using in-band space. EDO will break when exposed to these non-compliant devices. The only way to detect it would be to use an additional checksum (as noted in the text) - at least until the middlebox decides it wants to update that checksum but ignore EDO. > When we find EDO-unfriendly middleboxes by using TCP-AO or > EDO-checksum, > how we should react? > > There's no way to find EDO-unfriendly middleboxes per se except with > an additional checksum. TCP-AO, or even IPsec won't find boxes that > permit those protocols but not EDO. > > > Shall we terminate the connection? Or, is there any > > way to fallback safely? Or just re-transmit the segments? I > think this > point should be clarified in the draft. > > > I don't. > > We cannot write new specifications with the assumption that old > specifications aren't being minimally followed. We'd never get anywhere. > > I think the issue of what happens if these boxes are encountered > should be addressed, and blame placed where it lies - with the > "meddlebox". > > > This makes sense to me if you claim dealing with middleboxes like 2: is > out-of-scope of the draft. Agreed. > But, I thought the reason why you mentioned TCP-AO or checksums in EDO > in the draft is to find such middleboxes. Not so much to find them as to ensure that it EDO would fail safely in the presence of those boxes. > My point is if you mentioned integrity checking mechanisms in the draft, > why you don't mention the behavior when you find errors. Because you don't know the reason for the error. You're not finding anything definite; all you know is that the packet has been reformatted in a way that corrupts its ability to support EDO. At that point, you should terminate the connection with an error. There's nothing you can do to recover except retransmit the segments without EDO, but I don't think we should be adding a signal to make that happen. Joe From nobody Mon Jul 14 07:20:33 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323B51A04A1 for ; Mon, 14 Jul 2014 07:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd6GmlpZzRp1 for ; Mon, 14 Jul 2014 07:20:24 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6DE1A0492 for ; Mon, 14 Jul 2014 07:20:24 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 87E8927810C for ; Mon, 14 Jul 2014 23:20:22 +0900 (JST) Received: by mail-lb0-f173.google.com with SMTP id n15so956809lbi.18 for ; Mon, 14 Jul 2014 07:20:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.239.41 with SMTP id vp9mr13742539lbc.8.1405347619591; Mon, 14 Jul 2014 07:20:19 -0700 (PDT) Received: by 10.114.81.40 with HTTP; Mon, 14 Jul 2014 07:20:19 -0700 (PDT) In-Reply-To: <53C073F9.60303@isi.edu> References: <53C0282C.7040108@isi.edu> <53C073F9.60303@isi.edu> Date: Mon, 14 Jul 2014 07:20:19 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=001a11348a3aa6df9604fe27fd88 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/qrdWNWmNl9GRJ73n-i3NZM__1pM Cc: "tcpm@ietf.org" Subject: Re: [tcpm] a comment on draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 14:20:27 -0000 --001a11348a3aa6df9604fe27fd88 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Fri, Jul 11, 2014 at 4:32 PM, Joe Touch wrote > But, I thought the reason why you mentioned TCP-AO or checksums in EDO >> in the draft is to find such middleboxes. >> > > Not so much to find them as to ensure that it EDO would fail safely in the > presence of those boxes. > > My point is if you mentioned integrity checking mechanisms in the draft, >> why you don't mention the behavior when you find errors. >> > > Because you don't know the reason for the error. You're not finding > anything definite; all you know is that the packet has been reformatted in > a way that corrupts its ability to support EDO. > I agree. > At that point, you should terminate the connection with an error. There's > nothing you can do to recover except retransmit the segments without EDO, > but I don't think we should be adding a signal to make that happen. I support terminating connections with an error. My personal preference is to mention it explicitly as I don't want to see someone work on some "smart" logics with different interpretations. Especially, if it aims for standard track. Thanks, -- Yoshi --001a11348a3aa6df9604fe27fd88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Fri, Jul 11, 2014 at 4:32 PM, Joe Touch <touch@isi.edu> wrote
But, I thought the reason why you mentioned TCP-AO or checksums in EDO
in the draft is to find such middleboxes.

Not so much to find them as to ensure that it EDO would fail safely in the = presence of those boxes.

=C2=A0My point is if you mentioned integrity checking mechanisms in the dra= ft,
why you don't mention the behavior when you find errors.

Because you don't know the reason for the error. You're not finding= anything definite; all you know is that the packet has been reformatted in= a way that corrupts its ability to support EDO.

I agree.
=C2=A0
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:19:20 -0000 Gorry, Sorry for delay. Now it's me who missed your response for a while. Inline.... At 08:32 11/07/2014, Gorry Fairhurst wrote: >Sorry for the long delay in response, please see below comments as >an individual: > >On 03/07/2014 14:10, Bob Briscoe wrote: >>Gorry, >> >>I wanted to respond to your dislike of our argument against the nonce >>and a couple of other points... (sorry I didn't notice your email back >>in March). >> >>We don't need to have this argument in the accecn-reqs doc, so we've >>taken it out. But we do need to have the argument on the list. inline... >I saw this. > >>At 11:47 08/03/2014, Gorry Fairhurst wrote: >>>Section 2: >>> >>>Disagree with text: "However, as the ECN Nonce is a separate extension >>>to ECN, even if a sender tries to protect itself with the ECN Nonce, >>>any receiver wishing to conceal marked packets only has to pretend not >>>to support the ECN Nonce and simply does not provide any nonce sum >>>feedback." >>>- To me this argument is ridiculous (and I have said so), and I think >>>we should not perpetuate this argument! >>>[[Here is why: if a sender were to require a NS, then a receiver >>>would need to provide that or expect the sender would not continue use >>>of ECN, or at least limit is trust of ECN. So the wording could be >>>improved, but RFC3540 says: "If the receiver has never sent a >>>non-zero nonce sum, the sender can infer that the receiver does not >>>understand the nonce, and rate limit the connection, place it in a >>>lower-priority queue, or cease setting ECT in outgoing segments."]] >>>- Saying the nonce sum has a second problem in that it only works if >>>it is deployed and actually used seems obvious. >> >>I believe our argument is correct. >> >>1) First, let's allow an assumption that the nonce is only for >>protection against ECN cheating (it isn't)... >> >>One person saying they don't support the nonce is not a suspicious sign >>of potential malice when a majority of users don't support it either, or >>even a minority. >This is a deployment problem, not a protocol problem. If a sender >accepts ECN feedback from a receiver that isn't NS capable, then it >can not take advantage of the NS. You could be more conservative if >you knew the NS was not implemented, or something else. My point was entirely that this is a deployment problem. I can't see a way to deploy the nonce protocol so that it allows TCP senders to distinguish cheating receivers from genuine. Whether or not the protocol is perfect when universally deployed is surely irrelevant if it provides little or no security while it is partially deployed. The negotiation of a protocol capability is part of a protocol, so if it can be declined by those who don't want to be caught, and by many other innocent bystanders who create an environment where cheaters can hide in plain sight, then it is not a secure protocol. >>Here's a scenario: I'll be generous and assume that nonce support has >>been deployed unilaterally by one (or two) large mobile device vendors. >>Then imagine that you are running a Web server. Millions of clients ask >>you for ECN TCP connections. You support ECN because you have determined >>that it improves performance. You also want to get the client to use the >>nonce if supported, so you set the flags accordingly. The client >>responds with ECN support, but nonce sum =0. >> >>By your argument you (the server) decline to use ECN further or you >>negate the performance benefits. Certainly you want to decline ECN for >>the one or two malicious users who use the device from the above >>vendor(s) but have hacked it to say it doesn't support the nonce. >>However, you also cannot help but decline to use ECN (or negate any >>performance benefits) for the millions of users who don't use those >>devices that support it. Are you really likely to have gone to all the >>hassle of deploying ECN then you decline to use it or you limit >>performance for 99.999% of users because the other 0.001% might be >>malicious? No. >> >>The whole point of the nonce is to identify precisely which users are >>cheating. If you still have to use judgement and heuristics anyway, the >>nonce is not a solution. >If implemented as a part of ECN support, I think the mechanism works >- albeit you have to decide what to do about a client that chooses >not to return a NS. Yes, if the nonce had been a mandatory part of ECN, it would have given believable security. But it wasn't :( >>2) Now, let's assume you are having trouble with clients mounting one of >>the attacks described in RFC3540 that supresses loss feedback (not ECN). >> >>Any client that wants to mount these attacks just doesn't ask for ECN >>support. What are you going to do as a server. Reset every connection >>that doesn't ask for ECN? Again, you would have to punish large numbers >>of your customers in case a few might be cheating. >> >>It's not helpful to say this argument is ridiculous. If I'm missing >>something, please describe a believable scenario where the nonce would >>be useful. > >I see some (potentially useful outcomes, we could agree upon?: > >The problem that was intended to be addressed by the NS mechanism is >a useful function that still should be addressed. > >The NS mechanism was not (widely) deployed. > >Other uses are permitted in the RFC-series, for ECT(1) - e.g. in >combination with alternate DSCPs. > >Perhaps more important, there may be mechanisms that can be still >deployed to achieve the same goals, but with a better overall characteristic. Yes. Agree (strongly) with all this. Thx. And thx for the rest of the mail below. Cheers Bob >>>It speaks of [...] Conex (specified for a specific domain). >> >>I need to correct this misconception: ConEx is an e2e mechanism added to >>IP using transport feedback of loss or ECN where available. ConEx >>policing would certainly be applied in individual network domains, but >>the ConEx signal is e2e and defined in updates to e2e transport specs >>(starting with TCP). >I agree with what you say. > >>>Section 4: >>> >>>Usage of RFC 2119: Personally, I really do not like use of RFC2119 >>>keywords in this way: "This leads to the following requirements, which >>>MUST be discussed for any proposed more accurate ECN feedback scheme:" >>>- Mandating discussion is not helpful. >>> >>>(point 2 above): If we have requirements as the title suggests, then I >>>personally would encourage you to list them as requirements using RFC >>>2119 language - but I don't mind seeing no RFC 2119 keywords if the WG >>>wants this, as long as I can see the relative importance of each >>>topic. At the moment I can't see this. >> >>I recall that relative priority of requirements was already discussed in >>tcpm, and the general opinion (I think) was that this would be hard to >>do in abstract terms without a particular mechanism in mind that makes >>particular trade-offs. I strongly support that view - otherwise we will >>be having circular arguments for ever. >> >>I also think mandating discussion is helpful. accecn-reqs is a checklist >>of things that need to be aired in any candidate spec. What's wrong with >>that? >I read the latest version and said on-list that I *was* indeed happy >with this aspect of the version being WGLC'ed. > >> >>Bob >> >> >>________________________________________________________________ >>Bob Briscoe, BT > >Gorry ________________________________________________________________ Bob Briscoe, BT From nobody Fri Jul 18 10:47:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CBE1B27E0 for ; Fri, 18 Jul 2014 10:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCLuINCf2aWx for ; Fri, 18 Jul 2014 10:47:43 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7211B2982 for ; Fri, 18 Jul 2014 10:47:40 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6IHlK0n011081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 18 Jul 2014 10:47:21 -0700 (PDT) Message-ID: <53C95DA9.8030300@isi.edu> Date: Fri, 18 Jul 2014 10:47:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/S00Jwcs86rzdheyuzyG9wO0Tkd0 Subject: Re: [tcpm] WG acceptance of draft-touch-tcpm-tcp-edo-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:47:48 -0000 On 7/4/2014 4:26 AM, Scharf, Michael (Michael) wrote: > Hi all, > > Given the recent list discussions on extending the TCP option space, > this e-mail starts a WG acceptance call for draft-touch-tcpm-tcp-edo-03. > The call will run on the mailing list until Friday July 18, 2014. > > The chairs would like to confirm that the TCPM community agrees to > > * adopt the document draft-touch-tcpm-tcp-edo-03 as a TCPM working group item, heading towards publication on standards track, and > > * add a corresponding milestone to the TCPM charter. I'm not sure if WG calls expect responses from authors, but in case there's any doubt, +1 from me. Joe From nobody Fri Jul 18 13:40:24 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758F41B27B6 for ; Fri, 18 Jul 2014 13:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.129 X-Spam-Level: *** X-Spam-Status: No, score=3.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOvFCrSHwMHd for ; Fri, 18 Jul 2014 13:40:22 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3CA1B280F for ; Fri, 18 Jul 2014 13:40:21 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B098827816B for ; Sat, 19 Jul 2014 05:40:19 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id el20so3196055lab.24 for ; Fri, 18 Jul 2014 13:40:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.120.195 with SMTP id le3mr8094501lab.16.1405716016775; Fri, 18 Jul 2014 13:40:16 -0700 (PDT) Received: by 10.114.241.41 with HTTP; Fri, 18 Jul 2014 13:40:16 -0700 (PDT) Date: Fri, 18 Jul 2014 13:40:16 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=089e01227abcd5c97904fe7dc360 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eL-a0yghThP2jOa48fE-2P-3HUg Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Slides for toronto meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 20:40:23 -0000 --089e01227abcd5c97904fe7dc360 Content-Type: text/plain; charset=UTF-8 Hello presenters for Toronto meeting, Please send your presentation materials to chairs ** by Sunday Morning **. We appreciate your cooperation. Thanks, -- tcpm co-chairs --089e01227abcd5c97904fe7dc360 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello presenters for Toronto meeting,=C2=A0

Please = send your presentation materials to chairs ** by Sunday Morning **.=C2=A0
We apprecia= te your cooperation.

Thanks,--
tcpm co= -chairs
--089e01227abcd5c97904fe7dc360-- From nobody Fri Jul 18 17:10:44 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929851A02E5 for ; Fri, 18 Jul 2014 17:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.129 X-Spam-Level: *** X-Spam-Status: No, score=3.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX9FDmMrn9u1 for ; Fri, 18 Jul 2014 17:10:42 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A351A02E7 for ; Fri, 18 Jul 2014 17:10:42 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9912E278167 for ; Sat, 19 Jul 2014 09:10:40 +0900 (JST) Received: by mail-lb0-f175.google.com with SMTP id 10so184592lbg.6 for ; Fri, 18 Jul 2014 17:10:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.181.74 with SMTP id du10mr8634284lbc.40.1405728637742; Fri, 18 Jul 2014 17:10:37 -0700 (PDT) Received: by 10.114.241.41 with HTTP; Fri, 18 Jul 2014 17:10:37 -0700 (PDT) Date: Fri, 18 Jul 2014 17:10:37 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a11c36fe41a742f04fe80b4d4 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yPn3E-87qtBaefeGHdBY56FGwhI Subject: [tcpm] note takers and jabber volunteer for Toronto meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 00:10:43 -0000 --001a11c36fe41a742f04fe80b4d4 Content-Type: text/plain; charset=UTF-8 Hi, We're looking for volunteer for note taking and jabber for our WG meeting in Toronto. If you're interested, please let chairs know. It will save our meeting time if we can have someone before the meeting starts. We really appreciate your cooperation. If you're interested, but you're not very sure what to do, please feel free to contact me. Thanks, -- Yoshi on behalf of tcpm co-chairs --001a11c36fe41a742f04fe80b4d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We're looking for volunteer for note taking= and jabber for our WG=C2=A0meeting in Toronto.
If you're interested= , please let chairs know. It will save our meeting=C2=A0time if we can have= someone before the meeting starts.
We really appreciate your cooperation.

If you're interested, but= you're not very sure what to do, please feel=C2=A0free to contact me.<= br>
Thanks,
--
Yoshi on behalf of tcpm co-chairs
--001a11c36fe41a742f04fe80b4d4-- From nobody Sun Jul 20 13:34:36 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CCA1B2792 for ; Sun, 20 Jul 2014 13:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHJVR9cHbwvs for ; Sun, 20 Jul 2014 13:34:34 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 081831A0B05 for ; Sun, 20 Jul 2014 13:34:33 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4F4CB2861D for ; Sun, 20 Jul 2014 20:34:33 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 35A4228600 for ; Sun, 20 Jul 2014 20:34:33 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 1A4652026 for ; Sun, 20 Jul 2014 20:34:33 +0000 (GMT) Message-ID: <53CC27D9.2010407@akamai.com> Date: Sun, 20 Jul 2014 16:34:33 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <655C07320163294895BBADA28372AF5D165C0046@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140704142643.GL85889@verdi> In-Reply-To: <20140704142643.GL85889@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/zrj3r8OapTGliVjgLUUJsMNOP_I Subject: Re: [tcpm] WG acceptance of draft-touch-tcpm-tcp-edo-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: brandon.williams@akamai.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:34:36 -0000 +1 On 07/04/2014 10:26 AM, John Leslie wrote: > Scharf, Michael (Michael) wrote: >> >> The chairs would like to confirm that the TCPM community agrees to >> >> * adopt the document draft-touch-tcpm-tcp-edo-03 as a TCPM working group >> item, heading towards publication on standards track, and >> >> * add a corresponding milestone to the TCPM charter. > > Yes. > > (I promise to participate in the discussion.) > > -- > John Leslie > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Sun Jul 20 14:17:17 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F0A1B2D21 for ; Sun, 20 Jul 2014 14:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_EcfPX2Xk0a for ; Sun, 20 Jul 2014 14:17:08 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADD51B2D39 for ; Sun, 20 Jul 2014 14:17:07 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 20 Jul 2014 22:17:05 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 20 Jul 2014 22:17:04 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Sun, 20 Jul 2014 22:17:03 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.12.169]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6KLGxmT029619; Sun, 20 Jul 2014 22:17:00 +0100 Message-ID: <201407202117.s6KLGxmT029619@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 20 Jul 2014 22:16:23 +0100 To: Yoshifumi Nishida From: Bob Briscoe In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/xbGfJE_NAMxb9fBZDHhFnKw_OYc Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Slides for toronto meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 21:17:14 -0000 Yoshfumi, My slides are all here: Or specifically (you can replace the file type with pdf if you want): You already have the tcp-syn-eos ones from Joe (no difference). Sorry for delay - I've been waiting for the last co-author's confirmation. Bob At 21:40 18/07/2014, Yoshifumi Nishida wrote: >Hello presenters for Toronto meeting,=C2 > >Please send your presentation materials to chairs ** by Sunday Morning **.= =C2 >We appreciate your cooperation. > >Thanks, >-- >tcpm co-chairs >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm ________________________________________________________________ Bob Briscoe, BT=20 From nobody Mon Jul 21 07:12:37 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DE21A0011 for ; Mon, 21 Jul 2014 07:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWT-eGKuVTar for ; Mon, 21 Jul 2014 07:12:34 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54801A0008 for ; Mon, 21 Jul 2014 07:12:33 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 21 Jul 2014 15:12:26 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 21 Jul 2014 15:12:31 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 21 Jul 2014 15:12:30 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.123.47]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6LECP6N032672; Mon, 21 Jul 2014 15:12:26 +0100 Message-ID: <201407211412.s6LECP6N032672@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Jul 2014 15:12:25 +0100 To: Yoshifumi Nishida , "SAROLAHTI, Pasi" , SCHARF Michael , Joe Touch From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KSGrRDhV4EozzhJYk92Auy22XLQ Cc: tcpm IETF list Subject: [tcpm] An even better way of extending TCP options on a SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:12:36 -0000 Chairs, Joe, This will come as a surprise to everyone. Overnight, I believe I thought up a much better way of extending the option space on a SYN. So I rushed to write it up before the TCPM meeting. I have just posted it as: "Extended TCP Option Space in the Payload of an Alternative SYN" I will still talk about the joint draft between Joe & I in the meeting - in a few minutes, but I may also mention this new one (if time). Bob ________________________________________________________________ Bob Briscoe, BT From nobody Mon Jul 21 08:36:09 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23E61A01C6 for ; Mon, 21 Jul 2014 08:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHf1bvU9BfSY for ; Mon, 21 Jul 2014 08:36:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA261A0137 for ; Mon, 21 Jul 2014 08:36:07 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6LFZatt021327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Jul 2014 08:35:39 -0700 (PDT) Message-ID: <53CD334A.5000705@isi.edu> Date: Mon, 21 Jul 2014 08:35:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe , Yoshifumi Nishida , "SAROLAHTI, Pasi" , SCHARF Michael References: <201407211412.s6LECP6N032672@bagheera.jungle.bt.co.uk> In-Reply-To: <201407211412.s6LECP6N032672@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TjwsH8dNp19pK6JeOouBkYXMokA Cc: tcpm IETF list Subject: Re: [tcpm] An even better way of extending TCP options on a SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:36:09 -0000 Hi, Bob, This is the same as SYN-EOS DS with these three changes: 1) instead of the two SYNs working together, SYN-C is self-contained 2) the option is after the payload rather than before 3) use of a magic number to detect rewriting On these points: #1 - DS SYNs already basically do this PRO of this solution: no need to wait for SYN-D if SYN-C arrives first CON of this solution: connections to upgraded servers have the same overhead for client and server as legacy in EOS-DS: client needs to keep track of two connections and RST one in process server needs to open two connections all the time, just to kill one off I don't see the PRO worth the CON, but that's me #2 - seems like unnecessary complexity This just complicates option processing - remember that there are other options that process options, such as TCP-AO, and having the space be discontinuous begs how it is handled in cases like AO with no option coverage (for NAT traversal) #3 - insufficient vs. a true checksum I don't think a checksum needs to be incredibly strong, but I also don't think a magic number is a sufficient substitute So I don't think this is better, but that's me... Joe On 7/21/2014 7:12 AM, Bob Briscoe wrote: > Chairs, Joe, > > This will come as a surprise to everyone. > > Overnight, I believe I thought up a much better way of extending the > option space on a SYN. So I rushed to write it up before the TCPM > meeting. I have just posted it as: > > "Extended TCP Option Space in the Payload of an Alternative SYN" > > > I will still talk about the joint draft between Joe & I in the meeting - > in a few minutes, but I may also mention this new one (if time). > > > Bob > > > > > ________________________________________________________________ > Bob Briscoe, BT From nobody Mon Jul 21 12:25:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CAC1A036A for ; Mon, 21 Jul 2014 12:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmejTQw4ANlT for ; Mon, 21 Jul 2014 12:25:13 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610DC1A020B for ; Mon, 21 Jul 2014 12:25:13 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 21 Jul 2014 20:25:12 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 21 Jul 2014 20:25:11 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Mon, 21 Jul 2014 20:25:10 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.228.102]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6LJP4RS001572; Mon, 21 Jul 2014 20:25:08 +0100 Message-ID: <201407211925.s6LJP4RS001572@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Jul 2014 20:24:06 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <53CD334A.5000705@isi.edu> References: <201407211412.s6LECP6N032672@bagheera.jungle.bt.co.uk> <53CD334A.5000705@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/x0aVwUXq4YfVb2d4wwQ89bZB_kc Cc: tcpm IETF list Subject: Re: [tcpm] An even better way of extending TCP options on a SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:25:20 -0000 Joe, At 16:35 21/07/2014, Joe Touch wrote: >Hi, Bob, > >This is the same as SYN-EOS DS with these three changes: > > 1) instead of the two SYNs working together, SYN-C is > self-contained > > 2) the option is after the payload rather than before > > 3) use of a magic number to detect rewriting > >On these points: > >#1 - DS SYNs already basically do this > > PRO of this solution: > no need to wait for SYN-D if SYN-C arrives first Main PRO is no need for fate sharing (if the 2 SYNs end up at different servers, or crossing different paths, it doesn't matter, 'cos you only use one or the other, so each has to be self-contained. > CON of this solution: > connections to upgraded servers have the same > overhead for client and server as legacy in EOS-DS: > client needs to keep track of two connections > and RST one in process You will probably prefer the alternative solution in the appendix. Did you read this? > server needs to open two connections > all the time, just to kill one off Again, the alternative solution allows the upgraded server not to have to open the second connection. You might wonder why I put the solution that solves these problems in the appendix and not in the body. I chose the one for the body based on near-perfect middlebox traversal, 'cos I put function above non-functional issues like overhead/performance. Others may have different priorities - which is why I documented both solutions. > I don't see the PRO worth the CON, but that's me Solving the fate sharing problem with DS is the big win. And the new one is far simpler. >#2 - seems like unnecessary complexity > > This just complicates option processing - remember > that there are other options that process options, > such as TCP-AO, and having the space be discontinuous > begs how it is handled in cases like AO with no > option coverage (for NAT traversal) Surely it's no problem to marshall the options and the payload out of the packet into two separate structures (in memory) before working through the options and applying them to the remaining payload? It's only the same sort of operation as a pseudoheader. >#3 - insufficient vs. a true checksum > > I don't think a checksum needs to be incredibly strong, > but I also don't think a magic number is a sufficient substitute The magic number isn't to protect against re-writing. It's so an upgraded server can distinguish an upgraded SYN. Again, you'll probably prefer the alt solution in the appendix that does this the conventional way with a visible TCP option, rather than a hidden one. Bob >So I don't think this is better, but that's me... > >Joe > >On 7/21/2014 7:12 AM, Bob Briscoe wrote: >>Chairs, Joe, >> >>This will come as a surprise to everyone. >> >>Overnight, I believe I thought up a much better way of extending the >>option space on a SYN. So I rushed to write it up before the TCPM >>meeting. I have just posted it as: >> >>"Extended TCP Option Space in the Payload of an Alternative SYN" >> >> >>I will still talk about the joint draft between Joe & I in the meeting - >>in a few minutes, but I may also mention this new one (if time). >> >> >>Bob >> >> >> >> >>________________________________________________________________ >>Bob Briscoe, BT > >________________________________________________________________ >Bob Briscoe, BT From nobody Mon Jul 21 13:00:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCD61A041B for ; Mon, 21 Jul 2014 13:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OATHCoaOW52f for ; Mon, 21 Jul 2014 13:00:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14811A03C2 for ; Mon, 21 Jul 2014 13:00:31 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s6LK08WU012625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Jul 2014 13:00:08 -0700 (PDT) Message-ID: <53CD7148.2060704@isi.edu> Date: Mon, 21 Jul 2014 13:00:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <201407211412.s6LECP6N032672@bagheera.jungle.bt.co.uk> <53CD334A.5000705@isi.edu> <201407211925.s6LJP4RS001572@bagheera.jungle.bt.co.uk> In-Reply-To: <201407211925.s6LJP4RS001572@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nNF3w1SPBaWaTOVkKg0ODLSqyOA Cc: tcpm IETF list Subject: Re: [tcpm] An even better way of extending TCP options on a SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:00:38 -0000 On 7/21/2014 12:24 PM, Bob Briscoe wrote: > Joe, > > At 16:35 21/07/2014, Joe Touch wrote: >> Hi, Bob, >> >> This is the same as SYN-EOS DS with these three changes: >> >> 1) instead of the two SYNs working together, SYN-C is >> self-contained >> >> 2) the option is after the payload rather than before >> >> 3) use of a magic number to detect rewriting >> >> On these points: >> >> #1 - DS SYNs already basically do this >> >> PRO of this solution: >> no need to wait for SYN-D if SYN-C arrives first > > Main PRO is no need for fate sharing (if the 2 SYNs end up at different > servers, or crossing different paths, it doesn't matter, 'cos you only > use one or the other, so each has to be self-contained. Yes, it avoids fate-sharing problems. >> CON of this solution: >> connections to upgraded servers have the same >> overhead for client and server as legacy in EOS-DS: >> client needs to keep track of two connections >> and RST one in process > > You will probably prefer the alternative solution in the appendix. Did > you read this? I did, but it's much messier and I don't think it is better. FWIW, the client overhead statement above isn't affected; instead of sending a RST, it just interprets the SYN/ACK-L as a RST. I don't like interpreting a segment as something it isn't; IMO, a RST should have been sent. >> server needs to open two connections >> all the time, just to kill one off > > Again, the alternative solution allows the upgraded server not to have > to open the second connection. It depends on what you call "open"; the upgraded server still needs to process both incoming SYNs and respond to them both. Even without allocating extra memory, that's a different amount of work than silently keeping the OOB supplement. > You might wonder why I put the solution that solves these problems in > the appendix and not in the body. I chose the one for the body based on > near-perfect middlebox traversal,'cos I put function above > non-functional issues like overhead/performance. Others may have > different priorities - which is why I documented both solutions. > >> I don't see the PRO worth the CON, but that's me > > Solving the fate sharing problem with DS is the big win. And the new one > is far simpler. It's nearly exactly the same, AFAICT - except for fate sharing. IMO, this can be a fix of SYN-EOS DS rather than a separate approach, but it's your call. >> #2 - seems like unnecessary complexity >> >> This just complicates option processing - remember >> that there are other options that process options, >> such as TCP-AO, and having the space be discontinuous >> begs how it is handled in cases like AO with no >> option coverage (for NAT traversal) > > Surely it's no problem to marshall the options and the payload out of > the packet into two separate structures (in memory) before working > through the options and applying them to the remaining payload? That's a copy operation that slows things down, and AFAICT serves no useful purpose. > It's > only the same sort of operation as a pseudoheader. Yes, but that's entrenched in TCP and UDP processing; you're adding a new one. >> #3 - insufficient vs. a true checksum >> >> I don't think a checksum needs to be incredibly strong, >> but I also don't think a magic number is a sufficient substitute > > The magic number isn't to protect against re-writing. It's so an > upgraded server can distinguish an upgraded SYN. Why is that any different than the option type? I don't see the benefit. > Again, you'll probably prefer the alt solution in the appendix that does > this the conventional way with a visible TCP option, rather than a > hidden one. > > > Bob > > >> So I don't think this is better, but that's me... >> >> Joe >> >> On 7/21/2014 7:12 AM, Bob Briscoe wrote: >>> Chairs, Joe, >>> >>> This will come as a surprise to everyone. >>> >>> Overnight, I believe I thought up a much better way of extending the >>> option space on a SYN. So I rushed to write it up before the TCPM >>> meeting. I have just posted it as: >>> >>> "Extended TCP Option Space in the Payload of an Alternative SYN" >>> >>> >>> I will still talk about the joint draft between Joe & I in the meeting - >>> in a few minutes, but I may also mention this new one (if time). >>> >>> >>> Bob >>> >>> >>> >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT >> >> ________________________________________________________________ >> Bob Briscoe, BT From nobody Mon Jul 21 14:01:25 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AA21A04F1 for ; Mon, 21 Jul 2014 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrqAwSDfHnWC for ; Mon, 21 Jul 2014 14:01:22 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDFEF1A0444 for ; Mon, 21 Jul 2014 14:01:21 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 21 Jul 2014 22:01:20 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 21 Jul 2014 22:01:16 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 21 Jul 2014 22:01:15 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.144.220]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6LL1CLm001936; Mon, 21 Jul 2014 22:01:13 +0100 Message-ID: <201407212101.s6LL1CLm001936@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Jul 2014 22:01:09 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <53CD7148.2060704@isi.edu> References: <201407211412.s6LECP6N032672@bagheera.jungle.bt.co.uk> <53CD334A.5000705@isi.edu> <201407211925.s6LJP4RS001572@bagheera.jungle.bt.co.uk> <53CD7148.2060704@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/fZTIkx6cUT6GxwMUEEZWwJ8xbJo Cc: tcpm IETF list Subject: Re: [tcpm] An even better way of extending TCP options on a SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:01:24 -0000 At 21:00 21/07/2014, Joe Touch wrote: >On 7/21/2014 12:24 PM, Bob Briscoe wrote: >>Joe, >> >>At 16:35 21/07/2014, Joe Touch wrote: >>>Hi, Bob, >>> >>>This is the same as SYN-EOS DS with these three changes: >>> >>> 1) instead of the two SYNs working together, SYN-C is >>> self-contained >>> >>> 2) the option is after the payload rather than before >>> >>> 3) use of a magic number to detect rewriting >>> >>>On these points: >>> >>>#1 - DS SYNs already basically do this >>> >>> PRO of this solution: >>> no need to wait for SYN-D if SYN-C arrives first >> >>Main PRO is no need for fate sharing (if the 2 SYNs end up at different >>servers, or crossing different paths, it doesn't matter, 'cos you only >>use one or the other, so each has to be self-contained. > >Yes, it avoids fate-sharing problems. >>> CON of this solution: >>> connections to upgraded servers have the same >>> overhead for client and server as legacy in EOS-DS: >>> client needs to keep track of two connections >>> and RST one in process >> >>You will probably prefer the alternative solution in the appendix. Did >>you read this? > >I did, but it's much messier and I don't think it is better. I don't think you can have read it. It is cleaner, not messier, ... ...because the server can explicitly know the SYN-L is from an upgraded client, so it can explicitly say it knows this, and not have to open connection state. Then the client explicitly knows that the server knows. In the other solution, there's more guessing and timeouts (but its middlebox traveral is likely to be very comprehensive - maybe 100%). >FWIW, the client overhead statement above isn't affected; instead of >sending a RST, it just interprets the SYN/ACK-L as a RST. I don't >like interpreting a segment as something it isn't; IMO, a RST should >have been sent. That's a good idea. I'll change it so the server sends RST instead of SYN/ACK-L. And I'll ACK you. (I obviously didn't think too hard about this part - I've just realised I didn't even define the SYN/ACK-L segment. Now I don't have to.) >>> server needs to open two connections >>> all the time, just to kill one off >> >>Again, the alternative solution allows the upgraded server not to have >>to open the second connection. > >It depends on what you call "open"; the upgraded server still needs >to process both incoming SYNs and respond to them both. Even without >allocating extra memory, that's a different amount of work than >silently keeping the OOB supplement. No it's not. It's a straight discard of that SYN, against one 'if' statement: if (SYN-OP-SIS-supported && incoming SYN-L flag) discard >>You might wonder why I put the solution that solves these problems in >>the appendix and not in the body. I chose the one for the body based on >>near-perfect middlebox traversal,'cos I put function above >>non-functional issues like overhead/performance. Others may have >>different priorities - which is why I documented both solutions. >> >>> I don't see the PRO worth the CON, but that's me >> >>Solving the fate sharing problem with DS is the big win. And the new one >>is far simpler. > >It's nearly exactly the same, AFAICT - except for fate sharing. > >IMO, this can be a fix of SYN-EOS DS rather than a separate >approach, but it's your call. THere is a huge amount more complexity in DS (& OOB), because of the attempt to tie together two segments. Treating them as alternatives cuts through a load of crap. >>>#2 - seems like unnecessary complexity >>> >>> This just complicates option processing - remember >>> that there are other options that process options, >>> such as TCP-AO, and having the space be discontinuous >>> begs how it is handled in cases like AO with no >>> option coverage (for NAT traversal) >> >>Surely it's no problem to marshall the options and the payload out of >>the packet into two separate structures (in memory) before working >>through the options and applying them to the remaining payload? > >That's a copy operation that slows things down, and AFAICT serves no >useful purpose. ...other than proxy traversal. > > It's >>only the same sort of operation as a pseudoheader. > >Yes, but that's entrenched in TCP and UDP processing; you're adding a new one. > >>>#3 - insufficient vs. a true checksum >>> >>> I don't think a checksum needs to be incredibly strong, >>> but I also don't think a magic number is a sufficient substitute >> >>The magic number isn't to protect against re-writing. It's so an >>upgraded server can distinguish an upgraded SYN. > >Why is that any different than the option type? I don't see the benefit. The headers of /all/ segments contain no hint that anything different is happening. Bob >>Again, you'll probably prefer the alt solution in the appendix that does >>this the conventional way with a visible TCP option, rather than a >>hidden one. >> >> >>Bob >> >> >>>So I don't think this is better, but that's me... >>> >>>Joe >>> >>>On 7/21/2014 7:12 AM, Bob Briscoe wrote: >>>>Chairs, Joe, >>>> >>>>This will come as a surprise to everyone. >>>> >>>>Overnight, I believe I thought up a much better way of extending the >>>>option space on a SYN. So I rushed to write it up before the TCPM >>>>meeting. I have just posted it as: >>>> >>>>"Extended TCP Option Space in the Payload of an Alternative SYN" >>>> >>>> >>>>I will still talk about the joint draft between Joe & I in the meeting - >>>>in a few minutes, but I may also mention this new one (if time). >>>> >>>> >>>>Bob >>>> >>>> >>>> >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, BT >>> >>>________________________________________________________________ >>>Bob Briscoe, BT >> >>________________________________________________________________ >>Bob Briscoe, BT From nobody Mon Jul 21 14:22:07 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82721A0428 for ; Mon, 21 Jul 2014 14:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7CLgAhY_rHk for ; Mon, 21 Jul 2014 14:22:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE481A02C1 for ; Mon, 21 Jul 2014 14:22:02 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s6LLLokB005389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Jul 2014 14:21:50 -0700 (PDT) Message-ID: <53CD846E.40808@isi.edu> Date: Mon, 21 Jul 2014 14:21:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <201407211412.s6LECP6N032672@bagheera.jungle.bt.co.uk> <53CD334A.5000705@isi.edu> <201407211925.s6LJP4RS001572@bagheera.jungle.bt.co.uk> <53CD7148.2060704@isi.edu> <201407212101.s6LL1CLm001936@bagheera.jungle.bt.co.uk> In-Reply-To: <201407212101.s6LL1CLm001936@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BFQ3bxaMACf1CTcZweOQT_kk4DY Cc: tcpm IETF list Subject: Re: [tcpm] An even better way of extending TCP options on a SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:22:05 -0000 On 7/21/2014 2:01 PM, Bob Briscoe wrote: > At 21:00 21/07/2014, Joe Touch wrote: > > >> On 7/21/2014 12:24 PM, Bob Briscoe wrote: >>> Joe, >>> >>> At 16:35 21/07/2014, Joe Touch wrote: >>>> Hi, Bob, >>>> >>>> This is the same as SYN-EOS DS with these three changes: >>>> >>>> 1) instead of the two SYNs working together, SYN-C is >>>> self-contained >>>> >>>> 2) the option is after the payload rather than before >>>> >>>> 3) use of a magic number to detect rewriting >>>> >>>> On these points: >>>> >>>> #1 - DS SYNs already basically do this >>>> >>>> PRO of this solution: >>>> no need to wait for SYN-D if SYN-C arrives first >>> >>> Main PRO is no need for fate sharing (if the 2 SYNs end up at different >>> servers, or crossing different paths, it doesn't matter, 'cos you only >>> use one or the other, so each has to be self-contained. >> >> Yes, it avoids fate-sharing problems. >>>> CON of this solution: >>>> connections to upgraded servers have the same >>>> overhead for client and server as legacy in EOS-DS: >>>> client needs to keep track of two connections >>>> and RST one in process >>> >>> You will probably prefer the alternative solution in the appendix. Did >>> you read this? >> >> I did, but it's much messier and I don't think it is better. > > I don't think you can have read it. It is cleaner, not messier, ... I consider acting on a SYN/ACK-L as if it were a RST messier. > ...because the server can explicitly know the SYN-L is from an upgraded > client, so it can explicitly say it knows this, and not have to open > connection state. SYN-EOS DS already knows that too. I didn't understand why the corresponding SYN in the main body didn't have the option. > Then the client explicitly knows that the server knows. It only knows when the other connection succeeds or gets a RST (or SYN/ACK-L) back. Until then, it doesn't know what kind of server it's dealing with. > In the other solution, there's more guessing and timeouts (but its > middlebox traveral is likely to be very comprehensive - maybe 100%). Yeah, but it a trivial difference; as I said, it's basically what is already in SYN-EOS DS, so I had been assuming it as any dual-SYN solution. >> FWIW, the client overhead statement above isn't affected; instead of >> sending a RST, it just interprets the SYN/ACK-L as a RST. I don't like >> interpreting a segment as something it isn't; IMO, a RST should have >> been sent. > > That's a good idea. I'll change it so the server sends RST instead of > SYN/ACK-L. > And I'll ACK you. But then you're basically just back to SYN-EOS DS except that the SYNs are mutually exclusive. A server still may need to cache the SYN-L because it can't know that the upgraded SYN will make it through the middlebox (it could have blocked it because it's on another port, or sent it somewhere else). I.e., you still have the endpoint fate-sharing problem here. > (I obviously didn't think too hard about this part - I've just realised > I didn't even define the SYN/ACK-L segment. Now I don't have to.) > > >>>> server needs to open two connections >>>> all the time, just to kill one off >>> >>> Again, the alternative solution allows the upgraded server not to have >>> to open the second connection. >> >> It depends on what you call "open"; the upgraded server still needs to >> process both incoming SYNs and respond to them both. Even without >> allocating extra memory, that's a different amount of work than >> silently keeping the OOB supplement. > > No it's not. It's a straight discard of that SYN, against one 'if' > statement: > if (SYN-OP-SIS-supported && incoming SYN-L flag) discard You can't just jump to that conclusion; what happens if the other SYN is blocked or went to a different endpoint (that might not support SYN-OP-SIS)? >>> You might wonder why I put the solution that solves these problems in >>> the appendix and not in the body. I chose the one for the body based on >>> near-perfect middlebox traversal,'cos I put function above >>> non-functional issues like overhead/performance. Others may have >>> different priorities - which is why I documented both solutions. >>> >>>> I don't see the PRO worth the CON, but that's me >>> >>> Solving the fate sharing problem with DS is the big win. And the new one >>> is far simpler. >> >> It's nearly exactly the same, AFAICT - except for fate sharing. >> >> IMO, this can be a fix of SYN-EOS DS rather than a separate approach, >> but it's your call. > > THere is a huge amount more complexity in DS (& OOB), because of the > attempt to tie together two segments. Treating them as alternatives cuts > through a load of crap. You still need to tie the segments together or you might end up never connecting in some cases (e.g., when a middlebox allows the legacy version through but scrambles the upgraded version). So sure, we can easily put the one new idea here in the other doc - one that, FWIW, we did consider - that the options are mutually exclusive, not merged. I.e.: DS: legacy uses only SYN-D options. upgraded uses only SYN-C options. OOB: legacy uses only SYN options. upgraded uses only OOB options. In both cases, you want the supplement to be a strict superset of the options in the legacy case. >>>> #2 - seems like unnecessary complexity >>>> >>>> This just complicates option processing - remember >>>> that there are other options that process options, >>>> such as TCP-AO, and having the space be discontinuous >>>> begs how it is handled in cases like AO with no >>>> option coverage (for NAT traversal) >>> >>> Surely it's no problem to marshall the options and the payload out of >>> the packet into two separate structures (in memory) before working >>> through the options and applying them to the remaining payload? >> >> That's a copy operation that slows things down, and AFAICT serves no >> useful purpose. > > ...other than proxy traversal. I don't see it helping any more than putting the options at the head. What am I missing? I didn't check whether you lie about the TCP segment size, but if you do a server might be correct in truncating those options off the end. >> > It's >>> only the same sort of operation as a pseudoheader. >> >> Yes, but that's entrenched in TCP and UDP processing; you're adding a >> new one. >> >>>> #3 - insufficient vs. a true checksum >>>> >>>> I don't think a checksum needs to be incredibly strong, >>>> but I also don't think a magic number is a sufficient >>>> substitute >>> >>> The magic number isn't to protect against re-writing. It's so an >>> upgraded server can distinguish an upgraded SYN. >> >> Why is that any different than the option type? I don't see the benefit. > > The headers of /all/ segments contain no hint that anything different is > happening. Sure they do - the magic number. You're just creating a new field that you hope nobody steps on, rather than using one that's already defined for that purpose. Joe > > > > Bob > > >>> Again, you'll probably prefer the alt solution in the appendix that does >>> this the conventional way with a visible TCP option, rather than a >>> hidden one. >>> >>> >>> Bob >>> >>> >>>> So I don't think this is better, but that's me... >>>> >>>> Joe >>>> >>>> On 7/21/2014 7:12 AM, Bob Briscoe wrote: >>>>> Chairs, Joe, >>>>> >>>>> This will come as a surprise to everyone. >>>>> >>>>> Overnight, I believe I thought up a much better way of extending the >>>>> option space on a SYN. So I rushed to write it up before the TCPM >>>>> meeting. I have just posted it as: >>>>> >>>>> "Extended TCP Option Space in the Payload of an Alternative SYN" >>>>> >>>>> >>>>> I will still talk about the joint draft between Joe & I in the >>>>> meeting - >>>>> in a few minutes, but I may also mention this new one (if time). >>>>> >>>>> >>>>> Bob >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________________________________________ >>>>> Bob Briscoe, BT >>>> >>>> ________________________________________________________________ >>>> Bob Briscoe, BT >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT From nobody Tue Jul 22 21:43:00 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E16E1A0302 for ; Tue, 22 Jul 2014 21:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyII5xY4E2Sq for ; Tue, 22 Jul 2014 21:42:56 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053971B2788 for ; Tue, 22 Jul 2014 21:42:55 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 23 Jul 2014 05:42:48 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 23 Jul 2014 05:42:53 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 23 Jul 2014 05:42:52 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.1.220]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6N4gi40009219; Wed, 23 Jul 2014 05:42:47 +0100 Message-ID: <201407230442.s6N4gi40009219@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Jul 2014 05:42:42 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <53CD846E.40808@isi.edu> References: <201407211412.s6LECP6N032672@bagheera.jungle.bt.co.uk> <53CD334A.5000705@isi.edu> <201407211925.s6LJP4RS001572@bagheera.jungle.bt.co.uk> <53CD7148.2060704@isi.edu> <201407212101.s6LL1CLm001936@bagheera.jungle.bt.co.uk> <53CD846E.40808@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TNcbMI26XQOS0J9QqQsRKknRlyY Cc: tcpm IETF list Subject: Re: [tcpm] An even better way of extending TCP options on a SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 04:42:59 -0000 Joe, At 22:21 21/07/2014, Joe Touch wrote: >On 7/21/2014 2:01 PM, Bob Briscoe wrote: >>At 21:00 21/07/2014, Joe Touch wrote: >> >> >>>On 7/21/2014 12:24 PM, Bob Briscoe wrote: >>>>Joe, >>>> >>>>At 16:35 21/07/2014, Joe Touch wrote: >>>>>Hi, Bob, >>>>> >>>>>This is the same as SYN-EOS DS with these three changes: >>>>> >>>>> 1) instead of the two SYNs working together, SYN-C is >>>>> self-contained >>>>> >>>>> 2) the option is after the payload rather than before >>>>> >>>>> 3) use of a magic number to detect rewriting >>>>> >>>>>On these points: >>>>> >>>>>#1 - DS SYNs already basically do this >>>>> >>>>> PRO of this solution: >>>>> no need to wait for SYN-D if SYN-C arrives first >>>> >>>>Main PRO is no need for fate sharing (if the 2 SYNs end up at different >>>>servers, or crossing different paths, it doesn't matter, 'cos you only >>>>use one or the other, so each has to be self-contained. >>> >>>Yes, it avoids fate-sharing problems. >>>>> CON of this solution: >>>>> connections to upgraded servers have the same >>>>> overhead for client and server as legacy in EOS-DS: >>>>> client needs to keep track of two connections >>>>> and RST one in process >>>> >>>>You will probably prefer the alternative solution in the appendix. Did >>>>you read this? >>> >>>I did, but it's much messier and I don't think it is better. >> >>I don't think you can have read it. It is cleaner, not messier, ... > >I consider acting on a SYN/ACK-L as if it were a RST messier. > >>...because the server can explicitly know the SYN-L is from an upgraded >>client, so it can explicitly say it knows this, and not have to open >>connection state. > >SYN-EOS DS already knows that too. I didn't understand why the >corresponding SYN in the main body didn't have the option. The main solution is designed to work without any new TCP options in the header before the payload. Then it will (naturally) work if middleboxes strip options. And it will work through split connections that don't pass options on. >>Then the client explicitly knows that the server knows. > >It only knows when the other connection succeeds or gets a RST (or >SYN/ACK-L) back. Until then, it doesn't know what kind of server >it's dealing with. No. In the alternative solution (appendix) the client knows (that the server knows that the client is upgraded) immediately the response returns, because the protocol requires the response to the SYN-L from an upgraded server to be different to that from a legacy server. That's why there's a wait shown in the main solution, but not in the alternative solution. >>In the other solution, there's more guessing and timeouts (but its >>middlebox traveral is likely to be very comprehensive - maybe 100%). > >Yeah, but it a trivial difference; as I said, it's basically what is >already in SYN-EOS DS, so I had been assuming it as any dual-SYN solution. > >>>FWIW, the client overhead statement above isn't affected; instead of >>>sending a RST, it just interprets the SYN/ACK-L as a RST. I don't like >>>interpreting a segment as something it isn't; IMO, a RST should have >>>been sent. >> >>That's a good idea. I'll change it so the server sends RST instead of >>SYN/ACK-L. >>And I'll ACK you. > >But then you're basically just back to SYN-EOS DS except that the >SYNs are mutually exclusive. > >A server still may need to cache the SYN-L because it can't know >that the upgraded SYN will make it through the middlebox (it could >have blocked it because it's on another port, or sent it somewhere else). > >I.e., you still have the endpoint fate-sharing problem here. Nope. There is now no assumption that the two upgraded servers are even the same physical server. They have the same IP address & port, but they are serving two completely independent connections from different source ports. >>(I obviously didn't think too hard about this part - I've just realised >>I didn't even define the SYN/ACK-L segment. Now I don't have to.) >> >> >>>>> server needs to open two connections >>>>> all the time, just to kill one off >>>> >>>>Again, the alternative solution allows the upgraded server not to have >>>>to open the second connection. >>> >>>It depends on what you call "open"; the upgraded server still needs to >>>process both incoming SYNs and respond to them both. Even without >>>allocating extra memory, that's a different amount of work than >>>silently keeping the OOB supplement. >> >>No it's not. It's a straight discard of that SYN, against one 'if' >>statement: >> if (SYN-OP-SIS-supported && incoming SYN-L flag) discard > >You can't just jump to that conclusion; what happens if the other >SYN is blocked or went to a different endpoint (that might not >support SYN-OP-SIS)? See above. The design is different from SYN-EOS DS: servers don't know or care about other connections. The client is the only node responsible for coordinating its activity on the two connections. If one connection doesn't work, the client uses the other. >>>>You might wonder why I put the solution that solves these problems in >>>>the appendix and not in the body. I chose the one for the body based on >>>>near-perfect middlebox traversal,'cos I put function above >>>>non-functional issues like overhead/performance. Others may have >>>>different priorities - which is why I documented both solutions. >>>> >>>>> I don't see the PRO worth the CON, but that's me >>>> >>>>Solving the fate sharing problem with DS is the big win. And the new one >>>>is far simpler. >>> >>>It's nearly exactly the same, AFAICT - except for fate sharing. >>> >>>IMO, this can be a fix of SYN-EOS DS rather than a separate approach, >>>but it's your call. >> >>THere is a huge amount more complexity in DS (& OOB), because of the >>attempt to tie together two segments. Treating them as alternatives cuts >>through a load of crap. > >You still need to tie the segments together or you might end up >never connecting in some cases (e.g., when a middlebox allows the >legacy version through but scrambles the upgraded version). I've added text for the fall-back if neither connection returns anything useful (draft...01 just submitted). >So sure, we can easily put the one new idea here in the other doc - >one that, FWIW, we did consider - that the options are mutually >exclusive, not merged. > >I.e.: DS: > legacy uses only SYN-D options. > upgraded uses only SYN-C options. > >OOB: > legacy uses only SYN options. > upgraded uses only OOB options. > >In both cases, you want the supplement to be a strict superset of >the options in the legacy case. I'm currently updating it independently. I don't particularly want to maintain DS any more. I think 'SynOpSis' is wholly superior (altho I admit I haven't done a systematic comparison of every case). SynOpSis could replace DS in the SYN-EOS doc. But currently I don't see enough common features that argue for these two approaches being in the same doc. It would make it more confusing than useful to try to lever them into the same doc. But I'm prepared to be convinced otherwise. >>>>>#2 - seems like unnecessary complexity >>>>> >>>>> This just complicates option processing - remember >>>>> that there are other options that process options, >>>>> such as TCP-AO, and having the space be discontinuous >>>>> begs how it is handled in cases like AO with no >>>>> option coverage (for NAT traversal) >>>> >>>>Surely it's no problem to marshall the options and the payload out of >>>>the packet into two separate structures (in memory) before working >>>>through the options and applying them to the remaining payload? >>> >>>That's a copy operation that slows things down, and AFAICT serves no >>>useful purpose. The rules on processing order in both cases (see draft) are arranged to allow some of the extra options in the payload to be processed before regular header options, if required. So, even if the extra options were at the front of the payload, you would not be able to just run on from the end of the regular TCP options into those in the payload. Anyway, to process blocks of data in memory in a certain sequence doesn't require them to be copied around in memory. They only have to referenced (pointed to) in order. >>...other than proxy traversal. > >I don't see it helping any more than putting the options at the >head. What am I missing? I didn't check whether you lie about the >TCP segment size, but if you do a server might be correct in >truncating those options off the end. No lying. Middleboxes that inspect app-layer headers expect them to be at the front of the payload. >>> > It's >>>>only the same sort of operation as a pseudoheader. >>> >>>Yes, but that's entrenched in TCP and UDP processing; you're adding a >>>new one. For a good reason. >>>>>#3 - insufficient vs. a true checksum >>>>> >>>>> I don't think a checksum needs to be incredibly strong, >>>>> but I also don't think a magic number is a sufficient >>>>>substitute >>>> >>>>The magic number isn't to protect against re-writing. It's so an >>>>upgraded server can distinguish an upgraded SYN. >>> >>>Why is that any different than the option type? I don't see the benefit. >> >>The headers of /all/ segments contain no hint that anything different is >>happening. > >Sure they do - the magic number. You're just creating a new field >that you hope nobody steps on, rather than using one that's already >defined for that purpose. I think you need to look again at the draft. The SynOpSis option is in the payload (at least in the spec in the main body). I.e. the option that says there are options in the payload is itself in the payload. I'm about to post a revision -01, which has some text about the probability of a clash with this magic number. Bob >Joe > > >> >> >> >>Bob >> >> >>>>Again, you'll probably prefer the alt solution in the appendix that does >>>>this the conventional way with a visible TCP option, rather than a >>>>hidden one. >>>> >>>> >>>>Bob >>>> >>>> >>>>>So I don't think this is better, but that's me... >>>>> >>>>>Joe >>>>> >>>>>On 7/21/2014 7:12 AM, Bob Briscoe wrote: >>>>>>Chairs, Joe, >>>>>> >>>>>>This will come as a surprise to everyone. >>>>>> >>>>>>Overnight, I believe I thought up a much better way of extending the >>>>>>option space on a SYN. So I rushed to write it up before the TCPM >>>>>>meeting. I have just posted it as: >>>>>> >>>>>>"Extended TCP Option Space in the Payload of an Alternative SYN" >>>>>> >>>>>> >>>>>>I will still talk about the joint draft between Joe & I in the >>>>>>meeting - >>>>>>in a few minutes, but I may also mention this new one (if time). >>>>>> >>>>>> >>>>>>Bob >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>________________________________________________________________ >>>>>>Bob Briscoe, BT >>>>> >>>>>________________________________________________________________ >>>>>Bob Briscoe, BT >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, BT >>> >>>________________________________________________________________ >>>Bob Briscoe, BT From nobody Tue Jul 22 21:49:56 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A031B27FF for ; Tue, 22 Jul 2014 21:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruFV7YUJ-lzs for ; Tue, 22 Jul 2014 21:49:54 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3E71B27E8 for ; Tue, 22 Jul 2014 21:49:53 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 23 Jul 2014 05:49:52 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 23 Jul 2014 05:49:51 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 23 Jul 2014 05:49:51 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.1.220]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s6N4ni7k009254 for ; Wed, 23 Jul 2014 05:49:47 +0100 Message-ID: <201407230449.s6N4ni7k009254@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Jul 2014 05:49:42 +0100 To: tcpm IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4Fz4vuuT2gLadtJnKEEW1QCMY-Y Subject: [tcpm] option space on a SYN draft-briscoe-tcpm-syn-op-sis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 04:49:55 -0000 TCPM, I've updated the new draft I posted yesterday. Main changes from briscoe...-00 to briscoe...-01: Technical changes: * Deterministic Protocol Spec: Replaced SYN/ACK-L with RST (Joe Touch) * Added 2 more Alternative Protocol Specs in Appendices * Added Comparison of Alternatives as an Appendix * Security Considerations: Added note about crypto coverage of TCP options in the payload being different from that of other TCP options. * Added an appendix to record outstanding Protocol Design Issues, and included segmentation boundary issue (Yuchung Cheng). Editorial changes: * Protocol Spec: Explained why the extra TCP options are placed at the end of the payload * Throughout: avoided the ambiguity in the word payload, now that there are TCP options at the end of the payload. Some might consider these to be within the payload, while others might consider them to be placed beyond the payload. BOb >From: >To: Bob Briscoe , "Bob J. Briscoe" >Subject: New Version Notification for draft-briscoe-tcpm-syn-op-sis-01.txt >Date: Tue, 22 Jul 2014 21:37:01 -0700 > > >A new version of I-D, draft-briscoe-tcpm-syn-op-sis-01.txt >has been successfully submitted by Bob Briscoe and posted to the >IETF repository. > >Name: draft-briscoe-tcpm-syn-op-sis >Revision: 01 >Title: Extended TCP Option Space in the Payload of an Alternative SYN >Document date: 2014-07-22 >Group: Individual Submission >Pages: 15 >URL: >http://www.ietf.org/internet-drafts/draft-briscoe-tcpm-syn-op-sis-01.txt >Status: >https://datatracker.ietf.org/doc/draft-briscoe-tcpm-syn-op-sis/ >Htmlized: http://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-01 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-briscoe-tcpm-syn-op-sis-01 > >Abstract: > This document describes an experimental method to extend the option > space for connection parameters within the initial TCP SYN segment at > the start of a TCP connection. In this method the TCP client sends > two alternative SYNs: one intended for legacy servers and one > intended for upgraded servers. Once it establishes which type of > server has responded, it continues the connection appropriate to that > server type and aborts the other. The SYN intended for upgraded > servers includes additional options at the end of the payload. > > > > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat ________________________________________________________________ Bob Briscoe, BT From nobody Thu Jul 24 07:29:34 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A697B1A0395 for ; Thu, 24 Jul 2014 07:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJm36cObe6zV for ; Thu, 24 Jul 2014 07:29:29 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id 55B931A02E1 for ; Thu, 24 Jul 2014 07:29:29 -0700 (PDT) Received: from pasisarahtismbp.lan (80.223.92.46) by kirsi1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 53D0A9E800099DB9 for tcpm@ietf.org; Thu, 24 Jul 2014 17:29:28 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 24 Jul 2014 17:29:27 +0300 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/f9PuLbNnYPxsSu3tINrxXvu2zl8 Subject: [tcpm] Draft TCPM meeting minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:29:32 -0000 Hi, Draft meeting minutes are now available at = http://www.ietf.org/proceedings/90/minutes/minutes-90-tcpm . Many thanks = to Michael Welzl and Stuart Cheshire for taking excellent notes! Please = let us know of any needed corrections. One belated comment related to the discussion about the status of = draft-ietf-tcpm-newcwv: there has been no earlier WGLC on the draft yet. = Last March we had a call to confirm the consensus on Experimental vs. PS = status, but that was not a WGLC for draft content. There is a small = editorial note in the minutes to make that clarification, to avoid any = future confusion. - Pasi From nobody Fri Jul 25 12:04:55 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D601A0401; Fri, 25 Jul 2014 12:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThcX8ROgA5EY; Fri, 25 Jul 2014 12:04:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 877D91A0402; Fri, 25 Jul 2014 12:04:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140725190452.9921.17305.idtracker@ietfa.amsl.com> Date: Fri, 25 Jul 2014 12:04:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Fv9DULkLwa8U9WdrNp2cx77PX6U Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:04:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Problem Statement and Requirements for a More Accurate ECN Feedback Authors : Mirja Kuehlewind Richard Scheffenegger Bob Briscoe Filename : draft-ietf-tcpm-accecn-reqs-07.txt Pages : 16 Date : 2014-07-25 Abstract: Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like ConEx or DCTCP) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accecn-reqs-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 29 07:34:29 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2B1B2858 for ; Tue, 29 Jul 2014 07:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuQr7UxP9yy7 for ; Tue, 29 Jul 2014 07:34:24 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB8A1B281E for ; Tue, 29 Jul 2014 07:34:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,757,1400050800"; d="asc'?scan'208";a="178803204" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 29 Jul 2014 07:33:56 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Jul 2014 07:33:56 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 29 Jul 2014 07:33:56 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::8c6:4c4c:718d:b192%21]) with mapi id 15.00.0913.011; Tue, 29 Jul 2014 07:33:55 -0700 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: New Version Notification for draft-zimmermann-tcpm-undeployed-01.txt Thread-Index: AQHPqzci9aNE2elhOEaW07CxLiofLg== Date: Tue, 29 Jul 2014 14:33:55 +0000 Message-ID: <89635FEF-4663-4C1D-8D4B-174AB734BCC2@netapp.com> References: <20140729141219.17062.63137.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_E19052FE-1250-40EE-A038-D09AE9349FC4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EG-hnibq_tFCECoiSrc2l-xfRag Subject: [tcpm] Fwd: New Version Notification for draft-zimmermann-tcpm-undeployed-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 14:34:28 -0000 --Apple-Mail=_E19052FE-1250-40EE-A038-D09AE9349FC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi folks, I updated 'draft-zimmermann-tcpm-undeployed=92. Basically, I * checked via the data tracker if we have problems w/ normative = references that point to those drafts. No problems. * deleted RFC0761 from the list, because it is already obsolete * we obsolete now RFC1078 (TCPMUX) * we do not obsolete RFC0813 and RFC0816 anymore. Instead, we mark them = as Informational * we mark RFC0896 as Informational Last open question is now if we (in the case the draft is accepted as WG = item) can obsolete RFC6013 since this RFC was published via the Independent Stream. The = ball is now at the IESG (Martin) Alex Anfang der weitergeleiteten Nachricht: > Von: > Betreff: New Version Notification for = draft-zimmermann-tcpm-undeployed-01.txt > Datum: 29. Juli 2014 16:12:19 MESZ > An: Lars Eggert , Lars Eggert , = "Wesley M.Eddy" , Wesley Eddy = , "Alexander Zimmermann" = , Alexander Zimmermann = >=20 >=20 > A new version of I-D, draft-zimmermann-tcpm-undeployed-01.txt > has been successfully submitted by Alexander Zimmermann and posted to = the > IETF repository. >=20 > Name: draft-zimmermann-tcpm-undeployed > Revision: 01 > Title: Moving Undeployed TCP Extensions to Historic and = Informational Status -- An addition to RFC 6247 > Document date: 2014-07-29 > Group: Individual Submission > Pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-zimmermann-tcpm-undeployed-01.tx= t > Status: = https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-undeployed/ > Htmlized: = http://tools.ietf.org/html/draft-zimmermann-tcpm-undeployed-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-zimmermann-tcpm-undeployed-01 >=20 > Abstract: > This document reclassifies several TCP extensions that have either > been superceded or never seen widespread use to Historic status. = The > affected RFCs are RFC 675, RFC 721, RFC 879, RFC 1078, and RFC 6013. > Additionally, it reclassifies RFC 813, RFC 814, RFC 816, RFC 817, = RFC > 872, RFC 896, and RFC 964 to Informational status. Most of those > RFCs are today part of RFC 1122. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_E19052FE-1250-40EE-A038-D09AE9349FC4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEUEARECAAYFAlPXsNYACgkQdyiq39b9uS7D4wCdGwESGYkbw5Axy1TgNRFmP1tf W4MAliYd9WmT8RMrYpzT9NzBb7qhpLE= =GkBd -----END PGP SIGNATURE----- --Apple-Mail=_E19052FE-1250-40EE-A038-D09AE9349FC4--