From nobody Fri Sep 1 04:10:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7E1132EDB for ; Fri, 1 Sep 2017 04:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7z3t6iqzaScf for ; Fri, 1 Sep 2017 04:10:28 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E33133174 for ; Fri, 1 Sep 2017 04:10:27 -0700 (PDT) Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v81B9rxN009170; Fri, 1 Sep 2017 12:09:53 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0319.002; Fri, 1 Sep 2017 12:09:36 +0100 From: Lucas Pardue To: Spencer Dawkins at IETF , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "gorry@erg.abdn.ac.uk" , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , "quic@ietf.org" , Christian Huitema Subject: RE: Congestion Control Questions Thread-Topic: Congestion Control Questions Thread-Index: AQHTHcsJFuR7PBr0kE26nOgjmbN0bqKVaHoAgABBtgCABBAlgIAAODeAgAAFuQCAAWP8gIAEgwtA Date: Fri, 1 Sep 2017 11:09:35 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A377665A5@bgb01xud1012> References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23296.004 x-tm-as-result: No--22.517700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A377665A5bgb01xud1012_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 11:10:30 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A377665A5bgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gQXVnIDI5IDIwMTcsIFNwZW5jZXIgRGF3a2lucyB3cm90ZToNCg0KSSdtIGhvcGluZyB0aGF0 J3MgdHJ1ZSwgYnV0IGZlZWwgSSBzaG91bGQgYXNrIGlmIHBlb3BsZSBhcmUgdGhpbmtpbmcgYWJv dXQgYmVoYXZpb3IgdGhhdCdzIE5PVCBzZW5kZXItc2lkZSBvbmx5LCByaWdodCBhYm91dCBoZXJl LCBpbiB0aGlzIHRocmVhZC4NCg0KVHdvIHRob3VnaHRzIGNvbWUgdG8gbWluZDoNCg0KDQogIDEu ICBQcmV2aW91cyBkaXNjdXNzaW9ucyBvbiB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGhhdmUgZWxp Y2l0ZWQgc29tZSBpZGVhcyBvbiB1bmlkaXJlY3Rpb25hbCBmbG93cy4gV2l0aG91dCBmYWxsaW5n IGludG8gdGhlIG11bHRpcGF0aCB0cmFwLCBkbyB0aGVzZSBoYXZlIHNlbmRlci1zaWRlIG9ubHkg Q0MgY2hhcmFjdGVyaXN0aWNzPw0KICAyLiAgTXVsdGljYXN0LiBUcnlpbmcgdG8gYXZvaWQgb3Bl bmluZyB0aGF0IGNhbiBvZiB3b3JtcyBidXQgdGhlcmUgYXJlIHNvbWUgc2ltaWxhcml0aWVzIHRv IHRoZSBhYm92ZSB1bmlkaXJlY3Rpb25hbCBmbG93IHRob3VnaHRzLiBCQ1AgMTQ1IFNlY3Rpb24g NC4xIGNvdmVycyB0aGlzIHRvcGljLCBzdGF0aW5nIOKAnEFwcGxpY2F0aW9ucyB1c2luZyBtdWx0 aWNhc3QgU0hPVUxEIHByb3ZpZGUgYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiBjb250cm9s4oCdIGFu ZCBkZWZpbmVzIHR3byBzdHlsZXMgb2YgQ0M6IOKAnEZlZWRiYWNrLWJhc2Vk4oCdIGFuZCDigJxS ZWNlaXZlci1kcml2ZW7igJ0uIFJlY2VpdmVyLWRyaXZlbiBDQyBjYW4gc3RpbGwgYmUgc3ViamVj dCB0byBjb25nZXN0aW9uIGluIHRoZSBuZXR3b3JrWzFdLCBhbmQgd2hpbGUgdGhlcmUgbWF5IGJl IHNvbWUgcHJvcG9zYWxzIChzdWNoIGFzIENpcmN1aXQgQnJlYWtlcnMpIHRvIGhlbHAgYXZvaWQg dGhpcywgaXQgc3RpbGwgYXBwZWFycyB0byBiZSBvcGVuLg0KDQpJIGFwcHJlY2lhdGUgdGhpcyBp cyBwcm9iYWJseSBvdXQgb2Ygc2NvcGUgb2YgUVVJQyBhdCB0aGlzIHRpbWUsIGhvd2V2ZXIgd2Ug aGF2ZSBiZWVuIHBsYXlpbmcgd2l0aCBhIGZvcm0gb2YgUmVjZWl2ZXItZHJpdmVuIENDIHdpdGgg UVVJQy4NCg0KTHVjYXMNCg0KWzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3 L3NsaWRlcy9zbGlkZXMtOTctaWNjcmctbWFsaWNpb3VzLW92ZXJzdWJzY3JpYmluZy1pbi1tdWx0 aWNhc3QtcHJvYmxlbS1hbmQtcHJvcG9zZWQtc29sdXRpb24tMDAucGRmDQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A377665A5bgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6Njc5NjI0NDY1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMTIzNDc2Njg1MCAxMzQ4MDc1NjkgMTM0ODA3NTc3IDEz NDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3 IDEzNDgwNzU3OTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1 ZyAyOSAyMDE3LCBTcGVuY2VyIERhd2tpbnMgd3JvdGU6PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGhvcGluZyB0aGF0 J3MgdHJ1ZSwgYnV0IGZlZWwgSSBzaG91bGQgYXNrIGlmIHBlb3BsZSBhcmUgdGhpbmtpbmcgYWJv dXQgYmVoYXZpb3IgdGhhdCdzIE5PVCBzZW5kZXItc2lkZSBvbmx5LCByaWdodCBhYm91dCBoZXJl LCBpbiB0aGlzIHRocmVhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+VHdvIHRob3VnaHRzIGNvbWUgdG8gbWluZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIx Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5QcmV2aW91cyBkaXNjdXNz aW9ucyBvbiB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGhhdmUgZWxpY2l0ZWQgc29tZSBpZGVhcyBv biB1bmlkaXJlY3Rpb25hbCBmbG93cy4gV2l0aG91dCBmYWxsaW5nIGludG8NCiB0aGUgbXVsdGlw YXRoIHRyYXAsIGRvIHRoZXNlIGhhdmUgc2VuZGVyLXNpZGUgb25seSBDQyBjaGFyYWN0ZXJpc3Rp Y3M/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+TXVsdGljYXN0LiBUcnlpbmcgdG8gYXZvaWQgb3BlbmluZyB0aGF0IGNhbiBvZiB3b3Jt cyBidXQgdGhlcmUgYXJlIHNvbWUgc2ltaWxhcml0aWVzIHRvIHRoZSBhYm92ZSB1bmlkaXJlY3Rp b25hbCBmbG93DQogdGhvdWdodHMuIEJDUCAxNDUgU2VjdGlvbiA0LjEgY292ZXJzIHRoaXMgdG9w aWMsIHN0YXRpbmcg4oCcQXBwbGljYXRpb25zIHVzaW5nIG11bHRpY2FzdCBTSE9VTEQgcHJvdmlk ZSBhcHByb3ByaWF0ZSBjb25nZXN0aW9uIGNvbnRyb2zigJ0gYW5kIGRlZmluZXMgdHdvIHN0eWxl cyBvZiBDQzog4oCcRmVlZGJhY2stYmFzZWTigJ0gYW5kIOKAnFJlY2VpdmVyLWRyaXZlbuKAnS4g UmVjZWl2ZXItZHJpdmVuIENDIGNhbiBzdGlsbCBiZSBzdWJqZWN0IHRvIGNvbmdlc3Rpb24NCiBp biB0aGUgbmV0d29ya1sxXSwgYW5kIHdoaWxlIHRoZXJlIG1heSBiZSBzb21lIHByb3Bvc2FscyAo c3VjaCBhcyBDaXJjdWl0IEJyZWFrZXJzKSB0byBoZWxwIGF2b2lkIHRoaXMsIGl0IHN0aWxsIGFw cGVhcnMgdG8gYmUgb3Blbi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBhcHByZWNpYXRlIHRoaXMg aXMgcHJvYmFibHkgb3V0IG9mIHNjb3BlIG9mIFFVSUMgYXQgdGhpcyB0aW1lLCBob3dldmVyIHdl IGhhdmUgYmVlbiBwbGF5aW5nIHdpdGggYSBmb3JtIG9mIFJlY2VpdmVyLWRyaXZlbiBDQyB3aXRo IFFVSUMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkx1Y2FzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlsxXSBodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LWljY3JnLW1hbGljaW91 cy1vdmVyc3Vic2NyaWJpbmctaW4tbXVsdGljYXN0LXByb2JsZW0tYW5kLXByb3Bvc2VkLXNvbHV0 aW9uLTAwLnBkZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7CF7F94CB496BF4FAB1676F375F9666A377665A5bgb01xud1012_-- From nobody Fri Sep 1 06:48:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32D2132EB9 for ; Fri, 1 Sep 2017 06:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 KfrtO5yPrfgx for ; Fri, 1 Sep 2017 06:48:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040B1132D4A for ; Fri, 1 Sep 2017 06:48:44 -0700 (PDT) X-AuditID: c1b4fb30-57fff70000005897-80-59a9653a2ce1 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C4.F7.22679.A3569A95; Fri, 1 Sep 2017 15:48:42 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Sep 2017 15:48:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o6u7ENVSkazf4vMvCB3I0jLCC3SywA90zWleY+xdDDA=; b=HRWG4/6O0HDnxMau99L0LalP1ZTwoFNVlfy7fdYpH0PNkB+em+d5+KDoIVxXtbB4i0eTr/tSrGftDa1BbdvPxvmln8jbLDmtsfIAagJ7r3ZQPvMp7CnAbAqmgPf4u32mgAHy750wo2UqGCmNdTeYYRllt72NIuXu4VcaDp9au+c= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB0734.eurprd07.prod.outlook.com (10.242.223.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Fri, 1 Sep 2017 13:48:39 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::6cfe:5150:638e:9143]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::6cfe:5150:638e:9143%14]) with mapi id 15.20.0013.012; Fri, 1 Sep 2017 13:48:39 +0000 From: Ingemar Johansson S To: Spencer Dawkins at IETF , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "gorry@erg.abdn.ac.uk" , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , "quic@ietf.org" , Christian Huitema Subject: RE: Congestion Control Questions Thread-Topic: Congestion Control Questions Thread-Index: AQHTIPkz40u5gle9skOrQ8TU6wbvv6KgDDbw Date: Fri, 1 Sep 2017 13:48:39 +0000 Message-ID: References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB0734; 6:SVnyY0yOX2YPuEYov6ODj8wO6WXu/14CEewF1xGqpjAZRerpsNKutXz9eShFeRCylOlTDIWkW/4qbeXAcmsQOVNwAymKA/B5TEjGNRgRbP4msHbCNTFv2DTLCPoZNa5MVR/wlN54UNjGymwBRfAUg19pu4A7MASBtwnFADfus9afBtgqEPvFZE0tuWaDtQkbOxeZ5z4JSa0M1zvuP6BC8yeYjDPx7PLIHsjg+LmJWIPooN0UYDaF4aCaR9f377gR3lv5RXVL4j31o/Oz06GEjfsctr+aGu3eOjm6pqK5IKBtgtLNpkvr8JdwPd1IEGT+uF8hksx3r7dgY0w4E11Kow==; 5:xFOOzrLJna3UlZhoo30b6N5MwsSG2zXxfy6X1PRCHy2VodXVXKTtXKlv1cK42mnvUh3OLUK+FFKPOirCoMuTdg6+fgh2IPP8tbVHD42vESzD8VokeB53jSiKbPbPmvONWajY7zhMcUR/tYbC0lQv4g==; 24:DVubNNixp16HbQ00pMBYxeDmg9EHvxbbpwGINFoovmn2TJNSuA1IUcKTMa+bDhKREobe8tCtUTgkRexdTOzk4FbRo2lP/feS/9iFx9kUVdo=; 7:f4VcrFxSaPvlbQ1ZLB6edm55hrrL85g+pDz2wBbaQq5Sv4vED431ikATJ+2li0P2HItaaa3SoenwBXs7c7emxLDPgZy1IWTKncB7I5Kn1ubcn/4HtGkqjKb9xM7JCVtVciZyTn/WblFBViF5cyTiiqbc8bYiIeMbbBprlq465mHL3IZCyohI5h/7PP+hKj7Q/bh37r/flN8hrLh0+CP25Sp2g/6lYQ6sc7qgVLR7BgY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5c8cef8c-033c-4bac-6bb4-08d4f14026d6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB0734; x-ms-traffictypediagnostic: DB4PR07MB0734: x-exchange-antispam-report-test: UriScan:(82608151540597)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB0734; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB0734; x-forefront-prvs: 0417A3FFD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(85664002)(199003)(189002)(377454003)(24454002)(8936002)(6246003)(14454004)(3660700001)(106356001)(3280700002)(105586002)(189998001)(101416001)(81156014)(6506006)(478600001)(81166006)(2906002)(229853002)(2900100001)(7736002)(5250100002)(53936002)(6436002)(9326002)(66066001)(93886005)(7696004)(5660300001)(7116003)(8676002)(86362001)(74316002)(2950100002)(25786009)(97736004)(236005)(54906002)(3480700004)(6306002)(54896002)(4326008)(53546010)(9686003)(68736007)(39060400002)(3846002)(102836003)(6116002)(55016002)(19609705001)(790700001)(54356999)(76176999)(99286003)(33656002)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0734; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348A9376404DEA5FA0AE170C2920DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2017 13:48:39.6776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0734 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGO/fe3V1Xi+Na+GoFNYLSUnNFDBHJilpfYFCY+kcuvehyTt1U NIom2lpTI9O+3GxCs7LCJI2+JHNmrpg4NQINU1NLM01ME5WkbVeh/573eX7nvO97OAwpauf5 MUp1BqtRK1QSWkDdOvEsKjCUrYreNlS+UjaqNyFZSa6JL6t5WErJCiuWy+6W1pOygeFachct L/w9TMhflPXw5d03P1Byq3WWkPd0dxDydxPTdCQdIwhLYFXKLFYTHB4nSOp500CmGeOzL5fY CR2qiTMiLwbwDsgz3CCNSMCI8FsEbZUVi0ULgnb9BM9NUbiIBMfts1xwjQCTo5zmij4Ek6a3 tJuicRhU2WaQOxDjCwhyjRcpd0FiB4JveX8oN7UK+4Oh9ZJHi3EAFEw38jgtBUuZxXWacfXb CEWPPLYQx0Dhwjx/cUASzIPPkDvwwkdhtqCfdGuE10HvzBfPnST2ge5BC8Fth8Fa30ZyejWM DCzwOD4eJruKeO5egNeD9a8vh6yDDkuBZwHAej6Y7/UiLgiCp8Vji/oIVLc7SQ76SkCjsZri ggDQtd5ZhA7CD/uSnwx9pcUEd6CTB/kzdpoL1kJTwxRxBW0t+29wTqeCYb6SKvO8gDe8vzXo 0ozL94fHL4M5ZAOUFvTzOb0ZLpjL+f/7FYj/AK3WstpTKYlSaRCrUcZrtanqIDWb8QS5Plpj 3fy252jke4QNYQZJVginrtyPFvEUWdqcFBsChpSIhbEJVdEiYYIi5wyrST2pyVSxWhtaw1AS H2HEa+cJEU5UZLDJLJvGapZSgvHy06Gk3Xs7BC0H3jj9m2l10qbU9OvGos5XivPZ2V023fHP sTLHDesD++FlTqHqV+a4fnCuOitl+0ToMkvyvvAgb12Ib8DYuXRn06hyz8vaOUGEITxS3Gww jWflG0vooS2+C/p+ZdNPx7HAjyHSNq+6WN3OBb3xdJd5r37/vkNRsk9XJZQ2SRESQGq0in/w Rez5ZAMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 13:48:48 -0000 --_000_DB4PR07MB348A9376404DEA5FA0AE170C2920DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCk5vdCBzdXJlIGlmIEkgZm9sbG93IHRoZSBpbnRlbnRpb24gd2l0aCB0aGlzIGNvbmdlc3Rp b24gY29udHJvbCBkaXNjdXNzaW9uIGFuZCB3aGVyZSBpdCBpcyBnb2luZy4NCg0KSWYgdGhlcmUg YXJlIGlkZWFzIHRvIHNwbGl0IGNvbmdlc3Rpb24gY29udHJvbCBiZXR3ZWVuIHNlbmRlciBhbmQg cmVjZWl2ZXIgdGhlbiBJIHdvdWxkIGFzayBwZW9wbGUgdG8gYXQgbGVhc3QgdGhpbmsgdHdpY2Ug YmVmb3JlIGdvaW5nIGRvd24gdGhhdCBsaW5lLiBPbmUgYmlnIHF1ZXN0aW9uIG1hcmsgaXMgaW50 ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIHZlcnNpb25zLCBhIHNlbmRlciBiYXNlZCBDQyBvbmx5IChv ciByZWNlaXZlciBvbmx5KSBpcyBtdWNoIG1vcmUgbGlrZWx5IHRvIGJlIGludGVyb3BlcmFibGUg YmV0d2VlbiBRVUlDIHZlcnNpb25zIHRoYW4gYSBDQyB3aGVyZSBwYXJ0cyBhcmUgc3BsaXQgdXAu IE15IHByZWZlcmVuY2UgKHJlZmxlY3RlZCBpbiB0aGUgU0NSZUFNIHdvcmspIGlzIGEgc2VuZGVy IHNpZGUgb25seSBhcyB0aGUgc2VuZGVyIGZvciBuYXR1cmFsIHJlYXNvbnMgaGFzIHRoZSBiZXN0 IGtub3dsZWRnZSB3aGF0IGl0IGlzIHRvIHRyYW5zbWl0Lg0KDQpJIGhhdmUgc29tZSBiYWQgZXhw ZXJpZW5jZSB3aXRoIHRoZSBNVFNJIChWb2ljZSwgVmlkZW8pIGNvbmdlc3Rpb24gY29udHJvbCBp biAzR1BQICh3aGljaCBJIGFtIHBhcnRseSBndWlsdHkgb2YpLiBJdCBzcGVjaWZpZXMgYSBtaXgg b2YgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29zLCB3aGVyZSBzb21lIHBhcnRzIGFyZSBpbXBsZW1l bnRlZCBvbiB0aGUgc2VuZGVyIHNpZGUgYW5kIHNvbWUgcGFydHMgYXJlIG9uIHRoZSByZWNlaXZl ciBzaWRlLiBUaGUgZW5kIHJlc3VsdCBpcyBxdWl0ZSBtZXNzeS4gSW4gc29tZSBlZmZvcnQgIG9m IGEgZGVmZW5zZSBmb3IgdGhlIE1UU0kgY29uZ2VzdGlvbiBjb250cm9sIGlzIHRoYXQgaXQgbmVl ZGVkIHRvIHdvcmsgYWxzbyB3aXRoIGNpcmN1aXQgc3dpdGNoZWQgY29ubmVjdGlvbnMsIGlmIHJl LWRvbmUgdG9kYXkgSSBiZWxpZXZlIHRoYXQgaXQgd291bGQgYmUgbXVjaCBjbGVhbmVyIGJ1dCB3 ZSBhcmUgc3R1Y2sgd2l0aCBhIG5lZWQgdG8gaW50ZXJvcCB3aXRoIG9sZGVyIGxlZ2FjeSBlcXVp cG1lbnQuLg0KDQovSW5nZW1hcg0KDQpGcm9tOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFp bHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tXQ0KU2VudDogZGVuIDI5IGF1Z3VzdGkg MjAxNyAxNjozNw0KVG86IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVl LmV0aHouY2g+DQpDYzogZ29ycnlAZXJnLmFiZG4uYWMudWs7IFN3aW5kZWxscywgVGhvbWFzIChO b2tpYSAtIEdCL0NhbWJyaWRnZSwgVUspIDx0aG9tYXMuc3dpbmRlbGxzQG5va2lhLmNvbT47IHF1 aWNAaWV0Zi5vcmc7IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3Vi amVjdDogUmU6IENvbmdlc3Rpb24gQ29udHJvbCBRdWVzdGlvbnMNCg0KRldJVywNCg0KT24gTW9u LCBBdWcgMjgsIDIwMTcgYXQgMTI6MjMgUE0sIE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhs ZXdpbmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHou Y2g+PiB3cm90ZToNCk15IHRoaW5raW5nIGFjdHVhbGx5IHdhcyB0aGF0IHRoZSByZWNvdmVyeSBh bmQgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZXMgYXJlIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQg YmVjYXVzZSB0aGlzIGdpdmVzIHlvdSB0aGUgZmxleGliaWxpdHkgdG8gc3BlY2lmeSBhbHRlcm5h dGl2ZXMgaW4gZnV0dXJlLg0KDQpUaGF0IHdhcyBjZXJ0YWlubHkgbXkgdW5kZXJzdGFuZGluZywg d2hlbiB3ZSB3ZXJlIGRvaW5nIHRoZSBjaGFydGVyLg0KDQpJZiB0aGVyZSBhcmUgcGFydHMgaW4g dGhpcyBkb2N1bWVudCB0aGF0IGFyZSBtYW5kYXRvcnkgZm9yIGFsbCBmdXR1cmUgaW5zdGFuY2Vz IG9mIHRoaXMgdmVyc2lvbiBvZiBRVUlDIG9yIHNwZWNpZnkgcmVxdWlyZW1lbnRzLCB0aGV5IHNo b3VsZCBnbyBpbnRvIHRoZSBtYWluIHRyYW5zcG9ydCBzcGVjLiBIb3dldmVyLCBJIHRoaW5rIGFs bCB3ZSByZWFsbHkgbmVlZCBpbiB0aGUgbWFpbiBzcGVjIGlzIGEgcmVxdWlyZW1lbnQgdG8gZG8g Y29uZ2VzdGlvbiBjb250cm9sIGF0IGFsbDsNCg0KSSB3b3VsZCBzdXBwb3J0IHRoYXQgLi4uIGJ1 dCwganVzdCB0byB0YWtlIGEgUVVJQyghKSBzYW1wbGUgLi4uDQoNCmV2ZXJ5dGhpbmcgZWxzZSBp biB0aGUgcmVjb3ZlcnkvY2MgZHJhZnQgc2hvdWxkIGJlIHNlbmRlci1zaWRlIG9ubHkgYW5kIGNh biB0aGVyZWZvcmUgYmUgY2hhbmdlZCB3aXRob3V0IHJlcXVpcmluZyBhbnkgbmVnb3RpYXRpb24g b3IgY2hhbmdlcyBieSB0aGUgb3RoZXIgZW5kLg0KDQpJJ20gaG9waW5nIHRoYXQncyB0cnVlLCBi dXQgZmVlbCBJIHNob3VsZCBhc2sgaWYgcGVvcGxlIGFyZSB0aGlua2luZyBhYm91dCBiZWhhdmlv ciB0aGF0J3MgTk9UIHNlbmRlci1zaWRlIG9ubHksIHJpZ2h0IGFib3V0IGhlcmUsIGluIHRoaXMg dGhyZWFkLg0KDQpTcGVuY2VyDQo= --_000_DB4PR07MB348A9376404DEA5FA0AE170C2920DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qgc3Vy ZSBpZiBJIGZvbGxvdyB0aGUgaW50ZW50aW9uIHdpdGggdGhpcyBjb25nZXN0aW9uIGNvbnRyb2wg ZGlzY3Vzc2lvbiBhbmQgd2hlcmUgaXQgaXMgZ29pbmcuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SWYgdGhlcmUgYXJlIGlkZWFzIHRvIHNwbGl0IGNvbmdlc3Rpb24gY29udHJvbCBiZXR3ZWVu IHNlbmRlciBhbmQgcmVjZWl2ZXIgdGhlbiBJIHdvdWxkIGFzayBwZW9wbGUgdG8gYXQgbGVhc3Qg dGhpbmsgdHdpY2UgYmVmb3JlIGdvaW5nIGRvd24gdGhhdCBsaW5lLiBPbmUgYmlnIHF1ZXN0aW9u IG1hcmsgaXMgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIHZlcnNpb25zLCBhIHNlbmRlciBiYXNl ZCBDQyBvbmx5IChvcg0KIHJlY2VpdmVyIG9ubHkpIGlzIG11Y2ggbW9yZSBsaWtlbHkgdG8gYmUg aW50ZXJvcGVyYWJsZSBiZXR3ZWVuIFFVSUMgdmVyc2lvbnMgdGhhbiBhIENDIHdoZXJlIHBhcnRz IGFyZSBzcGxpdCB1cC4gTXkgcHJlZmVyZW5jZSAocmVmbGVjdGVkIGluIHRoZSBTQ1JlQU0gd29y aykgaXMgYSBzZW5kZXIgc2lkZSBvbmx5IGFzIHRoZSBzZW5kZXIgZm9yIG5hdHVyYWwgcmVhc29u cyBoYXMgdGhlIGJlc3Qga25vd2xlZGdlIHdoYXQgaXQgaXMgdG8gdHJhbnNtaXQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzb21lIGJhZCBleHBlcmllbmNlIHdpdGggdGhlIE1UU0kg KFZvaWNlLCBWaWRlbykgY29uZ2VzdGlvbiBjb250cm9sIGluIDNHUFAgKHdoaWNoIEkgYW0gcGFy dGx5IGd1aWx0eSBvZikuIEl0IHNwZWNpZmllcyBhIG1peCBvZiBjb25nZXN0aW9uIGNvbnRyb2wg YWxnb3MsIHdoZXJlIHNvbWUgcGFydHMgYXJlIGltcGxlbWVudGVkIG9uIHRoZSBzZW5kZXIgc2lk ZSBhbmQgc29tZSBwYXJ0cyBhcmUgb24NCiB0aGUgcmVjZWl2ZXIgc2lkZS4gVGhlIGVuZCByZXN1 bHQgaXMgcXVpdGUgbWVzc3kuIEluIHNvbWUgZWZmb3J0ICZuYnNwO29mIGEgZGVmZW5zZSBmb3Ig dGhlIE1UU0kgY29uZ2VzdGlvbiBjb250cm9sIGlzIHRoYXQgaXQgbmVlZGVkIHRvIHdvcmsgYWxz byB3aXRoIGNpcmN1aXQgc3dpdGNoZWQgY29ubmVjdGlvbnMsIGlmIHJlLWRvbmUgdG9kYXkgSSBi ZWxpZXZlIHRoYXQgaXQgd291bGQgYmUgbXVjaCBjbGVhbmVyIGJ1dCB3ZSBhcmUgc3R1Y2sgd2l0 aA0KIGEgbmVlZCB0byBpbnRlcm9wIHdpdGggb2xkZXIgbGVnYWN5IGVxdWlwbWVudC4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RnJvbTo8L2I+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3BlbmNlcmRhd2tpbnMu aWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDI5IGF1Z3VzdGkgMjAxNyAx NjozNzxicj4NCjxiPlRvOjwvYj4gTWlyamEgS8O8aGxld2luZCAmbHQ7bWlyamEua3VlaGxld2lu ZEB0aWsuZWUuZXRoei5jaCZndDs8YnI+DQo8Yj5DYzo8L2I+IGdvcnJ5QGVyZy5hYmRuLmFjLnVr OyBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSAmbHQ7dGhvbWFz LnN3aW5kZWxsc0Bub2tpYS5jb20mZ3Q7OyBxdWljQGlldGYub3JnOyBDaHJpc3RpYW4gSHVpdGVt YSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IENv bmdlc3Rpb24gQ29udHJvbCBRdWVzdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5GV0lXLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgQXVnIDI4LCAyMDE3IGF0IDEyOjIzIFBNLCBNaXJqYSBLw7xobGV3aW5kICZs dDs8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0 PSJfYmxhbmsiPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB0aGlu a2luZyBhY3R1YWxseSB3YXMgdGhhdCB0aGUgcmVjb3ZlcnkgYW5kIGNvbmdlc3Rpb24gY29udHJv bCBzY2hlbWVzIGFyZSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IGJlY2F1c2UgdGhpcyBnaXZlcyB5 b3UgdGhlIGZsZXhpYmlsaXR5IHRvIHNwZWNpZnkgYWx0ZXJuYXRpdmVzIGluIGZ1dHVyZS4NCjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhhdCB3YXMgY2VydGFpbmx5IG15IHVuZGVyc3RhbmRpbmcsIHdoZW4gd2Ugd2VyZSBkb2lu ZyB0aGUgY2hhcnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlcmUgYXJlIHBhcnRzIGluIHRoaXMgZG9jdW1lbnQgdGhh dCBhcmUgbWFuZGF0b3J5IGZvciBhbGwgZnV0dXJlIGluc3RhbmNlcyBvZiB0aGlzIHZlcnNpb24g b2YgUVVJQyBvciBzcGVjaWZ5IHJlcXVpcmVtZW50cywgdGhleSBzaG91bGQgZ28gaW50byB0aGUg bWFpbiB0cmFuc3BvcnQgc3BlYy4gSG93ZXZlciwgSSB0aGluayBhbGwgd2UgcmVhbGx5IG5lZWQg aW4gdGhlIG1haW4gc3BlYyBpcyBhIHJlcXVpcmVtZW50DQogdG8gZG8gY29uZ2VzdGlvbiBjb250 cm9sIGF0IGFsbDsgPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIHN1cHBvcnQgdGhhdCAuLi4gYnV0LCBqdXN0IHRvIHRh a2UgYSBRVUlDKCEpIHNhbXBsZSAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZXZlcnl0aGluZyBlbHNlIGluIHRoZSByZWNvdmVy eS9jYyBkcmFmdCBzaG91bGQgYmUgc2VuZGVyLXNpZGUgb25seSBhbmQgY2FuIHRoZXJlZm9yZSBi ZSBjaGFuZ2VkIHdpdGhvdXQgcmVxdWlyaW5nIGFueSBuZWdvdGlhdGlvbiBvciBjaGFuZ2VzIGJ5 IHRoZSBvdGhlciBlbmQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gaG9waW5nIHRoYXQncyB0cnVlLCBidXQgZmVlbCBJIHNo b3VsZCBhc2sgaWYgcGVvcGxlIGFyZSB0aGlua2luZyBhYm91dCBiZWhhdmlvciB0aGF0J3MgTk9U IHNlbmRlci1zaWRlIG9ubHksIHJpZ2h0IGFib3V0IGhlcmUsIGluIHRoaXMgdGhyZWFkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVuY2Vy Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DB4PR07MB348A9376404DEA5FA0AE170C2920DB4PR07MB348eurprd_-- From nobody Fri Sep 1 16:55:14 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF3132E22 for ; Fri, 1 Sep 2017 16:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 3zbc9h6R4g5o for ; Fri, 1 Sep 2017 16:55:10 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C9B13433E for ; Fri, 1 Sep 2017 16:55:10 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id c85so1558405ywa.0 for ; Fri, 01 Sep 2017 16:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HdhPNrhlM1mra/1jYIJUUhFL9urxytqg5PHLjzOSlns=; b=Fdd7VMZFBRSKCr6/IOtQMby3KsT3D4cxqd4COxT4ESi/UKLpyHKKoeTQsDuu87RwQt KHQpr6osFmiLEZ/EOAtRiR9/QxcYtOS/a6Yldsxh5kv2mB0VfuA4RU+wDg0lia2egMYO FB1iAd8xO2iCSZIMKHDDBSHD1uL7j1f9BIKVrmqkJB0UfgJmWkXrC0pd+yBMQqqFE32V /VKLMy++ADsfYFqmG0o8HtZmoAN5rE3mRNtqnbR7iPVyWZQfSmHhNo1OhEho0l3f/DmX Zd4de2s5a7LSj7Ymy/jKPsZKEvi6yO7DgY3uMKTD4u0yr+QN0uPp3O/KZ+5WnTFLyMS3 0nOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HdhPNrhlM1mra/1jYIJUUhFL9urxytqg5PHLjzOSlns=; b=ak1Tik8L06JQAnwT5rW7vAcHMajphR740Y2JaOM551lOzdKEEvGg5gm2iSebV1VXvY cAkfWj2BrwcXs9sXUSPXHE2RrcXp+6W/ZF7+sf3VHnTEVQDJI8ItAfmwfuoGGOlKq9Xs hQn5Mq2CLaVAhC5JRh2hqO6BLG3ldtuGKOOu03yw4gM8JUqGOE9gKMywAGWh1ym6X18D ueDRbaaDXLbzenS4EBknJLHxC+fOc1irdCeCOd29Hn4Ed2LJdTrqI2Z9zcv6wV118+Ha Q7QcUM7aqDyTpRr8Z+xa/4uwV1CcO3HyhAgu43KUBRr7rNXqQEq4pfdsm95ebAnpblST V/7g== X-Gm-Message-State: AHPjjUipDEgV2rvHbd+meuCHQjiVM56wKXR32GGjx0aYColNp7A2sq7k agcuhrjT89ysZD5ips+WlhkBcmUrt+Sl X-Google-Smtp-Source: ADKCNb787bxQZcTqzS2MteRdBmPC8zDX/mp8YfCBCMikZdemxJTGpukCNNc3zMXlGblO+VhBJL6H9yuKljH04GTRVNc= X-Received: by 10.37.118.84 with SMTP id r81mr3254210ybc.283.1504310109744; Fri, 01 Sep 2017 16:55:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Fri, 1 Sep 2017 16:55:08 -0700 (PDT) In-Reply-To: References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> From: Jana Iyengar Date: Fri, 1 Sep 2017 16:55:08 -0700 Message-ID: Subject: Re: Congestion Control Questions To: Ingemar Johansson S Cc: Spencer Dawkins at IETF , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "gorry@erg.abdn.ac.uk" , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , "quic@ietf.org" , Christian Huitema Content-Type: multipart/alternative; boundary="001a114b690ab997910558297d27" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 23:55:13 -0000 --001a114b690ab997910558297d27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would love to talk about other CC mechanisms, but in ICCRG :-) Pull the conversation back to the spec, I think we should keep recovery and CC both in this doc for now, and see if it's worth splitting them out later. I'm not convinced that the receiver needs to have input into the ack rate, but we can discuss that on issue #230. On Fri, Sep 1, 2017 at 6:48 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > Not sure if I follow the intention with this congestion control discussio= n > and where it is going. > > > > If there are ideas to split congestion control between sender and receive= r > then I would ask people to at least think twice before going down that > line. One big question mark is interoperability between versions, a sende= r > based CC only (or receiver only) is much more likely to be interoperable > between QUIC versions than a CC where parts are split up. My preference > (reflected in the SCReAM work) is a sender side only as the sender for > natural reasons has the best knowledge what it is to transmit. > > > > I have some bad experience with the MTSI (Voice, Video) congestion contro= l > in 3GPP (which I am partly guilty of). It specifies a mix of congestion > control algos, where some parts are implemented on the sender side and so= me > parts are on the receiver side. The end result is quite messy. In some > effort of a defense for the MTSI congestion control is that it needed to > work also with circuit switched connections, if re-done today I believe > that it would be much cleaner but we are stuck with a need to interop wit= h > older legacy equipment.. > > > > /Ingemar > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* den 29 augusti 2017 16:37 > *To:* Mirja K=C3=BChlewind > *Cc:* gorry@erg.abdn.ac.uk; Swindells, Thomas (Nokia - GB/Cambridge, UK) = < > thomas.swindells@nokia.com>; quic@ietf.org; Christian Huitema < > huitema@huitema.net> > *Subject:* Re: Congestion Control Questions > > > > FWIW, > > > > On Mon, Aug 28, 2017 at 12:23 PM, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > My thinking actually was that the recovery and congestion control schemes > are in a separate document because this gives you the flexibility to > specify alternatives in future. > > > > That was certainly my understanding, when we were doing the charter. > > > > If there are parts in this document that are mandatory for all future > instances of this version of QUIC or specify requirements, they should go > into the main transport spec. However, I think all we really need in the > main spec is a requirement to do congestion control at all; > > > > I would support that ... but, just to take a QUIC(!) sample ... > > > > everything else in the recovery/cc draft should be sender-side only and > can therefore be changed without requiring any negotiation or changes by > the other end. > > > > I'm hoping that's true, but feel I should ask if people are thinking abou= t > behavior that's NOT sender-side only, right about here, in this thread. > > > > Spencer > --001a114b690ab997910558297d27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would love to talk about other CC mechanisms, but in ICC= RG :-)

Pull the conversation back to the spec, I think w= e should keep recovery and CC both in this doc for now, and see if it's= worth splitting them out later. I'm not convinced that the receiver ne= eds to have input into the ack rate, but we can discuss that on issue #230.=

On Fr= i, Sep 1, 2017 at 6:48 AM, Ingemar Johansson S <ingemar.s.j= ohansson@ericsson.com> wrote:

Hi

Not sure if I follow the intention with this congest= ion control discussion and where it is going.

=C2=A0

If there are ideas to split congestion control betwe= en sender and receiver then I would ask people to at least think twice befo= re going down that line. One big question mark is interoperability between = versions, a sender based CC only (or receiver only) is much more likely to be interoperable between QUIC versio= ns than a CC where parts are split up. My preference (reflected in the SCRe= AM work) is a sender side only as the sender for natural reasons has the be= st knowledge what it is to transmit.

=C2=A0

I have some bad experience with the MTSI (Voice, Vid= eo) congestion control in 3GPP (which I am partly guilty of). It specifies = a mix of congestion control algos, where some parts are implemented on the = sender side and some parts are on the receiver side. The end result is quite messy. In some effort =C2=A0of = a defense for the MTSI congestion control is that it needed to work also wi= th circuit switched connections, if re-done today I believe that it would b= e much cleaner but we are stuck with a need to interop with older legacy equipment..

=C2=A0

/Ingemar

=C2=A0

From: Spencer Dawkins at IETF [mailto:spencerdawkins.= ietf@gmail.com]
Sent: den 29 augusti 2017 16:37
To: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch><= br> Cc: gorry@= erg.abdn.ac.uk; Swindells, Thomas (Nokia - GB/Cambridge, UK) <thomas.swindells@= nokia.com>; quic@= ietf.org; Christian Huitema <huitema@huitema.net>
Subject: Re: Congestion Control Questions

=C2=A0

FWIW,

=C2=A0

On Mon, Aug 28, 2017 at 12:23 PM, Mirja K=C3=BChlewi= nd <mirja.kuehlewind@tik.ee.ethz.ch> wrote:

My thinking actually was that the recovery and conge= stion control schemes are in a separate document because this gives you the= flexibility to specify alternatives in future.

=C2=A0

That was certainly my understanding, when we were do= ing the charter.

=C2=A0

If there are parts in this document that are mandato= ry for all future instances of this version of QUIC or specify requirements= , they should go into the main transport spec. However, I think all we real= ly need in the main spec is a requirement to do congestion control at all;

=C2=A0

I would support that ... but, just to take a QUIC(!)= sample ...

=C2=A0

everything else in the recovery/cc draft should be s= ender-side only and can therefore be changed without requiring any negotiat= ion or changes by the other end.

=C2=A0

I'm hoping that's true, but feel I should as= k if people are thinking about behavior that's NOT sender-side only, ri= ght about here, in this thread.

=C2=A0

Spencer=C2=A0


--001a114b690ab997910558297d27-- From nobody Sun Sep 3 05:55:13 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29EC13219B for ; Sun, 3 Sep 2017 05:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 P12XkSq8mRm4 for ; Sun, 3 Sep 2017 05:55:09 -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 E9BA4126B7E for ; Sun, 3 Sep 2017 05:55:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUR40312; Sun, 03 Sep 2017 12:55:06 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 3 Sep 2017 13:55:06 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Sun, 3 Sep 2017 20:55:02 +0800 From: Roni Even To: Martin Thomson , QUIC WG Subject: RE: -05 drafts published - transport draft comment Thread-Topic: -05 drafts published - transport draft comment Thread-Index: AdMks9mPiliaOEXMTGO0Nw9DpmzW1Q== Date: Sun, 3 Sep 2017 12:55:01 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD800ED6@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59ABFBAB.0041, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 960d38ff271065b57806f93300535f43 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 12:55:11 -0000 SGksDQpJIG5vdGljZWQgdGhhdCBwdWJsaWMgcmVzZXQgaXMgdGlsbCBtZW50aW9uZWQgaW4gc2Vj dGlvbiA1LjcgYW5kIDcuNw0KDQpSb25pIEV2ZW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTWFydGluIFRob21zb24NCj4gU2VudDog15nXldedwqDXkyAxNiDXkNeV15LXldeh15gg MjAxNyAwODoyMw0KPiBUbzogUVVJQyBXRw0KPiBTdWJqZWN0OiAtMDUgZHJhZnRzIHB1Ymxpc2hl ZA0KPiANCj4gWW91IHdpbGwgc2VlIHRoZXNlIGNvbWluZyB0aHJvdWdoIHNvb24uDQo+IA0KPiBU aGVyZSdzIG5ldmVyIGEgZ29vZCB0aW1lIHRvIGRvIHRoaXMsIGJ1dCB0aGUgZWRpdG9ycyBhZ3Jl ZWQgdGhhdCBpdCB3YXMgYWJvdXQNCj4gdGltZS4gIFRoZXJlIGFyZSBzb21lIGxhcmdlciBjaGFu Z2VzIGluIHRoZSBwaXBlLCBzbyB3ZSB0aG91Z2h0IHRoYXQgaXQgd291bGQNCj4gYmUgaGVscGZ1 bCB0byBjcmVhdGUgYSBtYXJrZXIgZm9yIGltcGxlbWVudGF0aW9ucy4NCg0K From nobody Sun Sep 3 21:55:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E794124207 for ; Sun, 3 Sep 2017 21:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ub6XgKmuBxkj for ; Sun, 3 Sep 2017 21:55:04 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FD61204DA for ; Sun, 3 Sep 2017 21:55:04 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id r203so36686133oih.0 for ; Sun, 03 Sep 2017 21:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DWmkIHOPZazc6PSFmyuCTPT2JfTnTOkoKyjqZCqyZxs=; b=Cb0NAJQh+aJAq9ZRxJphC1fqlhdKXY2jwCVHosQiTjhYXtkYLQFnn98c3U8Y6oFWzj uXQLfly+Aufhhs2vEkejkr2VyLW+g2pPjADm/iS53tZMUh8tQdgleDREYK1v/PlMv0mm XDAQhKeSCYSrrjMN2JQLzppBqHNixRn/+K4QU/wdTUjb3J1SkjhGAdbSLMuH4cNm3F+C 0xC6tIGBwT0o7Ae3DVJ8i7jl5lHDv6doDCmVAzsffwLdTyn1geRuWTsERsytFha1e7XQ PJ0UyaDME6aWsCs01bhWicEvBtqEvmbKkK4JZzRLwOBcBsQ+xS+3YpOzR/3NCV1w5F4v Ej+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DWmkIHOPZazc6PSFmyuCTPT2JfTnTOkoKyjqZCqyZxs=; b=J1BNXsPRTDpQxRynd0O3nm709ZYbLcw6pvsVtX5+47m/aQ3vyGSbF7wxMSWSP0aC4K ANK5JmjrY4Yc1O95vg+VdDGqPkpOWhqVEeUhMKut/HbTn+hLuMdv32iYif+bGP0z8HS0 4bxkyz9lL+AFl+tU8ngNytSWbs/Rb4nPQeLbTUxNMON4KJe6XvbiLmYDl0h7YVbtfDwe 1cZDGpGWJ9NwKRQJBw84SClJi25Esu4VhdSeNvh4naTXyiu/PtXH1XEj6TWEa8FhpdUb zqNTHSd0VXHkDv+aoiDQGllKcV7FmcBwP4bRK/WUcGCXT43+Y4opnDE0MxHlLZPwrrTA 5hXA== X-Gm-Message-State: AHPjjUjX75QQXg0d59VhNpak42aMgfV/QX8kYrKbA+T2I3txrEPAoASZ Q1h0weT5jmKzgMbk5o6TtIJDio3h2JgNLKg= X-Google-Smtp-Source: ADKCNb6615vxugJz4HXCPSQ53OqHjHgfZ8MxynjO5bhqQCNlaVeINmDXxvNUrn/9rye9NfnNBKJR2iKlxmkT43H449U= X-Received: by 10.202.229.198 with SMTP id c189mr195862oih.5.1504500903147; Sun, 03 Sep 2017 21:55:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Sun, 3 Sep 2017 21:55:02 -0700 (PDT) From: Martin Thomson Date: Mon, 4 Sep 2017 14:55:02 +1000 Message-ID: Subject: Split error codes in two To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 04:55:05 -0000 Input sought. I've a proposal in that splits the error code space: https://github.com/quicwg/base-drafts/pull/722 The basic idea here - one that I believe that we have agreement on, but would like to confirm - is that only applications should be cancelling streams. In short: if the transport kills a stream that the application was relying on, the whole application protocol state becomes indeterminate. In order to ensure no possibility of confusion, I think that it is cleaner to have transport errors and application errors. The above PR makes that split. It's a pretty clean cut, but there are a few costs: CONNECTION_CLOSE needs to be split because both application and transport might need to kill a connection. The NO_ERROR code is then duplicated. There is surprisingly little need for overlap on other error codes. In doing this, I realized two further things: 1. STOP_SENDING is a purely application-layer construct, but it's a transport-layer frame. That makes it much harder to manage with this change. Moving it to HTTP makes a lot of sense (to me). https://github.com/quicwg/base-drafts/pull/759 2. We are now nudging 20 error codes (plus the per-frame-type ones). 4 billion might be a little more space than we need, so halving the number of bits with give error cords seems reasonable: https://github.com/quicwg/base-drafts/pull/723 From nobody Mon Sep 4 13:03:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F00C126BF0 for ; Mon, 4 Sep 2017 13:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7IzRY9TshYgP for ; Mon, 4 Sep 2017 13:03:30 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D835124239 for ; Mon, 4 Sep 2017 13:03:30 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx26.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1doxac-00065T-VM for quic@ietf.org; Mon, 04 Sep 2017 22:03:29 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1doxaX-0001G1-OL for quic@ietf.org; Mon, 04 Sep 2017 16:03:21 -0400 Received: (qmail 27036 invoked from network); 4 Sep 2017 20:03:15 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.88]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Sep 2017 20:03:14 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <76d443bc-3e05-b91c-2d82-4b42a2e39f67@huitema.net> Date: Mon, 4 Sep 2017 13:03:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Split error codes in two X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbMzHFUa97P3bfY1LzB69ykND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23I3JrZ/fXFMymk2/Yv7IMGvzLO0shYmHPpSXw 3S8A3AqRkHyVzuSTWH072zVdykCPYOEkjsX7F8KmpUaZQHV+SaoNpL7PRmmTib7l1mO88Em2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpCbsjdvAic40+cHi4LtB9yDfPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEe4PW2FvUI0j8pJmeRPf+1Zqpb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/OySQHb3iwsf1ON/gXoJDVrp17vcIhp4/vU15YpEcaF91b7LCVq2nuinYFw/C3rfJ2V 3KD8IdSHBSi9yjOsRb3k8wJfEo0cbb0YLkzPOD/FDLswybukjjR7SZbxkOJ/tGOswfMZlU6KrHdP H7E9FnA1BOfl8hIUxn/cFVzK5dYMjHB/3WCT/ywxqGyDcX7ymo81pn6M7II0pBZMP8Q2yl7HZ8cC 5NCzOtKFVG2OgcPUMeKVse1sVhWabI0/+PN3sILCmP4sL9m2Y1BvIAo6egCemilw+ioChJ5n7tfm eH2kchap9/JGM7LGxIWWH81zEGo= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:03:32 -0000 On 9/3/2017 9:55 PM, Martin Thomson wrote: > In doing this, I realized two further things: > > 1. STOP_SENDING is a purely application-layer construct, but it's a > transport-layer frame. That makes it much harder to manage with this > change. Moving it to HTTP makes a lot of sense (to me). > > https://github.com/quicwg/base-drafts/pull/759 Arguably, MAX STREAM DATA is also an application-layer construct. If an application does not want to receive more bytes on a stream, it could stop increasing that counter. That would have more or less the same effect as STOP SENDING, in a passive aggressive way... > > 2. We are now nudging 20 error codes (plus the per-frame-type ones). > 4 billion might be a little more space than we need, so halving the > number of bits with give error cords seems reasonable: > > https://github.com/quicwg/base-drafts/pull/723 Is that really a priority? I mean, we probably do not really need to save 2 bytes in error messages. And then, how do we deal with extensions? Suppose that I define an experimental version of the protocol that brings both new functionality and new error codes. What number range shall I use for these extended error codes? --=20 Christian Huitema From nobody Mon Sep 4 16:55:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D37132193 for ; Mon, 4 Sep 2017 16:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Y7nmkeWA_Hce for ; Mon, 4 Sep 2017 16:55:52 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1198132192 for ; Mon, 4 Sep 2017 16:55:51 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id h70so13541229oic.1 for ; Mon, 04 Sep 2017 16:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=77YmVEVmpWgYaqTzTmBgTIgswNB5ZMBoA4eoKI0FEeo=; b=CCeEZ3US8hRbzI+zo1twIWZFwfxUeOR2ODa9vgJTCBbsSj/Xx/qH/+g7om1bo8o53P PbUmuuXf8PP6DeqAFAvoiivgyzH+sV9BjUEkZ+q3AxAYYgJGpg5QGVP8018RXr1E1wYg prmSxDD9wfoHANAb4RbWOLl0VeuYcxi4qz2DHFL1AMAkvsgMrH0qAdH4a9MxYWwPJn1x bFH2Lv2XP3fEN/FNWBHLfltRuTSC+UoEQAV7g6xY0b1MyV2fTsjfdCh8VIYbxuhz/QBu 4ewXC0M3r4KcGx93Z0wcPJD0bMjiOCUrp6qZBVegQ6V3C8i80/uQ6mwbFGqY34lC4aFB XqRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=77YmVEVmpWgYaqTzTmBgTIgswNB5ZMBoA4eoKI0FEeo=; b=DQys1nlk5IbHBc5yYfUobUSIu9VfwxiOvUXxRbtLHFWhwUvgYYbIt5DdyP7wVPe+kq 9tUJlaYEo44MnBpo6nT5AyyJjf5N6Nn7obqRNOKG5QETjvla3ODRGn5YSdWIXJlWhVxy 2AmfvNjH/iz/FjBR2v3OyprlhjXcdlX4Aw/a4MZTjadCugXZNg5G2G9eX4MWsWJnSkpQ 1KuJZgrqjrAlqnvX3EzxowbdEB4RwRuQuvkcoo713sOuoFILtnVKINyQElVPAcNFxMAP u71nsSmcfk/u5JkQFdP6ohoHX18/YYr8T48hoyd6fuuikDMQjM8ag5jXIqYxOceHkpZg E+Aw== X-Gm-Message-State: AHPjjUgz764pRVj6WFawsubB7eTIPNliagADFzGPtCVbMg7x9nSX0qnW KPZa/7TLw31wzQaGWNHMtIjtq3VRSBYF X-Google-Smtp-Source: ADKCNb5XmnrCOgWKaeHdxwsCH1SMkpa2vQ7FaKwneS4XUljE8oXBIbyEhwaZfxPxyml/IAZuKtAbBPA3MdPl807kPlA= X-Received: by 10.202.87.213 with SMTP id l204mr2015003oib.38.1504569351171; Mon, 04 Sep 2017 16:55:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Mon, 4 Sep 2017 16:55:50 -0700 (PDT) In-Reply-To: <76d443bc-3e05-b91c-2d82-4b42a2e39f67@huitema.net> References: <76d443bc-3e05-b91c-2d82-4b42a2e39f67@huitema.net> From: Martin Thomson Date: Tue, 5 Sep 2017 09:55:50 +1000 Message-ID: Subject: Re: Split error codes in two To: Christian Huitema Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 23:55:54 -0000 On Tue, Sep 5, 2017 at 6:03 AM, Christian Huitema wrote: > On 9/3/2017 9:55 PM, Martin Thomson wrote: >> In doing this, I realized two further things: >> >> 1. STOP_SENDING is a purely application-layer construct, but it's a >> transport-layer frame. That makes it much harder to manage with this >> change. Moving it to HTTP makes a lot of sense (to me). >> >> https://github.com/quicwg/base-drafts/pull/759 > > Arguably, MAX STREAM DATA is also an application-layer construct. If an > application does not want to receive more bytes on a stream, it could > stop increasing that counter. That would have more or less the same > effect as STOP SENDING, in a passive aggressive way... MAX_STREAM_DATA definitely has to be visible to the transport. But having STOP_SENDING visible is actually more of a hazard than a help. If the transport cancels a stream, then it might destroy application state. >> 2. We are now nudging 20 error codes (plus the per-frame-type ones). >> 4 billion might be a little more space than we need, so halving the >> number of bits with give error cords seems reasonable: >> >> https://github.com/quicwg/base-drafts/pull/723 > Is that really a priority? I mean, we probably do not really need to > save 2 bytes in error messages. No, it's not a priority, but it was easy to do. And I can't see any way that 4 billion helps us. > And then, how do we deal with extensions? Suppose that I define an > experimental version of the protocol that brings both new functionality > and new error codes. What number range shall I use for these extended > error codes? We've a fair bit of experience with that. Provided that we don't put an insane policy on the registry, new values are easy to acquire. I prefer the "provisional registration" approach, but we also have the policy TLS uses, and there is the option of a free-for-all chunk. None of that requires 4 billion codes. From nobody Tue Sep 5 03:12:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4E013292F for ; Tue, 5 Sep 2017 03:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 e5ndDj9hoRD2 for ; Tue, 5 Sep 2017 03:12:08 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9712113292C for ; Tue, 5 Sep 2017 03:12:08 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id i50so10320206qtf.0 for ; Tue, 05 Sep 2017 03:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bwM5Stfh5Qww/dddNDZXW15ALsm+MKM//dr0B5T4mlU=; b=OA5myZHuuok57Ir4DJ5Bwc9STqsuu45jIAg+bYJbuxnNMn94Y3bF/3Bg52odHDFoXc GAQAQGLtT/YZK8rMwmu1dEY+QG0AqSjV3X4o8IhQgBx6TRfqcjp7/Mel1c+YgPt87on1 BciUptjjiczh4nQ6+hrnPP7nshvFr301fI8QbgzanXECSkxaTFUKKKiwKTpw9V8in0BB vvdp2j+85Ae1ayIEuhKeyqE4LVbI+iYqGoafs6hduMoP6B6L2WwwkQyXF+8VFvftaHIq 0S+9g3CNHInprxeEngUV+aMQdwq1Mxoozj9Jozdf3349iSp57BW5XxWmZMXPwxUbrHcv rnWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bwM5Stfh5Qww/dddNDZXW15ALsm+MKM//dr0B5T4mlU=; b=ZmyXJsXFvkxfEDGBZkxlbdohbiM8Q3ROTo3Lba/4Ne0BZCOJCz/3g0KZ9F22yyQlnI /1PABTaCdsmmbwmiJ+pjte3fodRYVssQKGCRJshC6NmxQtKACO91qKYoK5eQW47AQu5k dIiKRa+Alk6Waaf/S+p3X1e7lVentbCUhN4ANIh0OLCz7MAqp+A8x5G7tJtUUAxFlzaM Dy2XX4Y/dCp+gO107BdKQCFe2FwtHeGESk2VeQIGEs+Fk8xxKKj6NPfQuvFpp4W9WGkS JONixtU5DKUp4Tk5jTmywTVuwcPz6VzTpgAfnCQNNYT/lJHaPDlQybnisQIr6To93OeO GzTw== X-Gm-Message-State: AHPjjUjDrE3uW+3c/pKB6D8jSWNT49COkdlIlb1FlodnOpAl5S7zVbGo ynmZig3aSpGkP3+wM6kx89PrdkAOt6Rv X-Google-Smtp-Source: ADKCNb6ONMQtrff682amXTriwvKOxKPOEcSssHpdGw0D9NHmnFj6YfkVzkePFSCWumI3jluXL4m2H9wEFIHdKaPrEc4= X-Received: by 10.200.42.4 with SMTP id k4mr4786065qtk.268.1504606327609; Tue, 05 Sep 2017 03:12:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.27.12 with HTTP; Tue, 5 Sep 2017 03:12:07 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Tue, 5 Sep 2017 03:12:07 -0700 Message-ID: Subject: Re: Split error codes in two To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a1138fa2aaf7d6505586e753e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 10:12:10 -0000 --001a1138fa2aaf7d6505586e753e Content-Type: text/plain; charset="UTF-8" On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson wrote: > The basic idea here - one that I believe that we have agreement on, > but would like to confirm - is that only applications should be > cancelling streams. In short: if the transport kills a stream that > the application was relying on, the whole application protocol state > becomes indeterminate. > I assume this means only on the wire? Because you have to close the streams both when your connection goes down, and when you get a 0-RTT reject. --001a1138fa2aaf7d6505586e753e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Sep 3, 2017 at 9:55 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
The basic idea he= re - one that I believe that we have agreement on,
but would like to confirm - is that only applications should be
cancelling streams.=C2=A0 In short: if the transport kills a stream that the application was relying on, the whole application protocol state
becomes indeterminate.

I assume this me= ans only on the wire?=C2=A0 Because you have to close
the streams= both when your connection goes down, and when you get
a 0-RTT re= ject.
--001a1138fa2aaf7d6505586e753e-- From nobody Tue Sep 5 04:18:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68913292F for ; Tue, 5 Sep 2017 04:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ds9TnIUzXRU7 for ; Tue, 5 Sep 2017 04:18:54 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1C113292B for ; Tue, 5 Sep 2017 04:18:54 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id n18so22360291oig.2 for ; Tue, 05 Sep 2017 04:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D2I/8yprzdnUOnoDJXQQ1v3uMZHocBfOAJ0Vygq078M=; b=uZSNq3uSivpz1i5i5v4ECrHQs4eRMwMA/AheBDJblyM5acWQ33lsK/pBVYMvbtBtqy TEqmtft0vSxeYfkKNxXM/FjIgJAWapB6woWKAewXZ7EHGCYWGcV26FD+dkYQlT/Oj4aF qTSUSVMEbUadCr6CaYucJfHHQgomgAcwu3lppq+g/36DqiKRUnuIYXzyzl/CrPBKQsdH pw0LfXrfdaF3CgSbjdtTl+3N4bZlnXZlSo/rsNqc2WU5KWfE84jsRZoubBnH9GFHSXso bJqeYvJ+fOwbgJyGQySoW1BbdJsasvdb2rWisg1cCCK4UmmTcICbgRvkCrIsPMsCdUV/ DkTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D2I/8yprzdnUOnoDJXQQ1v3uMZHocBfOAJ0Vygq078M=; b=l3pr5hEYSDkyyoqcBRfUWTHBF1vZBjQjVOdDkRDpHLCI2OYzgXnQpsiLzXlYMTVQpO iTkLmL9kXn7E3ls0U/IILtiEj49X8CrbsHDNvQu94HgnVIOUp9IfqtKE0F8D7DpPt4ye ng44tj8wOAz8097zNDvDvZNXBleaEYU/zG0VAZn410yct2Lfs2l61LCSnK+riWoVlzR1 Cy+1UCeAVrVQE/UFPFkeOpiR7ZLMvRC3IMcH1DEyRMAPj90YMbUNqUaK+ZOtsvLn95am xZLZx43GTANYcBkQqV/gcyY0E4JkBzhUhnwvC0ZhZ8KJnnF6obP86tUUZ7bCv9TWa47E H9uA== X-Gm-Message-State: AHPjjUgiDsg1GM17UgrARjGQ0AwW9SEUMn2RaTgxlufy9koS9HF0KYI4 KMVs1Z9jesgUAtCYU8poQmJv69rOqA== X-Google-Smtp-Source: ADKCNb4TYtT+kDaQEGPIIgJZeK7ypkQrkWDLCoFObH3PvY//2xQKgRAKaDYiJ0w+HdZN867xJSBjH0+HPnoEVJC3g+s= X-Received: by 10.202.229.203 with SMTP id c194mr3551010oih.92.1504610333448; Tue, 05 Sep 2017 04:18:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Tue, 5 Sep 2017 04:18:53 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 5 Sep 2017 21:18:53 +1000 Message-ID: Subject: Re: Split error codes in two To: Victor Vasiliev Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 11:18:55 -0000 On Tue, Sep 5, 2017 at 8:12 PM, Victor Vasiliev wrote: > On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson > wrote: >> >> The basic idea here - one that I believe that we have agreement on, >> but would like to confirm - is that only applications should be >> cancelling streams. In short: if the transport kills a stream that >> the application was relying on, the whole application protocol state >> becomes indeterminate. > > > I assume this means only on the wire? Because you have to close > the streams both when your connection goes down, and when you get > a 0-RTT reject. I forget where this discussion happened, but the current thinking was that 0-RTT reject doesn't result in streams being closed. Instead, it causes any data that was sent to need to be retransmitted. Basically, treat it as lost (though not for the purposes of congestion signals, waves hands a little). Does that make sense? From nobody Tue Sep 5 04:31:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B131C13292B for ; Tue, 5 Sep 2017 04:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 1oFn6eQeNauy for ; Tue, 5 Sep 2017 04:31:38 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1353713219C for ; Tue, 5 Sep 2017 04:31:38 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id b52so6241925qtb.3 for ; Tue, 05 Sep 2017 04:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qqhHT9HrYfcqGISZvWL7EUNX9/csEgKt73QL8tbOCxk=; b=Q7HaCnOXQKxFF8WpjTzfuyJw/rIbFJfhyfw52VrEKhB1BeNjV42y91NoCgrIAcq1Xl yKjFsS3lxBx7wEsYlylilLUdDpKRRr869FpkexnnL5M/d+SeiHkWPlKQOo78IVFznxBC Dx2dr+VhMpEASll03IRxmKONQLPexNmgPa/7rBLgf54q3xul3yJIKe7uGN+PZilxsMYw p9y2P8RnZi+xxkBiBeVS2y7MFi9yIR8dxNtFXSs2iaexdhhTQsnYKWzCw9WRMHfvp8An r+PQfm2mQ4RnLrEcnTL8Hx+aa/SXDP9BLmqg+c5ATI5UFX4YSLbFhajZLX38EN6sakiC tM8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qqhHT9HrYfcqGISZvWL7EUNX9/csEgKt73QL8tbOCxk=; b=ew+ZS6FgjRYpkvgilktvzpsj7GmNFgiSrTZj79IL0AXTNOT45bvCOFP4E3m08xPZtQ pqt1tVT93Gd+EthhJ9BgW8ADET996mKTHd5zWDvyOEwLRWwVz9llWGG2j3KBcsM86mWT YrkayE2oiw91Gnsr96Z5CLVSXQSsgvW1FMjwrcliV1aHJlt8/JnbcZDVa2F5VY5yHf5i u6dwolJXsNF10to8oaYEoNTVfCUmh4B0puuo7qAVb8Y6U4epIuYWFQEec2T81kZLnamB VQwtfdRyfhassqWDwLRbDe7U7kLJqq+Y6xNABe8D/s6JAlziEkVf0K2nF5IRK/aYR/UG v0Hw== X-Gm-Message-State: AHPjjUgLXrxBIEOV9uw9udT4Wunc/7u3CFnzy1M9ACf1+xSOHvRjxmkW 9GYI4zgWFOTVUxP64bxv+rlj4K5iO2w4 X-Google-Smtp-Source: ADKCNb5UW3dJh1BB6IHvIlsbG37SYGLfMnVtrYnmyjjHxfORh5gizvTNRsVAIi0N/W6v1CNBJmkzpFQHdX8pDrY0wKw= X-Received: by 10.237.35.230 with SMTP id k35mr4638657qtc.238.1504611096996; Tue, 05 Sep 2017 04:31:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.27.12 with HTTP; Tue, 5 Sep 2017 04:31:36 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Tue, 5 Sep 2017 07:31:36 -0400 Message-ID: Subject: Re: Split error codes in two To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a113e4d4ef6b98105586f911d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 11:31:41 -0000 --001a113e4d4ef6b98105586f911d Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 7:18 AM, Martin Thomson wrote: > On Tue, Sep 5, 2017 at 8:12 PM, Victor Vasiliev > wrote: > > On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson > > > wrote: > >> > >> The basic idea here - one that I believe that we have agreement on, > >> but would like to confirm - is that only applications should be > >> cancelling streams. In short: if the transport kills a stream that > >> the application was relying on, the whole application protocol state > >> becomes indeterminate. > > > > > > I assume this means only on the wire? Because you have to close > > the streams both when your connection goes down, and when you get > > a 0-RTT reject. > > I forget where this discussion happened, but the current thinking was > that 0-RTT reject doesn't result in streams being closed. Instead, it > causes any data that was sent to need to be retransmitted. Basically, > treat it as lost (though not for the purposes of congestion signals, > waves hands a little). Does that make sense? > That is what the current gQUIC code does, and it has been historically sufficiently problematic that I've been trying to switch us away from that behavior. TLS prohibits automatic resend without explicit opt-in from the application, and even then, it's a bad idea. Application payload may vary substantially depending on the state of the TLS connection, so if the connection changes, client's presented identity, the exporter secrets used, etc, may become different (and in case of exporter secrets, they will). --001a113e4d4ef6b98105586f911d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 5, 2017 at 7:18 AM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
On Tue, Sep 5, 2017 a= t 8:12 PM, Victor Vasiliev <vasilv= v@google.com> wrote:
> On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> The basic idea here - one that I believe that we have agreement on= ,
>> but would like to confirm - is that only applications should be >> cancelling streams.=C2=A0 In short: if the transport kills a strea= m that
>> the application was relying on, the whole application protocol sta= te
>> becomes indeterminate.
>
>
> I assume this means only on the wire?=C2=A0 Because you have to close<= br> > the streams both when your connection goes down, and when you get
> a 0-RTT reject.

I forget where this discussion happened, but the current thinki= ng was
that 0-RTT reject doesn't result in streams being closed.=C2=A0 Instead= , it
causes any data that was sent to need to be retransmitted.=C2=A0 Basically,=
treat it as lost (though not for the purposes of congestion signals,
waves hands a little).=C2=A0 Does that make sense?

That is what the current gQUIC code does= , and it has been historically
sufficiently= problematic that I've been trying to switch us away from that
behavior.=C2=A0 TLS prohibits automatic resend with= out explicit opt-in from the
application, a= nd even then, it's a bad idea.=C2=A0 Application payload may vary
=
substantially depending on the state of the TLS = connection, so if the
connection changes, c= lient's presented identity, the exporter secrets used,
etc, may become different (and in case of exporter secrets= , they will).
--001a113e4d4ef6b98105586f911d-- From nobody Tue Sep 5 09:30:21 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEC9132D8D for ; Tue, 5 Sep 2017 09:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 HrXlgHMyslxh for ; Tue, 5 Sep 2017 09:30:14 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83516132D93 for ; Tue, 5 Sep 2017 09:30:11 -0700 (PDT) X-Envelope-From: phils@in-panik.de X-Envelope-To: Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v85GTnkR009156 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 5 Sep 2017 18:29:49 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dpGjD-0005Sv-C2 for quic@ietf.org; Tue, 05 Sep 2017 18:29:31 +0200 From: "Philipp S. Tiesel" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Unreliable Stream Support for QUIC Message-Id: Date: Tue, 5 Sep 2017 18:29:48 +0200 To: QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:30:19 -0000 Hi, as promised, we just submitted a draft on unreliable streams for QUIC, including support for partial reliability:=20 = https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams/ TL;DR:=20 - In principal, supporting unreliable streams in QUIC does not require changes to the datft-05 wire-protocol. - To get a nice interface between QUIC transport and the application, we need one bit in the stream frame header to indicate whether a stream is supposed to be reliable. To give an application example, we did also draft how HTTP/2 over QUIC can be extended to support partial reliability based on the draft above: https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-http/ We have no finished implementation yet, but are working on one.=20 AVE! Philipp S. Tiesel / phils=E2=80=A6 From nobody Tue Sep 5 10:20:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BA6132DD6 for ; Tue, 5 Sep 2017 10:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 1ziBdVQ-j1jC for ; Tue, 5 Sep 2017 10:20:35 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9270D132D62 for ; Tue, 5 Sep 2017 10:20:35 -0700 (PDT) Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v85HKXC7007337; Tue, 5 Sep 2017 18:20:34 +0100 (BST) Received: from BGB01XI1015.national.core.bbc.co.uk (10.161.14.78) by BGB01XI1011.national.core.bbc.co.uk (10.161.14.15) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 5 Sep 2017 18:20:33 +0100 Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1015.national.core.bbc.co.uk ([10.161.14.78]) with mapi id 14.03.0319.002; Tue, 5 Sep 2017 18:20:32 +0100 From: Lucas Pardue To: "Philipp S. Tiesel" , QUIC WG Subject: RE: Unreliable Stream Support for QUIC Thread-Topic: Unreliable Stream Support for QUIC Thread-Index: AQHTJmRPDJY4uXGd60ScIiysX8LipqKmiHIg Date: Tue, 5 Sep 2017 17:20:32 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A37766AB0@bgb01xud1012> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] X-TM-AS-Product-Ver: SMEX-11.0.0.4255-8.100.1062-23306.000 X-TM-AS-Result: No--11.250300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 17:20:37 -0000 Hi Philipp, Thanks for publishing these. I've only had a chance to skim read so I only = have a basic question right now. For the HTTP/QUIC mapping, have you considered server push? The document do= esn't mention anything but I wonder if you have some ideas. I'm thinking th= at the push promise includes your request header to indicate to the client = that the pushed body will be unreliable. An alternative would be to have al= l pushed streams inherit the reliability of the parent stream.=20 Kind regards Lucas ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Philipp S. Tiesel [phils@in= -panik.de] Sent: 05 September 2017 17:29 To: QUIC WG Subject: Unreliable Stream Support for QUIC Hi, as promised, we just submitted a draft on unreliable streams for QUIC, including support for partial reliability: https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams/ TL;DR: - In principal, supporting unreliable streams in QUIC does not require changes to the datft-05 wire-protocol. - To get a nice interface between QUIC transport and the application, we need one bit in the stream frame header to indicate whether a stream is supposed to be reliable. To give an application example, we did also draft how HTTP/2 over QUIC can be extended to support partial reliability based on the draft above: https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-http/ We have no finished implementation yet, but are working on one. AVE! Philipp S. Tiesel / phils=85 From nobody Tue Sep 5 17:07:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00057132E3D for ; Tue, 5 Sep 2017 17:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 hc_63Fjb40bQ for ; Tue, 5 Sep 2017 17:07:37 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880C11321CB for ; Tue, 5 Sep 2017 17:07:37 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id m35so16221209qte.1 for ; Tue, 05 Sep 2017 17:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nj5kIlfIKmHqrk7wQoI+xLFhKH5aE6UNC6Ux5FGLcbk=; b=pSQrNTKa9ZYW5mEwpxzD+i4nNhWmaggrRuqo/fnWBqLWnPB63JGnUQi3qL0f0EkUHJ ae6lPEWIxyBczTWrnYwbYpYo8kRrpgAj77W0BaOlPyPEKrPWgNLbsJY7OIubS60x9XVO XZN48j9stOLedUEyi8ykmlSuHS/ifchblNsMFdfndGex912CDy3H720jxCAube3G/1dW +pGZX47Y5BNGcLgQMfrjnRuklLxiU18KouZW+Qyek5ziVIJdcGuQR9Tf5vcbGA1LQMr0 uJjVsKFwZcsoXb0ldM1uLeqpcbhwfTSXJ0CSc4U4LLjeHBW1i1THG5uK2bHkCm3Mz5RL L0Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nj5kIlfIKmHqrk7wQoI+xLFhKH5aE6UNC6Ux5FGLcbk=; b=MWJDYyfJ6CSTcw9X+hQolBvDL6IRQ395n+VnFhmxAhX2ftenlnA0c8Kv0glDuPiL+W virKDMvcX0FMALdBB09NeiKbwdpsf5RW6xrucEzr8p65sVvdjp1dYyrpPVS4fh5KasuP HkBL8kVrUyVV5iwr1eESq6tDEHewBEkzayAyXAq295pkRG9o9vQGwRO23XcOlalgccTR hX55jyQ1AEFmXXrRcFF4Q9kvqbuQQXwS+kBCJMxYqvoaDCBsqeX1MvlPjlSfFwaKN1mJ oSnoYe/CXwcb/+/Cwi/PLrws8t/PUCuW0Wk3j/5XcgYHohYAepeDdM2colvuVZnDPSTr DWtQ== X-Gm-Message-State: AHPjjUihkMB16i6sKc2H6nMY0iQu1Mc/I5ah/AyjlDtoxykZwd0fhzBb 3u1SBvY4YF7+reTHl8ogdxbQgOxT0hGl X-Google-Smtp-Source: ADKCNb4P6E6dwd5JktQzK7wnBzQWVyjPuLjgtlQuKQuhocu3Quk/wT95SxIpvB7Yja6F803JhyeC0EzJqlOBZSa+iaQ= X-Received: by 10.200.41.240 with SMTP id 45mr1176285qtt.284.1504656456379; Tue, 05 Sep 2017 17:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.36.138 with HTTP; Tue, 5 Sep 2017 17:07:15 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Tue, 5 Sep 2017 17:07:15 -0700 Message-ID: Subject: Re: Split error codes in two To: Victor Vasiliev Cc: Martin Thomson , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 00:07:39 -0000 The approach of treating rejected 0-RTT data like it was lost and retransmitting at the transport layer causes problems. As Victor mentioned, one of the problems is that the exporter secret changes, which is a problem for Token Binding if a client attempts 0-RTT Token Binding and 0-RTT is rejected. In this case, the Token Binding HTTP header needs to be rewritten to be a signature over the new exporter value, when the original stream had a Token Binding header that covered the old exporter value. I agree with Victor that on 0-RTT reject, streams should be closed. On Tue, Sep 5, 2017 at 4:31 AM, Victor Vasiliev wrote: > On Tue, Sep 5, 2017 at 7:18 AM, Martin Thomson > wrote: >> >> On Tue, Sep 5, 2017 at 8:12 PM, Victor Vasiliev >> wrote: >> > On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson >> > >> > wrote: >> >> >> >> The basic idea here - one that I believe that we have agreement on, >> >> but would like to confirm - is that only applications should be >> >> cancelling streams. In short: if the transport kills a stream that >> >> the application was relying on, the whole application protocol state >> >> becomes indeterminate. >> > >> > >> > I assume this means only on the wire? Because you have to close >> > the streams both when your connection goes down, and when you get >> > a 0-RTT reject. >> >> I forget where this discussion happened, but the current thinking was >> that 0-RTT reject doesn't result in streams being closed. Instead, it >> causes any data that was sent to need to be retransmitted. Basically, >> treat it as lost (though not for the purposes of congestion signals, >> waves hands a little). Does that make sense? > > > That is what the current gQUIC code does, and it has been historically > sufficiently problematic that I've been trying to switch us away from that > behavior. TLS prohibits automatic resend without explicit opt-in from the > application, and even then, it's a bad idea. Application payload may vary > substantially depending on the state of the TLS connection, so if the > connection changes, client's presented identity, the exporter secrets used, > etc, may become different (and in case of exporter secrets, they will). From nobody Tue Sep 5 17:59:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194CE132E41 for ; Tue, 5 Sep 2017 17:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 MiRQpFvsKJks for ; Tue, 5 Sep 2017 17:59:34 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96DA1252BA for ; Tue, 5 Sep 2017 17:59:33 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s62so2377496ywg.0 for ; Tue, 05 Sep 2017 17:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=79kLrHUTKJbDekg5y/+ZqwuHYIt0fXOaB4KsSb4c18o=; b=a4Qa8VPWczFvsx1KjO4x6M2eudmB7k6xJI0FmKrQDOrU2sJGqXekOq+HWl/jK6BzyJ OlEaSeCBs1IeWz0F3FDSIqUhbj3eyc5OI9BVSN/qQK9KlveVap/qNAwFtc0fnNV0TnT7 qLwCwOWwu+AstYYHcOUc2WrMpw+FKjHRZbwTuVASk+pRAI6KdcsuPSCqVu+BK0t7m6HV D8saaDwKelO3lt6QfyhHfioWM6rc6YcusUBgrSK7PFGZlrg6ADWBqw0KLCwad/nBJWp2 iJrdH4JS9YbrNN3vUwOf/3AnUR5jVW1ZHLhK2WEXOue5UJqKV9hpDJzPAMEOd1p8HrZP loYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=79kLrHUTKJbDekg5y/+ZqwuHYIt0fXOaB4KsSb4c18o=; b=nxmIneH0FsgS2p5fuWxJYEith757IZSWrxdRAl2elAv8C996an+e2FH3ztz+JC4EAG jfN/weqlbU2W0H5uhu1/6FTKXQrEKJmwiEpukf9WrJo+z2r/Hy1M+gjD1Llc/+rT0IY+ Fn2fNJd7CrBqY8J56QXtqH7jJ4FFix9oaWEbpOQ2OBDnLmC/hUjfrifrC3QBsM7MFSgl HXBjfcIAodf7fo4hRdHr8SZEtuw4V7BCLwUU11QZ5y6e7KvILwATLDYuyIbCSYMfJio7 rrghcB83KKtCE6uelWBJc/nJIkilg3wBwwP5smog7H4c1AdYBsL9SOhnzOJoAIxRIzea zl3A== X-Gm-Message-State: AHPjjUisrWqKNE7PC0rhUYWXy5IKmDUvY+lFrY/V7ppUGdcNaVhA9S0n tMwiibLkruEX7faJ09bvcZfucyxsQfv/ X-Google-Smtp-Source: ADKCNb5IZMPsHG2ERQKiRrGAgrz19+AVDABnIkkSX0AyG/gU0YTRddNdVDwZ6YBsgtPumsU4cHcMmR+WIgrusMtosWM= X-Received: by 10.37.203.207 with SMTP id b198mr755188ybg.226.1504659572831; Tue, 05 Sep 2017 17:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Tue, 5 Sep 2017 17:59:32 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Tue, 5 Sep 2017 17:59:32 -0700 Message-ID: Subject: Re: Split error codes in two To: Nick Harper Cc: Victor Vasiliev , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c0565c6594f6d05587adb02" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 00:59:36 -0000 --94eb2c0565c6594f6d05587adb02 Content-Type: text/plain; charset="UTF-8" I think this (0-RTT) is a non-issue, but correct me if I'm wrong. This is really about sending RST_STREAMs, not about anything else. I agree with Victor and Nick that 0-RTT data cannot simply be retransmitted, but I think this set of PRs is really about the wire protocol. The way I read it, QUIC should never be sending RST_STREAMs of its own accord; that should be an application-controlled mechanism. And to be clear, the only place that's not true in gQUIC is when a RST_STREAM is received. gQUIC responds immediately with a RST_STREAM. In the current draft, we've already changed that requirement: the application is expected to generate a RST_STREAM in response to a received RST_STREAM. That leaves the transport requirement of responding with a RST_STREAM to a STOP_SENDING. I believe STOP_SENDING really is an HTTP-ism and belongs in HTTP. A transport that wants to throttle the sender on a particular stream can use flow control to do it. I think reducing error code space is innocuous, and I'm fine with it. On Tue, Sep 5, 2017 at 5:07 PM, Nick Harper wrote: > The approach of treating rejected 0-RTT data like it was lost and > retransmitting at the transport layer causes problems. As Victor > mentioned, one of the problems is that the exporter secret changes, > which is a problem for Token Binding if a client attempts 0-RTT Token > Binding and 0-RTT is rejected. In this case, the Token Binding HTTP > header needs to be rewritten to be a signature over the new exporter > value, when the original stream had a Token Binding header that > covered the old exporter value. I agree with Victor that on 0-RTT > reject, streams should be closed. > > On Tue, Sep 5, 2017 at 4:31 AM, Victor Vasiliev > wrote: > > On Tue, Sep 5, 2017 at 7:18 AM, Martin Thomson > > > wrote: > >> > >> On Tue, Sep 5, 2017 at 8:12 PM, Victor Vasiliev > >> wrote: > >> > On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson > >> > > >> > wrote: > >> >> > >> >> The basic idea here - one that I believe that we have agreement on, > >> >> but would like to confirm - is that only applications should be > >> >> cancelling streams. In short: if the transport kills a stream that > >> >> the application was relying on, the whole application protocol state > >> >> becomes indeterminate. > >> > > >> > > >> > I assume this means only on the wire? Because you have to close > >> > the streams both when your connection goes down, and when you get > >> > a 0-RTT reject. > >> > >> I forget where this discussion happened, but the current thinking was > >> that 0-RTT reject doesn't result in streams being closed. Instead, it > >> causes any data that was sent to need to be retransmitted. Basically, > >> treat it as lost (though not for the purposes of congestion signals, > >> waves hands a little). Does that make sense? > > > > > > That is what the current gQUIC code does, and it has been historically > > sufficiently problematic that I've been trying to switch us away from > that > > behavior. TLS prohibits automatic resend without explicit opt-in from > the > > application, and even then, it's a bad idea. Application payload may > vary > > substantially depending on the state of the TLS connection, so if the > > connection changes, client's presented identity, the exporter secrets > used, > > etc, may become different (and in case of exporter secrets, they will). > > --94eb2c0565c6594f6d05587adb02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this (0-RTT) is a non-issue, but correct me if I&#= 39;m wrong. This is really about sending RST_STREAMs, not about anything el= se. I agree with Victor and Nick that 0-RTT data cannot simply be retransmi= tted, but I think this set of PRs is really about the wire protocol. The wa= y I read it, QUIC should never be sending RST_STREAMs of its own accord; th= at should be an application-controlled mechanism. And to be clear, the only= place that's not true in gQUIC is when a RST_STREAM is received. gQUIC= responds immediately with a RST_STREAM.

In the current = draft, we've already changed that requirement: the application is expec= ted to generate a RST_STREAM in response to a received RST_STREAM. That lea= ves the transport requirement of responding with a RST_STREAM to a STOP_SEN= DING. I believe STOP_SENDING really is an HTTP-ism and belongs in HTTP. A t= ransport that wants to throttle the sender on a particular stream can use f= low control to do it.

I think reducing error code = space is innocuous, and I'm fine with it.

On Tue, Sep 5, 2017 at 5:07 PM, Nic= k Harper <nharper@google.com> wrote:
The approach of treating rejected 0-RTT data like it was lost= and
retransmitting at the transport layer causes problems. As Victor
mentioned, one of the problems is that the exporter secret changes,
which is a problem for Token Binding if a client attempts 0-RTT Token
Binding and 0-RTT is rejected. In this case, the Token Binding HTTP
header needs to be rewritten to be a signature over the new exporter
value, when the original stream had a Token Binding header that
covered the old exporter value. I agree with Victor that on 0-RTT
reject, streams should be closed.

On Tue, Sep 5, 2017 at 4:31 AM, Victor Vasiliev <vasilvv@google.com> wrote:
> On Tue, Sep 5, 2017 at 7:18 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On Tue, Sep 5, 2017 at 8:12 PM, Victor Vasiliev <vasilvv@google.com>
>> wrote:
>> > On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson
>> > <martin.thomso= n@gmail.com>
>> > wrote:
>> >>
>> >> The basic idea here - one that I believe that we have agr= eement on,
>> >> but would like to confirm - is that only applications sho= uld be
>> >> cancelling streams.=C2=A0 In short: if the transport kill= s a stream that
>> >> the application was relying on, the whole application pro= tocol state
>> >> becomes indeterminate.
>> >
>> >
>> > I assume this means only on the wire?=C2=A0 Because you have = to close
>> > the streams both when your connection goes down, and when you= get
>> > a 0-RTT reject.
>>
>> I forget where this discussion happened, but the current thinking = was
>> that 0-RTT reject doesn't result in streams being closed.=C2= =A0 Instead, it
>> causes any data that was sent to need to be retransmitted.=C2=A0 B= asically,
>> treat it as lost (though not for the purposes of congestion signal= s,
>> waves hands a little).=C2=A0 Does that make sense?
>
>
> That is what the current gQUIC code does, and it has been historically=
> sufficiently problematic that I've been trying to switch us away f= rom that
> behavior.=C2=A0 TLS prohibits automatic resend without explicit opt-in= from the
> application, and even then, it's a bad idea.=C2=A0 Application pay= load may vary
> substantially depending on the state of the TLS connection, so if the<= br> > connection changes, client's presented identity, the exporter secr= ets used,
> etc, may become different (and in case of exporter secrets, they will)= .


--94eb2c0565c6594f6d05587adb02-- From nobody Tue Sep 5 18:05:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9327132E3D for ; Tue, 5 Sep 2017 18:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pef2J5jRHuAF for ; Tue, 5 Sep 2017 18:05:26 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447571252BA for ; Tue, 5 Sep 2017 18:05:26 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id h70so34262609oic.1 for ; Tue, 05 Sep 2017 18:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=XJmqWN1cjCnGWGWElOtrana6d0q6a+qAuMU9pVQe0do=; b=aFJh1u/8e2/dv78WcDlGsES1UJO23xQJiktwUf/sQZp1+3V0SgHTb9gEBPaGNi9CIY ydgtLyWlGSSPuucvLmKlZbANdIKxa59Mt0bLtT8WroySxhXqPkIwqcX+IAYX3kgIB0SE SSFlHAi/luVH+NAzGNteUW+nUgU63MoaC9PnJ+o5w7kVhKc2blKnXD5XSiZcLvph0Xmz KaOFMc7svabtFBp7TZ9YkUd5WsD9BQTpcuPzsD2ZOzO0I2N2pclp9DM86hto3ZvA2p37 bSSvapqFHOjzvt+ZXLf8btFRpPXPHRHGn/+G+lLkWz1EsejW7eZgP/dlY9utLQqZtKg4 Qsng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=XJmqWN1cjCnGWGWElOtrana6d0q6a+qAuMU9pVQe0do=; b=LBiCJJw7NTsZ1Fk+zIMKzkay0Mvb0lgVE/Cntbxps9J86U2xq0cEP8e/W2vlxhFI9F cCPY++cb+kD9LS+XXgJ+gG2UbiQobO4HM+XPUSK6/rBSNv8kBMkuQuIHuN/w49JThmd8 4lUBAS9SRkxtoxcdEXIC4gKDnmfhfIrgghPLkIni9TiAdFkTKLARGTIdDB1tT3XmHXI2 REJ39ojtHbJD8oQuM1z4DLTbcKORz4qia3LzE9Fl/9LcFXRqUSoYo7fuSTikRU8MeLy4 g9++F7eWsD3qTb5frlBipzvVc+pfBKJEk2W+LqE5+Hv4EN7fHAAoLuQCcmEtb8J5XgV8 75ew== X-Gm-Message-State: AHPjjUgkFVPbyHZHeT+O9WR4hN6LGTHPbTb9264DeID5UOcY/1ds7wpA EuC761VwkzCJZ4bDpVKj5+bWtg3lLw== X-Google-Smtp-Source: ADKCNb6Pzftd9sYyNflVNfSaCECj2SnrMNaPK/2loKSG5CEdHu94gGou3uYWNmjAv36BHZy57IJtuecm7ah8T2zAXMQ= X-Received: by 10.202.85.138 with SMTP id j132mr936419oib.319.1504659925595; Tue, 05 Sep 2017 18:05:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Tue, 5 Sep 2017 18:05:25 -0700 (PDT) From: Martin Thomson Date: Wed, 6 Sep 2017 11:05:25 +1000 Message-ID: Subject: Rejecting 0-RTT (was Re: Split error codes in two) To: Nick Harper Cc: Victor Vasiliev , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 01:05:28 -0000 On Wed, Sep 6, 2017 at 10:07 AM, Nick Harper wrote: > The approach of treating rejected 0-RTT data like it was lost and > retransmitting at the transport layer causes problems. As Victor > mentioned, one of the problems is that the exporter secret changes, > which is a problem for Token Binding if a client attempts 0-RTT Token > Binding and 0-RTT is rejected. In this case, the Token Binding HTTP > header needs to be rewritten to be a signature over the new exporter > value, when the original stream had a Token Binding header that > covered the old exporter value. I agree with Victor that on 0-RTT > reject, streams should be closed. OK, that's two arguing against continuing. Given that TLS recommends "starting over", I think that I'd prefer that to saying that streams close. That is, if 0-RTT is rejected, you treat the connect as a new one (stream 0 is again special here, which leads me to question - again - the wisdom of our design there, but that's a separate problem). That way you initiate all application actions as if the connection were brand new. Also, you can't close stream 1. https://github.com/quicwg/base-drafts/issues/761 The only question I have there is what we need to tell the congestion controller. Obviously all that 0-RTT won't get acknowledged, but you can't really pretend that you didn't send it at all, you also can't mark all those packets as lost either. https://github.com/quicwg/base-drafts/issues/762 From nobody Tue Sep 5 18:10:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A4D132E3C for ; Tue, 5 Sep 2017 18:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jzVi839RK0n4 for ; Tue, 5 Sep 2017 18:10:27 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDBB1252BA for ; Tue, 5 Sep 2017 18:10:27 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id n18so34186528oig.2 for ; Tue, 05 Sep 2017 18:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ae/GhB6IvpIVWRW+ziBkO+6KoU8sauueR506QwVGJUs=; b=BcYC1XfsEAEc3xBtyZGoZPOc6pElK63XRvA/E1MgBroMsC96hABACSf0cmA6VuS4/4 N/gJNRI3NHRVTdQVk1xI9yI7vqWlTFszPGw6CdniPa3W+3j+nrpprueFQhk530JjzBOn rf8ZHSoX1BxpQCvdgwyMyKKdt01iip03aJbz2qAhaSw4b2Ts+gUOZpQtVOigiYng77xb 1/44YEiYcAH5zzrw6OnfIg/Eq39yJn3ICXYk6Wk+zCYmEXET2cZpUi8P8wsMZoaROaQI caHvncrrc6W4sxvEVFCY9X3dptdAiYq924uvfTM4MOqGBtBQzRwBRTP9DjRXTj9h7PM0 m8vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ae/GhB6IvpIVWRW+ziBkO+6KoU8sauueR506QwVGJUs=; b=ro0ZN0HWcAAFJE9aRyORUShgjbXXqs4wGqIViwoFTgGYd6u/vo1u5vWM/Qo14blAq6 djZtofFBnAlPrq5np95+FW7EvigDuAgfhfJ6nNTZyj0ampPwP8I42+e6KJ9Q9TuXceBk hOUVNksA2pUA1XXiirnXF32xw61VPGjji0PdF2AadICnWOoRZWJoNWVRJpUpbJoBgx+O JlCisliqGQtnnswmEXGV7R60VjwUdMsZw5+kwdAXnqRKgW3qeQbYrnfegAr7f0WaO+Hj xNZvYFxFJc86TjEUKYdg5fEMHjX98OE0ZG3vIHRqu+yOJK4L36vBSkLzGcZKg5HyecA/ ZdVA== X-Gm-Message-State: AHPjjUg2nTwIB8XrLm3y2Q850hmP+/iUinhLjdcNpUOEnRFPXgT6+phO uHsLSd/wK0YKl3Bg5PP700BNHm/5fw== X-Google-Smtp-Source: ADKCNb7FLliX4E6k8RvkjXe6L2KwibB7K0QkU4hocZxVprOfTQtNMidoqemQbtJ4p/vGbZh1+dFvOZa29/C6BBjgYFk= X-Received: by 10.202.86.69 with SMTP id k66mr975416oib.320.1504660226472; Tue, 05 Sep 2017 18:10:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Tue, 5 Sep 2017 18:10:26 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 6 Sep 2017 11:10:26 +1000 Message-ID: Subject: Re: Split error codes in two To: Jana Iyengar Cc: Nick Harper , Victor Vasiliev , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 01:10:29 -0000 On Wed, Sep 6, 2017 at 10:59 AM, Jana Iyengar wrote: > I think this (0-RTT) is a non-issue, but correct me if I'm wrong. This is > really about sending RST_STREAMs, not about anything else. I agree with > Victor and Nick that 0-RTT data cannot simply be retransmitted, but I think > this set of PRs is really about the wire protocol. The way I read it, QUIC > should never be sending RST_STREAMs of its own accord; that should be an > application-controlled mechanism. And to be clear, the only place that's not > true in gQUIC is when a RST_STREAM is received. gQUIC responds immediately > with a RST_STREAM. I've spun the 0-RTT discussion off onto another thread. I think that there are issues, but hopefully they are minor. > In the current draft, we've already changed that requirement: the > application is expected to generate a RST_STREAM in response to a received > RST_STREAM. That text was removed with the addition of STOP_SENDING. (Or at least I couldn't find it). I think that's the right answer, because this will be entirely discretionary on the part of applications. (I'm not disagreeing with any of your conclusions, just pointing that out in case you thought that it was an important consideration.) From nobody Tue Sep 5 18:13:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E61132E41 for ; Tue, 5 Sep 2017 18:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 o-3mDmwzeZ5H for ; Tue, 5 Sep 2017 18:12:55 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2C9132E44 for ; Tue, 5 Sep 2017 18:12:55 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id w204so17760402ywg.3 for ; Tue, 05 Sep 2017 18:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IIxj/vvuW+9C4AHDRWxxhm7OpcRId/EFBG4doW2vTgE=; b=XFKL3204i/eLTcNOu1fDFoSqmj/D9pSebrlfJMRUGrKIN0Q0dX6X7aDm6oEvMhmj2E cGDVaVDkt7PDAJP6uOSVsiPi0GpsdxQTkSXACJv5eRAhoG1BCp4DytT1NsdR56u4ihxn e7RoLPGg2dpGQHPjyrnydBiG3Y3tCyXKPwlPJg2LAjhOSvU+mjIjQq+EdCnLFSQMGZj+ TbUJhZT2lKUwnDzCuTSKRfHtoZrMvIrE2nxY+NX52OGrmd4QiUNccnY9PcjoV0noZGIX lQPvvPSbqcd0Hgtjq0lcRQ6DvJNKdRyRLficiB62x/dHL4BWiHnDlMWTba06cLIJTdgX W0ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IIxj/vvuW+9C4AHDRWxxhm7OpcRId/EFBG4doW2vTgE=; b=PFiIb3elemyIlHwJyq8GQyDXHCSu9iOXv3+A/JSOHIxgHM70SFY4QZHDcNsCAe+arX VbMXxAedBEEVlYVJ3VTL2nr4PN18hMsFi66g+ni3c3ls0nIZLg8yGwo+aKrnoYlYTp9u Zyd4VrxovQOICjlajuflHfhfjpPudVoocII4FgaLqnSRhsPIxArqo/vhu1c8WkvwChdr XBFdfryqFQGMhqk4yM1Kd8xArixQeioeYg7LFEOFfmHA6JZorzaCo7D4vNgB/BR+trHX LQC3ARZy2V4PhnvblEIYeldMUWnOwvNiQiKUkEdxzXC7SUIyU2gkv3gg7kYot/WwNCee oQ+Q== X-Gm-Message-State: AHPjjUgQ3qaFo/0UW3X+6Fg+LsPUdufii0DDDYd6tJKSW9YL9W4jid4Z tfn7e3GwF2Q7WXdSrpTTcqlPrjQ2XXNq X-Google-Smtp-Source: ADKCNb73nOmZT+kVmOkbgSC6MiaY8yG0jinGoQyVadvoh+Zp9eeu/AI5MQEr8Qqx3OKDUf8yNJ3gOnKvlDLQ/lB7dd8= X-Received: by 10.129.79.200 with SMTP id d191mr761087ywb.162.1504660374537; Tue, 05 Sep 2017 18:12:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Tue, 5 Sep 2017 18:12:52 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Tue, 5 Sep 2017 18:12:52 -0700 Message-ID: Subject: Re: Split error codes in two To: Martin Thomson Cc: Nick Harper , Victor Vasiliev , QUIC WG Content-Type: multipart/alternative; boundary="001a114dd16622b28705587b0b8a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 01:13:02 -0000 --001a114dd16622b28705587b0b8a Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 6:10 PM, Martin Thomson wrote: > On Wed, Sep 6, 2017 at 10:59 AM, Jana Iyengar wrote: > > I think this (0-RTT) is a non-issue, but correct me if I'm wrong. This is > > really about sending RST_STREAMs, not about anything else. I agree with > > Victor and Nick that 0-RTT data cannot simply be retransmitted, but I > think > > this set of PRs is really about the wire protocol. The way I read it, > QUIC > > should never be sending RST_STREAMs of its own accord; that should be an > > application-controlled mechanism. And to be clear, the only place that's > not > > true in gQUIC is when a RST_STREAM is received. gQUIC responds > immediately > > with a RST_STREAM. > > I've spun the 0-RTT discussion off onto another thread. I think that > there are issues, but hopefully they are minor. I think they're orthogonal, but I'll go look at the other thread. > > > In the current draft, we've already changed that requirement: the > > application is expected to generate a RST_STREAM in response to a > received > > RST_STREAM. > > That text was removed with the addition of STOP_SENDING. (Or at least > I couldn't find it). I think that's the right answer, because this > will be entirely discretionary on the part of applications. > Yup, I was just pointing out the reasons that we don't need RST_STREAM to be a transport directive. > (I'm not disagreeing with any of your conclusions, just pointing that > out in case you thought that it was an important consideration.) > --001a114dd16622b28705587b0b8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 6:10 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On Wed, Sep 6, 2017 at 10:59 AM, Jana Iyengar <jri@google.com> wrote:
> I think this (0-RTT) is a non-issue, but correct me if I'm wrong. = This is
> really about sending RST_STREAMs, not about anything else. I agree wit= h
> Victor and Nick that 0-RTT data cannot simply be retransmitted, but I = think
> this set of PRs is really about the wire protocol. The way I read it, = QUIC
> should never be sending RST_STREAMs of its own accord; that should be = an
> application-controlled mechanism. And to be clear, the only place that= 's not
> true in gQUIC is when a RST_STREAM is received. gQUIC responds immedia= tely
> with a RST_STREAM.

I've spun the 0-RTT discussion off onto another thread.=C2=A0 I = think that
there are issues, but hopefully they are minor.

=
I think they're orthogonal, but I'll go look at the other thre= ad.
=C2=A0
<= br> > In the current draft, we've already changed that requirement: the<= br> > application is expected to generate a RST_STREAM in response to a rece= ived
> RST_STREAM.

That text was removed with the addition of STOP_SENDING.=C2=A0 (Or a= t least
I couldn't find it).=C2=A0 I think that's the right answer, because= this
will be entirely discretionary on the part of applications.

Yup, I was just pointing out the reasons that we don&#= 39;t need RST_STREAM to be a transport directive.
=C2=A0
(I'm not disagreeing with any of your conclusions, just pointing that out in case you thought that it was an important consideration.)

--001a114dd16622b28705587b0b8a-- From nobody Tue Sep 5 21:14:25 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07C1321DE for ; Tue, 5 Sep 2017 21:14:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9pT6mjzusVUu for ; Tue, 5 Sep 2017 21:14:21 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id E67A613219F for ; Tue, 5 Sep 2017 21:14:20 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v864EBBB015037; Wed, 6 Sep 2017 06:14:11 +0200 Date: Wed, 6 Sep 2017 06:14:11 +0200 From: Willy Tarreau To: Martin Thomson Cc: Nick Harper , Victor Vasiliev , QUIC WG Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) Message-ID: <20170906041411.GA15025@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 04:14:23 -0000 On Wed, Sep 06, 2017 at 11:05:25AM +1000, Martin Thomson wrote: > The only question I have there is what we need to tell the congestion > controller. Obviously all that 0-RTT won't get acknowledged, but you > can't really pretend that you didn't send it at all, you also can't > mark all those packets as lost either. > > https://github.com/quicwg/base-drafts/issues/762 Probably that this means the protocol needs to have explicit provisions for ignored/rejected data, which are data properly delivered by the transport layer but rejected by the application. I don't know what it implies for now, but it sounds that this use case is real and cannot be hidden under the carpet :-) Willy From nobody Tue Sep 5 21:17:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBC913219F for ; Tue, 5 Sep 2017 21:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6iFDKd9n1F0j for ; Tue, 5 Sep 2017 21:17:53 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814351321DF for ; Tue, 5 Sep 2017 21:17:52 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id h70so35752725oic.1 for ; Tue, 05 Sep 2017 21:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r5FGcWlD8N2CDG7AcYW8pMrtXsd/+5myoEdehX+bxT0=; b=dZpD+cEuaXEkIygmnMT21zl4ZRzO09EcEyq4LdRJi9TrJf1G3Z1gdCbe65AQyzG7/J 6pix0qPam4K+oJc80JNo/Iq9uXp6iB3cOMMvAou2au33+zfG1796CsKBKnMXi4V0KkEj h/z0BqnQVtJF6CtucQ4ObYgn/2CD777HFkIuEo0bdcW1NxhicyP9YOpPwzpFDhJRgzux sKvCqgmPWfyf7tSUf8dKrVQRnA0cvFyf/W5bvpzzRUxUX3sHMxGq5HA8wacEG/3ZqtNv IPysLUtVjyqvIVYHDg+zz67yFCr2BKvGOQYQDf+guK6UZSMAyhia45TNb5v7NpChxNH4 09xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r5FGcWlD8N2CDG7AcYW8pMrtXsd/+5myoEdehX+bxT0=; b=OgrLQLYHfhzzh0ah+X9oB+O84Od1gJKhXt645EbQ756B8SroBWx/tjrCO1QIPLZgC3 m84rLYGNB1Y8t6CyCONvSoCDmKud9XF8mpJkyTG6oedQG6TkP3ricBZTtM8fqmAgRq7S Hl0fVaV+guCcmakyi0Gor+jTFyJwbYo3KWt/EiZrplFPdWxvFbm8KEBPkA3Agk1bQ/EC EbYescww/MOgzxqUwV+gCduNfUwWrooXaaJkGBp7yJ9xLXm99BB/jZFW44KzVcr3ZaT0 H+38cepwtr86I2R6V9haK5z1oSPAtHiKGCxFNsJDgR8C457liUoo37NiGOVO+VRgDztJ UtqA== X-Gm-Message-State: AHPjjUj2EfiFi4jK5nePWKR32T8OnHXuiJbydDbJGNTn+V3XsOSc9RSS /j9Kl2B79kQHIgHIJQmFMnxmVWQxSg== X-Google-Smtp-Source: ADKCNb7Sv6jL3VZoGuAD456Fq7/2xGNL1gFvn//qF/FP+yQtu1ld83o8Pm+D4drvK3NCT5V0eNcI3H0L/ffpAG3Qumc= X-Received: by 10.202.86.69 with SMTP id k66mr1283054oib.320.1504671471867; Tue, 05 Sep 2017 21:17:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Tue, 5 Sep 2017 21:17:51 -0700 (PDT) In-Reply-To: <20170906041411.GA15025@1wt.eu> References: <20170906041411.GA15025@1wt.eu> From: Martin Thomson Date: Wed, 6 Sep 2017 14:17:51 +1000 Message-ID: Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Willy Tarreau Cc: Nick Harper , Victor Vasiliev , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 04:17:55 -0000 On Wed, Sep 6, 2017 at 2:14 PM, Willy Tarreau wrote: > On Wed, Sep 06, 2017 at 11:05:25AM +1000, Martin Thomson wrote: >> The only question I have there is what we need to tell the congestion >> controller. Obviously all that 0-RTT won't get acknowledged, but you >> can't really pretend that you didn't send it at all, you also can't >> mark all those packets as lost either. >> >> https://github.com/quicwg/base-drafts/issues/762 > > Probably that this means the protocol needs to have explicit provisions > for ignored/rejected data, which are data properly delivered by the > transport layer but rejected by the application It's worse than that, even the transport can't know whether the data was delivered. It's encrypted and the server can't decrypt it (or it has to at least pretend that it can't decrypt it). > I don't know what it > implies for now, but it sounds that this use case is real and cannot be > hidden under the carpet :-) Rejection is a critical part of 0-RTT, yes. From nobody Tue Sep 5 21:51:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BCB1321DE for ; Tue, 5 Sep 2017 21:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jAZxevazdDSf for ; Tue, 5 Sep 2017 21:51:38 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72141321AF for ; Tue, 5 Sep 2017 21:51:38 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dpSJM-0001ib-CW for quic@ietf.org; Wed, 06 Sep 2017 06:51:36 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dpSJF-00031z-Bx for quic@ietf.org; Wed, 06 Sep 2017 00:51:33 -0400 Received: (qmail 11816 invoked from network); 6 Sep 2017 04:51:28 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.88]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Sep 2017 04:51:28 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: Date: Tue, 5 Sep 2017 21:51:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.23) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYWwktM+UPDyXniaU9ttNgkND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA236BgSsqWId2s/EK3fxqNw4RiOWcEewJjiuLOX Vvq33J6n/V7KhiqJLOESMCW/qNBsYOEkjsX7F8KmpUaZQHV+SZbCEQkE+Ttak7yNVmHZUfi2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpPLwHqwRykc1ByOUA6hOga/fPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEe3u6byHDW8cWJ7iCjtIM7/6pb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/OySQHb3iwsf1ON/gXoJDVrp17vcIhp4/vU15YpEcaF91b7LCVq2nuinYFw/C3rfJ2V 3KD8IdSHBSi9yjOsRb3k8wJfEo0cbb0YLkzPOD/FDLswybukjjR7SZbxkOJ/tGNO+a/fwIMnWcpJ 1yUDJVm56aLg0KxZgxaY5ApIGBRP3nB/3WCT/ywxqGyDcX7ymo81pn6M7II0pBZMP8Q2yl7HZ8cC 5NCzOtKFVG2OgcPUMeKVse1sVhWabI0/+PN3sILCmP4sL9m2Y1BvIAo6egCemilw+ioChJ5n7tfm eH2kchap9/JGM7LGxIWWH81zEGo= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 04:51:41 -0000 On 9/5/2017 6:05 PM, Martin Thomson wrote: > On Wed, Sep 6, 2017 at 10:07 AM, Nick Harper wrote= : >> The approach of treating rejected 0-RTT data like it was lost and >> retransmitting at the transport layer causes problems. As Victor >> mentioned, one of the problems is that the exporter secret changes, >> which is a problem for Token Binding if a client attempts 0-RTT Token >> Binding and 0-RTT is rejected. In this case, the Token Binding HTTP >> header needs to be rewritten to be a signature over the new exporter >> value, when the original stream had a Token Binding header that >> covered the old exporter value. I agree with Victor that on 0-RTT >> reject, streams should be closed. > OK, that's two arguing against continuing. I am a bit concerned that the argument about Token Binding is specific to HTTP. That would be an argument for placing the rejection behavior at the app layer, instead of forcing it in the transport spec. > > Given that TLS recommends "starting over", I think that I'd prefer > that to saying that streams close. Isn't that a violation of the general principle that streams shall only be closed by the application? > That is, if 0-RTT is rejected, you treat the connect as a new one > (stream 0 is again special here, which leads me to question - again - > the wisdom of our design there, but that's a separate problem). That > way you initiate all application actions as if the connection were > brand new. > > Also, you can't close stream 1. That's HTTP specific, isn't it? If I look at application-independent transport API, the simplest solution is an "automatic restart" in which "all streams except stream 0 are put back in their original virgin state." This implies some kind of check-pointing in the app, and that would be the price to pay for attempting 0-RTT. I can hardly see any reason to do something special for stream 1. > https://github.com/quicwg/base-drafts/issues/761 > > The only question I have there is what we need to tell the congestion > controller. Obviously all that 0-RTT won't get acknowledged, but you > can't really pretend that you didn't send it at all, you also can't > mark all those packets as lost either. > > https://github.com/quicwg/base-drafts/issues/762 > We kind of agreed that the congestion controller behavior is "sender only", and we only have to specify a New Reno equivalent. I would go back to the initial condition. --=20 Christian Huitema From nobody Tue Sep 5 21:54:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EE5132139 for ; Tue, 5 Sep 2017 21:54:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 O3PVJ37aktDo for ; Tue, 5 Sep 2017 21:54:44 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 39E501321AF for ; Tue, 5 Sep 2017 21:54:44 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v864sceH015572; Wed, 6 Sep 2017 06:54:38 +0200 Date: Wed, 6 Sep 2017 06:54:38 +0200 From: Willy Tarreau To: Martin Thomson Cc: Nick Harper , Victor Vasiliev , QUIC WG Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) Message-ID: <20170906045438.GF15025@1wt.eu> References: <20170906041411.GA15025@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 04:54:46 -0000 On Wed, Sep 06, 2017 at 02:17:51PM +1000, Martin Thomson wrote: > On Wed, Sep 6, 2017 at 2:14 PM, Willy Tarreau wrote: > > On Wed, Sep 06, 2017 at 11:05:25AM +1000, Martin Thomson wrote: > >> The only question I have there is what we need to tell the congestion > >> controller. Obviously all that 0-RTT won't get acknowledged, but you > >> can't really pretend that you didn't send it at all, you also can't > >> mark all those packets as lost either. > >> > >> https://github.com/quicwg/base-drafts/issues/762 > > > > Probably that this means the protocol needs to have explicit provisions > > for ignored/rejected data, which are data properly delivered by the > > transport layer but rejected by the application > > It's worse than that, even the transport can't know whether the data > was delivered. It's encrypted and the server can't decrypt it (or it > has to at least pretend that it can't decrypt it). I see. Maybe that could be considered equivalent to some out-of-band data. Ie the sender would at least have to say "hey I sent you this amount of early data, maybe you don't know what it is but please at least ACK its receipt as something opaque". Willy From nobody Wed Sep 6 00:35:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6059D13236D for ; Wed, 6 Sep 2017 00:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AHXU_f3Ql2GK for ; Wed, 6 Sep 2017 00:35:48 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6AF1270AB for ; Wed, 6 Sep 2017 00:35:48 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id n18so37268196oig.2 for ; Wed, 06 Sep 2017 00:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0F47aLqjrxLteKTJLrTIK1V8Bs+HOQJ+5+wlMvsoM9o=; b=nuwSmaQ1njcYWj2sE/7IPyWhH4lO1sRs/e3fbowmtFqPmRZVAjNjnNZhqebVRQ93UG 5OOle21H/XxCjTmpNE2LvcO+j/L8ycshZ9B5q0SktmlsBsCozxhPdoQfvrBpYgx/sAu4 /37j0Zkqheu7Gx0n3b/WRgJ6Uif1Bm/cEAt4sHojduip4l4Mh5LM9qTDxmDDK6q7PH5I 4cVkU7DRxUjjNZ5TWBdR2mFxy5FojjOI4ISwgDh3TDjTKndjETGZ5snbW5fngI0Jd/tR kYE0UY1z4ALkzJRdlpPhxeTSJ6MXDIyOkXH/i8esX+xEL8HoOreL+JIBI/hSm6TN9kID nShg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0F47aLqjrxLteKTJLrTIK1V8Bs+HOQJ+5+wlMvsoM9o=; b=DQhkNBqj7kUv1C4wDkNIP4hw3AIPpCWhAC9/z77dctS1xIttp/oQfy/lClw8znLP7I prajItuYWHVFtTsoTYzgRIohYqH7I4KVo7zGpFoFkGYDcLvklGI+3gh036ipCyl7u9UC XpRO3BmJrNzxKROr7ai/nNC4BptXka3h8sYJgvCIGFPhxEHVPadP5yOr/5LDPUOPSIm6 opZiJS5g8Vcf9svFUTS3KGnLUq6MyHUSIC73daA8YpRUyFeNdUNCdFpCmszq54WS72ZB Hrj9YEIJyXV5v0gh8Ly0pXvE8qADTS5XXlTsDPY9P+TblNCDPqr2Pe8g30LdvHDAebSq Mhuw== X-Gm-Message-State: AHPjjUgglbBM54QNAz3gyh105VEgxVQ9vjk591gbpfXHkjZc3l93E0zt 2Ue253HifGjhn8hhfJ2z+NyiFNY93gS8 X-Google-Smtp-Source: ADKCNb5segkDBc9xyh638fwvi7AoC1wYxBesBeg17Jxm/Vai0krKjXTZzuervjrMVVJmM/Eb7P5xsFCOV/DnekwbL0k= X-Received: by 10.202.87.213 with SMTP id l204mr1829110oib.38.1504683348022; Wed, 06 Sep 2017 00:35:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Wed, 6 Sep 2017 00:35:47 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 6 Sep 2017 17:35:47 +1000 Message-ID: Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Christian Huitema Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 07:35:50 -0000 On Wed, Sep 6, 2017 at 2:51 PM, Christian Huitema wrote: > I am a bit concerned that the argument about Token Binding is specific > to HTTP. That would be an argument for placing the rejection behavior at > the app layer, instead of forcing it in the transport spec. Nick's argument was general, with a specific example from experience. Any application protocol that uses early exporters will likely be similarly affected. >> Given that TLS recommends "starting over", I think that I'd prefer >> that to saying that streams close. > Isn't that a violation of the general principle that streams shall only > be closed by the application? If the application has to treat the connection as a new one, the transport isn't closing the streams, it's effectively closing the connection and asking the application to try again (and promising that that is safe to do). >> That is, if 0-RTT is rejected, you treat the connect as a new one >> (stream 0 is again special here, which leads me to question - again - >> the wisdom of our design there, but that's a separate problem). That >> way you initiate all application actions as if the connection were >> brand new. >> >> Also, you can't close stream 1. > That's HTTP specific, isn't it? Well, again that's a specific example of a general problem: the transport can't close streams. > If I look at application-independent transport API, the simplest > solution is an "automatic restart" in which "all streams except stream 0 > are put back in their original virgin state." This implies some kind of > check-pointing in the app, and that would be the price to pay for > attempting 0-RTT. I can hardly see any reason to do something special > for stream 1. Right, that's what Victor proposes. It's also what TLS 1.3 recommends in the analogous scenario. > We kind of agreed that the congestion controller behavior is "sender > only", and we only have to specify a New Reno equivalent. I would go > back to the initial condition. What if you just sent a massive amount of data? Do you really want to send more without considering the potential impact that might have? From nobody Wed Sep 6 01:11:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF381326BB for ; Wed, 6 Sep 2017 01:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 M875Wmlv9aM1 for ; Wed, 6 Sep 2017 01:11:39 -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 3630E1323B0 for ; Wed, 6 Sep 2017 01:11:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNZ61144; Wed, 06 Sep 2017 08:11:37 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 6 Sep 2017 09:10:06 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Wed, 6 Sep 2017 16:10:01 +0800 From: Roni Even To: QUIC WG Subject: obsrvtaion on packet numbers Thread-Topic: obsrvtaion on packet numbers Thread-Index: AdMm5zHPD4iKjQeVQlG4Za1XZ0BzMQ== Date: Wed, 6 Sep 2017 08:10:01 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.153] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD801698DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59AFADB9.00F2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6052f9ba75873f32548530447d386b2d Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 08:11:41 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD801698DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have some observations on the new text on packet numbers "A QUIC endpoint MUST NOT reuse a packet number within the same connection = (that is, under the same cryptographic keys). If the packet number for send= ing reaches 2^64 - 1, the sender MUST close the connection without sending = a CONNECTION_CLOSE frame or any further packets; the sender MAY send a Stat= eless Reset packet in response to further packets that it receives." I post them here and not in github since I am not sure where to discuss it. 1. "the sender MAY send a Stateless Reset" - I believe that only a se= nder which is a server can do it. 2. "If the packet number for sending reaches 2^64 - 1,..." Here I am = confused. I understand that since wrap around is not allowed than the sende= r cannot send a CONNECTION_CLOSE or use the Immediate Close termination pro= cedure. I am not sure about application close termination procedure since I= assume it will also require some QUIC messages to close connection. On th= e other hand the sender may wish to continue sending using a new connection= , so is this a connection migration ? I assume that the state of the open s= treams should be kept. I think that some text is missing here and for the = connection migration procedure. Roni Even --_000_6E58094ECC8D8344914996DAD28F1CCD801698DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I have some observations on the new text on packet n= umbers

 

“A QUIC endpoint M= UST NOT reuse a packet number within the same connection (that is, under th= e same cryptographic keys). If the packet number for sending reaches 2^64 - 1, the sender MUST close the connection without sending a CONNECTIO= N_CLOSE frame or any further packets; the sender MAY send a Stateless Reset= packet in response to further packets that it receives.”<= /span>

 =

I post them here and not= in github since I am not sure where to discuss it.

 =

1.=    &n= bsp;   “the sender M= AY send a Stateless Reset” – I believe that only a sender which= is a server can do it.

2.=    &n= bsp;   “If the packet number for sending reaches 2^64 - 1,…&= #8221; Here I am confused. I understand that since wrap around is not allow= ed than the sender cannot send a CONNECTION_CLOSE or use the Immediate Close = termination procedure. I am not sure about application close termination pr= ocedure since I assume it will also require some QUIC messages to close con= nection.  On the other hand the sender may wish to continue sending using a new connection, so is this a c= onnection migration ? I assume that the state of the open streams should be= kept.  I think that some text is missing here and for the connection = migration procedure.

 

Roni Even

 

--_000_6E58094ECC8D8344914996DAD28F1CCD801698DGGEMM506MBXchina_-- From nobody Wed Sep 6 02:17:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FCA1323B4 for ; Wed, 6 Sep 2017 02:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 tSzwX9cgNoZd for ; Wed, 6 Sep 2017 02:17:13 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D47132623 for ; Wed, 6 Sep 2017 02:17:11 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v869G7WG000473 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Sep 2017 11:16:07 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dpWR3-0005K7-QP; Wed, 06 Sep 2017 11:15:49 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Split error codes in two From: "Philipp S. Tiesel" In-Reply-To: Date: Wed, 6 Sep 2017 11:16:06 +0200 Cc: Martin Thomson , Victor Vasiliev , QUIC WG , Nick Harper Content-Transfer-Encoding: quoted-printable Message-Id: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> References: To: Jana Iyengar X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:17:14 -0000 > On 6. Sep 2017, at 03:12, Jana Iyengar wrote: > On Tue, Sep 5, 2017 at 6:10 PM, Martin Thomson = wrote: > On Wed, Sep 6, 2017 at 10:59 AM, Jana Iyengar wrote: >>> In the current draft, we've already changed that requirement: the >>> application is expected to generate a RST_STREAM in response to a = received >>> RST_STREAM. >>>=20 >> That text was removed with the addition of STOP_SENDING. (Or at = least >> I couldn't find it). I think that's the right answer, because this >> will be entirely discretionary on the part of applications. >>=20 > Yup, I was just pointing out the reasons that we don't need RST_STREAM = to be a transport directive. RST_STREAM is also referenced in the "Stream Errors=E2=80=9D section and = still makes sense for transport errors only effecting a single stream Removing RST_STREAM also means making all errors effecting just a single = stream connection errors leading to teardown of the whole connection. AVE! Philipp S. Tiesel / phils=E2=80=A6 From nobody Wed Sep 6 02:37:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EAC132707 for ; Wed, 6 Sep 2017 02:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 wKZvioo0zjVG for ; Wed, 6 Sep 2017 02:37:31 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF7B1323B4 for ; Wed, 6 Sep 2017 02:37:31 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v869b9ev025602 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Sep 2017 11:37:09 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dpWlP-00060L-AG; Wed, 06 Sep 2017 11:36:51 +0200 From: "Philipp S. Tiesel" Message-Id: <5AD0AAE5-383B-4288-9350-4614E8AA896B@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_42DFF0B1-E005-49C7-B151-1C279F7E7EDA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Unreliable Stream Support for QUIC Date: Wed, 6 Sep 2017 11:37:08 +0200 In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A37766AB0@bgb01xud1012> Cc: QUIC WG To: Lucas Pardue References: <7CF7F94CB496BF4FAB1676F375F9666A37766AB0@bgb01xud1012> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:37:33 -0000 --Apple-Mail=_42DFF0B1-E005-49C7-B151-1C279F7E7EDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5. Sep 2017, at 19:20, Lucas Pardue wrote: >=20 > Hi Philipp, >=20 > Thanks for publishing these. I've only had a chance to skim read so I = only have a basic question right now. >=20 > For the HTTP/QUIC mapping, have you considered server push? The = document doesn't mention anything but I wonder if you have some ideas. = I'm thinking that the push promise includes your request header to = indicate to the client that the pushed body will be unreliable. An = alternative would be to have all pushed streams inherit the reliability = of the parent stream.=20 We have not thought about server push yet. As the server knows from the QUIC handshake that the client, in = principle, supports unreliable streams, HTTP/2 can use this knowledge. For draft-04, I agree with your first proposal, as the push-promise = headers should be the same as the request headers. The push stream is = then opened as unreliable stream. =20 For draft-05, the Server push description looks kind of broken to me. It = still references the request/response streams as used in -04 and the = frames needed for reference are gone. Assuming a sensible implementation with a new stream first carrying a = PUSH_PROMISE frame, then a bunch of DATA frames, the server must open = the push stream as unreliable and only retransmit the content of the = PUSH_PROMISE and probably late HEADERS frames. While I linke the design and will include it in the next version of the = draft, I fear it might not work well over multicast. AVE! Philipp S. Tiesel / phils=E2=80=A6 --Apple-Mail=_42DFF0B1-E005-49C7-B151-1C279F7E7EDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 5. Sep 2017, at 19:20, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:

Hi = Philipp,

Thanks for publishing these. I've = only had a chance to skim read so I only have a basic question right = now.

For the HTTP/QUIC mapping, have you = considered server push? The document doesn't mention anything but I = wonder if you have some ideas. I'm thinking that the push promise = includes your request header to indicate to the client that the pushed = body will be unreliable. An alternative would be to have all pushed = streams inherit the reliability of the parent stream.

We have = not thought about server push yet.

As = the server knows from the QUIC handshake that the client, in principle, = supports unreliable streams, HTTP/2 can use this = knowledge.

For draft-04, I agree = with your first proposal, as the push-promise headers should be the same = as the request headers. The push stream is then opened as unreliable = stream.
 
For draft-05, the Server push = description looks kind of broken to me. It still references the = request/response streams as used in -04 and the frames needed for = reference are gone.
Assuming a sensible implementation with a = new stream first carrying a PUSH_PROMISE frame, then a bunch of DATA = frames, the server must open the push stream as unreliable and only = retransmit the content of the PUSH_PROMISE and probably late HEADERS = frames.

While I linke the design and = will include it in the next version of the draft, I fear it might not = work well over multicast.

AVE!
  Philipp S. Tiesel / phils=E2=80=A6
= --Apple-Mail=_42DFF0B1-E005-49C7-B151-1C279F7E7EDA-- From nobody Wed Sep 6 02:52:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13321320D9 for ; Wed, 6 Sep 2017 02:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0h44LstUEKfW for ; Wed, 6 Sep 2017 02:52:05 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDAA1270AB for ; Wed, 6 Sep 2017 02:52:05 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id n18so38750843oig.2 for ; Wed, 06 Sep 2017 02:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YHoym99PFBrztvweAstg2bgjdecdtnLu8R7S9/xv5dU=; b=lKVdA6IpF/6SCcxtCKKBoPn2nVmaZFBtmJMOal02xJjO/IXlKYnRNfC8SEJjPzIALi /R4W/0aNeCjcc/2y6JaV94vEexB3QG7uw11YyqMtOqt5IZXDNa4I3W05CeEc5m9yar/x zBjDdIu0ITdZZ/rc5O6EcjFk+Z6U6kctIJn36+W1wCua/LSU4sMsmZ73XvOySqsDJz7X DnwL+vs2+Xk0vK6kFTnSUYgtLvdfRTvcMZBZD1UwGy07Yy2vSIPcWtgWsTi/MUZVdn3y iCAAS5PV/qKnSW2tTjxoPGEPzLIvURhtx1Nf/rFR4WR9welsBWVSmnkgvkJaQgmBnH0M GTtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YHoym99PFBrztvweAstg2bgjdecdtnLu8R7S9/xv5dU=; b=GklWR5LJR0BDZgNwxkRvW5ntbBpoNTPNp/OFIzp87xD0bYKikQRT1DM3CddDv4uoUH piVwY119GKNqgk51IXdEevXf0w0gbpe5ExRUrFVqXWCb/0X8tNwrH3UpXy/I8IAMf/gc Ie0P7lEZqzr8Wdh5Zs6XqB5BAdC2ZFycAyRAw1+cZbLLYXTz9ZI5QVnJ60g8jS3NZJmF Bu4JLbJ1vMDsRrz730Li+5nvQ68Q5sAmMbxbMd7MUBKFlPuR1JZK+k/XjH2YTKnnBSfG X+1eQu34Fo7VT0hywjtb+jgdZS/QwAq9/O295Ew1PdhDieuh2GlaVUJ9v8ocNq6vkYQH F52g== X-Gm-Message-State: AHPjjUiLrSWtQqzgtHqaxiYIilhOp3fAf3RiI3cGseA8Jam6YNBoBZ5V 1N8icwm1el6Ok4QajxM7SCo18vRf3w== X-Google-Smtp-Source: ADKCNb6FSt12xnh+Ib1JQ4JJu9KmggmbAqcGxHfWBsDpgRGn1HMpZhtzr+icFS96NCKM8LeeC7oMVHNcoEfhHn0pwlI= X-Received: by 10.202.93.136 with SMTP id r130mr533090oib.5.1504691524809; Wed, 06 Sep 2017 02:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Wed, 6 Sep 2017 02:52:04 -0700 (PDT) In-Reply-To: <20170906045438.GF15025@1wt.eu> References: <20170906041411.GA15025@1wt.eu> <20170906045438.GF15025@1wt.eu> From: Martin Thomson Date: Wed, 6 Sep 2017 19:52:04 +1000 Message-ID: Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Willy Tarreau Cc: Nick Harper , Victor Vasiliev , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:52:07 -0000 On Wed, Sep 6, 2017 at 2:54 PM, Willy Tarreau wrote: > On Wed, Sep 06, 2017 at 02:17:51PM +1000, Martin Thomson wrote: >> It's worse than that, even the transport can't know whether the data >> was delivered. It's encrypted and the server can't decrypt it (or it >> has to at least pretend that it can't decrypt it). > > I see. Maybe that could be considered equivalent to some out-of-band > data. Ie the sender would at least have to say "hey I sent you this > amount of early data, maybe you don't know what it is but please at > least ACK its receipt as something opaque". That's the best solution I could think of as well. It's not particularly ideal, because the signal can't be authenticated and so it would be subject to abuse and spoofing. It's also possible that some server deployments would reject 0-RTT because they can't guarantee proper routing of those packets, which leads to a new problem: they can't generate this pseudo-ACK at all and now you have what appears to be a genuine loss scenario... From nobody Wed Sep 6 02:55:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE4D1320D9 for ; Wed, 6 Sep 2017 02:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fkW9vlTlk90F for ; Wed, 6 Sep 2017 02:55:43 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA471270AB for ; Wed, 6 Sep 2017 02:55:43 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x190so23141912oix.3 for ; Wed, 06 Sep 2017 02:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=s4xqM1AB0nOiUFVr2g8x63srC1q4KMuJ2qPm+5NIwX4=; b=eqfygaSZjnmv3xG4AM622uLxCMalQNqwcR6S6grt9kn9oUWGtEkWIBsmdyGtzOxVqb B7ttAZtOkMxp8hMFa5LsLl2ZFeghzYE2iV1GIRaDeMSXZo0RK7gA9sPLTO3e23W6/RZu PaUZAvZqdBnCzr/Xege54m246KJIDs2H3FmpUzO4gQ6DuA3sECRqmQjImtIao1NvCacr 1EtblgR9Es76q6V0WOcJsYFfBUHN5uq8qmWdZ9aYzDjB4XEA/KoELOHwgEv+5ZEaq5PQ JtP5k0e/ZM6DWRLnLZWLRn1k3YNKWvWqdblaspF94YIMLyUGO/28Q+bYZZHvzZH4wNqQ jdqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s4xqM1AB0nOiUFVr2g8x63srC1q4KMuJ2qPm+5NIwX4=; b=FvK/QsONowTWnwjV3qs2o1aJV1nhHQTUhVwJiPikFcceuxTwV3Be/KbXcB4fuTSE2R qHWRWnjUvlTHos50V5l6pBsCM7ShxnYYynzULZWgpgp2rLh6t9wdoUEEDvcN+/ZRwT2X YnUBAR7Y5TsvH+ahAUJ7B4EmuJ/cHH4oOSL6g7LXoqCEVLwlVkg3IZvNEjKMj8qm0adO G49SaRYwJ1kg6Gp7KFKRxnQ0qLnrCTQ2oJ/Gyf2er8R5bApx44ofpEpKrT7OMuYrgYjM cd27Hrz9I5w6K2Ev3D9lDQgI42EHnPaF3I2qb/72MRoNwnJjXt3iVcQo/w97DR7RRjZb RgYw== X-Gm-Message-State: AHPjjUhjJHQ/HNJWZCnNt5epBQBXNMhAMZ9WbVA9ifyhpTIHDy8y5g6/ 57a8kPt3hggPzF3wOIkGKT1ppw3FDg== X-Google-Smtp-Source: ADKCNb4Kwhmdsgw75coiUTVCn8GbHoHItc8uCmR9f/6ZyGqOzGOZL7XGIlnbB/Iwr/fm3BZJXyl20nb2dqLX7AdNl8s= X-Received: by 10.202.93.136 with SMTP id r130mr539480oib.5.1504691742757; Wed, 06 Sep 2017 02:55:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Wed, 6 Sep 2017 02:55:42 -0700 (PDT) In-Reply-To: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> From: Martin Thomson Date: Wed, 6 Sep 2017 19:55:42 +1000 Message-ID: Subject: Re: Split error codes in two To: "Philipp S. Tiesel" Cc: Jana Iyengar , Victor Vasiliev , QUIC WG , Nick Harper Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:55:45 -0000 On Wed, Sep 6, 2017 at 7:16 PM, Philipp S. Tiesel wrote= : > RST_STREAM is also referenced in the "Stream Errors=E2=80=9D section and = still makes sense for transport errors only effecting a single stream The problem here is that a stream reset at the transport layer causes loss of application layer state. There might be some application data that is critical (the opposite of your partially reliability use case). The transport dropping it would leave the application in an indeterminate state. From nobody Wed Sep 6 03:20:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3421321C9 for ; Wed, 6 Sep 2017 03:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SssvaPp1jmjZ for ; Wed, 6 Sep 2017 03:20:49 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF571270AB for ; Wed, 6 Sep 2017 03:20:49 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id h70so39210504oic.1 for ; Wed, 06 Sep 2017 03:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=q4mOAJ3ELM7IozZpdDM8NU9q94+dHO56Y8HM6k4k418=; b=r5x5NFCgktpMzREv6pc/ivP2g0R2in8XrAkBZXqrxcUzfZtZCjPmD6Lw8JPQoLgu6o Jc/0WCpQqpvuf2YzbTKXbo9egW17ntsOLM3vOaZeEDSCb17L+0rsXt5auWyaBY6oLZYk QxrZH1jRX3Gjf1cR32sznv4djI7mQZ4K8vAMWBbywPmOu5LCLDvMjBsZvqriFvFD1YzB +dlfjDOOb/+0M2SLWx77SctG2XDX1+bsTuYAp4ve/FpM3tkrrOzwWAcf02bGRV5K1bq2 5ijyNSlNKYrKYLFbv7Tv6+3IA+Yzta/UBlCge5n1zdhtBGFUhzD63fNvXE2CPJC+AEx5 Wqbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=q4mOAJ3ELM7IozZpdDM8NU9q94+dHO56Y8HM6k4k418=; b=JeHNRD/XrB4703GqcGHhvuwHQe5OHfk6AJjJfEVtz547686orDTHGHgaTVBPB3E6Qq Ggj+WDfOMSVUYhXgVjL4HSDijxsx0HBtHYowyMi99fQ1tiIRvgq7sTXJazNyHZiedBw/ FyT4XPjD8K3vNaIkXZfOuToPRZrcnxPvUuC/7RCGcchdrjIqKWHjqAHmK3/uO51l+MZo rxyMzex6X0kzZhly4Ajh0+j95hqzFal4XviJ6lodqG1GurVfLAcUnmQN9X1ty3TNoFbW yVoWhpo1z/tFysNehAA/Jjc8zmv/tYhQwvUF+rjXTmXZSTYcfxD8o1UJRnQ+khA+eLGF q+ug== X-Gm-Message-State: AHPjjUgzTTv11BPpFwApGaxDTxRd0SMpUC2ehTN/YyQxnU/0cGuYRnNU a0JSEKLi2sxPwHD31PvOyjAO5dU2VA== X-Google-Smtp-Source: ADKCNb6ySUWZYDhJPOPuaxBofWdTK4xr/wNYy7IxfdgCqfJfBfAxZ2I0qWinj6/5PX9x1wK5938g5EFVkxzW2RJ4c3M= X-Received: by 10.202.86.132 with SMTP id k126mr1957117oib.277.1504693249111; Wed, 06 Sep 2017 03:20:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Wed, 6 Sep 2017 03:20:48 -0700 (PDT) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> From: Martin Thomson Date: Wed, 6 Sep 2017 20:20:48 +1000 Message-ID: Subject: Re: obsrvtaion on packet numbers To: Roni Even Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 10:20:51 -0000 Hi Roni, The text about the sender clearly needs to be qualified. s/the sender/a server/ in this case (I've made that change already). Let's just examine what this entails. 2^64 packets is an awful lot of packets, even accounting for the randomized start and frequent new connection IDs[1]. So many that we might not need to worry about this happening for a while (that's 0.5 trillion packets per second for a solid year if I'm reading the number correctly or 4 Pbps, that's the one with 15 zeros). So it's not obvious that special attention is needed here other than what is written (i.e., stop sending packets). We could advise the use of CONNECTION_CLOSE, but then we have to say something about when to send it. A graceful shutdown is even better, but that's even more amorphous and difficult to provide concrete advice about. Better to leave this corner unpainted in my opinion. What's more, it's clear that both sides know what is going on. Once this magic value is hit, then no more packets will be sent and both peers know it. No real need for any signaling. Note that this isn't a connection migration scenario. Any new connection would - at best - be able to retain cryptographic keys. Stream state would have to be lost. [1] On average new connection IDs would also get us here quicker maybe, though it would still take 272 per second for the same year. On Wed, Sep 6, 2017 at 6:10 PM, Roni Even wrote: > Hi, > > I have some observations on the new text on packet numbers > > > > =E2=80=9CA QUIC endpoint MUST NOT reuse a packet number within the same c= onnection > (that is, under the same cryptographic keys). If the packet number for > sending reaches 2^64 - 1, the sender MUST close the connection without > sending a CONNECTION_CLOSE frame or any further packets; the sender MAY s= end > a Stateless Reset packet in response to further packets that it receives.= =E2=80=9D > > > > I post them here and not in github since I am not sure where to discuss i= t. > > > > 1. =E2=80=9Cthe sender MAY send a Stateless Reset=E2=80=9D =E2=80= =93 I believe that only a > sender which is a server can do it. > > 2. =E2=80=9CIf the packet number for sending reaches 2^64 - 1,=E2= =80=A6=E2=80=9D Here I am > confused. I understand that since wrap around is not allowed than the sen= der > cannot send a CONNECTION_CLOSE or use the Immediate Close termination > procedure. I am not sure about application close termination procedure si= nce > I assume it will also require some QUIC messages to close connection. On > the other hand the sender may wish to continue sending using a new > connection, so is this a connection migration ? I assume that the state o= f > the open streams should be kept. I think that some text is missing here = and > for the connection migration procedure. > > > > Roni Even > > From nobody Wed Sep 6 05:32:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44F1132199 for ; Wed, 6 Sep 2017 05:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 E3DSwydGJUQt for ; Wed, 6 Sep 2017 05:32:13 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922F813263F for ; Wed, 6 Sep 2017 05:32:13 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v86CW4K5026383; Wed, 6 Sep 2017 13:32:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=ahFGWOCBAiU5szH+miuIsEd5xpX4Y0v0Am8YzLgUa2Y=; b=g21LulO6spYE14y+yW5PyT/W4V7JVxVOyIRLLrbkcWJrRD9SjR0HSHB2OHvy71n85wFo O+pNLUYX3J4x6TJIzyBwIH6Lcinqs/NB51ioAqIQHr0nd1qxHqkdo79uWagTuzg3MYJe g4mnkskqMQLYdmEzP7/EzoeMNifCT/+fOR5609c9AibPkNqdUI/fViZpY4R4ACLlJp4G C5fLDZGV+VMP0IYCNfUC8gf2fo4Rx61MPFvzYRv9ySlqPpXUWZjO7NGTdNVm0xkWTEaa E5tVpsOqwst1PETxpLiSQSSfeX+VI2e0DdgS4eUsRB7NPRTiN+2r284vKhc3/RbPR4Cq jA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2cqmpg564h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Sep 2017 13:32:11 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v86CV5Hk015055; Wed, 6 Sep 2017 08:32:10 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2cqqyvcaad-1; Wed, 06 Sep 2017 08:32:09 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id E40FE20064; Wed, 6 Sep 2017 06:32:05 -0600 (MDT) Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Martin Thomson Cc: QUIC WG References: From: Benjamin Kaduk Message-ID: <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> Date: Wed, 6 Sep 2017 07:32:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------63C4F5283B9710F1EF50067C" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709060173 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709060173 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 12:32:15 -0000 This is a multi-part message in MIME format. --------------63C4F5283B9710F1EF50067C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 09/06/2017 02:35 AM, Martin Thomson wrote: >> We kind of agreed that the congestion controller behavior is "sender >> only", and we only have to specify a New Reno equivalent. I would go >> back to the initial condition. > What if you just sent a massive amount of data? Do you really want to > send more without considering the potential impact that might have? > How much data can you have actually sent before receiving an early-data reject, if you are complying with a congestion control scheme equivalent to New Reno? -Ben --------------63C4F5283B9710F1EF50067C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 09/06/2017 02:35 AM, Martin Thomson wrote:
We kind of agreed that the congestion controller behavior is "sender
only", and we only have to specify a New Reno equivalent. I would go
back to the initial condition.

What if you just sent a massive amount of data?  Do you really want to
send more without considering the potential impact that might have?

How much data can you have actually sent before receiving an early-data reject, if you are complying with a congestion control scheme equivalent to New Reno?

-Ben
--------------63C4F5283B9710F1EF50067C-- From nobody Wed Sep 6 07:14:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6511270AB for ; Wed, 6 Sep 2017 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 nEMMlyRARfQE for ; Wed, 6 Sep 2017 07:14:28 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B50B132FC0 for ; Wed, 6 Sep 2017 07:08:33 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx15.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dpb0C-0005X1-LO for quic@ietf.org; Wed, 06 Sep 2017 16:08:30 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dpazf-0005BM-TJ for quic@ietf.org; Wed, 06 Sep 2017 10:08:22 -0400 Received: (qmail 18076 invoked from network); 6 Sep 2017 14:06:51 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.88]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Sep 2017 14:06:50 -0000 To: quic@ietf.org References: <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> From: Christian Huitema Message-ID: <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net> Date: Wed, 6 Sep 2017 07:06:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> Content-Type: multipart/alternative; boundary="------------637A16E779F4B270460F30F3" Content-Language: en-US Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.05) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYWwktM+UPDyXniaU9ttNgkND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA233kW7+4uosNUJec/68HulkJ5fvJwL02UBcVlA XGvcrY+R+SQq3snE9GARsJShr/gaYOEkjsX7F8KmpUaZQHV+SZbCEQkE+Ttak7yNVmHZUfi2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpPLwHqwRykc1ByOUA6hOga/fPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEe+JWJDxXXDKq0gFN0LIfQHmpb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/MrYIfz2tA4UHAvRGYpFGnXp17vcIhp4/vU15YpEcaF90KtMeX3khAusNtE6J0J+f3r WsuOKFQw4+DVXaDAYcOlhVR1id1GLKHJBvyjlI1w1FnlchNWE8e5icoecmvYRd3vBm/TgWToDWWS 7bXXhmcs1G7mF+3cMCQ5raTS7ft6i29uSl5jk2GSHPTeiS5jQRdhCzUOiI84TnM1VbcpKHR7xpOn 1bfMnWw/v8Bdr8FcBce5E3gE8Kl81GJcWDpdD/xGoON3HTTAwlo57pg+CKKIGeeJVu3iNHfFaXet oOmNOd4K6mLGc2whQNCsuCARgHQ= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:14:29 -0000 This is a multi-part message in MIME format. --------------637A16E779F4B270460F30F3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 9/6/2017 5:32 AM, Benjamin Kaduk wrote: > On 09/06/2017 02:35 AM, Martin Thomson wrote: >>> We kind of agreed that the congestion controller behavior is "sender >>> only", and we only have to specify a New Reno equivalent. I would go >>> back to the initial condition. >> What if you just sent a massive amount of data? Do you really want to >> send more without considering the potential impact that might have? >> > > How much data can you have actually sent before receiving an > early-data reject, if you are complying with a congestion control > scheme equivalent to New Reno? If we assume that a clear text ACK cannot acknowledge encrypted packets, 0-RTT data packets cannot be acknowledged before the connection is established. The sender can thus send at most an initial window. >From a congestion control point of view, how should "reset after 0-RTT reject" differ from starting a new connection? -- Christian Huitema --------------637A16E779F4B270460F30F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 9/6/2017 5:32 AM, Benjamin Kaduk wrote:

On 09/06/2017 02:35 AM, Martin Thomson wrote:
We kind of agreed that the congestion controller behavior is "sender
only", and we only have to specify a New Reno equivalent. I would go
back to the initial condition.

What if you just sent a massive amount of data?  Do you really want to
send more without considering the potential impact that might have?

How much data can you have actually sent before receiving an early-data reject, if you are complying with a congestion control scheme equivalent to New Reno?

If we assume that a clear text ACK cannot acknowledge encrypted packets, 0-RTT data packets cannot be acknowledged before the connection is established. The sender can thus send at most an initial window.

From a congestion control point of view, how should "reset after 0-RTT reject" differ from starting a new connection?

-- Christian Huitema

--------------637A16E779F4B270460F30F3-- From nobody Wed Sep 6 10:55:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFAD132494 for ; Wed, 6 Sep 2017 10:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 e5dirBcpnZ99 for ; Wed, 6 Sep 2017 10:55:17 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0125.outbound.protection.outlook.com [104.47.33.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025F8132055 for ; Wed, 6 Sep 2017 10:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oreXEfaKVXBfQEJ73ZP64XX0GgxeStsBTl5WgzPae/c=; b=Q9BeiGk4XXQK/A37dLXrN1vJ0qXcTkECH79xYWugEhjIqBkISssoRAxNqolGdfZM3hEGq3rrLY4KB0TH8UMzV2PRsxPLfbvyP5GBRgWvTtL80vCEmoIOYmqlWKgAxXT9R/3w5C/wveMvCF9ZrzsvARJXMM3n/JGNghSQvciKD54= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0749.namprd21.prod.outlook.com (10.173.51.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.0; Wed, 6 Sep 2017 17:55:14 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0056.003; Wed, 6 Sep 2017 17:55:14 +0000 From: Mike Bishop To: "Philipp S. Tiesel" , Jana Iyengar CC: Victor Vasiliev , QUIC WG , "Martin Thomson" , Nick Harper Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9lu8pyhHlCkWTBQfMudDeAKKmFGeAgAASp4CAAAOOAIAA0yCAgAAOnACAAAMMAIAAAK4AgACHAwCAAI1zwA== Date: Wed, 6 Sep 2017 17:55:14 +0000 Message-ID: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> In-Reply-To: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:c::51f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0749; 6:Z9TMPr1b45lSK8Z5W/XWoUR+tv/sRUICy11bDiWHts6XOeCVru1B6TYIN3Ko9egdK5btQeQ8wgr+Ig3ZMl3OpdgB3pDmDpqLusus6ygfts4MRvjBHQxNvtv25MbLqpeN9KXKEaP5UrnVryeC5qgUKwmT/X10OPiMw9Mmis7ig7J0uic7xAmannMgkhG7TSNw390d8CR25eQYwiyzkiTTI8/YOrk6C9YqyNrol/blXNaw/kP5x+sQ6g2eWQvYhKGRvAhm1Vlk9/lrCrZCBA1oYzMyJLxODCxabcJCAiMPLtJNZw+lEKuz5MEWNkDVzDx0FkiS6HnsFhOJKOr27gHL9w==; 5:3IKUwlp+obmTwtafv7zCZvJjnDPggQcBMzofVY5vK84Fi07ICWHoMXjscJFLwpfulOjUV/IY6Y6lrUd44Npqg32JQ0Le6AKlbqfznTn3P2hunj/aPBPhuwSQo/NemSOIsEBynpEU4HhXoZgUbqxIqA==; 24:v2CHVL7nB8PmPi+Iw3Cj+sqYYYRl+N8JN78P9YlQ62LESjDKLjgzMw+phLDnC6deMuJIFrcNS6UZlKF2LOT/zbfU6hEWgtkwJxzRp+sRbOg=; 7:ZOJtV832eJoEGuXIszAyhQCYG0HtSOJXjSVYSBE39hv5Iem71wfDDEIejA3hUZR6YR/ZvaqncqCqKwnadwyV6FHhqdxqNg6hoHKvX9KgidnZJCSdbThFAx7nHerBNb+IIMtNIs030oGeuwMafcId6jocE5U05V+Oe8IAZSU0bUbYgVih0l4+kuY6mP3MFuJRlpcRPr/pnR/dldn1a9+9ndosXLLi1usdFosyNSi/qcQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9591c8f8-e52e-4288-1f7e-08d4f5506d53 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0749; x-ms-traffictypediagnostic: MWHPR21MB0749: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(278428928389397)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0749; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0749; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(199003)(13464003)(377454003)(24454002)(51444003)(189002)(8936002)(81166006)(7696004)(2950100002)(9686003)(81156014)(14454004)(72206003)(8990500004)(10290500003)(8676002)(68736007)(5660300001)(3660700001)(74316002)(97736004)(7736002)(478600001)(189998001)(5005710100001)(10090500001)(3280700002)(34040400001)(305945005)(2906002)(54906002)(93886005)(33656002)(50986999)(54356999)(76176999)(25786009)(55016002)(99286003)(6116002)(105586002)(4326008)(77096006)(6436002)(39060400002)(101416001)(53546010)(6506006)(106356001)(102836003)(6246003)(229853002)(53936002)(86362001)(2900100001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0749; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2017 17:55:14.5810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0749 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:55:19 -0000 V2hhdCB0cmFuc3BvcnQtbGV2ZWwgc2luZ2xlLXN0cmVhbSBlcnJvcnMgYXJlIHRoZXJlIHdoaWNo IHNob3VsZG4ndCBraWxsIHRoZSBjb25uZWN0aW9uPyAgVGhlIG9ubHkgb25lcyBJIGNhbiB0aGlu ayBvZiBhcmUgZmxvdyBjb250cm9sIHZpb2xhdGlvbnMgYW5kIG1heC1zdHJlYW0tSUQgdmlvbGF0 aW9ucy4gIFBlcmhhcHMgImZyYW1lIGZvciBzdHJlYW0gaW4gd3Jvbmcgc3RhdGUsIiB0aG91Z2gg eW91IGhhdmUgdG8gYmUgc29tZXdoYXQgZ3JhY2lvdXMgYWJvdXQgdGhhdCBvbmUgZ2l2ZW4gcmVv cmRlcmluZy4gIEkgdGhpbmsgSSdtIG9rYXkgd2l0aCBtYWtpbmcgdGhvc2UgZmF0YWwuDQoNCkkn bSBsZXNzIGNvbnZpbmNlZCB0aGF0IFNUT1BfU0VORElORyBpcyBIVFRQLXNwZWNpZmljLiAgVG8g bXkgbWluZCwgaXQncyB0aGUgd2lyZSBleHByZXNzaW9uIG9mIGEgcmVhZF9jbG9zZSgpLCBqdXN0 IGFzIFJTVF9TVFJFQU0gaXMgdGhlIHdpcmUgZXhwcmVzc2lvbiBvZiBhIHdyaXRlX2Nsb3NlKCku ICBJZiB3ZSdkIGdvbmUgdGhlIGFkdmlzb3J5IHJvdXRlLCBpdCB3b3VsZCBiZSBhbiBIVFRQLWlz bS4gIChPciBhdCBsZWFzdCwgdGhlIG1hbmRhdGVkIGJlaGF2aW9yIHdvdWxkIGJlIGF0IHRoZSBI VFRQIGxheWVyLikgIEhvd2V2ZXIsIGlmIHdlIHRoaW5rIG90aGVyIGFwcGxpY2F0aW9ucyBhcmVu J3QgZXZlciBnb2luZyB0byB3YW50IHRvIGNsb3NlIGEgcmVhZCBzdHJlYW0uLi4uDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbGlwcCBTLiBUaWVzZWwNClNlbnQ6IFdlZG5lc2RheSwg U2VwdGVtYmVyIDYsIDIwMTcgMjoxNiBBTQ0KVG86IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5j b20+DQpDYzogVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBRVUlDIFdHIDxx dWljQGlldGYub3JnPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47 IE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogU3BsaXQgZXJy b3IgY29kZXMgaW4gdHdvDQoNCg0KPiBPbiA2LiBTZXAgMjAxNywgYXQgMDM6MTIsIEphbmEgSXll bmdhciA8anJpQGdvb2dsZS5jb20+IHdyb3RlOg0KPiBPbiBUdWUsIFNlcCA1LCAyMDE3IGF0IDY6 MTAgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyb3RlOg0K PiBPbiBXZWQsIFNlcCA2LCAyMDE3IGF0IDEwOjU5IEFNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29n bGUuY29tPiB3cm90ZToNCj4+PiBJbiB0aGUgY3VycmVudCBkcmFmdCwgd2UndmUgYWxyZWFkeSBj aGFuZ2VkIHRoYXQgcmVxdWlyZW1lbnQ6IHRoZSANCj4+PiBhcHBsaWNhdGlvbiBpcyBleHBlY3Rl ZCB0byBnZW5lcmF0ZSBhIFJTVF9TVFJFQU0gaW4gcmVzcG9uc2UgdG8gYSANCj4+PiByZWNlaXZl ZCBSU1RfU1RSRUFNLg0KPj4+IA0KPj4gVGhhdCB0ZXh0IHdhcyByZW1vdmVkIHdpdGggdGhlIGFk ZGl0aW9uIG9mIFNUT1BfU0VORElORy4gIChPciBhdCANCj4+IGxlYXN0IEkgY291bGRuJ3QgZmlu ZCBpdCkuICBJIHRoaW5rIHRoYXQncyB0aGUgcmlnaHQgYW5zd2VyLCBiZWNhdXNlIA0KPj4gdGhp cyB3aWxsIGJlIGVudGlyZWx5IGRpc2NyZXRpb25hcnkgb24gdGhlIHBhcnQgb2YgYXBwbGljYXRp b25zLg0KPj4gDQo+IFl1cCwgSSB3YXMganVzdCBwb2ludGluZyBvdXQgdGhlIHJlYXNvbnMgdGhh dCB3ZSBkb24ndCBuZWVkIFJTVF9TVFJFQU0gdG8gYmUgYSB0cmFuc3BvcnQgZGlyZWN0aXZlLg0K DQpSU1RfU1RSRUFNIGlzIGFsc28gcmVmZXJlbmNlZCBpbiB0aGUgIlN0cmVhbSBFcnJvcnPigJ0g c2VjdGlvbiBhbmQgc3RpbGwgbWFrZXMgc2Vuc2UgZm9yIHRyYW5zcG9ydCBlcnJvcnMgb25seSBl ZmZlY3RpbmcgYSBzaW5nbGUgc3RyZWFtDQoNClJlbW92aW5nIFJTVF9TVFJFQU0gYWxzbyBtZWFu cyBtYWtpbmcgYWxsIGVycm9ycyBlZmZlY3RpbmcganVzdCBhIHNpbmdsZSBzdHJlYW0gY29ubmVj dGlvbiBlcnJvcnMgbGVhZGluZyB0byB0ZWFyZG93biBvZiB0aGUgd2hvbGUgY29ubmVjdGlvbi4N Cg0KQVZFIQ0KICBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmDQoNCg== From nobody Wed Sep 6 11:30:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D8B132980 for ; Wed, 6 Sep 2017 11:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 qIoGy6C7Ecab for ; Wed, 6 Sep 2017 11:30:33 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0115.outbound.protection.outlook.com [104.47.38.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E8F132941 for ; Wed, 6 Sep 2017 11:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CEdiK3eckQkMhTQJT3Nx/+F3FvB0F1DOxw2WcY/FNW0=; b=I9ipxoceZzOh5y1ReeC+OrmQTgrpoydjK0Rcn+t3oqAuPwip4qn4UIy8x2jWGCZpfKBg85PpmNss8DoEWtNsShgSKy43R2c7WW4mg4T/6H1oPIKWU0ITgmnMic4nnwwfslyNYVjNtnojVzKU1b/qZ73lj6RPe/GLTiSTkbEwdxM= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0510.namprd21.prod.outlook.com (10.172.95.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.1; Wed, 6 Sep 2017 18:30:30 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0056.003; Wed, 6 Sep 2017 18:30:30 +0000 From: Mike Bishop To: "Philipp S. Tiesel" , QUIC WG Subject: RE: Unreliable Stream Support for QUIC Thread-Topic: Unreliable Stream Support for QUIC Thread-Index: AQHTJmRPIBwjFeAGckC2uCzLu/0xEKKoKAmw Date: Wed, 6 Sep 2017 18:30:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:c::51f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0510; 6:Z40ewC9ujIDXCgxZs1di5vH0sSJT8mMWs5fo7v8uff6L9GaUBJwbf+8IYxWWKeXD7F0BJNt7Y241tL4Y+KStI6kIFLwzjRDjamCq/a6qFB+IXKoKeOZN5eKVms1T4h/83ew1iFX16vYlIajvWD4WnevCWiSldR3oFA1GQhl+Q1KwO/8lH/ceiOtgB/Vhwajh6U6GqoYwWG3Uhv38pRPT77rUH/ZWzNZOvQ2KFxIRZ0EOmJKEO3YDYt5S1osh7nJdFXDDunS2exqwN5Oz7zQzzzei01WACT3X0tARMaD31RIJ25sDQAJ3gcBJSWJR3G0DjYagA/w2Epr995uXYZqPkg==; 5:Yry5Gi2B8/tL8U26ZNe0ae2OOcDYW8XKJd2DmL32y+/IueKrwrc9IyfkzkZ2i0wAPnjdYvsRb1PpQLqdjv6CxYWA8kf2E6nqQzgmqrpkFZV+z2+JN7fQLgHAjAuEUcwJyZrlqDwW50szdkuWGGIaUg==; 24:VquodDQiMrdEb7N8MSFRUhxVoZVl52u5lOCvBmNZf5N9fRiQd6EiiMM67yO4ajMOLX06NMXGANfZT1Q8Iu02P8pKrbaqpNf//hxUnQuStMQ=; 7:VboQr+qAW16cQgbzYkrMOK+7yzSIfg//F3tSrpmHdKQ4KRfM3EcA85Hmjgijb4p6ZRHRehyWnq+RZneHZCQZe+sIUjwwUrc3hDmpJKJCxWxMq1pmB3VQaMX3jP6NRvJCKkAUb2NaXr3W6/ZvYIEAxMYRw/BkUwgchrUE3eG1y0FF6AN70kQt3+rI4cc1/YhaIbsf2Yy4d5r+rh64K6Hey84bb74xixY4ucUCi7ZvcHo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b403ec70-9ab1-4e41-819c-08d4f5555a9a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0510; x-ms-traffictypediagnostic: MWHPR21MB0510: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(278428928389397)(189930954265078)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0510; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0510; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(189002)(13464003)(199003)(377454003)(5660300001)(6116002)(102836003)(33656002)(72206003)(2900100001)(6506006)(561944003)(77096006)(101416001)(25786009)(9686003)(229853002)(478600001)(97736004)(53546010)(76176999)(54356999)(50986999)(2906002)(55016002)(189998001)(3280700002)(3660700001)(99286003)(68736007)(8936002)(6306002)(53936002)(6436002)(105586002)(106356001)(5005710100001)(966005)(8676002)(8990500004)(305945005)(86362001)(575784001)(81156014)(6246003)(81166006)(74316002)(2950100002)(14454004)(7696004)(7736002)(10290500003)(10090500001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0510; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2017 18:30:30.6245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0510 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 18:30:35 -0000 UmVhZGluZyB0aHJvdWdoIHRoZSBkcmFmdCwgYSBmZXcgdGhvdWdodHMgd2l0aCBubyBwYXJ0aWN1 bGFyIG9yZ2FuaXphdGlvbi4NCg0KWW91ciBwcm9wb3NhbCBzYXlzIHRoYXQgIlVucmVsaWFibGUg c3RyZWFtcyBhcmUgc3ViamVjdCB0byByZWd1bGFyIGNvbmdlc3Rpb24gY29udHJvbC4gIENMT1NF X1NUUkVBTSBGcmFtZXMgYXJlLCBsaWtlIEFDSyBhbmQgUlNUX1NUUkVBTSBmcmFtZXMgbm90IHN1 YmplY3QgdG8gY29uZ2VzdGlvbiBjb250cm9sLiIgIEknbSBub3Qgc3VyZSB3aGVyZSB5b3UncmUg ZmluZGluZyB0aGF0IEFDSyBhbmQgUlNUX1NUUkVBTSBmcmFtZXMgYXJlIGlnbm9yZWQgYnkgY29u Z2VzdGlvbiBjb250cm9sLCBub3Igd2hhdCBpdCBtZWFucyBmb3IgYSBmcmFtZSBub3QgdG8gYmUg c3ViamVjdCB0byBjb25nZXN0aW9uIGNvbnRyb2wgKHdoaWNoIGRlYWxzIHdpdGggcGFja2V0cyku DQoNCkkgdGhpbmsgaW4gNS4zIHlvdSBtaWdodCB3YW50IHRvIGV4cGFuZCBvbiB3aGF0IHlvdSBt ZWFuIGJ5ICJVRFAtbGlrZSBiZWhhdmlvci4iICBQZXJoYXBzIHNvbWV0aGluZyBsaWtlICJVbnJl bGlhYmxlIHN0cmVhbXMgcHJlZmVyIGRhdGEgbG9zcyByYXRoZXIgdGhhbiBkZWxheWVkIGRlbGl2 ZXJ5IGR1ZSB0byByZXRyYW5zbWlzc2lvbi4gIEFwcGxpY2F0aW9ucyB3aGljaCBuZWVkIHRvIGF2 b2lkIGRlbGF5cyBpbiB0aGUgaW5pdGlhbCB0cmFuc21pc3Npb24gd291bGQgYWxzbyBuZWVkIHRv IGVuc3VyZS4uLiINCg0KSSByZWFsbHkgZGlzbGlrZSB0aGUgInpvbWJpZSBzdHJlYW0iIGlzc3Vl LiAgSSdtIG5vdCBvcHBvc2VkIHRvIHRoZSBDTE9TRV9TVFJFQU0gZGVzaWduLCB0aG91Z2ggSSdk IG5vdGUgdGhhdCB5b3UgY291bGQgYXMgZWFzaWx5IHNheSB0aGF0IGEgU1RSRUFNIGZyYW1lIGJl YXJpbmcgYSBGSU4gTVVTVCBiZSBkZWxpdmVyZWQgcmVsaWFibHkuICBJZiBhbiBpbXBsZW1lbnRh dGlvbiB3YW50cyB0byByZXRyYW5zbWl0IGl0IHdpdGhvdXQgZGF0YSwgdGhhdCB3b3VsZCBzdGls bCBiZSB2YWxpZC4gIEVpdGhlciB3YXksIGZsb3cgY29udHJvbCByZXF1aXJlcyB0aGF0IHRoZSBm aW5hbCBvZmZzZXQgYmUgZGVsaXZlcmVkIHJlbGlhYmx5IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0 aGUgZGF0YSBpcy4NCg0KTXkgb3RoZXIgaGVzaXRhdGlvbiB3aXRoIGEgQ0xPU0VfU1RSRUFNIGZy YW1lIGlzIHRoYXQgaXQgaW5jcmVhc2VzIHRoZSBvdmVyaGVhZCBvZiBhbiBhcHBsaWNhdGlvbiB1 c2luZyB0aGUgc3RyZWFtLWFzLW1lc3NhZ2UgYWJzdHJhY3Rpb24uICAoQW5kIHVzaW5nIFJTVF9T VFJFQU0gTk9fRVJST1IgdG8gaW5kaWNhdGUgbm9ybWFsIGNsb3N1cmUgZXZlbiBtb3JlIHNvIC0t IHNwZW5kaW5nIHRoZSBieXRlcyB0byB0cmFuc3BvcnQgYW4gZXJyb3IgY29kZSBmb3IgZXZlcnkg c3RyZWFtIHdoZW4gbW9zdCBvZiB0aGVtIHdvbid0IG5lZWQgaXQgc2VlbXMgZXhjZXNzaXZlLikN Cg0KQXMgd2l0aCAjNzIwLCB0aGlzIGFkZHMgZXZlbiBtb3JlIHN0cmVhbSBwcm9wZXJ0aWVzLiAg SSBhbSB3b25kZXJpbmcgd2hldGhlciB0aGVyZSdzIHZhbHVlIGluIHNpbXBseSBoYXZpbmcgYSBj b2xsZWN0ZWQgZGVjbGFyYXRpb24gb2Ygd2hhdCBhIHN0cmVhbSdzIHByb3BlcnRpZXMgYXJlLCBh bmQgaG93IHdlIG1pZ2h0IGhhbmRsZSB0aGlzIHdpdGggYSBtaW5pbXVtIG9mIGJ5dGVzIHBlciB0 aGUgcHJldmlvdXMgdGhvdWdodC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsaXBw IFMuIFRpZXNlbA0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDUsIDIwMTcgOTozMCBBTQ0KVG86 IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBVbnJlbGlhYmxlIFN0cmVhbSBTdXBw b3J0IGZvciBRVUlDDQoNCkhpLA0KDQphcyBwcm9taXNlZCwgd2UganVzdCBzdWJtaXR0ZWQgYSBk cmFmdCBvbiB1bnJlbGlhYmxlIHN0cmVhbXMgZm9yIFFVSUMsIGluY2x1ZGluZyBzdXBwb3J0IGZv ciBwYXJ0aWFsIHJlbGlhYmlsaXR5OiANCiAgIGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxlLXN0cmVhbXMlMkYmZGF0YT0wMiU3 QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYzE0MzI5YjlmN2FjNDZmMjFk NjUwOGQ0ZjQ3YjZmODglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM2NDAyMjU4Mzg0ODQwNDQwJnNkYXRhPThESWtGQWJ6Q3lsV2dPNiUyRlNCNUVqQlNTdDUw ejVQcDUxVkpjT1BXcml0cyUzRCZyZXNlcnZlZD0wDQoNClRMO0RSOiANCg0KIC0gSW4gcHJpbmNp cGFsLCBzdXBwb3J0aW5nIHVucmVsaWFibGUgc3RyZWFtcyBpbiBRVUlDDQogICBkb2VzIG5vdCBy ZXF1aXJlIGNoYW5nZXMgdG8gdGhlIGRhdGZ0LTA1IHdpcmUtcHJvdG9jb2wuDQoNCiAtIFRvIGdl dCBhIG5pY2UgaW50ZXJmYWNlIGJldHdlZW4gUVVJQyB0cmFuc3BvcnQgYW5kIHRoZQ0KICAgYXBw bGljYXRpb24sIHdlIG5lZWQgb25lIGJpdCBpbiB0aGUgc3RyZWFtIGZyYW1lIGhlYWRlcg0KICAg dG8gaW5kaWNhdGUgd2hldGhlciBhIHN0cmVhbSBpcyBzdXBwb3NlZCB0byBiZSByZWxpYWJsZS4N Cg0KDQpUbyBnaXZlIGFuIGFwcGxpY2F0aW9uIGV4YW1wbGUsIHdlIGRpZCBhbHNvIGRyYWZ0IGhv dyBIVFRQLzIgb3ZlciBRVUlDIGNhbiBiZSBleHRlbmRlZCB0byBzdXBwb3J0IHBhcnRpYWwgcmVs aWFiaWxpdHkgYmFzZWQgb24gdGhlIGRyYWZ0IGFib3ZlOg0KICAgaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tl ci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LXRpZXNlbC1xdWljLXVucmVsaWFibGUtaHR0cCUyRiZk YXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NjMTQzMjliOWY3 YWM0NmYyMWQ2NTA4ZDRmNDdiNmY4OCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdDMSU3QzAlN0M2MzY0MDIyNTgzODQ4NDA0NDAmc2RhdGE9aEJjRlg0bzBhRTVaOGk0TVpzelNr TFhoMjNEVDdHak1Gd1c0RmdycEFlYyUzRCZyZXNlcnZlZD0wDQoNCldlIGhhdmUgbm8gZmluaXNo ZWQgaW1wbGVtZW50YXRpb24geWV0LCBidXQgYXJlIHdvcmtpbmcgb24gb25lLiANCg0KQVZFIQ0K ICBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmDQoNCg== From nobody Wed Sep 6 11:59:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546751200F3 for ; Wed, 6 Sep 2017 11:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 0PYSB3_DKXai for ; Wed, 6 Sep 2017 11:59:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9141912008A for ; Wed, 6 Sep 2017 11:59:26 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by m0122331.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v86Iv1mr022909; Wed, 6 Sep 2017 19:59:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dzrX3b6e5zeHrpzgns/Wen3ySFpqQHeh2CBvKIEHTIQ=; b=Egf6Yyu/kEsWuJSNWDcxoGfjyl0xbhRy+8LMH3rRRpUV7nOIRHzNEiYkcIEN8xL4ZgCi aGLEj/nH+n+okPeCDL8jT5MNFYYs7lY6XcH1e19jSV1AwFil9US3NZy+rbBriFeJn+Pm WsGfKox7UKXx0p+GKfd7SKYZXR5wtxOyhGrSzUFc0tc8mwHbxbA1sEsS6n39/2P1TpIv vl7HkvNsImbQOSZXeP3YMdck/L74H5WAsovHg2/5f+dqJwej/tX+0+dm22BeutwHUXHG eNdc+fV6LgS7iN36gRWJtIRaq9qWsy4QtgikLIIfRCQ0HGa3T66GnxZQTNbmQmt0XS6Z 4w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2cqhgrpaa8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Sep 2017 19:59:20 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v86ItWuM018494; Wed, 6 Sep 2017 14:59:19 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2cqqyv2jcs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Sep 2017 14:59:19 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 6 Sep 2017 13:59:18 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Wed, 6 Sep 2017 13:59:18 -0500 From: "Lubashev, Igor" To: Mike Bishop , "Philipp S. Tiesel" , Jana Iyengar CC: Victor Vasiliev , QUIC WG , "Martin Thomson" , Nick Harper Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9U7CZmvfU3U+AKlwSnR9wwKKmV3WAgAASqICAAAONAIAA0yCAgAAOnACAAAMMAIAAAK4AgACXxwCAAJELAP//rYYQ Date: Wed, 6 Sep 2017 18:59:17 +0000 Message-ID: <08d7699108f94b4680579ce8bfcdea14@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709060269 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709060270 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 18:59:28 -0000 V2hldGhlciBTVE9QX1NFTkRJTkcgaXMgaW4gdHJhbnNwb3J0IGlzIGEgbWF0dGVyIG9mIHBpY2tp bmcgdGhlIGd1aWRpbmcgcHJpbmNpcGxlIGZvciB3aGF0IG9uZSB3b3VsZCBjb25zaWRlciBwdXR0 aW5nIGluIHRyYW5zcG9ydCB2cyBhcHBsaWNhdGlvbi4gIFNvbWUgb2YgdGhlIGFsdGVybmF0aXZl cyBmb3IgdGhlICJndWlkaW5nIHByaW5jaXBsZSIgYXJlOg0KKiAiSXMgbGlrZWx5IHRvIGJlIHVz ZWQgYnkgbWFueSBhcHBzPyINCiogIldpbGwgaXQgbGlrZWx5IHBlcmZvcm0gYmV0dGVyIGluIHRy YW5zcG9ydD8iDQogKiAiSXMgaXQgYSAnY2xlYW5lcicgZGVzaWduIGR1ZSB0byBhbGwgc29ydHMg b2Ygc3ltbWV0cmllcz8iDQoNCkkgdGhpbmsgdGhhdCBTVE9QX1NFTkRJTkcgIm1heSBwZXJmb3Jt IGJldHRlciBpbiB0cmFuc3BvcnQiIGR1ZSB0byB0aGUgcnVsZSBvZiB0aHVtYiB0aGF0ICJzdG9w IiBzaWduYWxzIHNob3VsZCB0YWtlIHByaW9yaXR5IG92ZXIgIm9yZGluYXJ5IiBkYXRhLiAgSS5l LiBoYXZpbmcgaXQgYXMgYSBwYXJ0IG9mIGFuIGFwcGxpY2F0aW9uIHByb3RvY29sIGhhcyBhIHJp c2sgdGhhdCBTVE9QX1NFTkRJTkcgd291bGQgYmUgYmxvY2tlZCBieSBmbG93IGNvbnRyb2wsIEhP TCBibG9ja2luZywgdHJhbnNwb3J0L2FwcCBpbnRlcmZhY2UsIGV0Yy4gIFRoZSAic3ltbWV0cnki IGFyZ3VtZW50LCBob3dldmVyLCBkb2VzIHB1dCBTVE9QX1NFTkRJTkcgaW4gdGhlIGFwcGxpY2F0 aW9uLCBzaW5jZSBSU1RfU1RSRUFNIGlzIG5ldmVyIGluaXRpYXRlZCBieSB0cmFuc3BvcnQgb3Ro ZXJ3aXNlLiAgQW5kIEkgaGF2ZSBsaXR0bGUgaW50dWl0aW9uIGFzIGZhciBhcyAidXNlIGJ5IG1h bnkgYXBwcyIgaXMgY29uY2VybmVkLg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogTWlrZSBCaXNob3AgW21haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tXSAN ClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDA2LCAyMDE3IDE6NTUgUE0NClRvOiBQaGlsaXBw IFMuIFRpZXNlbCA8cGhpbHNAaW4tcGFuaWsuZGU+OyBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUu Y29tPg0KQ2M6IFZpY3RvciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPjsgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+ OyBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPg0KU3ViamVjdDogUkU6IFNwbGl0IGVy cm9yIGNvZGVzIGluIHR3bw0KDQpXaGF0IHRyYW5zcG9ydC1sZXZlbCBzaW5nbGUtc3RyZWFtIGVy cm9ycyBhcmUgdGhlcmUgd2hpY2ggc2hvdWxkbid0IGtpbGwgdGhlIGNvbm5lY3Rpb24/ICBUaGUg b25seSBvbmVzIEkgY2FuIHRoaW5rIG9mIGFyZSBmbG93IGNvbnRyb2wgdmlvbGF0aW9ucyBhbmQg bWF4LXN0cmVhbS1JRCB2aW9sYXRpb25zLiAgUGVyaGFwcyAiZnJhbWUgZm9yIHN0cmVhbSBpbiB3 cm9uZyBzdGF0ZSwiIHRob3VnaCB5b3UgaGF2ZSB0byBiZSBzb21ld2hhdCBncmFjaW91cyBhYm91 dCB0aGF0IG9uZSBnaXZlbiByZW9yZGVyaW5nLiAgSSB0aGluayBJJ20gb2theSB3aXRoIG1ha2lu ZyB0aG9zZSBmYXRhbC4NCg0KSSdtIGxlc3MgY29udmluY2VkIHRoYXQgU1RPUF9TRU5ESU5HIGlz IEhUVFAtc3BlY2lmaWMuICBUbyBteSBtaW5kLCBpdCdzIHRoZSB3aXJlIGV4cHJlc3Npb24gb2Yg YSByZWFkX2Nsb3NlKCksIGp1c3QgYXMgUlNUX1NUUkVBTSBpcyB0aGUgd2lyZSBleHByZXNzaW9u IG9mIGEgd3JpdGVfY2xvc2UoKS4gIElmIHdlJ2QgZ29uZSB0aGUgYWR2aXNvcnkgcm91dGUsIGl0 IHdvdWxkIGJlIGFuIEhUVFAtaXNtLiAgKE9yIGF0IGxlYXN0LCB0aGUgbWFuZGF0ZWQgYmVoYXZp b3Igd291bGQgYmUgYXQgdGhlIEhUVFAgbGF5ZXIuKSAgSG93ZXZlciwgaWYgd2UgdGhpbmsgb3Ro ZXIgYXBwbGljYXRpb25zIGFyZW4ndCBldmVyIGdvaW5nIHRvIHdhbnQgdG8gY2xvc2UgYSByZWFk IHN0cmVhbS4uLi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsaXBwIFMuIFRpZXNl bA0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgNiwgMjAxNyAyOjE2IEFNDQpUbzogSmFuYSBJ eWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT4NCkNjOiBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29v Z2xlLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPjsgTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT4NClN1 YmplY3Q6IFJlOiBTcGxpdCBlcnJvciBjb2RlcyBpbiB0d28NCg0KDQo+IE9uIDYuIFNlcCAyMDE3 LCBhdCAwMzoxMiwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+IE9uIFR1 ZSwgU2VwIDUsIDIwMTcgYXQgNjoxMCBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT4gd3JvdGU6DQo+IE9uIFdlZCwgU2VwIDYsIDIwMTcgYXQgMTA6NTkgQU0sIEph bmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+IHdyb3RlOg0KPj4+IEluIHRoZSBjdXJyZW50IGRy YWZ0LCB3ZSd2ZSBhbHJlYWR5IGNoYW5nZWQgdGhhdCByZXF1aXJlbWVudDogdGhlIA0KPj4+IGFw cGxpY2F0aW9uIGlzIGV4cGVjdGVkIHRvIGdlbmVyYXRlIGEgUlNUX1NUUkVBTSBpbiByZXNwb25z ZSB0byBhIA0KPj4+IHJlY2VpdmVkIFJTVF9TVFJFQU0uDQo+Pj4gDQo+PiBUaGF0IHRleHQgd2Fz IHJlbW92ZWQgd2l0aCB0aGUgYWRkaXRpb24gb2YgU1RPUF9TRU5ESU5HLiAgKE9yIGF0IA0KPj4g bGVhc3QgSSBjb3VsZG4ndCBmaW5kIGl0KS4gIEkgdGhpbmsgdGhhdCdzIHRoZSByaWdodCBhbnN3 ZXIsIGJlY2F1c2UgDQo+PiB0aGlzIHdpbGwgYmUgZW50aXJlbHkgZGlzY3JldGlvbmFyeSBvbiB0 aGUgcGFydCBvZiBhcHBsaWNhdGlvbnMuDQo+PiANCj4gWXVwLCBJIHdhcyBqdXN0IHBvaW50aW5n IG91dCB0aGUgcmVhc29ucyB0aGF0IHdlIGRvbid0IG5lZWQgUlNUX1NUUkVBTSB0byBiZSBhIHRy YW5zcG9ydCBkaXJlY3RpdmUuDQoNClJTVF9TVFJFQU0gaXMgYWxzbyByZWZlcmVuY2VkIGluIHRo ZSAiU3RyZWFtIEVycm9yc+KAnSBzZWN0aW9uIGFuZCBzdGlsbCBtYWtlcyBzZW5zZSBmb3IgdHJh bnNwb3J0IGVycm9ycyBvbmx5IGVmZmVjdGluZyBhIHNpbmdsZSBzdHJlYW0NCg0KUmVtb3Zpbmcg UlNUX1NUUkVBTSBhbHNvIG1lYW5zIG1ha2luZyBhbGwgZXJyb3JzIGVmZmVjdGluZyBqdXN0IGEg c2luZ2xlIHN0cmVhbSBjb25uZWN0aW9uIGVycm9ycyBsZWFkaW5nIHRvIHRlYXJkb3duIG9mIHRo ZSB3aG9sZSBjb25uZWN0aW9uLg0KDQpBVkUhDQogIFBoaWxpcHAgUy4gVGllc2VsIC8gcGhpbHPi gKYNCg0K From nobody Wed Sep 6 12:21:13 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A11120720 for ; Wed, 6 Sep 2017 12:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 g5JlbT_4mDfl for ; Wed, 6 Sep 2017 12:21:09 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4151201F8 for ; Wed, 6 Sep 2017 12:21:09 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dpfsl-0002Jj-EB for quic@ietf.org; Wed, 06 Sep 2017 21:21:06 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dpfsg-0002CG-Pf for quic@ietf.org; Wed, 06 Sep 2017 15:21:02 -0400 Received: (qmail 13510 invoked from network); 6 Sep 2017 19:20:57 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.88]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Sep 2017 19:20:57 -0000 To: "quic@ietf.org" From: Christian Huitema Message-ID: Date: Wed, 6 Sep 2017 12:20:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: The timestamps in the ACK list X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.33) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23dhZHNjwWVzJ9CJltw7BdyJzZ8rfsXcrYidfw YfZGgWIaS6VVs1YnlmwPNW3xa9jmYOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRPfPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEe1SIOvWPJm3kdcpZGadMCSepb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/P4+ZPbnY750LC7YEawdKkkp17vcIhp4/vU15YpEcaF91b7LCVq2nuinYFw/C3rfJ2V 3KD8IdSHBSi9yjOsRb3kPEp9yjXip/VtM7DmXp70yQ0qPvBHv598IKY9sA+d7YCA0coyfWRkF/55 WlWn3rzabaW0KlbI7odCZa1sbCHLgXB/3WCT/ywxqGyDcX7ymo81pn6M7II0pBZMP8Q2yl7HZ8cC 5NCzOtKFVG2OgcPUMeKVse1sVhWabI0/+PN3sILCmP4sL9m2Y1BvIAo6egCemilw+ioChJ5n7tfm eH2kchap9/JGM7LGxIWWH81zEGo= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 19:21:11 -0000 There is already an open issue regarding the role of the time stamp list in the ACK frame, https://github.com/quicwg/base-drafts/issues/698. But there seems to be a more fundamental issue, which is: why do we need these time stamps at all? The ACK already convey the "largest received PN" and the delay between when that was received and when the ACK was sent. That gives a pretty good estimate of the RTT of the connection, several times per RTT. That's certainly enough for computing retransmission timers, and probably enough even for delay based congestion control algorithms. The only use I can think of is measurement of out of order deliveries. Is that the goal? Because if it is, we certainly need to say so, so the receivers put the time stamps of the right packets in the list. And we may need to revisit the ACK structure, because having something like "max out of order sequence number delta" and "max out of order delivery delay" would probably be much easier to understand. --=20 Christian Huitema From nobody Wed Sep 6 14:25:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF3128D0D for ; Wed, 6 Sep 2017 14:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yiPEarInqIMQ for ; Wed, 6 Sep 2017 14:25:39 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6328A124239 for ; Wed, 6 Sep 2017 14:25:39 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id 108so15938539wra.5 for ; Wed, 06 Sep 2017 14:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3roOYmwXodm7wGpGZrxdYWULAjd8ZmMgcuQ2hu6BTWM=; b=jQxnpR00u8oqeaEuJQgiSsENuo+io/OI9ImI3h4zW6VEBygHxNKeuCZD5vL7aBU44D KVogWzLWFpORL5IKG9T/mZ34z1Tta+IRL7E4matBG8sL7WRXnEiexumoAPNy78rMdzn5 xdIyTZMWncg0XpXql10M3ut+ZShIMdgsqK4EBU5kOu/V4Ow4geuP5dyVnkBft+jb1CBi u3qP2jAYdkvZ4ShzcXAHK0cEj7CTFvwjvD+sR78acy7QwSjrP+VJ2UwUU8vwtZg0LyXC q/NfJyN2pPy0WmXSva+EGP+9tzGo98uU56lLTHdoIGPpyNZPOskMjqWZWx8RZPl4B/xK rdUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3roOYmwXodm7wGpGZrxdYWULAjd8ZmMgcuQ2hu6BTWM=; b=tHwtNE4nz1iGLPvAdvj68YPzVO0oVhubgpHQhZSZvnAQ0hr3MS56bQUVigDcposiFA sXkB+dkPuQSWBR2AV+l7h4R5TAFihJx+RzhRLTADFstTonbdO+UERC8tuAXCelsYLTpo FH+IhTgalqPYmpgD3YxByJfk1WXKmdLlcH9KsqU8Iu+9EAsuaHQHEwrZS5isnIFDHSz0 mcBkCx3hiqlWIyNdau1c0iXQLOeEHtvg236xrQWUuw6oEo81PnkJrII0T6m03u7od6Bs RIaQx2YEKkdP4gFRdUQy/CZKyMNFCcIXAcay9H2ts/rER/iTE9oDTh5WVoGqJGzJ+EMx 777Q== X-Gm-Message-State: AHPjjUhAMupxlzxHdfrSdQlr+maFCc678UZPKj7LQFJ7Vvke+KLf5Rf1 RJTcd113+S04j+5mhHpxEWrJOGmsgYvb X-Google-Smtp-Source: ADKCNb7F2lYpmMAv5UeKYbYdb4u5AQ+zAzp6gqiqaEYzYcibn+Sp/W/87lwbevy2pQbowiTQpBDN5NHqW02kyL2JJTM= X-Received: by 10.223.163.208 with SMTP id m16mr284675wrb.185.1504733137552; Wed, 06 Sep 2017 14:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.185.56 with HTTP; Wed, 6 Sep 2017 14:25:37 -0700 (PDT) From: Martin Duke Date: Wed, 6 Sep 2017 14:25:37 -0700 Message-ID: Subject: ACK Frame Issues To: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045f157425490405588bfc4b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 21:25:42 -0000 --f403045f157425490405588bfc4b Content-Type: text/plain; charset="UTF-8" I've finally hacked my way through implementing the construction of an ACK frame from the spec. In my opinion, the spec lacks enough explanatory text. Furthermore, some aspects of this frame may require a fundamental rethink. I would like to create issues for this, but there's a complicated web of interrelated problems and I'd like to get some input on how to structure this. (1) *The spec sorely needs more normative text.* It appears fairly straightforward to implement a sort of half-assed Ack frame that doesn't have any optimizations. I can just ack data that I have not acked before (not repeating in-flight acks); not send timestamps if largest_acked have is more than 255 numbers ahead of the timestamp; and not worry too much about optimizing packet space when playing with block length sizes and so forth. However, sufficiently imaginative implementors worried about corner cases can go down serious ratholes, as I ended up doing. For example: (a) The number of ack blocks I can fit is mostly a function of the block length size. The block length size is a function of the block lengths I'm sending, which is related to the number of blocks I'm sending if one is especially large. So there's a recursive process where I compute the needed block length (by scanning over all blocks), see that it doesn't fit, eliminate some blocks, recompute the needed block length to see if it shrank, see that now I can fit a few more blocks, etc. (b) There are four ways to treat acks in flight on which the spec is silent: (i) Do not repeat them in subsequent acks (ii) Repeat them only if they do not require additional ack blocks (iii) Repeat them only if they require *neither *additional ack blocks nor longer block lengths. (iv) Always repeat them until acked Offline, Jana suggested that (iv) is what Google does, but you'd never guess that. I settled on (ii), for what it's worth. (c) One side effect of any option in (b) except (i) is that it will raise largest_ack, which might make it impossible to send some timestamps that are more than 255 packets below the maximum received. My workaround is to send a second ACK frame with one ack block and a low largest-ack to mop up these timestamps, as I SHOULD send them exactly once. But that might be unintended behavior. (d) One side effect of anything other than (iv) above is to possibly create too large of a gap in packet number to send the next ack block. (e) The spec is unclear if timestamps are sorted in order of arrival or reverse order of arrival. At least it's unclear to me! BTW having to sort new arrivals in both packet number and arrival order is unpleasant. I don't think the spec should prohibit any of this behavior. However, some normative text might indicate to implementors that they don't really need to worry about some of this stuff. (2) *The relationship between timestamps and ack blocks needs a rethink* People are all over the map on this. On the implementer slack channel, a lot of people are totally ignoring timestamps and don't think they're useful. Jana seems to view as a purely advisory channel. On the other hand, as issue #698 points out, a received timestamp means the packet has arrived, and sending an ack block for it in the same frame seems redundant. Finally, timestamps are a report with a completely different syntax. *Especially* if they are advisory, I believe there is a strong case for just putting it in its own frame and eliminating some of the weird dependencies (see (c) above) between largest_acked and the timestamp fields. Personally, I would recommend the following: (1) Move timestamps into a separate frame. (2) A host that receives a timestamp frame MUST interpret a timestamp for a packet as an acknowledgement for that packet. Packet recievers MAY omit ack blocks for packets for which a timestamp is in flight. (3) (possibly) make timestamps something negotiable (in each direction) at the start of a connection. For example, a host may only want timestamps from its peer if it is using delay-based congestion control. Martin Duke --f403045f157425490405588bfc4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've finally hacked my way through implementing the co= nstruction of an ACK frame from the spec. In my opinion, the spec lacks eno= ugh explanatory text. Furthermore, some aspects of this frame may require a= fundamental rethink.

I would like to create issues for = this, but there's a complicated web of interrelated problems and I'= d like to get some input on how to structure this.

(= 1) The spec sorely needs more normative text.

It appears fairly straightforward to implement a sort of half-assed Ack = frame that doesn't have any optimizations. I can just ack data that I h= ave not acked before (not repeating in-flight acks); not send timestamps if= largest_acked have is more than 255 numbers ahead of the timestamp; and no= t worry too much about optimizing packet space when playing with block leng= th sizes and so forth. However, sufficiently imaginative implementors worri= ed about corner cases can go down serious ratholes, as I ended up doing. Fo= r example:

(a) The number of ack blocks I can fit = is mostly a function of the block length size. The block length size is a f= unction of the block lengths I'm sending, which is related to the numbe= r of blocks I'm sending if one is especially large. So there's a re= cursive process where I compute the needed block length (by scanning over a= ll blocks), see that it doesn't fit, eliminate some blocks, recompute t= he needed block length to see if it shrank, see that now I can fit a few mo= re blocks, etc.

(b) There are four ways to treat a= cks in flight on which the spec is silent:
=C2=A0 =C2=A0 (i) Do n= ot repeat them in subsequent acks
=C2=A0 =C2=A0 (ii) Repeat them = only if they do not require additional ack blocks
=C2=A0 =C2=A0 (= iii) Repeat them only if they require neither additional ack blocks = nor longer block lengths.
=C2=A0 =C2=A0 (iv) Always repeat them u= ntil acked
Offline, Jana suggested that (iv) is what Google does,= but you'd never guess that. I settled on (ii), for what it's worth= .=C2=A0

(c) One side effect of any option in (b) e= xcept (i) is that it will raise largest_ack, which might make it impossible= to send some timestamps that are more than 255 packets below the maximum r= eceived. My workaround is to send a second ACK frame with one ack block and= a low largest-ack to mop up these timestamps, as I SHOULD send them exactl= y once. But that might be unintended behavior.

(d)= One side effect of anything other than (iv) above is to possibly create to= o large of a gap in packet number to send the next ack block.
(e) The spec is unclear if timestamps are sorted in order of ar= rival or reverse order of arrival. At least it's unclear to me! BTW hav= ing to sort new arrivals in both packet number and arrival order is unpleas= ant.

I don't think the spec should prohibit an= y of this behavior. However, some normative text might indicate to implemen= tors that they don't really need to worry about some of this stuff.

(2) The relationship between timestamps and = ack blocks needs a rethink

People are a= ll over the map on this. On the implementer slack channel, a lot of people = are totally ignoring timestamps and don't think they're useful. Jan= a seems to view as a purely advisory channel. On the other hand, as issue #= 698 points out, a received timestamp means the packet has arrived, and send= ing an ack block for it in the same frame seems redundant.

Finally, timestamps are a report with a completely different synta= x. Especially if they are advisory, I believe there is a strong case= for just putting it in its own frame and eliminating some of the weird dep= endencies (see (c) above) between largest_acked and the timestamp fields.

Personally, I would recommend the following:
<= div>(1) Move timestamps into a separate frame.
(2) A host that re= ceives a timestamp frame MUST interpret a timestamp for a packet as an ackn= owledgement for that packet. Packet recievers MAY omit ack blocks for packe= ts for which a timestamp is in flight.
(3) (possibly) make timest= amps something negotiable (in each direction) at the start of a connection.= For example, a host may only want timestamps from its peer if it is using = delay-based congestion control.

Martin Duke
<= /div> --f403045f157425490405588bfc4b-- From nobody Wed Sep 6 14:35:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6A4126BF0 for ; Wed, 6 Sep 2017 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 tBoM8WR0Tdxf for ; Wed, 6 Sep 2017 14:34:59 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49085124239 for ; Wed, 6 Sep 2017 14:34:59 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id r85so10366315ywg.1 for ; Wed, 06 Sep 2017 14:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rg8WB/nykkMoKZmmn/W4ZG3IzzwoPl5OnjfEugRqf+g=; b=RrgyG+XzYJpNV9jHjjLrzyEfdNud3bfv9r6Z7LwTe2yaMuGIHnx+bDgxqvdrEwKhaU ZYk5VQGt48W1T+YP56qTuV6zQuYpPa9UUUcXu/KJQl/0qQfKuXsWLq/5FSU/CFIk7cD8 wP7uxSb6EDTbM8Y38sn2ttAEktZJWmjkQ+B9cq+T9liO/xXUmEpslhKLO5WdbN4bxTAx xU1VAT+o24g2ta9+N31/wORnlzceddVk43ssS4NWx9WwCwiWOnd0bdAan2VY8yR2jiHs Wn0SIAOYzkHAih9e+OAlloH6r79DUPsgNaAnDEQMlSmRczMDK45BYiVzL0NYjWn+oeoc ZbEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rg8WB/nykkMoKZmmn/W4ZG3IzzwoPl5OnjfEugRqf+g=; b=H4TIfJR9KMmE2e2g1ioMaeAGX6J3fhAeReUe3tB/Lc5fXl5WV+gCdsM8JckJ4xZ5I8 oqpMIXP6PqDk3SvhPglpaGrP1qHdj3PMjKjVRJOHb/Nm0QEQ21bO690cXSn+lgjJ3Zyd YmfDcCR1+XJ108hJWIfSlUSe9qQmWf+RqUPKloFu/A+ouHqENlwo9Zm3R3qV4yFbFk53 W1tIv/Lqo3Jr4JVOgX9qPlraSrH/pvG9P6lq7v4+NhONfZn7YQWcipdtrRCOZ4kM8j4V dEpFiF6LCyrEiqU6mLoYy5LCsSM+uMvGmnSfW7sMNL6WIFP1kMM9whgP24+sNvz41Mus To+w== X-Gm-Message-State: AHPjjUiZMygkIlzk+QHWqDgR4FCuAcawgX0Y4v/uUU8bkyt4n+1Y4xgQ 9vS0TlRQHw24rJ/gErbcGdEi5VSRdZmS X-Google-Smtp-Source: ADKCNb5P196WDqqNxh5RlGKxSiYjIRXhpz7Ws9p6Yv26kbi70CzOtxm8vamhcDJKptWZLLMFbKNZfO43joh0fQnTI14= X-Received: by 10.129.169.68 with SMTP id g65mr436178ywh.363.1504733698314; Wed, 06 Sep 2017 14:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Wed, 6 Sep 2017 14:34:57 -0700 (PDT) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD800ED6@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD800ED6@DGGEMM506-MBX.china.huawei.com> From: Jana Iyengar Date: Wed, 6 Sep 2017 14:34:57 -0700 Message-ID: Subject: Re: -05 drafts published - transport draft comment To: Roni Even Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c146206925e6005588c1dc5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 21:35:01 -0000 --94eb2c146206925e6005588c1dc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for pointing this out Roni, this is fixed now in the editors' version. On Sun, Sep 3, 2017 at 5:55 AM, Roni Even wrote: > Hi, > I noticed that public reset is till mentioned in section 5.7 and 7.7 > > Roni Even > > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson > > Sent: =D7=99=D7=95=D7=9D =D7=93 16 =D7=90=D7=95=D7=92=D7=95=D7=A1=D7=98= 2017 08:23 > > To: QUIC WG > > Subject: -05 drafts published > > > > You will see these coming through soon. > > > > There's never a good time to do this, but the editors agreed that it wa= s > about > > time. There are some larger changes in the pipe, so we thought that it > would > > be helpful to create a marker for implementations. > > --94eb2c146206925e6005588c1dc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for pointing this out Roni, this is fixed now in th= e editors' version.

On Sun, Sep 3, 2017 at 5:55 AM, Roni Even <= ;roni.even@huawei= .com> wrote:
Hi,
I noticed that public reset is till mentioned in section 5.7 and 7.7

Roni Even

> -----Original Message-----
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Martin Thomson
> Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 16 =D7=90=D7=95=D7=92=D7=95=D7=A1= =D7=98 2017 08:23
> To: QUIC WG
> Subject: -05 drafts published
>
> You will see these coming through soon.
>
> There's never a good time to do this, but the editors agreed that = it was about
> time.=C2=A0 There are some larger changes in the pipe, so we thought t= hat it would
> be helpful to create a marker for implementations.


--94eb2c146206925e6005588c1dc5-- From nobody Wed Sep 6 14:48:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3794D132709 for ; Wed, 6 Sep 2017 14:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 02r692ckoK2y for ; Wed, 6 Sep 2017 14:48:15 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D8E126E64 for ; Wed, 6 Sep 2017 14:48:15 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dpiB2-0004aw-2p for quic@ietf.org; Wed, 06 Sep 2017 23:48:12 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dpiAv-0002dx-7y for quic@ietf.org; Wed, 06 Sep 2017 17:48:01 -0400 Received: (qmail 18688 invoked from network); 6 Sep 2017 21:47:54 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.88]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Sep 2017 21:47:54 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <5fafb10e-1421-537e-bf8a-5fdfdd19b439@huitema.net> Date: Wed, 6 Sep 2017 14:47:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CC49D41C2E926EF508527D80" Content-Language: en-US Subject: Re: ACK Frame Issues X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYWea6pBBugJdVQWCV6zgcsND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23b3Paah+/lGVhJWiyrZbTxFARmtUrs5uctmY2 TZP5WVNivE12DAmihF4VaIn7LacuYOEkjsX7F8KmpUaZQHV+SU9tg6wnJ2lrZSUCZrKFYsG2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKrrXdhf8mmRqp8CWMEqUPffPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEezxXYxTHfP8tqGAUCwq+EP+pb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/MFo5Cu5rasaSY5V1uIBhCffOag26sJVU91vDlVZmVFHoHOPocIAQXCXdbljHVoU+TL v3Mz7HKrwpxO8UZg9F+1Q0pmjPr72MdmVGuYwG34EHPyRGIReZEOMjENzbJnsOROzniPhr9h/ZXD HUMrEuNtmlz3QrTC9Mv0U135LV5vp3B/3WCT/ywxqGyDcX7ymo81pn6M7II0pBZMP8Q2yl7HZ8cC 5NCzOtKFVG2OgcPUMeKVse1sVhWabI0/+PN3sILCmP4sL9m2Y1BvIAo6egCemilw+ioChJ5n7tfm eH2kchap9/JGM7LGxIWWH81zEGo= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 21:48:17 -0000 This is a multi-part message in MIME format. --------------CC49D41C2E926EF508527D80 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/6/2017 2:25 PM, Martin Duke wrote: > ... > > (1) *The spec sorely needs more normative text.* > > ... > > (b) There are four ways to treat acks in flight on which the spec is > silent: > =C2=A0 =C2=A0 (i) Do not repeat them in subsequent acks > =C2=A0 =C2=A0 (ii) Repeat them only if they do not require additional a= ck blocks > =C2=A0 =C2=A0 (iii) Repeat them only if they require /neither /addition= al ack > blocks nor longer block lengths. > =C2=A0 =C2=A0 (iv) Always repeat them until acked > Offline, Jana suggested that (iv) is what Google does, but you'd never > guess that. I settled on (ii), for what it's worth. Picoquic also does (vi). It provides redundancy, so if an ACK is lost the next ACK will still acknowledge the received packets. > ... > > (e) The spec is unclear if timestamps are sorted in order of arrival > or reverse order of arrival. At least it's unclear to me! BTW having > to sort new arrivals in both packet number and arrival order is > unpleasant. Picoquic does not attempt to sort arrivals, but maintain a SACK structure similar to the "SACK dashboard" specified in TCP. > > I don't think the spec should prohibit any of this behavior. However, > some normative text might indicate to implementors that they don't > really need to worry about some of this stuff. > > (2) *The relationship between timestamps and ack blocks needs a rethink= * > * > * > People are all over the map on this. On the implementer slack channel, > a lot of people are totally ignoring timestamps and don't think > they're useful. Jana seems to view as a purely advisory channel. On > the other hand, as issue #698 points out, a received timestamp means > the packet has arrived, and sending an ack block for it in the same > frame seems redundant. Yes. That syntax is wrong, because it creates a potential conflict. > > Finally, timestamps are a report with a completely different syntax. > /Especially/ if they are advisory, I believe there is a strong case > for just putting it in its own frame and eliminating some of the weird > dependencies (see (c) above) between largest_acked and the timestamp > fields. No. There would still be a conflict. For example, in Picoquic, receiving at ACK erases the data related to the acknowledged packet -- including the timestamps. If the proposed "timestamp frame" arrived after the ACK frame, its information would be ignored because the packet was already marked received and the data erased. > > Personally, I would recommend the following: > (1) Move timestamps into a separate frame. > (2) A host that receives a timestamp frame MUST interpret a timestamp > for a packet as an acknowledgement for that packet. Packet recievers > MAY omit ack blocks for packets for which a timestamp is in flight. > (3) (possibly) make timestamps something negotiable (in each > direction) at the start of a connection. For example, a host may only > want timestamps from its peer if it is using delay-based congestion > control. > My preference would be to have exactly one time stamp per ACK, corresponding to the time at which the "largest acknowledged" packet was received, and expressed as microseconds since the beginning of the connection. 24 bits is probably OK, as long as the RTT is lower than 16 sec. 32 bit would be fine for anything but inter-planetary communications= =2E -- Christian Huitema --=20 Christian Huitema --------------CC49D41C2E926EF508527D80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 9/6/2017 2:25 PM, Martin Duke wrote:
...

(1) The spec sorely needs more normative text.

...

(b) There are four ways to treat acks in flight on which the spec is silent:
    (i) Do not repeat them in subsequent acks
    (ii) Repeat them only if they do not require additional ack blocks
    (iii) Repeat them only if they require neither additional ack blocks nor longer block lengths.
    (iv) Always repeat them until acked
Offline, Jana suggested that (iv) is what Google does, but you'd never guess that. I settled on (ii), for what it's worth.

Picoquic also does (vi). It provides redundancy, so if an ACK is lost the next ACK will still acknowledge the received packets.

...

(e) The spec is unclear if timestamps are sorted in order of arrival or reverse order of arrival. At least it's unclear to me! BTW having to sort new arrivals in both packet number and arrival order is unpleasant.

Picoquic does not attempt to sort arrivals, but maintain a SACK structure similar to the "SACK dashboard" specified in TCP.

I don't think the spec should prohibit any of this behavior. However, some normative text might indicate to implementors that they don't really need to worry about some of this stuff.

(2) The relationship between timestamps and ack blocks needs a rethink

People are all over the map on this. On the implementer slack channel, a lot of people are totally ignoring timestamps and don't think they're useful. Jana seems to view as a purely advisory channel. On the other hand, as issue #698 points out, a received timestamp means the packet has arrived, and sending an ack block for it in the same frame seems redundant.

Yes. That syntax is wrong, because it creates a potential conflict.


Finally, timestamps are a report with a completely different syntax. Especially if they are advisory, I believe there is a strong case for just putting it in its own frame and eliminating some of the weird dependencies (see (c) above) between largest_acked and the timestamp fields.

No. There would still be a conflict. For example, in Picoquic, receiving at ACK erases the data related to the acknowledged packet -- including the timestamps. If the proposed "timestamp frame" arrived after the ACK frame, its information would be ignored because the packet was already marked received and the data erased.

Personally, I would recommend the following:
(1) Move timestamps into a separate frame.
(2) A host that receives a timestamp frame MUST interpret a timestamp for a packet as an acknowledgement for that packet. Packet recievers MAY omit ack blocks for packets for which a timestamp is in flight.
(3) (possibly) make timestamps something negotiable (in each direction) at the start of a connection. For example, a host may only want timestamps from its peer if it is using delay-based congestion control.


My preference would be to have exactly one time stamp per ACK, corresponding to the time at which the "largest acknowledged" packet was received, and expressed as microseconds since the beginning of the connection. 24 bits is probably OK, as long as the RTT is lower than 16 sec. 32 bit would be fine for anything but inter-planetary communications.

-- Christian Huitema
-- 
Christian Huitema
--------------CC49D41C2E926EF508527D80-- From nobody Wed Sep 6 22:37:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23361132D7F for ; Wed, 6 Sep 2017 22:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 HDgFGcG0uyC3 for ; Wed, 6 Sep 2017 22:36:59 -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 7C25B13219F for ; Wed, 6 Sep 2017 22:36:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOC12690; Thu, 07 Sep 2017 05:36:56 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 7 Sep 2017 06:36:55 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Thu, 7 Sep 2017 13:36:48 +0800 From: Roni Even To: Martin Thomson CC: QUIC WG Subject: RE: obsrvtaion on packet numbers Thread-Topic: obsrvtaion on packet numbers Thread-Index: AdMm5zHPD4iKjQeVQlG4Za1XZ0BzMf//nx0A//46kWA= Date: Thu, 7 Sep 2017 05:36:47 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59B0DAF8.0051, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 38bc455450b94b9303fc213635ddc9cb Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 05:37:01 -0000 SGkgTWFydGluLA0KSSBhbSBPSyB3aXRoIGxlYXZpbmcgaXQgYXMgaXMgYnV0IGhlcmUgYXJlIHNv bWUgb3RoZXIgbnVtYmVycy4gDQpWUiBvciBsaXZlIGZlZWQgb2YgdmlkZW8gZXZlbnRzICB1c2lu ZyAxNiBjYW1lcmFzICgzNjAgZGVncmVlIHZpZXcpIGF0IDRLIHJlc29sdXRpb24gMzAgZnBzIDI0 IGJpdCBwZXIgcGl4ZWwgMzAwOjEgY29tcHJlc3Npb24gd2lsbCByZXF1aXJlIGFib3V0IDMwME1i L3NlYyBpZiBteSBjYWxjdWxhdGlvbiBpcyBjb3JyZWN0LiAgaWYgYSBwYWNrZXQgaXMgYWJvdXQg MTIwMCBieXRlcyBvZiBtZWRpYSAodGhpcyBpcyAyNWsgcGFja2V0cyBwZXIgc2VjKSBpdCB3aWxs IGJlIGEgb3ZlciAyNCBob3VycyB0byByZWFjaCB0aGUgZW5kIGlmIHN0YXJ0aW5nIHBhY2tldCBu dW1iZXIgYXQgMl4zMi4gDQpHb2luZyB0byA4ayBhdCA2MGZwcyB3aWxsIHRha2UgbGVzcyB0aW1l IGJ1dCBJIGFzc3VtZSBpdCB3aWxsIHJ1biBpbnRvIG5ldHdvcmsgYmFuZHdpZHRoIGlzc3Vlcy4N ClJvbmkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gVGhv bXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NCj4gU2VudDog15nXldedwqDX kyAwNiDXodek15jXnteR16ggMjAxNyAxMzoyMQ0KPiBUbzogUm9uaSBFdmVuDQo+IENjOiBRVUlD IFdHDQo+IFN1YmplY3Q6IFJlOiBvYnNydnRhaW9uIG9uIHBhY2tldCBudW1iZXJzDQo+IA0KPiBI aSBSb25pLA0KPiANCj4gVGhlIHRleHQgYWJvdXQgdGhlIHNlbmRlciBjbGVhcmx5IG5lZWRzIHRv IGJlIHF1YWxpZmllZC4gIHMvdGhlIHNlbmRlci9hDQo+IHNlcnZlci8gaW4gdGhpcyBjYXNlIChJ J3ZlIG1hZGUgdGhhdCBjaGFuZ2UgYWxyZWFkeSkuDQo+IA0KPiBMZXQncyBqdXN0IGV4YW1pbmUg d2hhdCB0aGlzIGVudGFpbHMuICAyXjY0IHBhY2tldHMgaXMgYW4gYXdmdWwgbG90IG9mIHBhY2tl dHMsDQo+IGV2ZW4gYWNjb3VudGluZyBmb3IgdGhlIHJhbmRvbWl6ZWQgc3RhcnQgYW5kIGZyZXF1 ZW50IG5ldyBjb25uZWN0aW9uDQo+IElEc1sxXS4gIFNvIG1hbnkgdGhhdCB3ZSBtaWdodCBub3Qg bmVlZCB0byB3b3JyeSBhYm91dCB0aGlzIGhhcHBlbmluZyBmb3IgYQ0KPiB3aGlsZSAodGhhdCdz IDAuNSB0cmlsbGlvbiBwYWNrZXRzIHBlciBzZWNvbmQgZm9yIGEgc29saWQgeWVhciBpZiBJJ20g cmVhZGluZyB0aGUNCj4gbnVtYmVyIGNvcnJlY3RseSBvciA0IFBicHMsIHRoYXQncyB0aGUgb25l IHdpdGggMTUgemVyb3MpLg0KPiANCj4gU28gaXQncyBub3Qgb2J2aW91cyB0aGF0IHNwZWNpYWwg YXR0ZW50aW9uIGlzIG5lZWRlZCBoZXJlIG90aGVyIHRoYW4gd2hhdCBpcw0KPiB3cml0dGVuIChp LmUuLCBzdG9wIHNlbmRpbmcgcGFja2V0cykuICBXZSBjb3VsZCBhZHZpc2UgdGhlIHVzZSBvZg0K PiBDT05ORUNUSU9OX0NMT1NFLCBidXQgdGhlbiB3ZSBoYXZlIHRvIHNheSBzb21ldGhpbmcgYWJv dXQgd2hlbiB0bw0KPiBzZW5kIGl0LiAgQSBncmFjZWZ1bCBzaHV0ZG93biBpcyBldmVuIGJldHRl ciwgYnV0IHRoYXQncyBldmVuIG1vcmUNCj4gYW1vcnBob3VzIGFuZCBkaWZmaWN1bHQgdG8gcHJv dmlkZSBjb25jcmV0ZSBhZHZpY2UgYWJvdXQuICBCZXR0ZXIgdG8gbGVhdmUNCj4gdGhpcyBjb3Ju ZXIgdW5wYWludGVkIGluIG15IG9waW5pb24uDQo+IA0KPiBXaGF0J3MgbW9yZSwgaXQncyBjbGVh ciB0aGF0IGJvdGggc2lkZXMga25vdyB3aGF0IGlzIGdvaW5nIG9uLiAgT25jZSB0aGlzDQo+IG1h Z2ljIHZhbHVlIGlzIGhpdCwgdGhlbiBubyBtb3JlIHBhY2tldHMgd2lsbCBiZSBzZW50IGFuZCBi b3RoIHBlZXJzIGtub3cgaXQuDQo+IE5vIHJlYWwgbmVlZCBmb3IgYW55IHNpZ25hbGluZy4NCj4g DQo+IE5vdGUgdGhhdCB0aGlzIGlzbid0IGEgY29ubmVjdGlvbiBtaWdyYXRpb24gc2NlbmFyaW8u ICBBbnkgbmV3IGNvbm5lY3Rpb24NCj4gd291bGQgLSBhdCBiZXN0IC0gYmUgYWJsZSB0byByZXRh aW4gY3J5cHRvZ3JhcGhpYyBrZXlzLg0KPiBTdHJlYW0gc3RhdGUgd291bGQgaGF2ZSB0byBiZSBs b3N0Lg0KPiANCj4gWzFdIE9uIGF2ZXJhZ2UgbmV3IGNvbm5lY3Rpb24gSURzIHdvdWxkIGFsc28g Z2V0IHVzIGhlcmUgcXVpY2tlciBtYXliZSwNCj4gdGhvdWdoIGl0IHdvdWxkIHN0aWxsIHRha2Ug MjcyIHBlciBzZWNvbmQgZm9yIHRoZSBzYW1lIHllYXIuDQo+IA0KPiBPbiBXZWQsIFNlcCA2LCAy MDE3IGF0IDY6MTAgUE0sIFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb20+IHdyb3RlOg0K PiA+IEhpLA0KPiA+DQo+ID4gSSBoYXZlIHNvbWUgb2JzZXJ2YXRpb25zIG9uIHRoZSBuZXcgdGV4 dCBvbiBwYWNrZXQgbnVtYmVycw0KPiA+DQo+ID4NCj4gPg0KPiA+IOKAnEEgUVVJQyBlbmRwb2lu dCBNVVNUIE5PVCByZXVzZSBhIHBhY2tldCBudW1iZXIgd2l0aGluIHRoZSBzYW1lDQo+ID4gY29u bmVjdGlvbiAodGhhdCBpcywgdW5kZXIgdGhlIHNhbWUgY3J5cHRvZ3JhcGhpYyBrZXlzKS4gSWYg dGhlIHBhY2tldA0KPiA+IG51bWJlciBmb3Igc2VuZGluZyByZWFjaGVzIDJeNjQgLSAxLCB0aGUg c2VuZGVyIE1VU1QgY2xvc2UgdGhlDQo+ID4gY29ubmVjdGlvbiB3aXRob3V0IHNlbmRpbmcgYSBD T05ORUNUSU9OX0NMT1NFIGZyYW1lIG9yIGFueSBmdXJ0aGVyDQo+ID4gcGFja2V0czsgdGhlIHNl bmRlciBNQVkgc2VuZCBhIFN0YXRlbGVzcyBSZXNldCBwYWNrZXQgaW4gcmVzcG9uc2UgdG8NCj4g ZnVydGhlciBwYWNrZXRzIHRoYXQgaXQgcmVjZWl2ZXMu4oCdDQo+ID4NCj4gPg0KPiA+DQo+ID4g SSBwb3N0IHRoZW0gaGVyZSBhbmQgbm90IGluIGdpdGh1YiBzaW5jZSBJIGFtIG5vdCBzdXJlIHdo ZXJlIHRvIGRpc2N1c3MgaXQuDQo+ID4NCj4gPg0KPiA+DQo+ID4gMS4gICAgICAg4oCcdGhlIHNl bmRlciBNQVkgc2VuZCBhIFN0YXRlbGVzcyBSZXNldOKAnSDigJMgSSBiZWxpZXZlIHRoYXQgb25s eSBhDQo+ID4gc2VuZGVyIHdoaWNoIGlzIGEgc2VydmVyIGNhbiBkbyBpdC4NCj4gPg0KPiA+IDIu ICAgICAgIOKAnElmIHRoZSBwYWNrZXQgbnVtYmVyIGZvciBzZW5kaW5nIHJlYWNoZXMgMl42NCAt IDEs4oCm4oCdIEhlcmUgSSBhbQ0KPiA+IGNvbmZ1c2VkLiBJIHVuZGVyc3RhbmQgdGhhdCBzaW5j ZSB3cmFwIGFyb3VuZCBpcyBub3QgYWxsb3dlZCB0aGFuIHRoZQ0KPiA+IHNlbmRlciBjYW5ub3Qg c2VuZCBhIENPTk5FQ1RJT05fQ0xPU0Ugb3IgdXNlIHRoZSBJbW1lZGlhdGUgQ2xvc2UNCj4gPiB0 ZXJtaW5hdGlvbiBwcm9jZWR1cmUuIEkgYW0gbm90IHN1cmUgYWJvdXQgYXBwbGljYXRpb24gY2xv c2UNCj4gPiB0ZXJtaW5hdGlvbiBwcm9jZWR1cmUgc2luY2UgSSBhc3N1bWUgaXQgd2lsbCBhbHNv IHJlcXVpcmUgc29tZSBRVUlDDQo+ID4gbWVzc2FnZXMgdG8gY2xvc2UgY29ubmVjdGlvbi4gIE9u IHRoZSBvdGhlciBoYW5kIHRoZSBzZW5kZXIgbWF5IHdpc2gNCj4gPiB0byBjb250aW51ZSBzZW5k aW5nIHVzaW5nIGEgbmV3IGNvbm5lY3Rpb24sIHNvIGlzIHRoaXMgYSBjb25uZWN0aW9uDQo+ID4g bWlncmF0aW9uID8gSSBhc3N1bWUgdGhhdCB0aGUgc3RhdGUgb2YgdGhlIG9wZW4gc3RyZWFtcyBz aG91bGQgYmUNCj4gPiBrZXB0LiAgSSB0aGluayB0aGF0IHNvbWUgdGV4dCBpcyBtaXNzaW5nIGhl cmUgYW5kIGZvciB0aGUgY29ubmVjdGlvbg0KPiBtaWdyYXRpb24gcHJvY2VkdXJlLg0KPiA+DQo+ ID4NCj4gPg0KPiA+IFJvbmkgRXZlbg0KPiA+DQo+ID4NCg== From nobody Wed Sep 6 23:11:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3C132D92 for ; Wed, 6 Sep 2017 23:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 u0ynvHFZzas9 for ; Wed, 6 Sep 2017 23:11:52 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3CD132A05 for ; Wed, 6 Sep 2017 23:11:52 -0700 (PDT) Received: from mb.local ([IPv6:2601:647:4201:9721:791b:d5f7:f1a4:bca6]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v876Bko7053010 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 7 Sep 2017 06:11:47 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9721:791b:d5f7:f1a4:bca6] claimed to be mb.local Subject: Re: obsrvtaion on packet numbers To: Roni Even , Martin Thomson Cc: QUIC WG References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> From: joel jaeggli Message-ID: <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> Date: Wed, 6 Sep 2017 23:11:50 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 06:11:53 -0000 On 9/6/17 22:36, Roni Even wrote: > Hi Martin, > I am OK with leaving it as is but here are some other numbers. > VR or live feed of video events using 16 cameras (360 degree view) at 4K resolution 30 fps 24 bit per pixel 300:1 compression will require about 300Mb/sec if my calculation is correct. if a packet is about 1200 bytes of media (this is 25k packets per sec) it will be a over 24 hours to reach the end if starting packet number at 2^32. 2^32 isn't half of 2^64, it's half of 2^33. 25kpps is 2 billion odd packets a day whereas 2^64 is 1.84 * 10^19. > Going to 8k at 60fps will take less time but I assume it will run into network bandwidth issues. There are much larger flows. > Roni > >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: יו× ד 06 ספטמבר 2017 13:21 >> To: Roni Even >> Cc: QUIC WG >> Subject: Re: obsrvtaion on packet numbers >> >> Hi Roni, >> >> The text about the sender clearly needs to be qualified. s/the sender/a >> server/ in this case (I've made that change already). >> >> Let's just examine what this entails. 2^64 packets is an awful lot of packets, >> even accounting for the randomized start and frequent new connection >> IDs[1]. So many that we might not need to worry about this happening for a >> while (that's 0.5 trillion packets per second for a solid year if I'm reading the >> number correctly or 4 Pbps, that's the one with 15 zeros). >> >> So it's not obvious that special attention is needed here other than what is >> written (i.e., stop sending packets). We could advise the use of >> CONNECTION_CLOSE, but then we have to say something about when to >> send it. A graceful shutdown is even better, but that's even more >> amorphous and difficult to provide concrete advice about. Better to leave >> this corner unpainted in my opinion. >> >> What's more, it's clear that both sides know what is going on. Once this >> magic value is hit, then no more packets will be sent and both peers know it. >> No real need for any signaling. >> >> Note that this isn't a connection migration scenario. Any new connection >> would - at best - be able to retain cryptographic keys. >> Stream state would have to be lost. >> >> [1] On average new connection IDs would also get us here quicker maybe, >> though it would still take 272 per second for the same year. >> >> On Wed, Sep 6, 2017 at 6:10 PM, Roni Even wrote: >>> Hi, >>> >>> I have some observations on the new text on packet numbers >>> >>> >>> >>> “A QUIC endpoint MUST NOT reuse a packet number within the same >>> connection (that is, under the same cryptographic keys). If the packet >>> number for sending reaches 2^64 - 1, the sender MUST close the >>> connection without sending a CONNECTION_CLOSE frame or any further >>> packets; the sender MAY send a Stateless Reset packet in response to >> further packets that it receives.†>>> >>> >>> >>> I post them here and not in github since I am not sure where to discuss it. >>> >>> >>> >>> 1. “the sender MAY send a Stateless Reset†– I believe that only a >>> sender which is a server can do it. >>> >>> 2. “If the packet number for sending reaches 2^64 - 1,…†Here I am >>> confused. I understand that since wrap around is not allowed than the >>> sender cannot send a CONNECTION_CLOSE or use the Immediate Close >>> termination procedure. I am not sure about application close >>> termination procedure since I assume it will also require some QUIC >>> messages to close connection. On the other hand the sender may wish >>> to continue sending using a new connection, so is this a connection >>> migration ? I assume that the state of the open streams should be >>> kept. I think that some text is missing here and for the connection >> migration procedure. >>> >>> >>> >>> Roni Even >>> >>> > From nobody Wed Sep 6 23:12:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D2B132D96 for ; Wed, 6 Sep 2017 23:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hBkz7jY8t9Om for ; Wed, 6 Sep 2017 23:12:17 -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 ABAE6132A05 for ; Wed, 6 Sep 2017 23:12:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOC16912; Thu, 07 Sep 2017 06:12:15 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 7 Sep 2017 07:12:14 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Thu, 7 Sep 2017 14:12:07 +0800 From: Roni Even To: QUIC WG Subject: transport-05 stream blocked Thread-Topic: transport-05 stream blocked Thread-Index: AdMnn7lnV19hbp9oRTKFrJJulwM9AA== Date: Thu, 7 Sep 2017 06:12:07 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD801A86@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.153] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD801A86DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59B0E33F.0073, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 331917e119ac675b9a9c91eda2123136 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 06:12:19 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD801A86DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The following text is in 8.9 but should be in 8.10 describing STREAM_ID_NEE= DED "An endpoint MAY send a STREAM_BLOCKED frame for a stream that exceeds the maximum stream ID set by its peer (see Section 8.6). This does not open the stream, but informs the peer that a new stream was needed, but the stream limit prevented the creation of the stream." Roni --_000_6E58094ECC8D8344914996DAD28F1CCD801A86DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The following text is in 8.9 but should be in 8.10 de= scribing STREAM_ID_NEEDED

 “An endpoint MAY send a STREAM_BLOCKED= frame for a stream that exceeds

   the maximum stream ID set by its peer (s= ee Section 8.6).  This does

   not open the stream, but informs the pee= r that a new stream was

   needed, but the stream limit prevented = the creation of the stream.”

 

Roni

--_000_6E58094ECC8D8344914996DAD28F1CCD801A86DGGEMM506MBXchina_-- From nobody Wed Sep 6 23:18:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A921E132A85 for ; Wed, 6 Sep 2017 23:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EiNBmXbyxoN9 for ; Wed, 6 Sep 2017 23:18:01 -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 BC1DC132A05 for ; Wed, 6 Sep 2017 23:18:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOC17695; Thu, 07 Sep 2017 06:17:59 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 7 Sep 2017 07:17:58 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Thu, 7 Sep 2017 14:17:41 +0800 From: Roni Even To: joel jaeggli , Martin Thomson CC: QUIC WG Subject: RE: obsrvtaion on packet numbers Thread-Topic: obsrvtaion on packet numbers Thread-Index: AdMm5zHPD4iKjQeVQlG4Za1XZ0BzMf//nx0A//46kWCAAxI0AP//eStg Date: Thu, 7 Sep 2017 06:17:41 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD801AA0@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> In-Reply-To: <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59B0E497.0089, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 38bc455450b94b9303fc213635ddc9cb Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 06:18:03 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogam9lbCBqYWVnZ2xpIFtt YWlsdG86am9lbGphQGJvZ3VzLmNvbV0NCj4gU2VudDog15nXldedwqDXlCAwNyDXodek15jXnteR 16ggMjAxNyAwOToxMg0KPiBUbzogUm9uaSBFdmVuOyBNYXJ0aW4gVGhvbXNvbg0KPiBDYzogUVVJ QyBXRw0KPiBTdWJqZWN0OiBSZTogb2JzcnZ0YWlvbiBvbiBwYWNrZXQgbnVtYmVycw0KPiANCj4g T24gOS82LzE3IDIyOjM2LCBSb25pIEV2ZW4gd3JvdGU6DQo+ID4gSGkgTWFydGluLA0KPiA+IEkg YW0gT0sgd2l0aCBsZWF2aW5nIGl0IGFzIGlzIGJ1dCBoZXJlIGFyZSBzb21lIG90aGVyIG51bWJl cnMuDQo+ID4gVlIgb3IgbGl2ZSBmZWVkIG9mIHZpZGVvIGV2ZW50cyAgdXNpbmcgMTYgY2FtZXJh cyAoMzYwIGRlZ3JlZSB2aWV3KSBhdCA0Sw0KPiByZXNvbHV0aW9uIDMwIGZwcyAyNCBiaXQgcGVy IHBpeGVsIDMwMDoxIGNvbXByZXNzaW9uIHdpbGwgcmVxdWlyZSBhYm91dA0KPiAzMDBNYi9zZWMg aWYgbXkgY2FsY3VsYXRpb24gaXMgY29ycmVjdC4gIGlmIGEgcGFja2V0IGlzIGFib3V0IDEyMDAg Ynl0ZXMgb2YNCj4gbWVkaWEgKHRoaXMgaXMgMjVrIHBhY2tldHMgcGVyIHNlYykgaXQgd2lsbCBi ZSBhIG92ZXIgMjQgaG91cnMgdG8gcmVhY2ggdGhlIGVuZCBpZg0KPiBzdGFydGluZyBwYWNrZXQg bnVtYmVyIGF0IDJeMzIuDQo+IA0KPiAyXjMyIGlzbid0IGhhbGYgb2YgMl42NCwgaXQncyBoYWxm IG9mIDJeMzMuIDI1a3BwcyBpcyAyIGJpbGxpb24gb2RkIHBhY2tldHMgYSBkYXkNCj4gd2hlcmVh cyAyXjY0IGlzIDEuODQgKiAxMF4xOS4NCltSb25pIEV2ZW5dSSB3YXMgYmFzaW5nIGl0IG9uIHRo ZSB0ZXh0IGFzc3VtaW5nIHRoYXQgcGFja2V0IG51bWJlciBkb2VzIG5vdCBzdGFydCBhdCAwICAi IFRoZSBpbml0aWFsIHZhbHVlIGZvciBwYWNrZXQgbnVtYmVyIE1VU1QgYmUgc2VsZWN0ZWQgZnJv bSBhbiB1bmlmb3JtDQogICByYW5kb20gZGlzdHJpYnV0aW9uIGJldHdlZW4gMCBhbmQgMl4zMS0x ICINCj4gDQo+ID4gR29pbmcgdG8gOGsgYXQgNjBmcHMgd2lsbCB0YWtlIGxlc3MgdGltZSBidXQg SSBhc3N1bWUgaXQgd2lsbCBydW4gaW50byBuZXR3b3JrDQo+IGJhbmR3aWR0aCBpc3N1ZXMuDQo+ IA0KPiBUaGVyZSBhcmUgbXVjaCBsYXJnZXIgZmxvd3MuDQo+IA0KPiA+IFJvbmkNCj4gPg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBNYXJ0aW4gVGhvbXNvbiBb bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NCj4gPj4gU2VudDog15nXldedwqDXkyAw NiDXodek15jXnteR16ggMjAxNyAxMzoyMQ0KPiA+PiBUbzogUm9uaSBFdmVuDQo+ID4+IENjOiBR VUlDIFdHDQo+ID4+IFN1YmplY3Q6IFJlOiBvYnNydnRhaW9uIG9uIHBhY2tldCBudW1iZXJzDQo+ ID4+DQo+ID4+IEhpIFJvbmksDQo+ID4+DQo+ID4+IFRoZSB0ZXh0IGFib3V0IHRoZSBzZW5kZXIg Y2xlYXJseSBuZWVkcyB0byBiZSBxdWFsaWZpZWQuICBzL3RoZQ0KPiA+PiBzZW5kZXIvYSBzZXJ2 ZXIvIGluIHRoaXMgY2FzZSAoSSd2ZSBtYWRlIHRoYXQgY2hhbmdlIGFscmVhZHkpLg0KPiA+Pg0K PiA+PiBMZXQncyBqdXN0IGV4YW1pbmUgd2hhdCB0aGlzIGVudGFpbHMuICAyXjY0IHBhY2tldHMg aXMgYW4gYXdmdWwgbG90DQo+ID4+IG9mIHBhY2tldHMsIGV2ZW4gYWNjb3VudGluZyBmb3IgdGhl IHJhbmRvbWl6ZWQgc3RhcnQgYW5kIGZyZXF1ZW50IG5ldw0KPiA+PiBjb25uZWN0aW9uIElEc1sx XS4gIFNvIG1hbnkgdGhhdCB3ZSBtaWdodCBub3QgbmVlZCB0byB3b3JyeSBhYm91dA0KPiA+PiB0 aGlzIGhhcHBlbmluZyBmb3IgYSB3aGlsZSAodGhhdCdzIDAuNSB0cmlsbGlvbiBwYWNrZXRzIHBl ciBzZWNvbmQNCj4gPj4gZm9yIGEgc29saWQgeWVhciBpZiBJJ20gcmVhZGluZyB0aGUgbnVtYmVy IGNvcnJlY3RseSBvciA0IFBicHMsIHRoYXQncyB0aGUNCj4gb25lIHdpdGggMTUgemVyb3MpLg0K PiA+Pg0KPiA+PiBTbyBpdCdzIG5vdCBvYnZpb3VzIHRoYXQgc3BlY2lhbCBhdHRlbnRpb24gaXMg bmVlZGVkIGhlcmUgb3RoZXIgdGhhbg0KPiA+PiB3aGF0IGlzIHdyaXR0ZW4gKGkuZS4sIHN0b3Ag c2VuZGluZyBwYWNrZXRzKS4gIFdlIGNvdWxkIGFkdmlzZSB0aGUNCj4gPj4gdXNlIG9mIENPTk5F Q1RJT05fQ0xPU0UsIGJ1dCB0aGVuIHdlIGhhdmUgdG8gc2F5IHNvbWV0aGluZyBhYm91dA0KPiB3 aGVuDQo+ID4+IHRvIHNlbmQgaXQuICBBIGdyYWNlZnVsIHNodXRkb3duIGlzIGV2ZW4gYmV0dGVy LCBidXQgdGhhdCdzIGV2ZW4gbW9yZQ0KPiA+PiBhbW9ycGhvdXMgYW5kIGRpZmZpY3VsdCB0byBw cm92aWRlIGNvbmNyZXRlIGFkdmljZSBhYm91dC4gIEJldHRlciB0bw0KPiA+PiBsZWF2ZSB0aGlz IGNvcm5lciB1bnBhaW50ZWQgaW4gbXkgb3Bpbmlvbi4NCj4gPj4NCj4gPj4gV2hhdCdzIG1vcmUs IGl0J3MgY2xlYXIgdGhhdCBib3RoIHNpZGVzIGtub3cgd2hhdCBpcyBnb2luZyBvbi4gIE9uY2UN Cj4gPj4gdGhpcyBtYWdpYyB2YWx1ZSBpcyBoaXQsIHRoZW4gbm8gbW9yZSBwYWNrZXRzIHdpbGwg YmUgc2VudCBhbmQgYm90aCBwZWVycw0KPiBrbm93IGl0Lg0KPiA+PiBObyByZWFsIG5lZWQgZm9y IGFueSBzaWduYWxpbmcuDQo+ID4+DQo+ID4+IE5vdGUgdGhhdCB0aGlzIGlzbid0IGEgY29ubmVj dGlvbiBtaWdyYXRpb24gc2NlbmFyaW8uICBBbnkgbmV3DQo+ID4+IGNvbm5lY3Rpb24gd291bGQg LSBhdCBiZXN0IC0gYmUgYWJsZSB0byByZXRhaW4gY3J5cHRvZ3JhcGhpYyBrZXlzLg0KPiA+PiBT dHJlYW0gc3RhdGUgd291bGQgaGF2ZSB0byBiZSBsb3N0Lg0KPiA+Pg0KPiA+PiBbMV0gT24gYXZl cmFnZSBuZXcgY29ubmVjdGlvbiBJRHMgd291bGQgYWxzbyBnZXQgdXMgaGVyZSBxdWlja2VyDQo+ ID4+IG1heWJlLCB0aG91Z2ggaXQgd291bGQgc3RpbGwgdGFrZSAyNzIgcGVyIHNlY29uZCBmb3Ig dGhlIHNhbWUgeWVhci4NCj4gPj4NCj4gPj4gT24gV2VkLCBTZXAgNiwgMjAxNyBhdCA2OjEwIFBN LCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPg0KPiB3cm90ZToNCj4gPj4+IEhpLA0K PiA+Pj4NCj4gPj4+IEkgaGF2ZSBzb21lIG9ic2VydmF0aW9ucyBvbiB0aGUgbmV3IHRleHQgb24g cGFja2V0IG51bWJlcnMNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IOKAnEEgUVVJQyBlbmRw b2ludCBNVVNUIE5PVCByZXVzZSBhIHBhY2tldCBudW1iZXIgd2l0aGluIHRoZSBzYW1lDQo+ID4+ PiBjb25uZWN0aW9uICh0aGF0IGlzLCB1bmRlciB0aGUgc2FtZSBjcnlwdG9ncmFwaGljIGtleXMp LiBJZiB0aGUNCj4gPj4+IHBhY2tldCBudW1iZXIgZm9yIHNlbmRpbmcgcmVhY2hlcyAyXjY0IC0g MSwgdGhlIHNlbmRlciBNVVNUIGNsb3NlDQo+ID4+PiB0aGUgY29ubmVjdGlvbiB3aXRob3V0IHNl bmRpbmcgYSBDT05ORUNUSU9OX0NMT1NFIGZyYW1lIG9yIGFueQ0KPiA+Pj4gZnVydGhlciBwYWNr ZXRzOyB0aGUgc2VuZGVyIE1BWSBzZW5kIGEgU3RhdGVsZXNzIFJlc2V0IHBhY2tldCBpbg0KPiA+ Pj4gcmVzcG9uc2UgdG8NCj4gPj4gZnVydGhlciBwYWNrZXRzIHRoYXQgaXQgcmVjZWl2ZXMu4oCd DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBJIHBvc3QgdGhlbSBoZXJlIGFuZCBub3QgaW4g Z2l0aHViIHNpbmNlIEkgYW0gbm90IHN1cmUgd2hlcmUgdG8gZGlzY3Vzcw0KPiBpdC4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IDEuICAgICAgIOKAnHRoZSBzZW5kZXIgTUFZIHNlbmQgYSBT dGF0ZWxlc3MgUmVzZXTigJ0g4oCTIEkgYmVsaWV2ZSB0aGF0IG9ubHkgYQ0KPiA+Pj4gc2VuZGVy IHdoaWNoIGlzIGEgc2VydmVyIGNhbiBkbyBpdC4NCj4gPj4+DQo+ID4+PiAyLiAgICAgICDigJxJ ZiB0aGUgcGFja2V0IG51bWJlciBmb3Igc2VuZGluZyByZWFjaGVzIDJeNjQgLSAxLOKApuKAnSBI ZXJlIEkgYW0NCj4gPj4+IGNvbmZ1c2VkLiBJIHVuZGVyc3RhbmQgdGhhdCBzaW5jZSB3cmFwIGFy b3VuZCBpcyBub3QgYWxsb3dlZCB0aGFuDQo+ID4+PiB0aGUgc2VuZGVyIGNhbm5vdCBzZW5kIGEg Q09OTkVDVElPTl9DTE9TRSBvciB1c2UgdGhlIEltbWVkaWF0ZQ0KPiBDbG9zZQ0KPiA+Pj4gdGVy bWluYXRpb24gcHJvY2VkdXJlLiBJIGFtIG5vdCBzdXJlIGFib3V0IGFwcGxpY2F0aW9uIGNsb3Nl DQo+ID4+PiB0ZXJtaW5hdGlvbiBwcm9jZWR1cmUgc2luY2UgSSBhc3N1bWUgaXQgd2lsbCBhbHNv IHJlcXVpcmUgc29tZSBRVUlDDQo+ID4+PiBtZXNzYWdlcyB0byBjbG9zZSBjb25uZWN0aW9uLiAg T24gdGhlIG90aGVyIGhhbmQgdGhlIHNlbmRlciBtYXkgd2lzaA0KPiA+Pj4gdG8gY29udGludWUg c2VuZGluZyB1c2luZyBhIG5ldyBjb25uZWN0aW9uLCBzbyBpcyB0aGlzIGEgY29ubmVjdGlvbg0K PiA+Pj4gbWlncmF0aW9uID8gSSBhc3N1bWUgdGhhdCB0aGUgc3RhdGUgb2YgdGhlIG9wZW4gc3Ry ZWFtcyBzaG91bGQgYmUNCj4gPj4+IGtlcHQuICBJIHRoaW5rIHRoYXQgc29tZSB0ZXh0IGlzIG1p c3NpbmcgaGVyZSBhbmQgZm9yIHRoZSBjb25uZWN0aW9uDQo+ID4+IG1pZ3JhdGlvbiBwcm9jZWR1 cmUuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBSb25pIEV2ZW4NCj4gPj4+DQo+ID4+Pg0K PiA+DQoNCg== From nobody Thu Sep 7 05:11:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05911326FE for ; Thu, 7 Sep 2017 05:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 F-Sj4VT7gTgz for ; Thu, 7 Sep 2017 05:11:00 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F68132644 for ; Thu, 7 Sep 2017 05:10:58 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v87CAa0Q004709 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Sep 2017 14:10:36 +0200 Received: from [2001:bf0:c801:101:b551:51b7:a305:931a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dpvdS-0000h0-3h; Thu, 07 Sep 2017 14:10:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Unreliable Stream Support for QUIC From: "Philipp S. Tiesel" In-Reply-To: Date: Thu, 7 Sep 2017 14:10:48 +0200 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Bishop X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 12:11:02 -0000 > On 6. Sep 2017, at 20:30, Mike Bishop = wrote: >=20 > Reading through the draft, a few thoughts with no particular = organization. >=20 > Your proposal says that "Unreliable streams are subject to regular = congestion control. CLOSE_STREAM Frames are, like ACK and RST_STREAM = frames not subject to congestion control." I'm not sure where you're = finding that ACK and RST_STREAM frames are ignored by congestion = control, nor what it means for a frame not to be subject to congestion = control (which deals with packets). It might be that i got the congestion control draft wrong, but I thought = most control messages can even be sent if the congestion window or max = data are depleted. Besides that, what byte counts are used for CC seem really weird - as I = read it now, all bytes of packets count except =E2=80=9Cack only = frames=E2=80=9D (why not =E2=80=9Cack only packets?=E2=80=9D)=20 That reads for me that a packet containing only an ACK a is not subject = to congestion control, but a packet containing an ACK and a MAX_DATA = frame is subject to congestion control. I see no description of what can be sent if congestion window is = depleted at all. > I think in 5.3 you might want to expand on what you mean by "UDP-like = behavior." Perhaps something like "Unreliable streams prefer data loss = rather than delayed delivery due to retransmission. Applications which = need to avoid delays in the initial transmission would also need to = ensure=E2=80=A6" Ack > I really dislike the "zombie stream" issue. I'm not opposed to the = CLOSE_STREAM design, though I'd note that you could as easily say that a = STREAM frame bearing a FIN MUST be delivered reliably. If an = implementation wants to retransmit it without data, that would still be = valid. Either way, flow control requires that the final offset be = delivered reliably regardless of whether the data is. Either design solves the "zombie stream issue=E2=80=9D and provides = input needed for flow control. We did not add the FIN retransmission variant to the proposal appendix = because we ran out of bits to signal unreliable streams. > My other hesitation with a CLOSE_STREAM frame is that it increases the = overhead of an application using the stream-as-message abstraction. = (And using RST_STREAM NO_ERROR to indicate normal closure even more so = -- spending the bytes to transport an error code for every stream when = most of them won't need it seems excessive.) >=20 > As with #720, this adds even more stream properties. I am wondering = whether there's value in simply having a collected declaration of what a = stream's properties are, and how we might handle this with a minimum of = bytes per the previous thought. I totally agree.=20 I fear #720 does not go well with unreliable streams. It would be = sufficient to signal whether a stream is unreliable, bit also needs to = be retransmitted if lost and therefore introduce additional head of line = blocking. I guess the best solution would be having a =E2=80=9Cshort=E2=80=9D and = a =E2=80=9Clong=E2=80=9D stream frame header. Unreliable, unidirectional and a few other things can be signalled in a = =E2=80=9Clong" stream frame header. Streams can switch to the short = header format once packets carrying those flags got acknowledged. I = could also imagine to allow 32bit byte offsets only in the long header = and that way safe another bit. >=20 > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Philipp S. = Tiesel > Sent: Tuesday, September 5, 2017 9:30 AM > To: QUIC WG > Subject: Unreliable Stream Support for QUIC >=20 > Hi, >=20 > as promised, we just submitted a draft on unreliable streams for QUIC, = including support for partial reliability:=20 > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-tiesel-quic-unreliable-streams%2F&data=3D02%7C= 01%7Cmichael.bishop%40microsoft.com%7Cc14329b9f7ac46f21d6508d4f47b6f88%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636402258384840440&sdata=3D8DIkF= AbzCylWgO6%2FSB5EjBSSt50z5Pp51VJcOPWrits%3D&reserved=3D0 >=20 > TL;DR:=20 >=20 > - In principal, supporting unreliable streams in QUIC > does not require changes to the datft-05 wire-protocol. >=20 > - To get a nice interface between QUIC transport and the > application, we need one bit in the stream frame header > to indicate whether a stream is supposed to be reliable. >=20 >=20 > To give an application example, we did also draft how HTTP/2 over QUIC = can be extended to support partial reliability based on the draft above: > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-tiesel-quic-unreliable-http%2F&data=3D02%7C01%= 7Cmichael.bishop%40microsoft.com%7Cc14329b9f7ac46f21d6508d4f47b6f88%7C72f9= 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636402258384840440&sdata=3DhBcFX4o0= aE5Z8i4MZszSkLXh23DT7GjMFwW4FgrpAec%3D&reserved=3D0 >=20 > We have no finished implementation yet, but are working on one.=20 >=20 > AVE! > Philipp S. Tiesel / phils=E2=80=A6 >=20 AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' From nobody Thu Sep 7 12:02:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE8F132946 for ; Thu, 7 Sep 2017 12:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 dupj_IU3YU8y for ; Thu, 7 Sep 2017 12:02:29 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE14B13263F for ; Thu, 7 Sep 2017 12:02:28 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id q80so1793083ywg.2 for ; Thu, 07 Sep 2017 12:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3LJm39xRzIAzne+VfKm/HEta7cvyKje7LgdZBv+8NYY=; b=iZfTrry6khx+DCLpaze5qt9lOA721dokOlaaVWIk7e9oOIFx9P4fEc4OjZeqJzskSs LCb/S8gnlSBn/PGgNfRAWioUzM5aFBaLY65QOAX3+PkzcTb061tOgE6xryNBud0x8Feo E2nVVTjxlWLZO6Q5QPOiQ1Z6QmIhSXU+mx2LeHpA3imXsrmPmbleELYRbvC7k8VEPxft ywKSpebrmzi9uEblBZlqweXSgVkvRWpjk6Q44VcRi3Ox0S17UalwbDwlnNgIkUJ+rvta xWeTc1byUzrsDso2IcVco+FrJWl32/CgHTRPUrvzdQm5LogMZb9fwQCP4Xa/skHbQGiw 6RdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3LJm39xRzIAzne+VfKm/HEta7cvyKje7LgdZBv+8NYY=; b=RbcUfrHkdw6JHfHqAOejNkJCptnFT9yNytIigi5ttHEzdvzZJ0IiPG+XLCA93HRWQ8 gx/xbliRTric7cARsqsFCxkfMbGzPbiODDrbUn75CijXbVo0Eecce1VIPLa2IHWmJyXW xbJZe56TLy9Pt7FeTCcLFZr2nK+Dym2dFHvhFdjbtep1WW0poWUlALFnfpUs/AYc24BY RumymkbsayEimGdWLUM+gtdfE+7OSTs2HLI5whQ3vjoTSMJHyRvQhPVVtJ8AxZ2idfX7 xOWoOtk/ISb8klEdZHhyYgQHKxmCYaZMpZBDvwdi6AUUDfOsHWWue9zWImGm2sXA3tkB DJiA== X-Gm-Message-State: AHPjjUiQHPzI8iV0GGJIW7arahQkef1AG9pNoBWgYGkSfEGH1BNXh8Xp 2+YOlu6N++DenhLS2giLrKULGDztf69G X-Google-Smtp-Source: ADKCNb78kEuPLhX1HE6KtdF9wydXb1QxklYsa2dLluYgX5z8bdo/lWAakUkYzmgCMKAJbDXyErBerLrsj+fg3vZXqkE= X-Received: by 10.129.156.200 with SMTP id t191mr279091ywg.279.1504810947808; Thu, 07 Sep 2017 12:02:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Thu, 7 Sep 2017 12:02:27 -0700 (PDT) In-Reply-To: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> From: Jana Iyengar Date: Thu, 7 Sep 2017 12:02:27 -0700 Message-ID: Subject: Re: Split error codes in two To: Mike Bishop Cc: "Philipp S. Tiesel" , Victor Vasiliev , QUIC WG , Martin Thomson , Nick Harper Content-Type: multipart/alternative; boundary="94eb2c0c091a0019e305589e1a15" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 19:02:30 -0000 --94eb2c0c091a0019e305589e1a15 Content-Type: text/plain; charset="UTF-8" > > I'm less convinced that STOP_SENDING is HTTP-specific. To my mind, it's > the wire expression of a read_close(), just as RST_STREAM is the wire > expression of a write_close(). If we'd gone the advisory route, it would > be an HTTP-ism. (Or at least, the mandated behavior would be at the HTTP > layer.) However, if we think other applications aren't ever going to want > to close a read stream.... TCP allows for read_close() with shutdown(socket, RD), and it basically means that TCP will send a RST to subsequent incoming data on that socket from the peer. The expectation is that the application knows to not send data to a peer that has issued a read_close(). What we're talking about here is different than a read_close(), since it's an instruction to the peer to stop sending. This is only useful if I don't want to stop sending but want only the peer to stop sending.... and the driving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use case odd, but I don't know that there's really a need for this otherwise. I'm not very married on this point, but I'm wary of providing a knob that really doesn't have a strong use case. --94eb2c0c091a0019e305589e1a15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm less convinced that S= TOP_SENDING is HTTP-specific.=C2=A0 To my mind, it's the wire expressio= n of a read_close(), just as RST_STREAM is the wire expression of a write_c= lose().=C2=A0 If we'd gone the advisory route, it would be an HTTP-ism.= =C2=A0 (Or at least, the mandated behavior would be at the HTTP layer.)=C2= =A0 However, if we think other applications aren't ever going to want t= o close a read stream....

TCP allows for re= ad_close() with shutdown(socket, RD), and it basically means that TCP will = send a RST to subsequent incoming data on that socket from the peer. The ex= pectation is that the application knows to not send data to a peer that has= issued a read_close().

What we're talking abo= ut here is different than a read_close(), since it's an instruction to = the peer to stop sending. This is only useful if I don't want to stop s= ending but want only the peer to stop sending.... and the driving use case = was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use case odd, but I d= on't know that there's really a need for this otherwise. I'm no= t very married on this point, but I'm wary of providing a knob that rea= lly doesn't have a strong use case.

--94eb2c0c091a0019e305589e1a15-- From nobody Thu Sep 7 14:36:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE4F132FD5 for ; Thu, 7 Sep 2017 14:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 4dXuD1OYAdwm for ; Thu, 7 Sep 2017 14:36:20 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99862132F5C for ; Thu, 7 Sep 2017 14:36:20 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id r85so2808290ywg.1 for ; Thu, 07 Sep 2017 14:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=opm5KqvkZxYSjw0+alfGk683EZuKewLbgedoBtu0NZU=; b=VOQ+EDgI+Q+FR4ZGD20BzM3vDVuhzR905iv8Mpv9vP4aU4FkY2ul4kwWHw//nrNUmb FiWARy3o3+zgx4JDlUUh9ZFOx+xr09ZFq/Lqc2Uuu9IBXX6hZ2nrIa8l+3k4Rp4RbKMf hhL6loHyOjMzvuDqULVYy3DhYt6Uhnmb0cTbJ3sWaq/WCNH/mC1lZfnM2jEgbubVzNfi u2QyDgoV2XXnaXDBTmCPUS+DhiVNoSWJSxuaujGxIL+pSLlY4w/stHayNJ6SmEyY/063 g4Nu60FJKEQm5Kzej3t0QbuNc/cQE9+LIJFnr8YqHz/mlygima4CgynfaMIxHu2ih1xq FKJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=opm5KqvkZxYSjw0+alfGk683EZuKewLbgedoBtu0NZU=; b=QaLt0sAwK8u6s20Xomq5yRl+d2w0E6rS/T1sXvd6P6NJEDpv76uV8rdhukFIwy4v0S pdZYjh9aMLV17q7SA2wB1L8yfwt2C75oKRoSllaWZS/ECwDLzy5pH8/OXLynf7ENDsue vFzWho9PaHKBaM0WIqgm967G1im5UXxHSShMrZHNpuGqJ3ZroReoN27MJof2M4ar+7Yk 18IQBDGcO76+wNBLePNaXyyrcuiLaJx/z/B9hG7Shdygkpm9XK/Qf6Lm1NsiXgXsehCW AgYyg8mrsbxqXZ8dW7LhQQLybnB81911Lb3ER+S8Mg4BoEmw/cB5P98GasXa9FRFVRb1 QX4Q== X-Gm-Message-State: AHPjjUgOxqi6S712UOCDKh3AK7/2JHE6kmVbKXnq+QOmKyypdINWMNm8 ttRP2wSeVlrz2CP7egb6ZnIcftsF/NCJ X-Google-Smtp-Source: AOwi7QB/VvITXciwSO+SozYZ0fPA+qmar4OD6gb1NZksuElXCqkO6Ejc7cdbwx/ObT8VYohUgu9uqPS2cmHQLAoIkkc= X-Received: by 10.37.2.141 with SMTP id 135mr675003ybc.190.1504820179500; Thu, 07 Sep 2017 14:36:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Thu, 7 Sep 2017 14:36:18 -0700 (PDT) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD801AA0@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> <6E58094ECC8D8344914996DAD28F1CCD801AA0@DGGEMM506-MBX.china.huawei.com> From: Jana Iyengar Date: Thu, 7 Sep 2017 14:36:18 -0700 Message-ID: Subject: Re: obsrvtaion on packet numbers To: Roni Even Cc: joel jaeggli , Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="001a113d491040839b0558a0402b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 21:36:22 -0000 --001a113d491040839b0558a0402b Content-Type: text/plain; charset="UTF-8" Roni, > > > 2^32 isn't half of 2^64, it's half of 2^33. 25kpps is 2 billion odd > packets a day > > whereas 2^64 is 1.84 * 10^19. > [Roni Even]I was basing it on the text assuming that packet number does > not start at 0 " The initial value for packet number MUST be selected from > an uniform > random distribution between 0 and 2^31-1 " Even if your initial packet number is the largest possible, that is, 2^32, you still have > 2^63 numbers left. 2^64 = 2^63 + 2^63, which is the total number of possible packet numbers, and 2^63 + 2^32 is the number of packets you can send with this worst case initial packet number. - jana --001a113d491040839b0558a0402b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roni,

> 2^32 isn't ha= lf of 2^64, it's half of 2^33. 25kpps is 2 billion odd packets a day > whereas 2^64 is 1.84 * 10^19.
[Roni Even]I was basing it on the text assuming that packet number d= oes not start at 0=C2=A0 " The initial value for packet number MUST be= selected from an uniform
=C2=A0 =C2=A0random distribution between 0 and 2^31-1 "

Even if your initial packet number is the largest possibl= e, that is, 2^32, you still have > 2^63 numbers left.
2^64 =3D= 2^63 + 2^63, which is the total number of possible packet numbers, and 2^6= 3 + 2^32 is the number of packets you can send with this worst case initial= packet number.

- jana
--001a113d491040839b0558a0402b-- From nobody Thu Sep 7 14:45:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AFD132FDB for ; Thu, 7 Sep 2017 14:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=DzwUQu3s; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=IxV3ZyZ+ 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 vA2O31ZzMeiA for ; Thu, 7 Sep 2017 14:45:37 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C99132392 for ; Thu, 7 Sep 2017 14:45:37 -0700 (PDT) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v87Lj2vZ002646; Thu, 7 Sep 2017 14:45:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=23ZasHbpUYV64LHrdLFvD1zktHs2sMpryoCA19Fl7mg=; b=DzwUQu3sFQMQiENjNucXoVJSOl/G/lHMTahj4iIvxKu7GpVWSnHPuOVH5VJQlxo1MMBY jz5a7VopuLSRIOE6VTbHmJfhHx4GJj3euXKtbfRQ+vCIwDKolIAp4JDBTrhz5Mrw9nZy PyyOb96fFOVT1G5P3fFjo63ZXCqBEsZa7B8= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cue9q808d-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 07 Sep 2017 14:45:27 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 7 Sep 2017 17:45:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=23ZasHbpUYV64LHrdLFvD1zktHs2sMpryoCA19Fl7mg=; b=IxV3ZyZ+tvhQto5Sl3WcJeqb1JXcbor9oKHT6tTol5NMIfH9e3RJxH9m9Gk6lfT88BDlU1ev5TS0h6TpyNILez3t/3f+DyQbkXj31TeGvwWLO3RtDTCIOPUTb98GwgxcMjPSYXG9p0l3D15lTmZIxdfuZoElfTwu55pvNTKu76g= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1628.namprd15.prod.outlook.com (10.175.105.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Thu, 7 Sep 2017 21:45:24 +0000 Received: from DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) by DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) with mapi id 15.20.0013.018; Thu, 7 Sep 2017 21:45:24 +0000 From: Roberto Peon To: Jana Iyengar , Roni Even CC: joel jaeggli , QUIC WG , Martin Thomson Subject: Re: obsrvtaion on packet numbers Thread-Topic: obsrvtaion on packet numbers Thread-Index: AdMm5zHPD4iKjQeVQlG4Za1XZ0BzMQAEpzcAAChfTIAAATlfAAAANE2AACAVEwD//40yAA== Date: Thu, 7 Sep 2017 21:45:24 +0000 Message-ID: <57990B52-041C-4ABE-A8BC-CE5CF408718F@fb.com> References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> <6E58094ECC8D8344914996DAD28F1CCD801AA0@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::4:8713] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1628; 20:yJ5mtUqzWkfSVTJfV7nAKE2DI0oPdhwMbt8TELOoqZen99oqP02F/HT7owFclKTg+Dg+GMjdurOL6xtK9ujejodTrrH4fxkWsgon6tKeccNxSslL+nKDBjOnLINX7hezR50TD40F2rA1HyVtX96djWQh8S4UpB3HzCXb6UTbLTU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7410008c-581a-4e8e-d24e-08d4f639bf39 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR15MB1628; x-ms-traffictypediagnostic: DM5PR15MB1628: x-exchange-antispam-report-test: UriScan:(50582790962513)(211936372134217)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(920507026)(6041248)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1628; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1628; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(5660300001)(3280700002)(86362001)(97736004)(229853002)(83716003)(53546010)(68736007)(2906002)(6512007)(6486002)(6306002)(77096006)(102836003)(54906002)(3660700001)(6506006)(99286003)(54896002)(53936002)(6436002)(3480700004)(2950100002)(101416001)(54356999)(34040400001)(36756003)(189998001)(76176999)(6116002)(50986999)(6246003)(8936002)(14454004)(2900100001)(33656002)(8676002)(4326008)(81166006)(82746002)(478600001)(81156014)(93886005)(7736002)(39060400002)(106356001)(105586002)(25786009)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1628; H:DM5PR15MB1883.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_57990B52041C4ABEA8BCCE5CF408718Ffbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 21:45:24.6795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1628 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-07_12:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 21:45:39 -0000 --_000_57990B52041C4ABEA8BCCE5CF408718Ffbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uY3JldGVseTogMl42MyByZXByZXNlbnRzIDExLDY5MCw4NDAuOSB5ZWFycyBvZiBwYWNrZXRz IGF0IDI1a3Bwcywgb3IgMjkyIHllYXJzIGF0IDEgR3Bwcy4NCg0KRXZlbiBpZiBpdCB3YXMgb25s eSAyXjMyLCB0aG91Z2gsIGEgbmV3IGNvbm5lY3Rpb24gcGVyIGRheSB3b3VsZCBiZSByZWFzb25h Ymxl4oCUbWFueSBzaXRlcyB3b27igJl0IHdhbnQgdG8gbWFpbnRhaW4gY29ubmVjdGlvbiBzdGF0 ZSBmb3Igc3Vic3RhbnRpYWxseSBtb3JlIHRoYW4gYSBkYXkgKHBlb3BsZSB1cGRhdGUgYmluYXJp ZXMvY2hhbmdlIGNvbmZpZywgbmVlZCB0byBzaHVmZmxlIGxvYWQgYXJvdW5kIHRvIGRlYWwgd2l0 aCBsb2FkIGFzeW1tZXRyaWVzLCBldGMuKS4NCg0KLT1SDQoNCkZyb206IFFVSUMgPHF1aWMtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+ DQpEYXRlOiBUaHVyc2RheSwgU2VwdGVtYmVyIDcsIDIwMTcgYXQgMjozNiBQTQ0KVG86IFJvbmkg RXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb20+DQpDYzogam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9n dXMuY29tPiwgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogb2JzcnZ0YWlvbiBvbiBwYWNrZXQgbnVt YmVycw0KDQpSb25pLA0KDQo+IDJeMzIgaXNuJ3QgaGFsZiBvZiAyXjY0LCBpdCdzIGhhbGYgb2Yg Ml4zMy4gMjVrcHBzIGlzIDIgYmlsbGlvbiBvZGQgcGFja2V0cyBhIGRheQ0KPiB3aGVyZWFzIDJe NjQgaXMgMS44NCAqIDEwXjE5Lg0KW1JvbmkgRXZlbl1JIHdhcyBiYXNpbmcgaXQgb24gdGhlIHRl eHQgYXNzdW1pbmcgdGhhdCBwYWNrZXQgbnVtYmVyIGRvZXMgbm90IHN0YXJ0IGF0IDAgICIgVGhl IGluaXRpYWwgdmFsdWUgZm9yIHBhY2tldCBudW1iZXIgTVVTVCBiZSBzZWxlY3RlZCBmcm9tIGFu IHVuaWZvcm0NCiAgIHJhbmRvbSBkaXN0cmlidXRpb24gYmV0d2VlbiAwIGFuZCAyXjMxLTEgIg0K DQpFdmVuIGlmIHlvdXIgaW5pdGlhbCBwYWNrZXQgbnVtYmVyIGlzIHRoZSBsYXJnZXN0IHBvc3Np YmxlLCB0aGF0IGlzLCAyXjMyLCB5b3Ugc3RpbGwgaGF2ZSA+IDJeNjMgbnVtYmVycyBsZWZ0Lg0K Ml42NCA9IDJeNjMgKyAyXjYzLCB3aGljaCBpcyB0aGUgdG90YWwgbnVtYmVyIG9mIHBvc3NpYmxl IHBhY2tldCBudW1iZXJzLCBhbmQgMl42MyArIDJeMzIgaXMgdGhlIG51bWJlciBvZiBwYWNrZXRz IHlvdSBjYW4gc2VuZCB3aXRoIHRoaXMgd29yc3QgY2FzZSBpbml0aWFsIHBhY2tldCBudW1iZXIu DQoNCi0gamFuYQ0K --_000_57990B52041C4ABEA8BCCE5CF408718Ffbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbmNyZXRlbHk6IDJeNjMg cmVwcmVzZW50cyAxMSw2OTAsODQwLjkgeWVhcnMgb2YgcGFja2V0cyBhdCAyNWtwcHMsIG9yIDI5 MiB5ZWFycyBhdCAxIEdwcHMuPGJyPg0KPGJyPg0KRXZlbiBpZiBpdCB3YXMgb25seSAyXjMyLCB0 aG91Z2gsIGEgbmV3IGNvbm5lY3Rpb24gcGVyIGRheSB3b3VsZCBiZSByZWFzb25hYmxl4oCUbWFu eSBzaXRlcyB3b27igJl0IHdhbnQgdG8gbWFpbnRhaW4gY29ubmVjdGlvbiBzdGF0ZSBmb3Igc3Vi c3RhbnRpYWxseSBtb3JlIHRoYW4gYSBkYXkgKHBlb3BsZSB1cGRhdGUgYmluYXJpZXMvY2hhbmdl IGNvbmZpZywgbmVlZCB0byBzaHVmZmxlIGxvYWQgYXJvdW5kIHRvIGRlYWwgd2l0aCBsb2FkIGFz eW1tZXRyaWVzLA0KIGV0Yy4pLjxicj4NCjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBv biBiZWhhbGYgb2YgSmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+VGh1cnNkYXksIFNlcHRlbWJlciA3LCAyMDE3IGF0IDI6MzYgUE08YnI+DQo8Yj5U bzogPC9iPlJvbmkgRXZlbiAmbHQ7cm9uaS5ldmVuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj5qb2VsIGphZWdnbGkgJmx0O2pvZWxqYUBib2d1cy5jb20mZ3Q7LCBRVUlDIFdHICZsdDtx dWljQGlldGYub3JnJmd0OywgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWls LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IG9ic3J2dGFpb24gb24gcGFja2V0IG51 bWJlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJvbmksIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyAyXjMyIGlzbid0IGhhbGYgb2YgMl42 NCwgaXQncyBoYWxmIG9mIDJeMzMuIDI1a3BwcyBpcyAyIGJpbGxpb24gb2RkIHBhY2tldHMgYSBk YXk8YnI+DQomZ3Q7IHdoZXJlYXMgMl42NCBpcyAxLjg0ICogMTBeMTkuPGJyPg0KW1JvbmkgRXZl bl1JIHdhcyBiYXNpbmcgaXQgb24gdGhlIHRleHQgYXNzdW1pbmcgdGhhdCBwYWNrZXQgbnVtYmVy IGRvZXMgbm90IHN0YXJ0IGF0IDAmbmJzcDsgJnF1b3Q7IFRoZSBpbml0aWFsIHZhbHVlIGZvciBw YWNrZXQgbnVtYmVyIE1VU1QgYmUgc2VsZWN0ZWQgZnJvbSBhbiB1bmlmb3JtPGJyPg0KJm5ic3A7 ICZuYnNwO3JhbmRvbSBkaXN0cmlidXRpb24gYmV0d2VlbiAwIGFuZCAyXjMxLTEgJnF1b3Q7PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5FdmVuIGlmIHlvdXIgaW5pdGlhbCBwYWNrZXQgbnVtYmVyIGlzIHRoZSBsYXJnZXN0IHBvc3Np YmxlLCB0aGF0IGlzLCAyXjMyLCB5b3Ugc3RpbGwgaGF2ZSAmZ3Q7IDJeNjMgbnVtYmVycyBsZWZ0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ml42 NCA9IDJeNjMgJiM0MzsgMl42Mywgd2hpY2ggaXMgdGhlIHRvdGFsIG51bWJlciBvZiBwb3NzaWJs ZSBwYWNrZXQgbnVtYmVycywgYW5kIDJeNjMgJiM0MzsgMl4zMiBpcyB0aGUgbnVtYmVyIG9mIHBh Y2tldHMgeW91IGNhbiBzZW5kIHdpdGggdGhpcyB3b3JzdCBjYXNlIGluaXRpYWwgcGFja2V0IG51 bWJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBqYW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_57990B52041C4ABEA8BCCE5CF408718Ffbcom_-- From nobody Thu Sep 7 15:29:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67572132F6C for ; Thu, 7 Sep 2017 15:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 og3XgdmyLtMe for ; Thu, 7 Sep 2017 15:29:15 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8AD6132F6D for ; Thu, 7 Sep 2017 15:29:12 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s62so3088977ywg.0 for ; Thu, 07 Sep 2017 15:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y9RrfuXBQMua2EkYgKv7/69fqM0FxYbDaMPT+jun+j8=; b=gAklHQXX2dmp0ISouTDaenUoM9Thn1aI7b84HU7IiIdJLquGk2RxeN2KQp6pmGyN0b YkmpYItpmyLzSVydcyNKazPM4XJmJuMFV1xNlpnx6E8SpfxJ5zn4oqG0DaLvgkjeddhY 0/7Xik3LFyBFJnL/MQlS1UFj1b83fZWFFj4nKuFUrSAQPNaIpgrNiOEz4sO5CikY5Xml wIYJx7CKYHGQvJvxL5RZPavpGVloDYEo37s6bVAXrtFebla8ox1LdQ+llpTE6rtU3cw1 ukIvzTcH1NlkFHPjx6ZE6TZwmD9Y7UsWE3tEFb0aVY4RtXCL5kEAeS0+FKhDJtE3FIXY OAFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y9RrfuXBQMua2EkYgKv7/69fqM0FxYbDaMPT+jun+j8=; b=pAoRqsFkxuf0lTOZc/sljMx2CaWBluN90bX8M1vKYuX9cRHElzPS5YvxYbTDWS7DHa ZvrGEHFEgoe1jyPnodV1Z2qerBNsGGSCfNHUSirOhUU5iV+QK9LOwqDuiRNKmHDFmDKE JmW3sXTGrHiZcEnfcpNwxfo6q4KmTTe7j0wn1WkReTrjOGOc8NBi8zpMW30sD1N4jSUZ hB5yjj0PxrwjXhXHikxs9X9uYmgzwyOYFvQeRTUti/PBvGfqy5OOg0KQ3q9+37m6tx+h kv5CuFF4rvBXKToZYnmIGsqp+6ShPREZfPTq8V24pStG1qXk5I0wflYxTV9KVp6n4i2j NQMw== X-Gm-Message-State: AHPjjUiydSBmqhbdCf3N1PbM30dAVGf8/qrvQCbvxFjIf9KdZToxlCvq Os19ewD40mqtYxEtsnWv2e9AQUkyDee7JdE= X-Google-Smtp-Source: ADKCNb4jYmkEe9uHkOdVhGLHVq50mHhu+tjPqXUUWi+19vzQGqh635WCUtAhAZbzUNkk1ovRuaU+w3y4AkT4mTXgJWY= X-Received: by 10.37.171.202 with SMTP id v68mr799455ybi.258.1504823351723; Thu, 07 Sep 2017 15:29:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Thu, 7 Sep 2017 15:29:10 -0700 (PDT) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD801A86@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD801A86@DGGEMM506-MBX.china.huawei.com> From: Jana Iyengar Date: Thu, 7 Sep 2017 15:29:10 -0700 Message-ID: Subject: Re: transport-05 stream blocked To: Roni Even Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a11e67b3454ee2c0558a0fd29" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 22:29:16 -0000 --001a11e67b3454ee2c0558a0fd29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the catch, Roni. I'll fix this. On Wed, Sep 6, 2017 at 11:12 PM, Roni Even wrote: > Hi, > > The following text is in 8.9 but should be in 8.10 describing > STREAM_ID_NEEDED > > =E2=80=9CAn endpoint MAY send a STREAM_BLOCKED frame for a stream that e= xceeds > > the maximum stream ID set by its peer (see Section 8.6). This does > > not open the stream, but informs the peer that a new stream was > > needed, but the stream limit prevented the creation of the stream.=E2= =80=9D > > > > Roni > --001a11e67b3454ee2c0558a0fd29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the catch, Roni. I'll fix this.

On Wed, Sep 6, 2017 at = 11:12 PM, Roni Even <roni.even@huawei.com> wrote:

Hi,

The following text is in 8.9 but= should be in 8.10 describing STREAM_ID_NEEDED

=C2=A0=E2=80=9CAn endpoint MA= Y send a STREAM_BLOCKED frame for a stream that exceeds

=C2=A0=C2=A0 the maximum stream = ID set by its peer (see Section 8.6).=C2=A0 This does<= /p>

=C2=A0=C2=A0 not open the stream= , but informs the peer that a new stream was

=C2=A0=C2=A0 needed, but the stream limit prevented = the creation of the stream.=E2=80=9D

=C2=A0

Roni


--001a11e67b3454ee2c0558a0fd29-- From nobody Thu Sep 7 15:51:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06590132025 for ; Thu, 7 Sep 2017 15:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 FJlmEyIY7PoQ for ; Thu, 7 Sep 2017 15:51:23 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C483112895E for ; Thu, 7 Sep 2017 15:51:23 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id v72so954253ywa.3 for ; Thu, 07 Sep 2017 15:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hD2afuqixAUKFIgNhLfmtBRMbBP5tKCIkUirpdb+Fxo=; b=C1qB1XLVqOYrBLDWcu6Uv87xtLZGwJtH1rxhi0De4a/KMPrPsMnAvuKWF/+YuSWF00 NULuZj16c78E6DXAfvlLaJmsy3RNQt4tCVdXSLX7P/qzvd9qpTyvMljDpHa1qHnn5Pj4 1n6EGYnDRAI+etPB1bOXm7Ye3Vb08/P2IoaOzZ9gn0QrzVXC5yQfwRgjwO6tPp9sK4pY 6wy3IAGTg/yb4Qa9kWZaYeQbVSA8jkQB9WJcugNvZXNploNHohSpdfgV339PJdThQ0AO OIdFF2FEooc6wqXK5Gpca7iSbU9Keo8Iz40on+3CtCIrlgc0RJNDh1Kx/lUOzEXyt0gD wtRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hD2afuqixAUKFIgNhLfmtBRMbBP5tKCIkUirpdb+Fxo=; b=juWIiOyx2Vkw4J1D7Y+5A99HB0o8cOQzqppFosUhh/ndebKZLAe8nQ3CGLpJPdV6zv ItqOkxOjC5jsBPZW5PyK+3YQ/MRP6PSDQMNAWSnWdl24wcd6pXgkDoWlCHaJ+3fhiBEP oX6XuITHU0wZI5e2PCjfku8IcmFwPotoWmMgKwZMy5VgKFKjZw2S+y74l2Q18x9aYVSy 53LhKXuY0Y/GXycgj9emnVLrHc67DPDK1iuutApMu0eZ5yobzyd9hI9QBQ7BbZV2hZ5H EOrzlGlXC6gYEWRa0Rr5CBUbVlsYNfsFsLHBr6kpygh678HXV8cQRu/6UZs8d628tuxL Wy+g== X-Gm-Message-State: AHPjjUhB7gkeZpAmbnr7rVnZF/U6M9Y/aa7p5lsVWP1nXD1lPWrOKUH2 AdlomPG0eDInAE2SooyPSPXJQYGMhq/zKxQ= X-Google-Smtp-Source: ADKCNb4ju9ftWaUkYjQecv1dX0vQB6QG07vT6RNl+1bSvDHZW6NGvqjmnpcG5NeTVpdqYsTCP39IXCfTUNFa9aIto0M= X-Received: by 10.37.248.32 with SMTP id u32mr796518ybd.137.1504824682637; Thu, 07 Sep 2017 15:51:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Thu, 7 Sep 2017 15:51:22 -0700 (PDT) In-Reply-To: <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net> References: <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net> From: Jana Iyengar Date: Thu, 7 Sep 2017 15:51:22 -0700 Message-ID: Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045da54ea8d7e80558a14cf5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 22:51:27 -0000 --f403045da54ea8d7e80558a14cf5 Content-Type: text/plain; charset="UTF-8" > > If we assume that a clear text ACK cannot acknowledge encrypted packets, > 0-RTT data packets cannot be acknowledged before the connection is > established. The sender can thus send at most an initial window. > > From a congestion control point of view, how should "reset after 0-RTT > reject" differ from starting a new connection? > I wouldn't do anything different with the controller. The sender is not going to receive acks for these packets, so it's best to do a clean slate and start again with the initial window. The sender *could* do something more complicated, like wait "a while" to let the network drain, but without knowing what network bandwidth is, the sender would still be in the dark about how long to wait. Any wait time here will be wrong, just as wrong as the initial window. So, I would reset the controller's state to initial state. --f403045da54ea8d7e80558a14cf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we assume= that a clear text ACK cannot acknowledge encrypted packets, 0-RTT data packets cannot be acknowledged before the connection is established. The sender can thus send at most an initial window.

From a congestion control point of view, how=C2=A0should "reset = after 0-RTT reject" differ from starting a new connection?=C2=A0

I=C2=A0 wouldn't do anything= different with the controller. The sender is not going to receive acks for= these packets, so it's best to do a clean slate and start again with t= he initial window. The sender *could* do something more complicated, like w= ait "a while" to let the network drain, but without knowing what = network bandwidth is,=C2=A0 the sender would still be in the dark about how= long to wait. Any wait time here will be wrong, just as wrong as the initi= al window. So, I would reset the controller's state to initial state.
--f403045da54ea8d7e80558a14cf5-- From nobody Thu Sep 7 16:26:23 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7D313302B for ; Thu, 7 Sep 2017 16:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=S/LDYOY2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Air87B8Q 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 8XXLgmavjaA4 for ; Thu, 7 Sep 2017 16:26:19 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0A1133021 for ; Thu, 7 Sep 2017 16:26:19 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v87NO7CQ001808; Thu, 7 Sep 2017 16:26:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=WBt8MSZgCYL6lXe/OboUZ7Dy3va3dx+XIOwNwbVM8qo=; b=S/LDYOY2CyN8PeordqCngvox2z+TyrVG3Q3yUpTzE4hxys3l1aVVr7FNnZudNZarXFts JOaMdcF1mHtbO7Bxma1iDIDTMBi3itOcYtpsRFI4gSogHwQlQDLSlrVoShnIMF5oyCcJ 9K3DuUK5eCJ/DQSx26gX0CYblkqef/MWRyk= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cubxhs05u-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 07 Sep 2017 16:26:16 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 7 Sep 2017 19:26:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WBt8MSZgCYL6lXe/OboUZ7Dy3va3dx+XIOwNwbVM8qo=; b=Air87B8QqLdM/6vOHjZF9XiVCb6q2XuT0zUsJMEoKf67+X3EZ0WQwXIpFnSnKUygtHfiIP8Y7Yfxm19+xqx8ol+3W/fvUJXmO1vn5NtOrN1AKtBTDUV/Kt6iMWeTqbmtLL1NXt0XZdurimz/9if5PoxJTVmg5bL2HS9fg1k7jU4= Received: from DM5PR15MB1449.namprd15.prod.outlook.com (10.173.225.19) by DM5PR15MB1676.namprd15.prod.outlook.com (10.175.111.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Thu, 7 Sep 2017 23:25:53 +0000 Received: from DM5PR15MB1449.namprd15.prod.outlook.com ([10.173.225.19]) by DM5PR15MB1449.namprd15.prod.outlook.com ([10.173.225.19]) with mapi id 15.20.0035.010; Thu, 7 Sep 2017 23:25:53 +0000 From: Subodh Iyengar To: Jana Iyengar , Mike Bishop CC: "Philipp S. Tiesel" , QUIC WG , "Martin Thomson" , Nick Harper , Victor Vasiliev Subject: Re: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn+yyrdzIw/mkyM1giG213Fj6KmFGeAgAASp4CAAAOOAIAA0yCAgAAOnACAAAMMAIAAAK4AgACHAwCAAJELAIABpR2AgABGp/M= Date: Thu, 7 Sep 2017 23:25:53 +0000 Message-ID: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:32a2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1676; 20:fD0DAgfEPHAyLsj4N0+HSYj4TzZhRTx895oJvCWMETaorlMMjNqQYM/NRqG4WaS/PTTtt++N9FC3XljdMXzp1oJaRHX5w5A5ntJT6CRGUaoNjsGQIxKpg0RQrFjdPZxdRH15GS7BguQKqjeD0jn7gMipl/PXNYIKv6DfEzMdlDo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fc1ffb3f-5e3c-4f5b-d5f1-08d4f647c87d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR15MB1676; x-ms-traffictypediagnostic: DM5PR15MB1676: x-exchange-antispam-report-test: UriScan:(278428928389397)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(920507026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1676; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1676; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(34040400001)(77096006)(8666007)(54906002)(6506006)(86362001)(105586002)(55016002)(14454004)(5660300001)(53936002)(106356001)(54896002)(9686003)(99286003)(19627405001)(6246003)(53546010)(229853002)(2561002)(93886005)(68736007)(39060400002)(2906002)(2950100002)(97736004)(6436002)(478600001)(76176999)(54356999)(101416001)(7736002)(6116002)(8676002)(2900100001)(3280700002)(3660700001)(8936002)(50986999)(189998001)(1511001)(74316002)(25786009)(2421001)(33656002)(81156014)(102836003)(81166006)(4326008)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1676; H:DM5PR15MB1449.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR15MB14497BB2F1971C5965882875B6940DM5PR15MB1449namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 23:25:53.1945 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1676 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-07_14:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:26:21 -0000 --_000_DM5PR15MB14497BB2F1971C5965882875B6940DM5PR15MB1449namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If an app wanted to send both the stop sending and the reset stream, would = it have to wait till stop sending was sent on the wire before sending reset= streams? For example a API might reasonably be something like transport->write(StopSendingFrame) transport->reset(); If the app calls reset, then the transport might dump all data associated w= ith the stream immediately so the stop sending might never even be sent. How do people intend to use stop sending from the app protocols that don't = send RST in response to RST? Subodh ________________________________ From: QUIC on behalf of Jana Iyengar Sent: Thursday, September 7, 2017 12:02:27 PM To: Mike Bishop Cc: Philipp S. Tiesel; QUIC WG; Martin Thomson; Nick Harper; Victor Vasilie= v Subject: Re: Split error codes in two I'm less convinced that STOP_SENDING is HTTP-specific. To my mind, it's th= e wire expression of a read_close(), just as RST_STREAM is the wire express= ion of a write_close(). If we'd gone the advisory route, it would be an HT= TP-ism. (Or at least, the mandated behavior would be at the HTTP layer.) = However, if we think other applications aren't ever going to want to close = a read stream.... TCP allows for read_close() with shutdown(socket, RD), and it basically mea= ns that TCP will send a RST to subsequent incoming data on that socket from= the peer. The expectation is that the application knows to not send data t= o a peer that has issued a read_close(). What we're talking about here is different than a read_close(), since it's = an instruction to the peer to stop sending. This is only useful if I don't = want to stop sending but want only the peer to stop sending.... and the dri= ving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use cas= e odd, but I don't know that there's really a need for this otherwise. I'm = not very married on this point, but I'm wary of providing a knob that reall= y doesn't have a strong use case. --_000_DM5PR15MB14497BB2F1971C5965882875B6940DM5PR15MB1449namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If an app wanted to send both the stop sending and the reset stream, wou= ld it have to wait till stop sending was sent on the wire before sending re= set streams? For example a API might reasonably be something like


   transport->write(StopSendingFrame)

   transport->reset();


If the app calls reset, then the transport might dump all data associate= d with the stream immediately so the stop sending might never even be sent.=


How do people intend to use stop sending from the app protocols that don= 't send RST in response to RST?


Subodh

From: QUIC <quic-bounces= @ietf.org> on behalf of Jana Iyengar <jri@google.com>
Sent: Thursday, September 7, 2017 12:02:27 PM
To: Mike Bishop
Cc: Philipp S. Tiesel; QUIC WG; Martin Thomson; Nick Harper; Victor = Vasiliev
Subject: Re: Split error codes in two
 
I'm less convinced that STOP_SENDING is HTTP-specific.  To my mind, it= 's the wire expression of a read_close(), just as RST_STREAM is the wire ex= pression of a write_close().  If we'd gone the advisory route, it woul= d be an HTTP-ism.  (Or at least, the mandated behavior would be at the HTTP layer.)  However, if we think other app= lications aren't ever going to want to close a read stream....

TCP allows for read_close() with shutdown(socket, RD), and it basicall= y means that TCP will send a RST to subsequent incoming data on that socket= from the peer. The expectation is that the application knows to not send d= ata to a peer that has issued a read_close().

What we're talking about here is different than a read_close(), since = it's an instruction to the peer to stop sending. This is only useful if I d= on't want to stop sending but want only the peer to stop sending.... and th= e driving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use case odd, but I don't know that there's r= eally a need for this otherwise. I'm not very married on this point, but I'= m wary of providing a knob that really doesn't have a strong use case.

--_000_DM5PR15MB14497BB2F1971C5965882875B6940DM5PR15MB1449namp_-- From nobody Thu Sep 7 16:42:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91EB132FC4 for ; Thu, 7 Sep 2017 16:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 6kUZGknbRuXX for ; Thu, 7 Sep 2017 16:42:54 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD46F13208E for ; Thu, 7 Sep 2017 16:42:54 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id q80so3378134ywg.2 for ; Thu, 07 Sep 2017 16:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LwILJeclmwB9I5GJNS6FlLh7IvJoF6c7UqShAgnsezg=; b=TN/gUAeuaJsTbMI0BcV/aFLIKdw+9/2dKTLvvo5F75kNkRZWwdhZPSWxRQ6xTGVkUx lnvzTbTNcxuFLTa/dD3b2RP7RBYLaAna+r8XJDehzkqfPbFRoFzsnh3zZcq9VzZtj5+l y+5AJFYFLJ4wI15h1gaw0P14K4I6CjUpW7QkpckPOf21dNzwDakN1tSDBqDwux9PtGGH QKcKvkAZ1QEKAc4yM9zMncvISAKwM/Gy3xCHyiFetV/eghrAk8Fj4IEkuJtQYyUw8Tcv jSRrYkdBf05+3dTPbrJEa8b+4NGviUwtyaT0nu0Yi4iQQp1BDTQVmxYRUEFz0/m4+8BR l74A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LwILJeclmwB9I5GJNS6FlLh7IvJoF6c7UqShAgnsezg=; b=cwXy8kLFnsfV9Pg+yT7ze+ti7nIQcG85HDloG00U3iqd3/SAJQFfz4BEL6qttv0XGy mI1V7eixQZQaC+dleCUYh/1f+dGnzeSMMNLn9Z92WcI+kRtR4dC04jFHb76JZeI+MIDG jaYxQVetaW/YCdgFq5BxDvIror60F0bsI7UORRl/msUyM7jV4FGnkN2do4RAOs+f5383 ETJ3/ixAyjqB1mBMJp2UUt/x+HvtTVmWWDG+pkPhCjPyxZKf6QS21Z4z84WCzHKNiXvn CL4lf3Dv/gkxV89u9SaNZFBXdznZ9nEukmiL48Oa5kaW2TYWrw34HIbnjMVMSJhddKqY jKPQ== X-Gm-Message-State: AHPjjUjuaioF5sogpawNVVf7dDxU0ew38I6fyPDfWHon4rqWs0AXac+O 9C/BCR30/65C55ZCfhzc3AiRTBnHlxKq X-Google-Smtp-Source: ADKCNb6A2hatiPGy/TBsSdwvWtNx2H7YiZHfbW4w+I2cV6GE1crkrQLqqcCot+2H418sfyPsKVQG1HVwYN4ZYpkYFSE= X-Received: by 10.129.79.200 with SMTP id d191mr948977ywb.162.1504827773697; Thu, 07 Sep 2017 16:42:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Thu, 7 Sep 2017 16:42:52 -0700 (PDT) In-Reply-To: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> From: Jana Iyengar Date: Thu, 7 Sep 2017 16:42:52 -0700 Message-ID: Subject: Re: Split error codes in two To: Subodh Iyengar Cc: Mike Bishop , "Philipp S. Tiesel" , QUIC WG , Martin Thomson , Nick Harper , Victor Vasiliev Content-Type: multipart/alternative; boundary="001a114dd166e6ae230558a2048f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:42:57 -0000 --001a114dd166e6ae230558a2048f Content-Type: text/plain; charset="UTF-8" So, a RST_STREAM is supposed to be an indication that everything about the stream is gone or going away. A sender of a RST_STREAM may not deliver data pending on that stream up to the application, so I don't think it makes sense to design an app protocol that doesn't send a RST in response to a RST. But this brings up an interesting issue: Here we have transport behavior that requires a particular application behavior, which I'm not a fan of. It may make sense to require the transport to send a RST in response to a RST, with a special error code that means "sent in response to a received RST". That ought to make the semantics of RST clear to apps. On Thu, Sep 7, 2017 at 4:25 PM, Subodh Iyengar wrote: > If an app wanted to send both the stop sending and the reset stream, would > it have to wait till stop sending was sent on the wire before sending reset > streams? For example a API might reasonably be something like > > > transport->write(StopSendingFrame) > > transport->reset(); > > > If the app calls reset, then the transport might dump all data associated > with the stream immediately so the stop sending might never even be sent. > > > How do people intend to use stop sending from the app protocols that don't > send RST in response to RST? > > > Subodh > ------------------------------ > *From:* QUIC on behalf of Jana Iyengar < > jri@google.com> > *Sent:* Thursday, September 7, 2017 12:02:27 PM > *To:* Mike Bishop > *Cc:* Philipp S. Tiesel; QUIC WG; Martin Thomson; Nick Harper; Victor > Vasiliev > *Subject:* Re: Split error codes in two > > >> I'm less convinced that STOP_SENDING is HTTP-specific. To my mind, it's >> the wire expression of a read_close(), just as RST_STREAM is the wire >> expression of a write_close(). If we'd gone the advisory route, it would >> be an HTTP-ism. (Or at least, the mandated behavior would be at the HTTP >> layer.) However, if we think other applications aren't ever going to want >> to close a read stream.... > > > TCP allows for read_close() with shutdown(socket, RD), and it basically > means that TCP will send a RST to subsequent incoming data on that socket > from the peer. The expectation is that the application knows to not send > data to a peer that has issued a read_close(). > > What we're talking about here is different than a read_close(), since it's > an instruction to the peer to stop sending. This is only useful if I don't > want to stop sending but want only the peer to stop sending.... and the > driving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use > case odd, but I don't know that there's really a need for this otherwise. > I'm not very married on this point, but I'm wary of providing a knob that > really doesn't have a strong use case. > > --001a114dd166e6ae230558a2048f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, a RST_STREAM is supposed to be an indication that ever= ything about the stream is gone or going away. A sender of a RST_STREAM may= not deliver data pending on that stream up to the application, so I don= 9;t think it makes sense to design an app protocol that doesn't send a = RST in response to a RST.

But this brings up an interest= ing issue: Here we have transport behavior that requires a particular appli= cation behavior, which I'm not a fan of. It may make sense to require t= he transport to send a RST in response to a RST, with a special error code = that means "sent in response to a received RST". That ought to ma= ke the semantics of RST clear to apps.

On Thu, Sep 7, 2017 at 4:25 PM, Subodh Iye= ngar <subodh@fb.com> wrote:

If an app wanted to send both the stop sending and the reset stream, wou= ld it have to wait till stop sending was sent on the wire before sending re= set streams? For example a=C2=A0API might reasonably be something like


=C2=A0=C2=A0 transport->write(StopSendingFrame)

=C2=A0=C2=A0 transport->reset();


If the app calls reset, then the transport might dump all data associate= d with the stream immediately so the stop sending might never even be sent.=


How do people intend to use stop sending from the app protocols that don= 't send RST in response to RST?


Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Jana Iyengar <jri@google.com>
Sent: Thursday, September 7, 2017 12:02:27 PM
To: Mike Bishop
Cc: Philipp S. Tiesel; QUIC WG; Martin Thomson; Nick Harper; Victor = Vasiliev
Subject: Re: Split error codes in two
=C2=A0
I'm less convinced that STOP_SENDING is HTTP-specific.=C2=A0 To my mind= , it's the wire expression of a read_close(), just as RST_STREAM is the= wire expression of a write_close().=C2=A0 If we'd gone the advisory ro= ute, it would be an HTTP-ism.=C2=A0 (Or at least, the mandated behavior would be at the HTTP layer.)=C2=A0 However, if we think other app= lications aren't ever going to want to close a read stream....

TCP allows for read_close() with shutdown(socket, RD), and it basicall= y means that TCP will send a RST to subsequent incoming data on that socket= from the peer. The expectation is that the application knows to not send d= ata to a peer that has issued a read_close().

What we're talking about here is different than a read_close(), si= nce it's an instruction to the peer to stop sending. This is only usefu= l if I don't want to stop sending but want only the peer to stop sendin= g.... and the driving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use case odd, but I don't know that there= 's really a need for this otherwise. I'm not very married on this p= oint, but I'm wary of providing a knob that really doesn't have a s= trong use case.


--001a114dd166e6ae230558a2048f-- From nobody Thu Sep 7 16:52:09 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D400C133030 for ; Thu, 7 Sep 2017 16:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dh23pYqvX6VU for ; Thu, 7 Sep 2017 16:52:04 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DE7133032 for ; Thu, 7 Sep 2017 16:52:04 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l74so2476434oih.1 for ; Thu, 07 Sep 2017 16:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ryiRhClAfJ2wHwY6ozgonj9SlOsrWMLfxJyyC9ohFqk=; b=ENknHMy56++GMBFYy8ohQnguhsgNZdrMMqV2KdwEHih9A33PBlqdUdaP4yfD2o5FED ZfrGNJXTxvO6ptEq3ZeNSfT6SEYv5ThwTkcJpIE9jZ1KFp70aDbDtouRAtkq4jToptxy yjRBYx6T/VFUGliwPEuzor1Llwv1u0prXsCs42j3ZndtgHbV7f4m1tqEtmMED/3U8DKH MdM3GpbvIVYFNH+5ORrZD1usAPcQUDmrtWPlak29GZ5IISufrZORBwXBewNGu0wWLUtW fRXMvXrVdoxY3n3n1fHiPRSgmsnpoirJxhaf0Emm6bQAJgOugxsCyCh560r6v7pqfEui Xfag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ryiRhClAfJ2wHwY6ozgonj9SlOsrWMLfxJyyC9ohFqk=; b=gSUCdMTxIGtgvi6XgYZV/ESPqs9p1bBqcABJuLLdvShM/mnF+84aNmTHNbgzPw7R2i F4hNW1MCejExNIJP16b3/WSMoMvfmSzBcYYeFkywNadHhH85yzryHK1sD+ECmLuH5lAB uVNY94y0xkC+B8CGpFD66ylxSBj7QNFu+p+mRiCxsM0snzuST3cAQ9V16nM8wzwUu4lY m3yzoXFqaltqTCXxU5Y7imCm2NuzrpwpeAM7JsZr4clIps5Z0mntai259FcZDqC9bFOt T+mmK+xrQJO5YISST28spKR0qppjE/6tRER7lKVrSckjQiI3LGTTRJXITipaZ4hD9DYJ 36sA== X-Gm-Message-State: AHPjjUjFbqRxIUS+kDWubX9NOT6eKvI+6q4xLq8d9oTDe/8cvfJWr3R0 GsRsS5LCM3Ct3fOVF9gD90ds8855hQ== X-Google-Smtp-Source: AOwi7QAQjB8+PeeDYxTLjDVJaLjLZZD+6/knkw6VsYwGpkEkF78GkYm5AYh09gFXLRjtffPdbVSxuuUii19ZW6xgkBc= X-Received: by 10.202.75.66 with SMTP id y63mr1020093oia.5.1504828323846; Thu, 07 Sep 2017 16:52:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Thu, 7 Sep 2017 16:52:03 -0700 (PDT) In-Reply-To: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> From: Martin Thomson Date: Fri, 8 Sep 2017 09:52:03 +1000 Message-ID: Subject: Re: Split error codes in two To: Subodh Iyengar Cc: Jana Iyengar , Mike Bishop , "Philipp S. Tiesel" , QUIC WG , Nick Harper , Victor Vasiliev Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:52:08 -0000 On Fri, Sep 8, 2017 at 9:25 AM, Subodh Iyengar wrote: > If the app calls reset, then the transport might dump all data associated > with the stream immediately so the stop sending might never even be sent. STOP_SENDING is sent on another stream, one that won't be killed by the reset. From nobody Thu Sep 7 16:54:33 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4723A133030 for ; Thu, 7 Sep 2017 16:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=OomU72Yw; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=gx0vdrdf 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 7bdBxgCgGaKj for ; Thu, 7 Sep 2017 16:54:30 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91219133035 for ; Thu, 7 Sep 2017 16:54:30 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v87NnqV5003285; Thu, 7 Sep 2017 16:54:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=iTha5svx85aPYyFgOGRpvt8xJKVPdPheXqfV1XJfqIY=; b=OomU72YwO6HBDtcrpn+l+UrXz3cWIMBG067S79G6MiKU/8sH/h9IlWDfe/3pHhuURMmJ zGPcYm3j1LDAHniq8WMe9hdlyOOVBjCwgFffwjcF0u7+MIvlbhFP5OSYdhvs3aYtSygt T7ZMYlJf4wzsoS/MdW0iTFXmhUiuRtrGbIA= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cud1jrru1-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 07 Sep 2017 16:54:27 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.34) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 7 Sep 2017 19:54:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iTha5svx85aPYyFgOGRpvt8xJKVPdPheXqfV1XJfqIY=; b=gx0vdrdfVhwHJUUTDifdGlMsUe0MUCFAwAuFO+9T+DvBHPoH106wlxCO+c2+vIAi/BTSLwJkbvE/h92Upw0YJysWJf1ysbNENxcKSOOdCbiDxtPDdmjB+oL+Ud+Z+SmqAOpCTsx0X0DFuF/4u6nv54NObo4prZY5z694GAxLeJQ= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1871.namprd15.prod.outlook.com (10.174.255.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Thu, 7 Sep 2017 23:54:23 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.20.0013.022; Thu, 7 Sep 2017 23:54:23 +0000 From: Subodh Iyengar To: Martin Thomson CC: Jana Iyengar , Mike Bishop , "Philipp S. Tiesel" , QUIC WG , Nick Harper , Victor Vasiliev Subject: Re: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn+yyrdzIw/mkyM1giG213Fj6KmFGeAgAASp4CAAAOOAIAA0yCAgAAOnACAAAMMAIAAAK4AgACHAwCAAJELAIABpR2AgABGp/OAAApDgIAAAGcx Date: Thu, 7 Sep 2017 23:54:23 +0000 Message-ID: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:32a2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1871; 20:0hsq12pn1lgRzrwcbVcAR5eCMo5INhYwD2puTGFBdYXtCFRRCBkjZRLsa4qneykqZgSxx71+2zqVJ7JuoVKATHB828iDbsxm26Xbp0QskxFk78sF1TLvD/MZIugUitV+nh1kfVUAT+GXpiiNYG7lcDS4p3VXCoS0/jw2fSk+KPE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e48c03ea-b5fe-48f7-58bf-08d4f64bc3da x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1871; x-ms-traffictypediagnostic: MWHPR15MB1871: x-exchange-antispam-report-test: UriScan:(158342451672863)(67672495146484); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1871; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1871; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(189002)(199003)(2900100001)(39060400002)(8936002)(4326008)(189998001)(6116002)(110136004)(6436002)(14454004)(54896002)(99286003)(8676002)(106356001)(55016002)(105586002)(9686003)(6246003)(68736007)(81156014)(54906002)(8666007)(102836003)(76176999)(6506006)(101416001)(50986999)(53936002)(74316002)(54356999)(7736002)(81166006)(33656002)(53546010)(25786009)(5660300001)(93886005)(97736004)(3660700001)(3280700002)(2906002)(86362001)(229853002)(7696004)(6916009)(478600001)(2950100002)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1871; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14558F4B3B76E672CC042321B6940MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 23:54:23.3210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1871 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-07_15:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:54:32 -0000 --_000_MWHPR15MB14558F4B3B76E672CC042321B6940MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > STOP_SENDING is sent on another stream, one that won't be killed by the r= eset. Ah I missed that in the PR. Makes sense now. Subodh ________________________________ From: Martin Thomson Sent: Thursday, September 7, 2017 4:52:03 PM To: Subodh Iyengar Cc: Jana Iyengar; Mike Bishop; Philipp S. Tiesel; QUIC WG; Nick Harper; Vic= tor Vasiliev Subject: Re: Split error codes in two On Fri, Sep 8, 2017 at 9:25 AM, Subodh Iyengar wrote: > If the app calls reset, then the transport might dump all data associated > with the stream immediately so the stop sending might never even be sent. STOP_SENDING is sent on another stream, one that won't be killed by the res= et. --_000_MWHPR15MB14558F4B3B76E672CC042321B6940MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> STOP_SENDING is sen= t on another stream, one that won't be killed by the reset. Ah I missed that in the PR. Makes sense now.

Subodh

From: Martin Thomson <= martin.thomson@gmail.com>
Sent: Thursday, September 7, 2017 4:52:03 PM
To: Subodh Iyengar
Cc: Jana Iyengar; Mike Bishop; Philipp S. Tiesel; QUIC WG; Nick Harp= er; Victor Vasiliev
Subject: Re: Split error codes in two
 
On Fri, Sep 8, 2017 at 9:25 AM, Subodh Iyengar <= ;subodh@fb.com> wrote:
> If the app calls reset, then the transport might dump all data associa= ted
> with the stream immediately so the stop sending might never even be se= nt.

STOP_SENDING is sent on another stream, one that won't be killed by the res= et.
 --_000_MWHPR15MB14558F4B3B76E672CC042321B6940MWHPR15MB1455namp_-- From nobody Thu Sep 7 16:55:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6050513303A for ; Thu, 7 Sep 2017 16:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 E0DDFKlheekW for ; Thu, 7 Sep 2017 16:55:04 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150DD133030 for ; Thu, 7 Sep 2017 16:55:04 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id l74so2500738oih.1 for ; Thu, 07 Sep 2017 16:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=znxcofP2hAuDLH9tAuTtRsy1Yb2H6NEXxjielV6N1FI=; b=m6QhHn6tfRp/pSi7fRPnyV2lbwz43I/yvcadyncoDc1VT8P2CyHkt/xV7cDE3g0n6p QnxqFIMc/3hXInRBGjZcvDdYvn5K3JoN92Y4SsJ7QBJPA1VxsBhGuDcdhYciixabl2Zp Om/+EhRoOawa3gmfM3r6LVVK5CnRjToMWn0to/We4Dzo7n7+k+c/ZZHDrE4omQJXpSSe 0Fp8Yhacq8fetbHuk7ly6b8hQbFhEmKFYM25ZgEWdfuQqaxaF/NoV7//f118S5gItxf7 vfgoPi1fsXe9kkN2OsiH9D8M0NUxh7Ip+rpenGp3/2Q93cF5z8JuKYhOoWVRfMS4tquc SOAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=znxcofP2hAuDLH9tAuTtRsy1Yb2H6NEXxjielV6N1FI=; b=qmtG9ItgDLBvDzQFbpBxPybSl7Ng0LTTwe6HlzFuYjrkpYN05uNgHqXGBk72TLbvWC TWhO4CDHZXdfdNt4VN6AnvRofhpk99WmOSX9j4T0SrKdazzhJySETI/D7gckgqHlmYgo P2/iB5ymm3RpEK5f0mE1FIT8laXPpNPb5rXYLydZr/GGSGUlU2L5NEgw5M9Hy+EGjNYD jVoi4hVm9KNxo4P09TghH6Tcgo2vQ97PF5qCHVLldVHHqftvcr66zXjcefPhLKxnG/GO uVX22AsOh4JIbUnuvNvhC7x3Pqe2r4/Ti8nI8nVzVmjlvxbzt4AwEw2og1nJP0zDuf97 TWhQ== X-Gm-Message-State: AHPjjUh87FRGMXUif6cY+FNedL+9P4qAsst3cvHE/BwPLtpflowKykfJ Wc/VIe3mDtYEpP26FWTR8cXPRhpG3QTW X-Google-Smtp-Source: AOwi7QDDxim6pssmoTjIeYvpBmQhTpQ4x4Bw03TiX48JzASFMirQl5GYNEZXKRlPTKO3beXPiLG1m6lXtjiw1Fz8OjQ= X-Received: by 10.202.87.213 with SMTP id l204mr1163999oib.38.1504828503391; Thu, 07 Sep 2017 16:55:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Thu, 7 Sep 2017 16:55:02 -0700 (PDT) In-Reply-To: References: <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net> From: Martin Thomson Date: Fri, 8 Sep 2017 09:55:02 +1000 Message-ID: Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Jana Iyengar Cc: Christian Huitema , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:55:05 -0000 On Fri, Sep 8, 2017 at 8:51 AM, Jana Iyengar wrote: > The sender is not > going to receive acks for these packets, so it's best to do a clean slate > and start again with the initial window. The sender *could* do something > more complicated, like wait "a while" to let the network drain, but without > knowing what network bandwidth is, the sender would still be in the dark > about how long to wait. Any wait time here will be wrong, just as wrong as > the initial window. So, I would reset the controller's state to initial > state. I have copied the above text to the issue. Is this a reasonable position to take? I think that it is. (The something more complicated might start at leaving the pacing timer running so that you don't make things worse by that much at least.) From nobody Thu Sep 7 17:19:25 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B77813213D for ; Thu, 7 Sep 2017 17:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 bpqRpafdAelI for ; Thu, 7 Sep 2017 17:19:21 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7603E1320CF for ; Thu, 7 Sep 2017 17:19:21 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id q80so3526150ywg.2 for ; Thu, 07 Sep 2017 17:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZvcpUCoBNx0lcXVVdjyJPXvZAHKU3EdE9MJe5apwLr8=; b=CcXKBm7Ez6Emmve6QY7IzjHI7tD1hb3e2pVsFyaceCxf03NOHa0bFx5bvBaMwZSirb 2Q6Fi2Io0ctVP04p0NsoM4WY5sQp3gPhlG8NYUR+nq0xyQHBKFHfTIrzfeIpNs5/4qg2 Gzt/1f8jK4OqnzvBMxJTRYZAoFjwvsRS27IMU3O5ZhOZclL5iGPbGWsHV11PZ8UWFdkM zBGiG+tSzkqQMl0EZIRuYubhdgzVoEpTVcWwzoBQ187jMXzp4B9WwCEkYo6SsBVV5sBZ g7nFcj1NILwXwvi8tPDJeqQCvukbfr83dbp2jBcCAXUevopbPC30aaQtgGiLw3rjwR3B KvUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZvcpUCoBNx0lcXVVdjyJPXvZAHKU3EdE9MJe5apwLr8=; b=ubSmy6+YAN+1iH4jqEhRdVYwQ3VVPrDt/uHnev6rnr3QzjDmFABPXIhyX1or/A3zFG qILcQelutWPIA7tFJ+PJDf290EtPlwoPLLX0wSDxiR6srWyWptS0N5vmGzE+H3GhyhZh 4r9SqiSc5CsQYzyByBbb4xomNL51XRpjT1Z7DopEqudJTrwRgiXFVRJByrbJp926ie6B q0ayqLeNHa3e/LCAm2VeizFAZ3oPb1GufP0smA/FHyTqMNX08UnUI9F7gcY7P9iMPIbb 5a0Pc8mdXgR/LC+dRcCjYKj3vC4DamHGUQ6QKzxfrlIcyJwDEOhftJmMW2Z5TnM2XSJa sl7Q== X-Gm-Message-State: AHPjjUgXGmvmPfcbaNx+aDt38je0CdTuiJmVGI46sz8gFZSMseDRZjx3 /Qv2JIKdSbE5K/Xd2akdXYs+VM/l6EIONrQ= X-Google-Smtp-Source: ADKCNb7IBtf4zExLAqW2TxpXFUTkyVQJ2rEJ5MmWZlUQfTJdM3ahgSBSdnKDOiOxQ4XVwTjX7JxldTG04oXFVPXVpZ0= X-Received: by 10.129.79.200 with SMTP id d191mr1015029ywb.162.1504829960243; Thu, 07 Sep 2017 17:19:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Thu, 7 Sep 2017 17:19:19 -0700 (PDT) In-Reply-To: References: <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net> From: Jana Iyengar Date: Thu, 7 Sep 2017 17:19:19 -0700 Message-ID: Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Martin Thomson Cc: Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114dd1663b05f60558a2871d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 00:19:23 -0000 --001a114dd1663b05f60558a2871d Content-Type: text/plain; charset="UTF-8" I agree that it's a reasonable position to take (since I said it :-)) But others should chime in. On Thu, Sep 7, 2017 at 4:55 PM, Martin Thomson wrote: > On Fri, Sep 8, 2017 at 8:51 AM, Jana Iyengar wrote: > > The sender is not > > going to receive acks for these packets, so it's best to do a clean slate > > and start again with the initial window. The sender *could* do something > > more complicated, like wait "a while" to let the network drain, but > without > > knowing what network bandwidth is, the sender would still be in the dark > > about how long to wait. Any wait time here will be wrong, just as wrong > as > > the initial window. So, I would reset the controller's state to initial > > state. > > I have copied the above text to the issue. Is this a reasonable > position to take? I think that it is. (The something more > complicated might start at leaving the pacing timer running so that > you don't make things worse by that much at least.) > --001a114dd1663b05f60558a2871d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that it's a reasonable position to take (since= I said it :-)) But others should chime in.

On Thu, Sep 7, 2017 at 4:55 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
On Fri, Sep 8, 2017 at 8:51 AM, Jana Iy= engar <jri@google.com> wrote: > The sender is not
> going to receive acks for these packets, so it's best to do a clea= n slate
> and start again with the initial window. The sender *could* do somethi= ng
> more complicated, like wait "a while" to let the network dra= in, but without
> knowing what network bandwidth is,=C2=A0 the sender would still be in = the dark
> about how long to wait. Any wait time here will be wrong, just as wron= g as
> the initial window. So, I would reset the controller's state to in= itial
> state.

I have copied the above text to the issue.=C2=A0 Is this a reasonabl= e
position to take?=C2=A0 I think that it is.=C2=A0 (The something more
complicated might start at leaving the pacing timer running so that
you don't make things worse by that much at least.)

--001a114dd1663b05f60558a2871d-- From nobody Thu Sep 7 17:24:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0C013304D for ; Thu, 7 Sep 2017 17:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 WjHUBGNFMRPd for ; Thu, 7 Sep 2017 17:24:28 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78981320BD for ; Thu, 7 Sep 2017 17:24:28 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id s62so3581526ywg.0 for ; Thu, 07 Sep 2017 17:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i2tvPSEnVqpQA/qPF7NZgxCxT+3tcpSKdjdAwkczZ1A=; b=UaGxfmBw9yhirp528vH2ei0sx7n6IcRq7IJ12HMfjEWowbMuWqn7eh6OjuAMXlcb4J crbWXIHPmZjLavnZlKPTke39dHwthiQyj6GEfKFRA2oaQWvcRSGedn18GR1tECpanwgY lC+ZZKVRt+O3Mak73GnqZhjbh7tfHzELvwymFKhwDTbCNWQVSF+SBqqwAZpMu7bOgjMV Uv1wnKd/gjTLzYAaYaWPfKmpNJ2zMKGjI/78RQ4SN99Yi70UZMch80sIY+A7Kyt02ZIq r+Zf24ID2AgJbLsEUgwKdwyfO1UT9T6cuBQTGELWcAlPz1cli2hDvxMjMTPv1QuJhdIz v0ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i2tvPSEnVqpQA/qPF7NZgxCxT+3tcpSKdjdAwkczZ1A=; b=NUyHM2QdBjPxWvudvsA1GRfe1qTM3eluziRipCX8c91GlCKVZvoHZRA6Z/9hUAjeMX 0fx6KPdIFguP7fBuNJ47mdu+eTcfsJK7ED9iPvQtqLknuld7/HuhQeBPBRpLLdWxj4VV mDJ9szbjc5SeqYKUfZ+osgxFgy7ReUtezzkaM2/JB8MvXtbTJRzveOCGSaVNW3c125kT ZU0PwbGcTiPgNVzlo+risGjFwfF8CPMsI0tms0IBYeIchjyRo27I/qw5b30x1ZfyMK8m sBraXzW00Bko57ICLi0/4v4QGT5aIES64GCY7vEp4+tJZR6ftWtNJPEHRmG/hqNYAjDC JVvA== X-Gm-Message-State: AHPjjUgkDhRCtrF3ys8BcN7n1Qb/Bih8Tt9Mr4PVTwpCM9F+1Wm2JARe mUoXlOv6TZSeeM6licq2hrb4bhKLjMp9 X-Google-Smtp-Source: ADKCNb52aLvSb+jpOOD9ObZDa007eEc5elXGzE7uCXcpR8QY90W4yQmVMFJyAEDL1mPeqz05Fb2TwmL+2sSR0+xGO/0= X-Received: by 10.129.67.37 with SMTP id q37mr996009ywa.37.1504830267986; Thu, 07 Sep 2017 17:24:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Thu, 7 Sep 2017 17:23:47 -0700 (PDT) In-Reply-To: References: <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net> From: Eric Rescorla Date: Thu, 7 Sep 2017 17:23:47 -0700 Message-ID: Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Jana Iyengar Cc: Martin Thomson , IETF QUIC WG , Christian Huitema Content-Type: multipart/alternative; boundary="f403045f3d989244bd0558a29917" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 00:24:30 -0000 --f403045f3d989244bd0558a29917 Content-Type: text/plain; charset="UTF-8" I tend to agree that this is the right answer. -Ekr On Thu, Sep 7, 2017 at 5:19 PM, Jana Iyengar wrote: > I agree that it's a reasonable position to take (since I said it :-)) But > others should chime in. > > On Thu, Sep 7, 2017 at 4:55 PM, Martin Thomson > wrote: > >> On Fri, Sep 8, 2017 at 8:51 AM, Jana Iyengar wrote: >> > The sender is not >> > going to receive acks for these packets, so it's best to do a clean >> slate >> > and start again with the initial window. The sender *could* do something >> > more complicated, like wait "a while" to let the network drain, but >> without >> > knowing what network bandwidth is, the sender would still be in the >> dark >> > about how long to wait. Any wait time here will be wrong, just as wrong >> as >> > the initial window. So, I would reset the controller's state to initial >> > state. >> >> I have copied the above text to the issue. Is this a reasonable >> position to take? I think that it is. (The something more >> complicated might start at leaving the pacing timer running so that >> you don't make things worse by that much at least.) >> > > --f403045f3d989244bd0558a29917 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I tend to agree that this is the right answer.

-Ekr


On Thu, Sep 7, 2017 at 5:19 PM, Jana Iyengar <jri@googl= e.com> wrote:
I agree that it's a reasonable position to take (since I said it :-= )) But others should chime in.

On Thu, Sep 7, 2= 017 at 4:55 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On Fri, Sep 8, 2017 at = 8:51 AM, Jana Iyengar <jri@google.com> wrote:
> The sender is not
> going to receive acks for these packets, so it's best to do a clea= n slate
> and start again with the initial window. The sender *could* do somethi= ng
> more complicated, like wait "a while" to let the network dra= in, but without
> knowing what network bandwidth is,=C2=A0 the sender would still be in = the dark
> about how long to wait. Any wait time here will be wrong, just as wron= g as
> the initial window. So, I would reset the controller's state to in= itial
> state.

I have copied the above text to the issue.=C2=A0 Is this a reasonabl= e
position to take?=C2=A0 I think that it is.=C2=A0 (The something more
complicated might start at leaving the pacing timer running so that
you don't make things worse by that much at least.)


--f403045f3d989244bd0558a29917-- From nobody Thu Sep 7 19:14:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A9B13308C for ; Thu, 7 Sep 2017 19:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 Ie4R0CCIJWnL for ; Thu, 7 Sep 2017 19:14:38 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE9A132D62 for ; Thu, 7 Sep 2017 19:14:38 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v882CuRk030720; Fri, 8 Sep 2017 03:14:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=B+QlF/hbFff0rwvMjmpdDBoI6IOI11s+lMslR3QrX78=; b=Np01F3gcKYwH948Druo2VnJzi+4L4jRA6kNGFst1fOXf1TfpHgJjjdiF4oLLsugcHQLM RI4HhLTsyXhARnXdRLUP7+YxpR/H7yIgcu1bNZzle237+ri3/vy2AafG5vPkltVFOUzx 9jpaHivLooabybr/EMk0b7DHvU1SzdxNU+alEUo63wv6QHOxk3kySOS0UuF9THVc9zNy Va6YKSSsXRPDYDtewAQqb+Sh5v+IrXyYR0uzytgYEoh95Bv2ZoMLBFnGWPwbcxbYGuhh auBUMMFcWPfFRNPNaEOdaqXCYUHcQgilmitMGSsRPZYYdLcrCCg9wIhP+dVcfNcYBC+l Zg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2cufku0mxq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Sep 2017 03:14:33 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v882BbWc027672; Thu, 7 Sep 2017 22:14:32 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2cqqyw08bh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Sep 2017 22:14:32 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 7 Sep 2017 21:14:31 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Thu, 7 Sep 2017 21:14:31 -0500 From: "Lubashev, Igor" To: "jri@google.com" , "subodh@fb.com" CC: "quic@ietf.org" , "vasilvv@google.com" , "phils@in-panik.de" , "martin.thomson@gmail.com" , "Michael.Bishop@microsoft.com" , "nharper@google.com" Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9U7CZmvfU3U+AKlwSnR9wwKKmV3WAgAASqICAAAONAIAA0yCAgAAOnACAAAMMAIAAAK4AgACXxwCAAJELAIABpR2AgABJmoCAAAS/AP//1o0z Date: Fri, 8 Sep 2017 02:14:31 +0000 Message-ID: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_f8ccd0a8ceb24db8afe66019a3fecc0fustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-08_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709080031 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-08_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709080031 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 02:14:40 -0000 --_000_f8ccd0a8ceb24db8afe66019a3fecc0fustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I don't think it makes sense to design an app protocol that doesn't send = a RST in response to a RST Currently, the transport spec does not require RST_STREAM in response to RS= T_STREAM. It treats RST_STREAM like STREAM-with-FIN-except-don't-expect-tra= nsmittions (and it allows the receiver to drop buffered data not yet delive= red to the application, although I would be very careful with that if the l= ibrary API provides "peek" or "getAvailableDataSize" functions). I can think of a number of applications for which send-data-after-receiving= -RST is a natural design alternative. For example, you can have a print sev= er that talks to a printer via QUIC with a stream-per-job. Once the server-= to-printer stream direction is closed (normally or job aborted via RST), th= e printer may wish to tell the server how many actual pages were printed by= that job. -----Original Message----- From: Jana Iyengar [jri@google.com] Received: Thursday, 07 Sep 2017, 7:43PM To: Subodh Iyengar [subodh@fb.com] CC: Mike Bishop [Michael.Bishop@microsoft.com]; Philipp S. Tiesel [phils@in= -panik.de]; Victor Vasiliev [vasilvv@google.com]; QUIC WG [quic@ietf.org]; = Martin Thomson [martin.thomson@gmail.com]; Nick Harper [nharper@google.com] Subject: Re: Split error codes in two So, a RST_STREAM is supposed to be an indication that everything about the = stream is gone or going away. A sender of a RST_STREAM may not deliver data= pending on that stream up to the application, so I don't think it makes se= nse to design an app protocol that doesn't send a RST in response to a RST. But this brings up an interesting issue: Here we have transport behavior th= at requires a particular application behavior, which I'm not a fan of. It m= ay make sense to require the transport to send a RST in response to a RST, = with a special error code that means "sent in response to a received RST". = That ought to make the semantics of RST clear to apps. On Thu, Sep 7, 2017 at 4:25 PM, Subodh Iyengar > wrote: If an app wanted to send both the stop sending and the reset stream, would = it have to wait till stop sending was sent on the wire before sending reset= streams? For example a API might reasonably be something like transport->write(StopSendingFrame) transport->reset(); If the app calls reset, then the transport might dump all data associated w= ith the stream immediately so the stop sending might never even be sent. How do people intend to use stop sending from the app protocols that don't = send RST in response to RST? Subodh ________________________________ From: QUIC > on behalf = of Jana Iyengar > Sent: Thursday, September 7, 2017 12:02:27 PM To: Mike Bishop Cc: Philipp S. Tiesel; QUIC WG; Martin Thomson; Nick Harper; Victor Vasilie= v Subject: Re: Split error codes in two I'm less convinced that STOP_SENDING is HTTP-specific. To my mind, it's th= e wire expression of a read_close(), just as RST_STREAM is the wire express= ion of a write_close(). If we'd gone the advisory route, it would be an HT= TP-ism. (Or at least, the mandated behavior would be at the HTTP layer.) = However, if we think other applications aren't ever going to want to close = a read stream.... TCP allows for read_close() with shutdown(socket, RD), and it basically mea= ns that TCP will send a RST to subsequent incoming data on that socket from= the peer. The expectation is that the application knows to not send data t= o a peer that has issued a read_close(). What we're talking about here is different than a read_close(), since it's = an instruction to the peer to stop sending. This is only useful if I don't = want to stop sending but want only the peer to stop sending.... and the dri= ving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use cas= e odd, but I don't know that there's really a need for this otherwise. I'm = not very married on this point, but I'm wary of providing a knob that reall= y doesn't have a strong use case. --_000_f8ccd0a8ceb24db8afe66019a3fecc0fustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I don't think it makes sense to design an app protoco= l that doesn't send a RST in response to a RST


Currently, the transport spec does not require RST_STREAM in response to RS= T_STREAM. It treats RST_STREAM like STREAM-with-FIN-except-don't-expect-tra= nsmittions (and it allows the receiver to drop buffered data not yet delive= red to the application, although I would be very careful with that if the library API provides "peek&q= uot; or "getAvailableDataSize" functions).

I can think of a number of applications for which send-data-after-receiving= -RST is a natural design alternative. For example, you can have a print sev= er that talks to a printer via QUIC with a stream-per-job. Once the server-= to-printer stream direction is closed (normally or job aborted via RST), the printer may wish to tell the server= how many actual pages were printed by that job.

-----Original Message-----
From: Jana Iyengar [jri@google.com]
Received: Thursday, 07 Sep 2017, 7:43PM
To: Subodh Iyengar [subodh@fb.com]
CC: Mike Bishop [Michael.Bishop@microsoft.com]; Philipp S. Tiesel [p= hils@in-panik.de]; Victor Vasiliev [vasilvv@google.com]; QUIC WG [quic@ietf= .org]; Martin Thomson [martin.thomson@gmail.com]; Nick Harper [nharper@goog= le.com]
Subject: Re: Split error codes in two
So, a RST_STREAM is supposed to be an indication that ever= ything about the stream is gone or going away. A sender of a RST_STREAM may= not deliver data pending on that stream up to the application, so I don't = think it makes sense to design an app protocol that doesn't send a RST in response to a RST.

But this brings up an interesting issue: Here we have transport behavi= or that requires a particular application behavior, which I'm not a fan of.= It may make sense to require the transport to send a RST in response to a = RST, with a special error code that means "sent in response to a received RST". That ought to make t= he semantics of RST clear to apps.

On Thu, Sep 7, 2017 at 4:25 PM, Subodh Iyengar <= span dir=3D"ltr"> <subodh@fb.com>= ; wrote:

If an app wanted to send both the stop sending and the reset stream, wou= ld it have to wait till stop sending was sent on the wire before sending re= set streams? For example a API might reasonably be something like


   transport->write(StopSendingFrame)

   transport->reset();


If the app calls reset, then the transport might dump all data associate= d with the stream immediately so the stop sending might never even be sent.=


How do people intend to use stop sending from the app protocols that don= 't send RST in response to RST?


Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Jana Iyengar <jri@google= .com>
Sent: Thursday, September 7, 2017 12:02:27 PM
To: Mike Bishop
Cc: Philipp S. Tiesel; QUIC WG; Martin Thomson; Nick Harper; Victor = Vasiliev
Subject: Re: Split error codes in two
 
I'm less convinced that STOP_SENDING is HTTP-specific.  To my mind, it= 's the wire expression of a read_close(), just as RST_STREAM is the wire ex= pression of a write_close().  If we'd gone the advisory route, it woul= d be an HTTP-ism.  (Or at least, the mandated behavior would be at the HTTP layer.)  However, if we think other app= lications aren't ever going to want to close a read stream....

TCP allows for read_close() with shutdown(socket, RD), and it basicall= y means that TCP will send a RST to subsequent incoming data on that socket= from the peer. The expectation is that the application knows to not send d= ata to a peer that has issued a read_close().

What we're talking about here is different than a read_close(), since = it's an instruction to the peer to stop sending. This is only useful if I d= on't want to stop sending but want only the peer to stop sending.... and th= e driving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use case odd, but I don't know that there's r= eally a need for this otherwise. I'm not very married on this point, but I'= m wary of providing a knob that really doesn't have a strong use case.


--_000_f8ccd0a8ceb24db8afe66019a3fecc0fustx2exdag1mb5msgcorpak_-- From nobody Thu Sep 7 19:50:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BE813309D for ; Thu, 7 Sep 2017 19:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wCoS1ZRShak9 for ; Thu, 7 Sep 2017 19:50:35 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D3C13309C for ; Thu, 7 Sep 2017 19:50:35 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id r20so8178301oie.0 for ; Thu, 07 Sep 2017 19:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZCdp8YAI4GhtdikYxvvHPj2slBHIpwy4Ky085PYMOtc=; b=MmgDwEDwh+KZZ50eFRf0s51q2YOnkQ+OtqmvBruzxXVgLoDZCUncGUxRtZX/xq4vsU b/ZEOSp+GF5XmFyoOpmFEqIGUwAtoEkdbKwCOG+ceke6lE45TAIQhEvTuvbKuv/45WrF HLtNypbhiKelmsf0qqkBFVP4xJLJHZxfLn1glyRbV3J1EurTgPPhjOv4xrrJJsx8N+f8 rznzPBwZkHlp1sKUjRa6AGtZbNT8ljz4xUO+Rdnuk2kHxmRBECZiN+jTTafD0L3IcDay WLNq7pS3pJ7iuwMidThWZlInmhhypYvJvDAsF0VneMCkputjfiYAUentArMViTAWpStV QtuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZCdp8YAI4GhtdikYxvvHPj2slBHIpwy4Ky085PYMOtc=; b=WP6BOODe+gZIdScxwtiSyHDa2SsY1I/5AsGofPwK18S0pmD5hBGhtRmBOdQyx7BFkv AvUbhYOt6ksylhNdI5u6gti/xpNKv0zss9YjtRP5BcBc9k/Zh3nRhEt8eVW4B5EkyJXS s0DEdfc17wSW6QGH4RsCAGpfLosrnyVLm4WMWPh3M0YZT+skW8+iv1usPV912O9SWTfm WWBiRZiP52fChhmyo0zGBMMT+hz3wkkicwnCr9R6keE5cAqBCwgiyNPQbDZcjZUzrgU2 N2FkQfmTckQz5H23beZ7pLks6fXyDa9mTGAXWmmkBaVKKc78ELucxnJ3vS1QzCFHmj5a tDZw== X-Gm-Message-State: AHPjjUgOfKqnAbUsc34XpdcKR1iG4eWXJ3uzQMoNwg0NM2eOnjw55NWW S0SvC8BN5sHSJ7/YnFN35GmQO6qfmg== X-Google-Smtp-Source: AOwi7QBnEg5QRefasYdINgbjGaO5t4FAal6IMqvpofltBXjlA0vDh7KNc6no9GXqfqSlGGbhUJ16kml0/ygeqn5C55M= X-Received: by 10.202.87.213 with SMTP id l204mr1511612oib.38.1504839034803; Thu, 07 Sep 2017 19:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Thu, 7 Sep 2017 19:50:34 -0700 (PDT) In-Reply-To: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> From: Martin Thomson Date: Fri, 8 Sep 2017 12:50:34 +1000 Message-ID: Subject: Re: Split error codes in two To: Jana Iyengar Cc: Subodh Iyengar , Mike Bishop , "Philipp S. Tiesel" , QUIC WG , Nick Harper , Victor Vasiliev Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 02:50:37 -0000 On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar wrote: > I don't think it makes sense to design an app protocol that doesn't send a > RST in response to a RST. I've been told not to invoke this particular demon, but you just invoked the Unidirectional streams problem. I think that we get there because of this meme that says that data in the one direction is somehow necessarily bound to data in the other direction. That's an entirely constructed notion. A useful construct at times, certainly, but that's not the point here. So I disagree. There are many protocols in which you send messages (== streams) in one direction but not another. One of the ways you get into a unidirectional state in the current draft is to end one side. A FIN is only one way to do that, a unidirectional RST can be faster and even superior in other ways. The HTTP use case clearly illustrates that. Also, as Igor observes, we don't require a reciprocal RST_STREAM in the current draft. From nobody Thu Sep 7 22:47:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134A91321C0 for ; Thu, 7 Sep 2017 22:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8ISH5QMXoLiG for ; Thu, 7 Sep 2017 22:47:11 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07ED61330CE for ; Thu, 7 Sep 2017 22:47:11 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id v66so3293082pgb.5 for ; Thu, 07 Sep 2017 22:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:content-language:mime-version; bh=m9S0tpQSxvKA3lnr0WJxRpfzj3rSAqy2BSKygLXiZBw=; b=NJMcr1dc5kYrmksKGsK6eHMe1HRtoYtAjo/jH1NnPtja84SN5YfRxqTYWZGY9SF4j5 miS4+5v46jxbEbU5QCLovMbKC0xG0lg9Tq5VELO0Ta2GF696rnrrhkCfD55uqcJURQx4 YymOq7092ghDd3vg8GCM3/4OeVQenE+zDzMvnde8dkgo2ArbmegMhsVmF0mr9nBs7FHW t05NCLcb3P1PINnjdHZZwlecbWiU9Ou/pfq9YwjoDrcc72IzT+4lSEBYbHSQILFkW2ml Ku6ZTidwPI52fR/i2ofE9V3SwV9rY8ONJvixK0NQD5pHssE24bgiA3yu94JS0z8PMjte +/zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:content-language :mime-version; bh=m9S0tpQSxvKA3lnr0WJxRpfzj3rSAqy2BSKygLXiZBw=; b=t6YQrcuOr7uunBp4ZJvfynDgXulYnyQwxvstkLLWQwV2Lkdbna4UolfO46XEtbqkVF 1oHSl6sdX7a2k5aS0TXuDONeNC35ZAIVi1inYJp8WccqcsiGwrqhHHcNJUd+AmvncCIv lIS7PqvEYmLaCK8rmaR6/amekhQHTJVOWtwfJByLGDxXnwXEwiMGzJsiliPrlYyvjf9n VYR1HobHeFhClaV6WcBXdfIXg+FZ3WiuEVqVDc87RUXtvGw379gmwf9Uy3XO/L/Xc7ZD 1gu2d7hQiZy5m+SzXkD8viEA9B0ZHeEjDbUu0vQTI/t/VGTWBlnzVd04x9KcX79Xu1rE jnXA== X-Gm-Message-State: AHPjjUilK39GWbTDcgoeJ2EMeHTm67/mRiCltGm5z+ZCZ2Tc0k0INzoJ oXZJzlSOQtxBfw== X-Google-Smtp-Source: ADKCNb45SxCAq3tqliMajkJVCdUAul6dPeqWhfaMOcE02W/rJRkRdCuao6gKvYWM+De+iSEiEyRBEQ== X-Received: by 10.98.2.65 with SMTP id 62mr1902634pfc.146.1504849630597; Thu, 07 Sep 2017 22:47:10 -0700 (PDT) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id i186sm1841234pfg.84.2017.09.07.22.47.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Sep 2017 22:47:09 -0700 (PDT) From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Roberto Peon , Jana Iyengar , Roni Even CC: joel jaeggli , QUIC WG , Martin Thomson Subject: Re: obsrvtaion on packet numbers Thread-Topic: obsrvtaion on packet numbers Thread-Index: AThDQTlD8wtDRJOyU3UlcF3NWO9NoXd6NEdjOUNBOUNiNjA4YzBDQTlDdzVzdGpGRkI0MqXEtHVR X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 8 Sep 2017 05:47:04 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> <6E58094ECC8D8344914996DAD28F1CCD801AA0@DGGEMM506-MBX.china.huawei.com> , <57990B52-041C-4ABE-A8BC-CE5CF408718F@fb.com> In-Reply-To: <57990B52-041C-4ABE-A8BC-CE5CF408718F@fb.com> Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17666AA24AA075AC07DC96C2AC950DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 05:47:13 -0000 --_000_DB6PR10MB17666AA24AA075AC07DC96C2AC950DB6PR10MB1766EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A connection a day is not sufficient, but the real problem is the stream ID= when sending multiple new streams per package - which happens in partially= reliable transmissions with uni-directional streams - you can exhaust ID s= pace within hours. Mikkel ________________________________ From: QUIC on behalf of Roberto Peon Sent: Thursday, September 7, 2017 11:45:24 PM To: Jana Iyengar; Roni Even Cc: joel jaeggli; QUIC WG; Martin Thomson Subject: Re: obsrvtaion on packet numbers Concretely: 2^63 represents 11,690,840.9 years of packets at 25kpps, or 292= years at 1 Gpps. Even if it was only 2^32, though, a new connection per day would be reasona= ble=97many sites won=92t want to maintain connection state for substantiall= y more than a day (people update binaries/change config, need to shuffle lo= ad around to deal with load asymmetries, etc.). -=3DR From: QUIC on behalf of Jana Iyengar Date: Thursday, September 7, 2017 at 2:36 PM To: Roni Even Cc: joel jaeggli , QUIC WG , Martin Thomso= n Subject: Re: obsrvtaion on packet numbers Roni, > 2^32 isn't half of 2^64, it's half of 2^33. 25kpps is 2 billion odd packe= ts a day > whereas 2^64 is 1.84 * 10^19. [Roni Even]I was basing it on the text assuming that packet number does not= start at 0 " The initial value for packet number MUST be selected from an= uniform random distribution between 0 and 2^31-1 " Even if your initial packet number is the largest possible, that is, 2^32, = you still have > 2^63 numbers left. 2^64 =3D 2^63 + 2^63, which is the total number of possible packet numbers,= and 2^63 + 2^32 is the number of packets you can send with this worst case= initial packet number. - jana --_000_DB6PR10MB17666AA24AA075AC07DC96C2AC950DB6PR10MB1766EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
A connection a day is not sufficient, but the = real problem is the stream ID when sending multiple new streams per package= - which happens in partially reliable transmissions with uni-directional s= treams - you can exhaust ID space within hours.

Mikkel

From: QUIC <quic-bounces= @ietf.org> on behalf of Roberto Peon <fenix@fb.com>
Sent: Thursday, September 7, 2017 11:45:24 PM
To: Jana Iyengar; Roni Even
Cc: joel jaeggli; QUIC WG; Martin Thomson
Subject: Re: obsrvtaion on packet numbers
 

Concretely: 2^63 represents 11,690,840.9 years of pa= ckets at 25kpps, or 292 years at 1 Gpps.

Even if it was only 2^32, though, a new connection per day would be reasona= ble=97many sites won=92t want to maintain connection state for substantiall= y more than a day (people update binaries/change config, need to shuffle lo= ad around to deal with load asymmetries, etc.).

-=3DR

 

Fro= m: QUIC <quic-bounces@iet= f.org> on behalf of Jana Iyengar <jri@google.com>
Date: Thursday, September 7, 2017 at 2:36 PM
To: Roni Even <roni.even@huawei.com>
Cc: joel jaeggli <joelja@bogus.com>, QUIC WG <quic@ietf.org= >, Martin Thomson <martin.thomson@gmail.com>
Subject: Re: obsrvtaion on packet numbers

 

Roni,


> 2^32 isn't half of 2^64, it's half of 2^33. 25kpps is 2 billion odd pa= ckets a day
> whereas 2^64 is 1.84 * 10^19.
[Roni Even]I was basing it on the text assuming that packet number does not= start at 0  " The initial value for packet number MUST be select= ed from an uniform
   random distribution between 0 and 2^31-1 "

 

Even if your initial packet number is the largest po= ssible, that is, 2^32, you still have > 2^63 numbers left.

2^64 =3D 2^63 + 2^63, which is the total number = of possible packet numbers, and 2^63 + 2^32 is the number of packets yo= u can send with this worst case initial packet number.

 

- jana

--_000_DB6PR10MB17666AA24AA075AC07DC96C2AC950DB6PR10MB1766EURP_-- From nobody Fri Sep 8 07:28:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C125132EE9 for ; Fri, 8 Sep 2017 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 GBfOR-ZbGMcf for ; Fri, 8 Sep 2017 07:28:30 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1079132339 for ; Fri, 8 Sep 2017 07:28:29 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v88EQcC3032181; Fri, 8 Sep 2017 15:28:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=l5f22PTJoJIXXekEzwGnIXqMl44Eo8ojbylRVeEQw5c=; b=Cw5GrWHYZ+Kw/4+Ej6ztxliGjWH/6evjBGyQGI0CgNp7Lpjxtf1Qz1zSk/kWRKQQDUAA a0TLas//8yOWJVOES86SCudmAe7gTUnquJ+u8SGcqsutnVcUlJ1s/HTE3w7SRnKXZgbW QbHrNrlPVNGLFSx5m8cY17gk9Z61H9yTJrnWm0KTB/s9HYA+AFh3tMXQYUR6z6HQyqLj +wk/yGHwr9CE9c1RDPfZhpvC6BKh19pIXm9aMQyLuLzafLXNppld9c+lxYme6esHNB8S 0GUvBFGF7bddNiuJuisynqGg+XFMNwO0+oi8Vz3MNXgFAPrTzDXQeSt6iBfP4NuBPQd5 fQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2cuuwg8aav-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Sep 2017 15:28:18 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v88EQFNJ031853; Fri, 8 Sep 2017 10:28:18 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cqqyv1w3y-1; Fri, 08 Sep 2017 10:28:18 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B2CB21FC85; Fri, 8 Sep 2017 14:28:17 +0000 (GMT) Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two) To: Jana Iyengar , Martin Thomson Cc: IETF QUIC WG , Christian Huitema References: <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net> From: Benjamin Kaduk Message-ID: <5734a1e2-052f-99c6-60e9-dec87049f29d@akamai.com> Date: Fri, 8 Sep 2017 09:28:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EB926ADAE83EB025A54D5A09" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-08_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709080215 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-08_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709080215 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 14:28:36 -0000 This is a multi-part message in MIME format. --------------EB926ADAE83EB025A54D5A09 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit It seems like the right thing to do, to me. -Ben On 09/07/2017 07:19 PM, Jana Iyengar wrote: > I agree that it's a reasonable position to take (since I said it :-)) > But others should chime in. > > On Thu, Sep 7, 2017 at 4:55 PM, Martin Thomson > > wrote: > > On Fri, Sep 8, 2017 at 8:51 AM, Jana Iyengar > wrote: > > The sender is not > > going to receive acks for these packets, so it's best to do a > clean slate > > and start again with the initial window. The sender *could* do > something > > more complicated, like wait "a while" to let the network drain, > but without > > knowing what network bandwidth is, the sender would still be in > the dark > > about how long to wait. Any wait time here will be wrong, just > as wrong as > > the initial window. So, I would reset the controller's state to > initial > > state. > > I have copied the above text to the issue. Is this a reasonable > position to take? I think that it is. (The something more > complicated might start at leaving the pacing timer running so that > you don't make things worse by that much at least.) > > --------------EB926ADAE83EB025A54D5A09 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit It seems like the right thing to do, to me.

-Ben

On 09/07/2017 07:19 PM, Jana Iyengar wrote:
I agree that it's a reasonable position to take (since I said it :-)) But others should chime in.

On Thu, Sep 7, 2017 at 4:55 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On Fri, Sep 8, 2017 at 8:51 AM, Jana Iyengar <jri@google.com> wrote:
> The sender is not
> going to receive acks for these packets, so it's best to do a clean slate
> and start again with the initial window. The sender *could* do something
> more complicated, like wait "a while" to let the network drain, but without
> knowing what network bandwidth is,  the sender would still be in the dark
> about how long to wait. Any wait time here will be wrong, just as wrong as
> the initial window. So, I would reset the controller's state to initial
> state.

I have copied the above text to the issue.  Is this a reasonable
position to take?  I think that it is.  (The something more
complicated might start at leaving the pacing timer running so that
you don't make things worse by that much at least.)


--------------EB926ADAE83EB025A54D5A09-- From nobody Fri Sep 8 17:34:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99540128D0F for ; Fri, 8 Sep 2017 17:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 leSin5goFvze for ; Fri, 8 Sep 2017 17:34:00 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25A61201F8 for ; Fri, 8 Sep 2017 17:33:59 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id v72so9327315ywa.3 for ; Fri, 08 Sep 2017 17:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=603gn0pJ/gzt+ZWBxyAHRH5LbRPpCkZRbb0Uacfsdzw=; b=PovulKozvcjeTDUK9g8OHKiq3k8yVjkfqD5pjPHndX7EjP4FMaYS0bBqSQrzuTz8Xw GLzbTmVqC8DBF6PDg+HsaVzBXd5kzPWMmihXsFEd0E/MHJWcqccGjry38Vg7bCbOLdna LdyL9XcLw3GiWPUlkdsn1PYCGE8ErrVmLdyQLZ7PP/2thypIZSo2J0VPvCe3xVA3sqj5 VCI8CGsLJTtqcH/mRwsIWCfh6UGFrnDcOX/yetAKWx+O5Xpdx1vFcgBT0yDKCgOmLEEQ V8QdikFW86alPkwE9AdcWipgv9vbvBjZW6S07dL5TwSRXF/zcsS3PX6B8UsIVQshgFkE 8j+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=603gn0pJ/gzt+ZWBxyAHRH5LbRPpCkZRbb0Uacfsdzw=; b=W6TVQfjAC56X060V1lnfhVJVgY8kFQfiFDFa2NnWfc6z3KVZ51z4fwwxjpEMVpxKCP dlPVgpfAzhlxr2BIyfxISazv7sXV1FYPDz0Ucd5m+gPSbvmhBFDNEGsPQH4NuoLAd0vG +GTiDQFvet8fYqP/z5FzV2FIG7JmJVorZYw4IyR7bPQKFSLmOQf3SabssHG+zrmczTVC h0zOc3bii6BP7zkXIfxRCA70p1bPrFDAmPn3UM+XTucarz1/Kfs5fwzHHKMLUxaW+gxM GN5ngkuD0xS6StASoSrXmUZoiBIjphqcmBj9XcUi9OcqDINS0ajeYdHYxBqWPWUaBVk/ hIJw== X-Gm-Message-State: AHPjjUjh/HwfJBvIErY5SmcsRVph1Pz5409Y4vkd8T8bUPI0myE/RZwW 63S7ThZNEGpAOj30dzDjCWYI36XM2lmB X-Google-Smtp-Source: ADKCNb7YsInFWqZB0KB5Xmj4fADHQ8J/QuohXp3qAWDHvL/H7jL5E9PmFZ7lwoh0d/ytE40WNNoSzd7GZLKO7enysrA= X-Received: by 10.129.118.3 with SMTP id r3mr3771825ywc.131.1504917238741; Fri, 08 Sep 2017 17:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Fri, 8 Sep 2017 17:33:57 -0700 (PDT) In-Reply-To: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> From: Jana Iyengar Date: Fri, 8 Sep 2017 17:33:57 -0700 Message-ID: Subject: Re: Split error codes in two To: Martin Thomson Cc: Subodh Iyengar , Mike Bishop , "Philipp S. Tiesel" , QUIC WG , Nick Harper , Victor Vasiliev Content-Type: multipart/alternative; boundary="f403045ef02a6f444d0558b6d9d7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 00:34:01 -0000 --f403045ef02a6f444d0558b6d9d7 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson wrote: > On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar wrote: > > I don't think it makes sense to design an app protocol that doesn't send > a > > RST in response to a RST. > > I've been told not to invoke this particular demon, but you just > invoked the Unidirectional streams problem. I think that we get there > because of this meme that says that data in the one direction is > somehow necessarily bound to data in the other direction. That's an > entirely constructed notion. A useful construct at times, certainly, > but that's not the point here. > I think that's the most common use of a RST -- to close both directions. > So I disagree. There are many protocols in which you send messages > (== streams) in one direction but not another. One of the ways you > get into a unidirectional state in the current draft is to end one > side. A FIN is only one way to do that, a unidirectional RST can be > faster and even superior in other ways. The HTTP use case clearly > illustrates that. > FIN is the primary way in which half-close is achieved, which is what you're talking about. The HTTP use case is a complete one-off -- STOP_SENDING is an odd enough use case that I'm always left wondering who actually uses it. > Also, as Igor observes, we don't require a reciprocal RST_STREAM in > the current draft. Yes, we don't. Recall that the RST_STREAM was, prior to the change that doesn't require reciprocity, a bidirectional signal, which was simplified to a unidirectional one, with the general expectation that apps would close the other side when they receive this signal from QUIC. It's surely going to be true of HTTP. It's possible for an app to receive a RST and then keep sending, but that is a use case I haven't seen in practice. --f403045ef02a6f444d0558b6d9d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 7, 2017 at 7:50 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
= On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar <jri@google.com> wrote:
> I don't think it makes sense to design an app protocol that doesn&= #39;t send a
> RST in response to a RST.

I've been told not to invoke this particular demon, but you just=
invoked the Unidirectional streams problem.=C2=A0 I think that we get there=
because of this meme that says that data in the one direction is
somehow necessarily bound to data in the other direction.=C2=A0 That's = an
entirely constructed notion.=C2=A0 A useful construct at times, certainly,<= br> but that's not the point here.

I th= ink that's the most common use of a RST -- to close both directions.=C2= =A0
=C2=A0
So I disagree.=C2=A0 There are many protocols in which you send messages (=3D=3D streams) in one direction but not another.=C2=A0 One of the ways yo= u
get into a unidirectional state in the current draft is to end one
side.=C2=A0 A FIN is only one way to do that, a unidirectional RST can be faster and even superior in other ways.=C2=A0 The HTTP use case clearly
illustrates that.

FIN is the primary wa= y in which half-close is achieved, which is what you're talking about. = The HTTP use case is a complete one-off -- STOP_SENDING is an odd enough us= e case that I'm always left wondering who actually uses it.
= =C2=A0
Also, as Igor observes, we don't require a reciprocal RST_STREAM in
the current draft.

Yes, we don't. Recal= l that the RST_STREAM was, prior to the change that doesn't require rec= iprocity, a bidirectional signal, which was simplified to a unidirectional = one, with the general expectation that apps would close the other side when= they receive this signal from QUIC. It's surely going to be true of HT= TP. It's possible for an app to receive a RST and then keep sending, bu= t that is a use case I haven't seen in practice.
=C2=A0
=
--f403045ef02a6f444d0558b6d9d7-- From nobody Sun Sep 10 01:25:01 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7243C132355 for ; Sun, 10 Sep 2017 01:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 b19bVj0CE90d for ; Sun, 10 Sep 2017 01:24:58 -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 6940A126B71 for ; Sun, 10 Sep 2017 01:24:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOG98509; Sun, 10 Sep 2017 08:24:55 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 10 Sep 2017 09:24:54 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Sun, 10 Sep 2017 16:24:47 +0800 From: Roni Even To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Roberto Peon , Jana Iyengar CC: joel jaeggli , QUIC WG , Martin Thomson Subject: RE: obsrvtaion on packet numbers Thread-Topic: obsrvtaion on packet numbers Thread-Index: AdMm5zHPD4iKjQeVQlG4Za1XZ0BzMf//nx0A//46kWCAAxI0AP//eStggAGJIACAAAKLAIAAhpQA//wtF6A= Date: Sun, 10 Sep 2017 08:24:46 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8022E5@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> <6E58094ECC8D8344914996DAD28F1CCD801AA0@DGGEMM506-MBX.china.huawei.com> , <57990B52-041C-4ABE-A8BC-CE5CF408718F@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.153] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8022E5DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59B4F6D7.007A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 38bc455450b94b9303fc213635ddc9cb Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 08:25:00 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8022E5DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIHN0YXJ0ZWQgdGhlIHRocmVhZCBzaW5jZSBJIHRyaWVkIHRvIHVuZGVyc3RhbmQgaG93 IHRvIGNsb3NlIGEgY29ubmVjdGlvbiB3aGVuIHBhY2tldCBudW1iZXIgcmVhY2ggdGhlIGVuZC4g VGhlIHRleHQgZG9lcyBub3Qgc3BlY2lmeSB0aGlzIGNhc2UgYW5kIE1hcnRpbiBUaG9tc29uIGNs YWltZWQgdGhhdCBpdCBpcyBub3QgaW1wb3J0YW50IGN1cnJlbnRseSBzaW5jZSB0aGlzIGNhc2Ug aGFzIGxvdyBwcm9iYWJpbGl0eS4NCkl0IGlzIG11Y2ggc2ltcGxlciB0byBjbG9zZSBhIGNvbm5l Y3Rpb24gd2hlbiBzdHJlYW0gSURzIGFyZSBleGhhdXN0ZWQgYW5kIHN0YXJ0IGEgbmV3IGNvbm5l Y3Rpb24sIHNvIGxlc3Mgd29ycnkuDQpSb25pDQoNCkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJn ZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb21dDQpTZW50OiDXmdeV150g15UgMDgg16HX pNeY157XkdeoIDIwMTcgMDg6NDcNClRvOiBSb2JlcnRvIFBlb247IEphbmEgSXllbmdhcjsgUm9u aSBFdmVuDQpDYzogam9lbCBqYWVnZ2xpOyBRVUlDIFdHOyBNYXJ0aW4gVGhvbXNvbg0KU3ViamVj dDogUmU6IG9ic3J2dGFpb24gb24gcGFja2V0IG51bWJlcnMNCg0KQSBjb25uZWN0aW9uIGEgZGF5 IGlzIG5vdCBzdWZmaWNpZW50LCBidXQgdGhlIHJlYWwgcHJvYmxlbSBpcyB0aGUgc3RyZWFtIElE IHdoZW4gc2VuZGluZyBtdWx0aXBsZSBuZXcgc3RyZWFtcyBwZXIgcGFja2FnZSAtIHdoaWNoIGhh cHBlbnMgaW4gcGFydGlhbGx5IHJlbGlhYmxlIHRyYW5zbWlzc2lvbnMgd2l0aCB1bmktZGlyZWN0 aW9uYWwgc3RyZWFtcyAtIHlvdSBjYW4gZXhoYXVzdCBJRCBzcGFjZSB3aXRoaW4gaG91cnMuDQoN Ck1pa2tlbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUVVJQyA8 cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+ DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDcsIDIwMTcgMTE6NDU6MjQgUE0NClRvOiBKYW5h IEl5ZW5nYXI7IFJvbmkgRXZlbg0KQ2M6IGpvZWwgamFlZ2dsaTsgUVVJQyBXRzsgTWFydGluIFRo b21zb24NClN1YmplY3Q6IFJlOiBvYnNydnRhaW9uIG9uIHBhY2tldCBudW1iZXJzDQoNCkNvbmNy ZXRlbHk6IDJeNjMgcmVwcmVzZW50cyAxMSw2OTAsODQwLjkgeWVhcnMgb2YgcGFja2V0cyBhdCAy NWtwcHMsIG9yIDI5MiB5ZWFycyBhdCAxIEdwcHMuDQoNCkV2ZW4gaWYgaXQgd2FzIG9ubHkgMl4z MiwgdGhvdWdoLCBhIG5ldyBjb25uZWN0aW9uIHBlciBkYXkgd291bGQgYmUgcmVhc29uYWJsZeKA lG1hbnkgc2l0ZXMgd29u4oCZdCB3YW50IHRvIG1haW50YWluIGNvbm5lY3Rpb24gc3RhdGUgZm9y IHN1YnN0YW50aWFsbHkgbW9yZSB0aGFuIGEgZGF5IChwZW9wbGUgdXBkYXRlIGJpbmFyaWVzL2No YW5nZSBjb25maWcsIG5lZWQgdG8gc2h1ZmZsZSBsb2FkIGFyb3VuZCB0byBkZWFsIHdpdGggbG9h ZCBhc3ltbWV0cmllcywgZXRjLikuDQoNCi09Ug0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKYW5h IEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+DQpEYXRlOiBU aHVyc2RheSwgU2VwdGVtYmVyIDcsIDIwMTcgYXQgMjozNiBQTQ0KVG86IFJvbmkgRXZlbiA8cm9u aS5ldmVuQGh1YXdlaS5jb208bWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tPj4NCkNjOiBqb2Vs IGphZWdnbGkgPGpvZWxqYUBib2d1cy5jb208bWFpbHRvOmpvZWxqYUBib2d1cy5jb20+PiwgUVVJ QyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+LCBNYXJ0aW4gVGhvbXNv biA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20+Pg0KU3ViamVjdDogUmU6IG9ic3J2dGFpb24gb24gcGFja2V0IG51bWJlcnMNCg0KUm9uaSwN Cg0KPiAyXjMyIGlzbid0IGhhbGYgb2YgMl42NCwgaXQncyBoYWxmIG9mIDJeMzMuIDI1a3BwcyBp cyAyIGJpbGxpb24gb2RkIHBhY2tldHMgYSBkYXkNCj4gd2hlcmVhcyAyXjY0IGlzIDEuODQgKiAx MF4xOS4NCltSb25pIEV2ZW5dSSB3YXMgYmFzaW5nIGl0IG9uIHRoZSB0ZXh0IGFzc3VtaW5nIHRo YXQgcGFja2V0IG51bWJlciBkb2VzIG5vdCBzdGFydCBhdCAwICAiIFRoZSBpbml0aWFsIHZhbHVl IGZvciBwYWNrZXQgbnVtYmVyIE1VU1QgYmUgc2VsZWN0ZWQgZnJvbSBhbiB1bmlmb3JtDQogICBy YW5kb20gZGlzdHJpYnV0aW9uIGJldHdlZW4gMCBhbmQgMl4zMS0xICINCg0KRXZlbiBpZiB5b3Vy IGluaXRpYWwgcGFja2V0IG51bWJlciBpcyB0aGUgbGFyZ2VzdCBwb3NzaWJsZSwgdGhhdCBpcywg Ml4zMiwgeW91IHN0aWxsIGhhdmUgPiAyXjYzIG51bWJlcnMgbGVmdC4NCjJeNjQgPSAyXjYzICsg Ml42Mywgd2hpY2ggaXMgdGhlIHRvdGFsIG51bWJlciBvZiBwb3NzaWJsZSBwYWNrZXQgbnVtYmVy cywgYW5kIDJeNjMgKyAyXjMyIGlzIHRoZSBudW1iZXIgb2YgcGFja2V0cyB5b3UgY2FuIHNlbmQg d2l0aCB0aGlzIHdvcnN0IGNhc2UgaW5pdGlhbCBwYWNrZXQgbnVtYmVyLg0KDQotIGphbmENCg== --_000_6E58094ECC8D8344914996DAD28F1CCD8022E5DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5tc29jaHBkZWZhdWx0LCBsaS5tc29jaHBkZWZh dWx0LCBkaXYubXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTptc29jaHBkZWZhdWx0Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmVtYWlsc3R5 bGUxNw0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMTc7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvaW5zMA0KCXtt c28tc3R5bGUtbmFtZTptc29pbnM7DQoJY29sb3I6dGVhbDsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SSBzdGFydGVkIHRoZSB0aHJlYWQgc2luY2UgSSB0cmllZCB0byB1 bmRlcnN0YW5kIGhvdyB0byBjbG9zZSBhIGNvbm5lY3Rpb24gd2hlbiBwYWNrZXQgbnVtYmVyIHJl YWNoIHRoZSBlbmQuIFRoZSB0ZXh0IGRvZXMgbm90IHNwZWNpZnkgdGhpcyBjYXNlIGFuZA0KPC9z cGFuPk1hcnRpbiBUaG9tc29uIDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5jbGFpbWVkIHRo YXQgaXQgaXMgbm90IGltcG9ydGFudCBjdXJyZW50bHkgc2luY2UgdGhpcyBjYXNlIGhhcyBsb3cg cHJvYmFiaWxpdHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SXQgaXMgbXVjaCBzaW1wbGVyIHRvIGNsb3Nl IGEgY29ubmVjdGlvbiB3aGVuIHN0cmVhbSBJRHMgYXJlIGV4aGF1c3RlZCBhbmQgc3RhcnQgYSBu ZXcgY29ubmVjdGlvbiwgc28gbGVzcyB3b3JyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Um9uaSA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRv Om1pa2tlbGZqQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiA8c3BhbiBsYW5nPSJIRSIg ZGlyPSJSVEwiPteZ15XXnTwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIGRpcj0i TFRSIj48L3NwYW4+Jm5ic3A7PHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XlTwvc3Bhbj48c3Bh biBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+IDA4DQo8c3BhbiBsYW5n PSJIRSIgZGlyPSJSVEwiPteh16TXmNee15HXqDwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFu PjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+IDIwMTcgMDg6NDc8YnI+DQo8Yj5Ubzo8L2I+IFJvYmVy dG8gUGVvbjsgSmFuYSBJeWVuZ2FyOyBSb25pIEV2ZW48YnI+DQo8Yj5DYzo8L2I+IGpvZWwgamFl Z2dsaTsgUVVJQyBXRzsgTWFydGluIFRob21zb248YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IG9i c3J2dGFpb24gb24gcGFja2V0IG51bWJlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IGlkPSJjb21wb3NlLWNvbnRhaW5lciI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QSBjb25uZWN0aW9uIGEgZGF5IGlz IG5vdCBzdWZmaWNpZW50LCBidXQgdGhlIHJlYWwgcHJvYmxlbSBpcyB0aGUgc3RyZWFtIElEIHdo ZW4gc2VuZGluZyBtdWx0aXBsZSBuZXcgc3RyZWFtcyBwZXIgcGFja2FnZSAtIHdoaWNoIGhhcHBl bnMgaW4gcGFydGlhbGx5IHJlbGlhYmxlIHRyYW5zbWlzc2lvbnMNCiB3aXRoIHVuaS1kaXJlY3Rp b25hbCBzdHJlYW1zIC0geW91IGNhbiBleGhhdXN0IElEIHNwYWNlIHdpdGhpbiBob3Vycy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+TWlra2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl ciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCjxociBzaXplPSIyIiB3aWR0aD0i OTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RN c2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gUVVJQyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9h PiZndDsgb24gYmVoYWxmIG9mIFJvYmVydG8gUGVvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZlbml4 QGZiLmNvbSI+ZmVuaXhAZmIuY29tPC9hPiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks IFNlcHRlbWJlciA3LCAyMDE3IDExOjQ1OjI0IFBNPGJyPg0KPGI+VG86PC9iPiBKYW5hIEl5ZW5n YXI7IFJvbmkgRXZlbjxicj4NCjxiPkNjOjwvYj4gam9lbCBqYWVnZ2xpOyBRVUlDIFdHOyBNYXJ0 aW4gVGhvbXNvbjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogb2JzcnZ0YWlvbiBvbiBwYWNrZXQg bnVtYmVyczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29uY3JldGVseTogMl42 MyByZXByZXNlbnRzIDExLDY5MCw4NDAuOSB5ZWFycyBvZiBwYWNrZXRzIGF0IDI1a3Bwcywgb3Ig MjkyIHllYXJzIGF0IDEgR3Bwcy48YnI+DQo8YnI+DQpFdmVuIGlmIGl0IHdhcyBvbmx5IDJeMzIs IHRob3VnaCwgYSBuZXcgY29ubmVjdGlvbiBwZXIgZGF5IHdvdWxkIGJlIHJlYXNvbmFibGXigJRt YW55IHNpdGVzIHdvbuKAmXQgd2FudCB0byBtYWludGFpbiBjb25uZWN0aW9uIHN0YXRlIGZvciBz dWJzdGFudGlhbGx5IG1vcmUgdGhhbiBhIGRheSAocGVvcGxlIHVwZGF0ZSBiaW5hcmllcy9jaGFu Z2UgY29uZmlnLCBuZWVkIHRvIHNodWZmbGUgbG9hZCBhcm91bmQgdG8gZGVhbCB3aXRoIGxvYWQg YXN5bW1ldHJpZXMsDQogZXRjLikuPGJyPg0KPGJyPg0KLT1SPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5RVUlDICZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg SmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBnb29n bGUuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIFNlcHRlbWJlciA3LCAy MDE3IGF0IDI6MzYgUE08YnI+DQo8Yj5UbzogPC9iPlJvbmkgRXZlbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tIj5yb25pLmV2ZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5qb2VsIGphZWdnbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2VsamFAYm9n dXMuY29tIj5qb2VsamFAYm9ndXMuY29tPC9hPiZndDssIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1h aWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDssIE1hcnRpbiBUaG9tc29u ICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogb2JzcnZ0YWlv biBvbiBwYWNrZXQgbnVtYmVyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9uaSwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyAyXjMyIGlzbid0IGhhbGYgb2YgMl42NCwgaXQn cyBoYWxmIG9mIDJeMzMuIDI1a3BwcyBpcyAyIGJpbGxpb24gb2RkIHBhY2tldHMgYSBkYXk8YnI+ DQomZ3Q7IHdoZXJlYXMgMl42NCBpcyAxLjg0ICogMTBeMTkuPGJyPg0KW1JvbmkgRXZlbl1JIHdh cyBiYXNpbmcgaXQgb24gdGhlIHRleHQgYXNzdW1pbmcgdGhhdCBwYWNrZXQgbnVtYmVyIGRvZXMg bm90IHN0YXJ0IGF0IDAmbmJzcDsgJnF1b3Q7IFRoZSBpbml0aWFsIHZhbHVlIGZvciBwYWNrZXQg bnVtYmVyIE1VU1QgYmUgc2VsZWN0ZWQgZnJvbSBhbiB1bmlmb3JtPGJyPg0KJm5ic3A7ICZuYnNw O3JhbmRvbSBkaXN0cmlidXRpb24gYmV0d2VlbiAwIGFuZCAyXjMxLTEgJnF1b3Q7PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVu IGlmIHlvdXIgaW5pdGlhbCBwYWNrZXQgbnVtYmVyIGlzIHRoZSBsYXJnZXN0IHBvc3NpYmxlLCB0 aGF0IGlzLCAyXjMyLCB5b3Ugc3RpbGwgaGF2ZSAmZ3Q7IDJeNjMgbnVtYmVycyBsZWZ0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ml42NCA9IDJe NjMgJiM0MzsgMl42Mywgd2hpY2ggaXMgdGhlIHRvdGFsIG51bWJlciBvZiBwb3NzaWJsZSBwYWNr ZXQgbnVtYmVycywgYW5kIDJeNjMgJiM0MzsgMl4zMiBpcyB0aGUgbnVtYmVyIG9mIHBhY2tldHMg eW91IGNhbiBzZW5kIHdpdGggdGhpcyB3b3JzdCBjYXNlIGluaXRpYWwgcGFja2V0IG51bWJlci48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBq YW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E58094ECC8D8344914996DAD28F1CCD8022E5DGGEMM506MBXchina_-- From nobody Sun Sep 10 23:17:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435A5132139 for ; Sun, 10 Sep 2017 23:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Zu8YxobowP4d for ; Sun, 10 Sep 2017 23:17:42 -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 ECF9A132F7A for ; Sun, 10 Sep 2017 23:17:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOI18940; Mon, 11 Sep 2017 06:17:39 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 11 Sep 2017 07:17:38 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Mon, 11 Sep 2017 14:16:57 +0800 From: Roni Even To: QUIC WG Subject: nits in draft-ietf-quic-recovery-05 Thread-Topic: nits in draft-ietf-quic-recovery-05 Thread-Index: AdMqxLEU0GzdUweDRv23LwH2ULxahQ== Date: Mon, 11 Sep 2017 06:16:57 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8025EC@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.153] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8025ECDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59B62A84.001B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e7615b0a190505572c61edd94dfc51f7 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 06:17:44 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8025ECDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In section 3.1 the bullet before the last one "a QUIC sender marks a packet= as lost when a packet larger than it is acknowledged" should be "with high= er packet number" instead of "larger"? In section 3.2.7.4 "if (retransmittable_packets_outstanding =3D 1):" shou= ld be "=3D=3D" instead of "=3D"? Thanks Roni --_000_6E58094ECC8D8344914996DAD28F1CCD8025ECDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

In section 3.1 the bullet before the last one “= a QUIC sender marks a packet as lost when a packet larger than it is ack= nowledged” should be “with higher packet number” instead of “larger= ”?

 

In section 3.2.7.4 “if (retransmittable_packets= _outstanding =3D 1):”   should be “=3D=3D” inst= ead of “=3D”?

 

Thanks

Roni

 

 

 

--_000_6E58094ECC8D8344914996DAD28F1CCD8025ECDGGEMM506MBXchina_-- From nobody Mon Sep 11 10:46:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E164A133182 for ; Mon, 11 Sep 2017 10:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=UJrINizG; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=HKijSXua 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 hESBE4YtenEr for ; Mon, 11 Sep 2017 10:46:25 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3AD132ED1 for ; Mon, 11 Sep 2017 10:46:25 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8BHiNTX010064; Mon, 11 Sep 2017 10:46:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=tZkjlhFM3xB3AKvxlw0PGngfyFANH6toNJnkLxEdp+Q=; b=UJrINizGrzL1/Sz+f02fUW0UodMCxV4OfgtbCQRdkir6E3aLFQhyYhQ8fH3GBtG6hkkH 8E3XiTBkfqglBy3sBtJZ7zK07GrNo33y7i+e0XTrCcYxttDJeb9VbY5QR+0VlHwYFBDa Ov6yDjGavD6YaxQWNoSWGTf1+G47PQ8VEPg= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cwqxe9wyw-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Sep 2017 10:46:08 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.25) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 11 Sep 2017 13:46:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tZkjlhFM3xB3AKvxlw0PGngfyFANH6toNJnkLxEdp+Q=; b=HKijSXuawKFxuAo4jHeQlT6qWJxM1rGzZMxdgb2mh9cb5Q+81bIPnZfroqHXvJ7ioTBzIlVHHfP2XeZSPMCvmLqAJ5hUXjqBvd1chdmVvbHbVg+VnpPSdzylsylFWz9xxDuxOUY09c1WnNgJKi8ia/Ronr/586hdp+js70nPVpI= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1802.namprd15.prod.outlook.com (10.174.246.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Mon, 11 Sep 2017 17:45:47 +0000 Received: from DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) by DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) with mapi id 15.20.0035.021; Mon, 11 Sep 2017 17:45:47 +0000 From: Roberto Peon To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Jana Iyengar , Roni Even CC: joel jaeggli , QUIC WG , Martin Thomson Subject: Re: obsrvtaion on packet numbers Thread-Topic: obsrvtaion on packet numbers Thread-Index: AdMm5zHPD4iKjQeVQlG4Za1XZ0BzMQAEpzcAAChfTIAAATlfAAAANE2AACAVEwD//40yAIAA++wAgAUKcwA= Date: Mon, 11 Sep 2017 17:45:47 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> <6E58094ECC8D8344914996DAD28F1CCD801AA0@DGGEMM506-MBX.china.huawei.com> <57990B52-041C-4ABE-A8BC-CE5CF408718F@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::4:b07f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1802; 20:YxZEttbVBjHgsvedr1104SWUsaeWo5RKRJ9bSnpf70PeP5LxZW3J7Pd+t4BBvxxKkMlTHHqDaJ40Tn9HY2lscIpDTBxEIB/gTQq7+EFQDYjJrgcV4ZkfPt3Ig5HIfQffDp1xh9MV5AiFFEUxh+v5fQUhfYOffhe26iAuEmNbTIs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 82c6a7ee-c3d5-48e0-b036-08d4f93cef6e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR15MB1802; x-ms-traffictypediagnostic: DM5PR15MB1802: x-exchange-antispam-report-test: UriScan:(50582790962513)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(920507026)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1802; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1802; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(50986999)(8936002)(81156014)(105586002)(34040400001)(76176999)(3480700004)(53546010)(6506006)(54356999)(81166006)(82746002)(8676002)(39060400002)(2900100001)(5660300001)(4326008)(25786009)(6486002)(54906002)(68736007)(6246003)(102836003)(6436002)(6116002)(101416001)(2950100002)(3280700002)(3660700001)(77096006)(97736004)(36756003)(478600001)(83716003)(53936002)(189998001)(93886005)(229853002)(14454004)(7736002)(106356001)(99286003)(33656002)(54896002)(6512007)(6306002)(2906002)(86362001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1802; H:DM5PR15MB1883.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EFD0A83BF0304237917297CCA9726BF4fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2017 17:45:47.5351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1802 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-11_06:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 17:46:28 -0000 --_000_EFD0A83BF0304237917297CCA9726BF4fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlra2Vs4oCUDQoNCk5vdCBzdXJlIHdoYXQgeW91IG1lYW4sIHNpbmNlIGl04oCZZCB0YWtlIH4x MSBtaWxsaW9uIHllYXJzIGF0IDY1MDAwIHBhY2tldHMvc2Vjb25kIHRvIGV4aGF1c3QgdGhlIElE IHNwYWNlLiBJZiB5b3UgdXNlZCB1cCA0IElEcyBwZXIgc3RyZWFtLCBpdCBpcyBzdGlsbCA+IDIg bWlsbGlvbiB5ZWFycy4NCg0KQW0gSSBtaXN1bmRlcnN0YW5kaW5nPw0KDQotPVINCg0KDQpGcm9t OiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+DQpEYXRlOiBU aHVyc2RheSwgU2VwdGVtYmVyIDcsIDIwMTcgYXQgMTA6NDcgUE0NClRvOiBSb2JlcnRvIFBlb24g PGZlbml4QGZiLmNvbT4sIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+LCBSb25pIEV2ZW4g PHJvbmkuZXZlbkBodWF3ZWkuY29tPg0KQ2M6IGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNv bT4sIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+LCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21z b25AZ21haWwuY29tPg0KU3ViamVjdDogUmU6IG9ic3J2dGFpb24gb24gcGFja2V0IG51bWJlcnMN Cg0KQSBjb25uZWN0aW9uIGEgZGF5IGlzIG5vdCBzdWZmaWNpZW50LCBidXQgdGhlIHJlYWwgcHJv YmxlbSBpcyB0aGUgc3RyZWFtIElEIHdoZW4gc2VuZGluZyBtdWx0aXBsZSBuZXcgc3RyZWFtcyBw ZXIgcGFja2FnZSAtIHdoaWNoIGhhcHBlbnMgaW4gcGFydGlhbGx5IHJlbGlhYmxlIHRyYW5zbWlz c2lvbnMgd2l0aCB1bmktZGlyZWN0aW9uYWwgc3RyZWFtcyAtIHlvdSBjYW4gZXhoYXVzdCBJRCBz cGFjZSB3aXRoaW4gaG91cnMuDQoNCk1pa2tlbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg Um9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDcs IDIwMTcgMTE6NDU6MjQgUE0NClRvOiBKYW5hIEl5ZW5nYXI7IFJvbmkgRXZlbg0KQ2M6IGpvZWwg amFlZ2dsaTsgUVVJQyBXRzsgTWFydGluIFRob21zb24NClN1YmplY3Q6IFJlOiBvYnNydnRhaW9u IG9uIHBhY2tldCBudW1iZXJzDQoNCkNvbmNyZXRlbHk6IDJeNjMgcmVwcmVzZW50cyAxMSw2OTAs ODQwLjkgeWVhcnMgb2YgcGFja2V0cyBhdCAyNWtwcHMsIG9yIDI5MiB5ZWFycyBhdCAxIEdwcHMu DQoNCkV2ZW4gaWYgaXQgd2FzIG9ubHkgMl4zMiwgdGhvdWdoLCBhIG5ldyBjb25uZWN0aW9uIHBl ciBkYXkgd291bGQgYmUgcmVhc29uYWJsZeKAlG1hbnkgc2l0ZXMgd29u4oCZdCB3YW50IHRvIG1h aW50YWluIGNvbm5lY3Rpb24gc3RhdGUgZm9yIHN1YnN0YW50aWFsbHkgbW9yZSB0aGFuIGEgZGF5 IChwZW9wbGUgdXBkYXRlIGJpbmFyaWVzL2NoYW5nZSBjb25maWcsIG5lZWQgdG8gc2h1ZmZsZSBs b2FkIGFyb3VuZCB0byBkZWFsIHdpdGggbG9hZCBhc3ltbWV0cmllcywgZXRjLikuDQoNCi09Ug0K DQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKYW5hIEl5 ZW5nYXIgPGpyaUBnb29nbGUuY29tPg0KRGF0ZTogVGh1cnNkYXksIFNlcHRlbWJlciA3LCAyMDE3 IGF0IDI6MzYgUE0NClRvOiBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPg0KQ2M6IGpv ZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT4sIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+LCBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KU3ViamVjdDogUmU6IG9i c3J2dGFpb24gb24gcGFja2V0IG51bWJlcnMNCg0KUm9uaSwNCg0KPiAyXjMyIGlzbid0IGhhbGYg b2YgMl42NCwgaXQncyBoYWxmIG9mIDJeMzMuIDI1a3BwcyBpcyAyIGJpbGxpb24gb2RkIHBhY2tl dHMgYSBkYXkNCj4gd2hlcmVhcyAyXjY0IGlzIDEuODQgKiAxMF4xOS4NCltSb25pIEV2ZW5dSSB3 YXMgYmFzaW5nIGl0IG9uIHRoZSB0ZXh0IGFzc3VtaW5nIHRoYXQgcGFja2V0IG51bWJlciBkb2Vz IG5vdCBzdGFydCBhdCAwICAiIFRoZSBpbml0aWFsIHZhbHVlIGZvciBwYWNrZXQgbnVtYmVyIE1V U1QgYmUgc2VsZWN0ZWQgZnJvbSBhbiB1bmlmb3JtDQogICByYW5kb20gZGlzdHJpYnV0aW9uIGJl dHdlZW4gMCBhbmQgMl4zMS0xICINCg0KRXZlbiBpZiB5b3VyIGluaXRpYWwgcGFja2V0IG51bWJl ciBpcyB0aGUgbGFyZ2VzdCBwb3NzaWJsZSwgdGhhdCBpcywgMl4zMiwgeW91IHN0aWxsIGhhdmUg PiAyXjYzIG51bWJlcnMgbGVmdC4NCjJeNjQgPSAyXjYzICsgMl42Mywgd2hpY2ggaXMgdGhlIHRv dGFsIG51bWJlciBvZiBwb3NzaWJsZSBwYWNrZXQgbnVtYmVycywgYW5kIDJeNjMgKyAyXjMyIGlz IHRoZSBudW1iZXIgb2YgcGFja2V0cyB5b3UgY2FuIHNlbmQgd2l0aCB0aGlzIHdvcnN0IGNhc2Ug aW5pdGlhbCBwYWNrZXQgbnVtYmVyLg0KDQotIGphbmENCg== --_000_EFD0A83BF0304237917297CCA9726BF4fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <979FBF72D3ACFA4EBE62A4CC620854D5@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29jaHBkZWZhdWx0 LCBsaS5tc29jaHBkZWZhdWx0LCBkaXYubXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTpt c29jaHBkZWZhdWx0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5lbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxzdHlsZTE3Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29p bnMNCgl7bXNvLXN0eWxlLW5hbWU6bXNvaW5zOw0KCWNvbG9yOnRlYWw7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6 dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlra2Vs4oCU PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCBzdXJlIHdoYXQgeW91IG1lYW4sIHNpbmNlIGl0 4oCZZCB0YWtlIH4xMSBtaWxsaW9uIHllYXJzIGF0IDY1MDAwIHBhY2tldHMvc2Vjb25kIHRvIGV4 aGF1c3QgdGhlIElEIHNwYWNlLiBJZiB5b3UgdXNlZCB1cCA0IElEcyBwZXIgc3RyZWFtLCBpdCBp cyBzdGlsbCAmZ3Q7IDIgbWlsbGlvbiB5ZWFycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCkFtIEkgbWlzdW5kZXJzdGFuZGluZz88YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi09Ujxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNl biAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwg U2VwdGVtYmVyIDcsIDIwMTcgYXQgMTA6NDcgUE08YnI+DQo8Yj5UbzogPC9iPlJvYmVydG8gUGVv biAmbHQ7ZmVuaXhAZmIuY29tJmd0OywgSmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZn dDssIFJvbmkgRXZlbiAmbHQ7cm9uaS5ldmVuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj5qb2VsIGphZWdnbGkgJmx0O2pvZWxqYUBib2d1cy5jb20mZ3Q7LCBRVUlDIFdHICZsdDtxdWlj QGlldGYub3JnJmd0OywgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IG9ic3J2dGFpb24gb24gcGFja2V0IG51bWJl cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iY29tcG9zZS1jb250 YWluZXIiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGNvbm5lY3Rpb24g YSBkYXkgaXMgbm90IHN1ZmZpY2llbnQsIGJ1dCB0aGUgcmVhbCBwcm9ibGVtIGlzIHRoZSBzdHJl YW0gSUQgd2hlbiBzZW5kaW5nIG11bHRpcGxlIG5ldyBzdHJlYW1zIHBlciBwYWNrYWdlIC0gd2hp Y2ggaGFwcGVucyBpbiBwYXJ0aWFsbHkgcmVsaWFibGUgdHJhbnNtaXNzaW9ucyB3aXRoIHVuaS1k aXJlY3Rpb25hbCBzdHJlYW1zIC0geW91IGNhbiBleGhhdXN0IElEIHNwYWNlIHdpdGhpbg0KIGhv dXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NaWtrZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIi Pg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2 IGlkPSJkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ IFFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFJvYmVydG8g UGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgU2Vw dGVtYmVyIDcsIDIwMTcgMTE6NDU6MjQgUE08YnI+DQo8Yj5Ubzo8L2I+IEphbmEgSXllbmdhcjsg Um9uaSBFdmVuPGJyPg0KPGI+Q2M6PC9iPiBqb2VsIGphZWdnbGk7IFFVSUMgV0c7IE1hcnRpbiBU aG9tc29uPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBvYnNydnRhaW9uIG9uIHBhY2tldCBudW1i ZXJzPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNvbmNyZXRlbHk6IDJeNjMgcmVwcmVzZW50cyAxMSw2OTAsODQwLjkg eWVhcnMgb2YgcGFja2V0cyBhdCAyNWtwcHMsIG9yIDI5MiB5ZWFycyBhdCAxIEdwcHMuPGJyPg0K PGJyPg0KRXZlbiBpZiBpdCB3YXMgb25seSAyXjMyLCB0aG91Z2gsIGEgbmV3IGNvbm5lY3Rpb24g cGVyIGRheSB3b3VsZCBiZSByZWFzb25hYmxl4oCUbWFueSBzaXRlcyB3b27igJl0IHdhbnQgdG8g bWFpbnRhaW4gY29ubmVjdGlvbiBzdGF0ZSBmb3Igc3Vic3RhbnRpYWxseSBtb3JlIHRoYW4gYSBk YXkgKHBlb3BsZSB1cGRhdGUgYmluYXJpZXMvY2hhbmdlIGNvbmZpZywgbmVlZCB0byBzaHVmZmxl IGxvYWQgYXJvdW5kIHRvIGRlYWwgd2l0aCBsb2FkIGFzeW1tZXRyaWVzLA0KIGV0Yy4pLjxicj4N Cjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UVVJ QyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSmFuYSBJeWVuZ2Fy ICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIFNlcHRl bWJlciA3LCAyMDE3IGF0IDI6MzYgUE08YnI+DQo8Yj5UbzogPC9iPlJvbmkgRXZlbiAmbHQ7cm9u aS5ldmVuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5qb2VsIGphZWdnbGkgJmx0O2pv ZWxqYUBib2d1cy5jb20mZ3Q7LCBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OywgTWFydGlu IFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IG9ic3J2dGFpb24gb24gcGFja2V0IG51bWJlcnM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvbmksIDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsgMl4zMiBpc24n dCBoYWxmIG9mIDJeNjQsIGl0J3MgaGFsZiBvZiAyXjMzLiAyNWtwcHMgaXMgMiBiaWxsaW9uIG9k ZCBwYWNrZXRzIGEgZGF5PGJyPg0KJmd0OyB3aGVyZWFzIDJeNjQgaXMgMS44NCAqIDEwXjE5Ljxi cj4NCltSb25pIEV2ZW5dSSB3YXMgYmFzaW5nIGl0IG9uIHRoZSB0ZXh0IGFzc3VtaW5nIHRoYXQg cGFja2V0IG51bWJlciBkb2VzIG5vdCBzdGFydCBhdCAwJm5ic3A7ICZxdW90OyBUaGUgaW5pdGlh bCB2YWx1ZSBmb3IgcGFja2V0IG51bWJlciBNVVNUIGJlIHNlbGVjdGVkIGZyb20gYW4gdW5pZm9y bTxicj4NCiZuYnNwOyAmbmJzcDtyYW5kb20gZGlzdHJpYnV0aW9uIGJldHdlZW4gMCBhbmQgMl4z MS0xICZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RXZlbiBpZiB5b3VyIGluaXRpYWwgcGFja2V0IG51bWJlciBpcyB0aGUg bGFyZ2VzdCBwb3NzaWJsZSwgdGhhdCBpcywgMl4zMiwgeW91IHN0aWxsIGhhdmUgJmd0OyAyXjYz IG51bWJlcnMgbGVmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjJeNjQgPSAyXjYzICYjNDM7IDJeNjMsIHdoaWNoIGlzIHRoZSB0b3RhbCBudW1i ZXIgb2YgcG9zc2libGUgcGFja2V0IG51bWJlcnMsIGFuZCAyXjYzICYjNDM7IDJeMzIgaXMgdGhl IG51bWJlciBvZiBwYWNrZXRzIHlvdSBjYW4gc2VuZCB3aXRoIHRoaXMgd29yc3QgY2FzZSBpbml0 aWFsIHBhY2tldCBudW1iZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0gamFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EFD0A83BF0304237917297CCA9726BF4fbcom_-- From nobody Mon Sep 11 11:15:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70E51331BA for ; Mon, 11 Sep 2017 11:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6_ERbPokYLD8 for ; Mon, 11 Sep 2017 11:15:22 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518D2133191 for ; Mon, 11 Sep 2017 11:15:22 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id v36so18777763ioi.1 for ; Mon, 11 Sep 2017 11:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=jizGyMaNYVnOxb7uBJPMaU/5VeviauEuVVzDYkhze+E=; b=W39mhCe3t+zPIWIgfttYz4w5OiF43/M09tGbhLT2PQ0Uh0qR9UQAuq6i6cGXiPNzRG nCMx80lypuERUlL/keOZ6Os0sebYxOTF/CpBdBmw3QB/J1LTGPYvS4shwSDCdALnTwEK 3wlO2arxDdnhr8aTSkPr7F+MmjjJQmfMEYMegiCPo10lKXiYP2rh/cWuHcH+VLDnx3bY mdae08mDPq3oZLOVXMYnwFAis5De8N3w2q3v7cLqRq0djlt1jpv50KCHA312LmsuXbOP E7E7eXyULzH+uiYVfjWUi44adrYLdeogFWpEo/0eDoWDsZioKul9jPBhnwTgGm5efvKb sDVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=jizGyMaNYVnOxb7uBJPMaU/5VeviauEuVVzDYkhze+E=; b=McwqsC41DKsYzLYAgae/Pfb0LW/XcxpV9dajjDYJCSZz6aoLUv2cxAl6h2o479LTwI uRo+DTkPItVtSK7rf9a5Sr1tjcRy4yp9zAs58tD/CYEuHsB4eYXs2KOqKRYUmMNSHcmM NCevZyvkovYFerywk03nkEbs/ZP25nZJIjBjZHifWcD2BL9fQlgYVEddkLFW2QTJd+VU WKhfjWHjWH10Vinf240GJBdJR2m5EebYo09zqTEWFh34BfOfCpaJhEIMCAHwqI9Y7cId 0L37UU18svaAMBVBG5Fj8Rt/JaKSecmCBV7hMtSWCZkzI+cJIiGk3XBG9iI5kKHHnyEK K3dQ== X-Gm-Message-State: AHPjjUhh0xSxDA2CrbzALneC0+UY2fVjdM3ofbPi7aC1YZdjacjJOMi4 ls62CmARADyUgM9BKeVt6SqBgZVWyQ== X-Google-Smtp-Source: AOwi7QA7mGLbyGdib6SYaSBd78TX5V5K5M5NpoyJ+pyTjCiilNnc2b/UNu5ttB7V7MvkHRestGEUvRqTCccDKQbbkaY= X-Received: by 10.107.166.206 with SMTP id p197mr5224995ioe.63.1505153721621; Mon, 11 Sep 2017 11:15:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 11 Sep 2017 11:15:20 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD801A59@DGGEMM506-MBX.china.huawei.com> <98fdd08c-553a-8dd0-b900-105c6096998b@bogus.com> <6E58094ECC8D8344914996DAD28F1CCD801AA0@DGGEMM506-MBX.china.huawei.com> <57990B52-041C-4ABE-A8BC-CE5CF408718F@fb.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 11 Sep 2017 11:15:20 -0700 Message-ID: Subject: Re: obsrvtaion on packet numbers To: Roni Even , Roberto Peon , Jana Iyengar Cc: Martin Thomson , joel jaeggli , QUIC WG Content-Type: multipart/alternative; boundary="001a1141d082e8e3850558ede8f0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 18:15:30 -0000 --001a1141d082e8e3850558ede8f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Robert, there is another thread on unreliable streams where this is covered, but I=E2=80=99ll try to summarise: With uni-directional streams (otherwise overhead is unfeasible) you can manage streams as paired bi-directional streams, or as uni-directional streams where you continuously add more frames over time, or (which is relevant here) you can create a virtual stream where each new frame gets a new stream id but the application stores a virtual stream id at the start of each frame. There is no virtual stream id concept in QUIC, but applications can meaningfully implement it and it makes just as much sense as adding message headers within a single stream. With a virtual stream id you can afford to loose some frames while maintaining ordering because each stream id will be larger than the previous. This could be used for video frames where you don=E2=80=99t care = about older frames that do not get through in time and you don=E2=80=99t want retransmission to block more recent frames. Video frames are large, but you can have other frame types that are small, such as stock tickers. In the above, you can churn a lot of frames. Another scenario is a lot of independent but small messages, such as neutron beam detection. A packet has about 1200 bytes payload and may have 100 stream ids per packet. You can move about 1000 packets per second and thus 100K messages per second. With a bit more bandwidth you easily get 1 million messages per second and thus 1 million frames per second. If you don=E2=80=99t have partial reliability as per virtual stream id exam= ple above, you might cause a massive traffic jam on a simple packet retransmission, so you do not want to send all the messages in the same stream - then you might just as well have used TCP instead. With 1 million messages per second you run out of IDs in roughly 4000 seconds or little more than 1 hour because the stream ID space is unsigned 32 bit. If you only pass 65000 messages per second you have 2^32 / 65000 / 3600 hours =3D 18 hours which is still short enough to having to care about implementing reconnection logic. Because that many messages need to be short, it makes sense to use a stream id format that is compressed but which can express significantly more than 32 bits. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 11 September 2017 at 19.46.19, Roberto Peon (fenix@fb.com) wrote: Mikkel=E2=80=94 Not sure what you mean, since it=E2=80=99d take ~11 million years at 65000 packets/second to exhaust the ID space. If you used up 4 IDs per stream, it is still > 2 million years. Am I misunderstanding? -=3DR *From: *Mikkel Fahn=C3=B8e J=C3=B8rgensen *Date: *Thursday, September 7, 2017 at 10:47 PM *To: *Roberto Peon , Jana Iyengar , Roni Even *Cc: *joel jaeggli , QUIC WG , Martin Thomson *Subject: *Re: obsrvtaion on packet numbers A connection a day is not sufficient, but the real problem is the stream ID when sending multiple new streams per package - which happens in partially reliable transmissions with uni-directional streams - you can exhaust ID space within hours. Mikkel ------------------------------ *From:* QUIC on behalf of Roberto Peon *Sent:* Thursday, September 7, 2017 11:45:24 PM *To:* Jana Iyengar; Roni Even *Cc:* joel jaeggli; QUIC WG; Martin Thomson *Subject:* Re: obsrvtaion on packet numbers Concretely: 2^63 represents 11,690,840.9 years of packets at 25kpps, or 292 years at 1 Gpps. Even if it was only 2^32, though, a new connection per day would be reasonable=E2=80=94many sites won=E2=80=99t want to maintain connection sta= te for substantially more than a day (people update binaries/change config, need to shuffle load around to deal with load asymmetries, etc.). -=3DR *From: *QUIC on behalf of Jana Iyengar < jri@google.com> *Date: *Thursday, September 7, 2017 at 2:36 PM *To: *Roni Even *Cc: *joel jaeggli , QUIC WG , Martin Thomson *Subject: *Re: obsrvtaion on packet numbers Roni, > 2^32 isn't half of 2^64, it's half of 2^33. 25kpps is 2 billion odd packets a day > whereas 2^64 is 1.84 * 10^19. [Roni Even]I was basing it on the text assuming that packet number does not start at 0 " The initial value for packet number MUST be selected from an uniform random distribution between 0 and 2^31-1 " Even if your initial packet number is the largest possible, that is, 2^32, you still have > 2^63 numbers left. 2^64 =3D 2^63 + 2^63, which is the total number of possible packet numbers, and 2^63 + 2^32 is the number of packets you can send with this worst case initial packet number. - jana --001a1141d082e8e3850558ede8f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi Robert,

there is another thread on unreliable streams where this is= covered, but I=E2=80=99ll try to summarise:

With uni-directional streams (otherwise overhead is= unfeasible) you can manage streams as paired bi-directional streams, or as= uni-directional streams where you continuously add more frames over time, = or (which is relevant here) you can create a virtual stream where each new = frame gets a new stream id but the application stores a virtual stream id a= t the start of each frame. There is no virtual stream id concept in QUIC, b= ut applications can meaningfully implement it and it makes just as much sen= se as adding message headers within a single stream.

With a virtual stream id you can afford to = loose some frames while maintaining ordering because each stream id will be= larger than the previous. This could be used for video frames where you do= n=E2=80=99t care about older frames that do not get through in time and you= don=E2=80=99t want retransmission to block more recent frames. Video frame= s are large, but you can have other frame types that are small, such as sto= ck tickers.
<= br>
In the ab= ove, you can churn a lot of frames. Another scenario is a lot of independen= t but small messages, such as neutron beam detection.

A packet has about 1200 bytes payload and = may have 100 stream ids per packet.
You can move about 1000 packets per second and thus = 100K messages per second. With a bit more bandwidth you easily get 1 millio= n messages per second and thus 1 million frames per second.

If you don=E2=80=99t have partial re= liability as per virtual stream id example above, you might cause a massive= traffic jam on a simple packet retransmission, so you do not want to send = all the messages in the same stream - then you might just as well have used= TCP instead.

With 1 = million messages per second you run out of IDs in roughly 4000 seconds or l= ittle more than 1 hour because the stream ID space is unsigned 32 bit.

If you only pass 65000 me= ssages per second you have 2^32 / 65000 / 3600 hours =3D 18 hours which is = still short enough to having to care about implementing reconnection logic.=

Because that many messages need to be short, it makes= sense to use a stream id format that is compressed but which can express s= ignificantly more than 32 bits.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 11 September 2017 at 19.46.19, Roberto Peon (fenix@fb.com) wrote:

Mikkel=E2=80=94

=C2=A0

Not sure what you mean, since it=E2=80=99d take ~11 = million years at 65000 packets/second to exhaust the ID space. If you used = up 4 IDs per stream, it is still > 2 million years.


Am I misunderstanding?

-=3DR

=C2=A0

From= : Mikkel Fahn=C3=B8= e J=C3=B8rgensen <mikkelfj@gmail.c= om>
Date: Thursday, September 7, 2017 at 10:47 PM
To: Roberto Peon <fenix@fb.com>, Jana Iyengar <jri@google.com>, Roni Even <roni.even@huaw= ei.com>
Cc: joel jaeggli <joelja@bogu= s.com>, QUIC WG <quic@ietf.org>, Martin Thomson <mart= in.thomson@gmail.com>
Subject: Re: obsrvtaion on packet numbers

=C2=A0

A connection a day is not sufficient, but the real p= roblem is the stream ID when sending multiple new streams per package - whi= ch happens in partially reliable transmissions with uni-directional streams= - you can exhaust ID space within hours.

=C2=A0

Mikkel

=C2=A0

From: QUIC <q= uic-bounces@ietf.org> on behalf of Roberto Peon <fenix@fb.com>
Sent: Thursday, September 7, 2017 11:45:24 PM
To: Jana Iyengar; Roni Even
Cc: joel jaeggli; QUIC WG; Martin Thomson
Subject: Re: obsrvtaion on packet numbers

=C2=A0

Concretely: 2^63 represents 11,690,840.9 years of pa= ckets at 25kpps, or 292 years at 1 Gpps.

Even if it was only 2^32, though, a new connection per day would be reasona= ble=E2=80=94many sites won=E2=80=99t want to maintain connection state for = substantially more than a day (people update binaries/change config, need t= o shuffle load around to deal with load asymmetries, etc.).

-=3DR

=C2=A0

From= : QUIC <quic-bounces@ietf.org> on behalf o= f Jana Iyengar <jri@google.com>=
Date: Thursday, September 7, 2017 at 2:36 PM
To: Roni Even <roni.even@= huawei.com>
Cc: joel jaeggli <joelja@bogu= s.com>, QUIC WG <quic@ietf.org>, Martin Thomson <mart= in.thomson@gmail.com>
Subject: Re: obsrvtaion on packet numbers

=C2=A0

Roni,


> 2^32 isn't half of 2^64, it's half of 2^33. 25kpps is 2 billio= n odd packets a day
> whereas 2^64 is 1.84 * 10^19.
[Roni Even]I was basing it on the text assuming that packet number does not= start at 0=C2=A0 " The initial value for packet number MUST be select= ed from an uniform
=C2=A0 =C2=A0random distribution between 0 and 2^31-1 "

=C2=A0

Even if your initial packet number is the largest po= ssible, that is, 2^32, you still have > 2^63 numbers left.

2^64 =3D 2^63 + 2^63, which is the total number of p= ossible packet numbers, and 2^63 + 2^32 is the number of packets you can se= nd with this worst case initial packet number.

=C2=A0

- jana

--001a1141d082e8e3850558ede8f0-- From nobody Mon Sep 11 11:45:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838B4132697 for ; Mon, 11 Sep 2017 11:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 XQYGNyJ4LZy6 for ; Mon, 11 Sep 2017 11:44:59 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9712132ECF for ; Mon, 11 Sep 2017 11:44:57 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id v66so16789783pgb.5 for ; Mon, 11 Sep 2017 11:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lnFYfsq0pGr9rCZI6UrSkFjusAf0HtUZOQFmg4IQq68=; b=OwWMa5v0gwtlrsnTKt2fpPk1v6veyNPR25hR8Wn9qS+3WiVMaiFillZ//i9QZs8Qkq cB4Gb2Jwcp5uQcmREf7xWls0h4MqVX7UV8fjZ42lC5Zi8GPLvUyTewWiym/MV9SCwTKQ 18bc+NbfYUkGdBSNNOpSqF73/ESw7ghegUN1x3mi+5OUOUFaJU0dLbu4Q4hTBTJPicCH rv82QXQPp5OEZ62RZfSLyD/1itnok65jj5M7EUVa1wnvLuJpnxBIukTOnDCf5wPGRs2w HgnvLA/szy7uU7dRV8aSq9VI+jGyuL6jJjZq5qbkgUfiFZqEoJgCTaRMw12PakoPUtEx 222A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lnFYfsq0pGr9rCZI6UrSkFjusAf0HtUZOQFmg4IQq68=; b=bJ09c6fxAjPawFGgrdvctlH8cQPboMfAyBJM4PC8XWTFV3bX8MF3Oi+JrNHGDMqFCu n3XRxw7/QJgyw/bmYAnhQPK7kYHdkzA7ka5pC0/8M/VhLZ5x1p7HNtZ7V40TuaGOnUe1 5RQHOsMdI79UvhaP9k/KAG6FqkctuB5OwS9XipKx2do3ojmFqUjcrr//nsX9wBlYVHpa qPWsSjU6tQxbLE5WeExyMZZeE5ap9MZdFEndfY4OOUUNolbFw4+Wq1wY/8eqc/AK7NXO IFcuMkLHcQ+D2sjUKsuxD8Q8hdjqApOCd350rHNTZ/W/+XtcNm+r+aDMCNAvVp7SVbJk WBPQ== X-Gm-Message-State: AHPjjUhQtCq86fj8CbAqhWd83yKNUyCgKEUF3/e5tNAnrZJzT1M6dh4h do8rR0Gx/Xdm+SGaxBOTqslE2TU+z7yP X-Google-Smtp-Source: ADKCNb7gC2XW2ovvRHKEpa+Jm22YgPcxsJf4T25HBARadz/ByGxgiz7FneJGGydr11NA/56FekifPzFXgNBIS6RAoWc= X-Received: by 10.84.211.39 with SMTP id b36mr2196087pli.330.1505155497019; Mon, 11 Sep 2017 11:44:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.144 with HTTP; Mon, 11 Sep 2017 11:44:56 -0700 (PDT) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8025EC@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD8025EC@DGGEMM506-MBX.china.huawei.com> From: Jana Iyengar Date: Mon, 11 Sep 2017 11:44:56 -0700 Message-ID: Subject: Re: nits in draft-ietf-quic-recovery-05 To: Roni Even Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c093b26bbb3b70558ee5277" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 18:45:01 -0000 --94eb2c093b26bbb3b70558ee5277 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roni, Thanks for your careful read of the draft! > In section 3.1 the bullet before the last one =E2=80=9Ca QUIC sender mark= s a > packet as lost when a packet larger than it is acknowledged=E2=80=9D shou= ld be > =E2=80=9Cwith higher packet number=E2=80=9D instead of =E2=80=9Clarger=E2= =80=9D? > We've consistently used "larger" packet number, so I'm inclined to stick with that, even if "higher" is slightly more correct? In section 3.2.7.4 =E2=80=9Cif (retransmittable_packets_outstanding =3D 1):= =E2=80=9D should > be =E2=80=9C=3D=3D=E2=80=9D instead of =E2=80=9C=3D=E2=80=9D? > I'll fix this. Thanks! - jana --94eb2c093b26bbb3b70558ee5277 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roni,

Thanks for your careful read o= f the draft!

In section 3.1 the bullet before the last one =E2=80= =9Ca QUIC sender marks a packet as lost when a packet larger than it is = acknowledged=E2=80=9D should be =E2=80=9Cwith higher packet number=E2=80=9D instead of =E2=80=9C= larger=E2=80=9D?

We've consiste= ntly used "larger" packet number, so I'm inclined to stick wi= th that, even if "higher" is slightly more correct?

In section 3.2.7.4 =E2=80=9Cif (= retransmittable_packets_outstanding =3D 1):=E2=80=9D =C2=A0=C2=A0shoul= d be =E2=80=9C=3D=3D=E2=80=9D instead of =E2=80=9C=3D=E2=80=9D?

<= /div>
I'll fix this.

Th= anks!
- jana
--94eb2c093b26bbb3b70558ee5277-- From nobody Mon Sep 11 14:30:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489E9132F61 for ; Mon, 11 Sep 2017 14:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DjhUvmKh3MlM for ; Mon, 11 Sep 2017 14:30:44 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FDB132D6A for ; Mon, 11 Sep 2017 14:30:44 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id v36so22428390ioi.1 for ; Mon, 11 Sep 2017 14:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RIeYqxvLO56x7K3xvB0+SNYj/YM9mI3DOmw0Q2QVqe4=; b=fRQlbkNll2MxDLXVS5Ypa+gimH0sQKt47Zg0MUklCs1XvL6sE0xhz1S68SwXy73IiE PWl71touftVaCCgZQ950oyCXrQ8UytqohWWoKSjNsIt/ErRyRdYNbp5N7m/9P1p6kLnC ChZ7YP5o6Gao8vz4CHGdACIXHCwUq5KsiNOkEiQCBo3A1eqj/UWo3HS9KaIKMqWvWx14 JSUdr0I3fXU5kHEmQPz6xuFPSJAAX7pswr63RU7vagDSKO5NFsSI+BaWkzk3MxeeNueT lAe40xcUdLEA/McHZOSDYvsU8ZisQH19dcbVxRMiRpCGGGUihrHuseTdiylXiCwRljy0 9Ijw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RIeYqxvLO56x7K3xvB0+SNYj/YM9mI3DOmw0Q2QVqe4=; b=YrXFYwpG3VqMmkMhNUqWCkhUk2F9Gw9O5VIkYdPgJHvGhB5mif/V5gmu12bjBC8Eku uNHUhD/BQO9oxYstapUviCVHKhgDku7xjnkmDwZF2/J0bGEW3oRS4HRvRNeyQMwsvlb+ niHUC/ITedG5NbCqdsZWJJ/fIeZt2LRHMe8dOgW7nnkN52QBJq20/u8VYjyXCbnHTT0C yu36xLW7tRVLTwGqtJ+0hZeoUryUlUAdcu/h1YNGDTynxbU2Mm4oUnFqDQ0obLbY8A5g xCX4IiMbI7nSxYdMPLUZNM1JO5LPYvhuPHZZfS68BvUmVLHRmEyUjCw4cFZnANgJ+EMm 5Lvw== X-Gm-Message-State: AHPjjUgvEesOuKWA3OF0m+XGPCSG71ABQkDKsEAM5YvYlyyWhSh+bzMD ZhVwwARfyqDwNLRM9WT8O9Xtnc4KDA== X-Google-Smtp-Source: AOwi7QCrjOig+Ind6Zpp9cpyQXscoPEoY9EHwIhAW++jk/y0BSD6HniJP4Po+F4busTlQ7Pf+yQsbYn7kAdbXMovrdo= X-Received: by 10.107.162.145 with SMTP id l139mr1767859ioe.193.1505165444231; Mon, 11 Sep 2017 14:30:44 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.138.137 with HTTP; Mon, 11 Sep 2017 14:30:43 -0700 (PDT) Received: by 10.107.138.137 with HTTP; Mon, 11 Sep 2017 14:30:43 -0700 (PDT) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD8025EC@DGGEMM506-MBX.china.huawei.com> From: Matthew Kerwin Date: Tue, 12 Sep 2017 07:30:43 +1000 X-Google-Sender-Auth: 2tDVLCjPf42yPtKYl4LbM3l0EFU Message-ID: Subject: Re: nits in draft-ietf-quic-recovery-05 To: Jana Iyengar Cc: Roni Even , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1140feaaa1b7700558f0a3af" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 21:30:47 -0000 --001a1140feaaa1b7700558f0a3af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 12 Sep. 2017 04:45, "Jana Iyengar" wrote: Hi Roni, Thanks for your careful read of the draft! > In section 3.1 the bullet before the last one =E2=80=9Ca QUIC sender mark= s a > packet as lost when a packet larger than it is acknowledged=E2=80=9D shou= ld be > =E2=80=9Cwith higher packet number=E2=80=9D instead of =E2=80=9Clarger=E2= =80=9D? > We've consistently used "larger" packet number, so I'm inclined to stick with that, even if "higher" is slightly more correct? A "larger packet", and a "packet with a higher/larger/greater/whatever id" are two different things. I think that's the contention. Cheers -- Matthew Kerwin --001a1140feaaa1b7700558f0a3af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 12 Sep. 2017 04:45, "Jana Iyengar" <jri@google.com> wrote:
Hi Roni,

Thanks for your careful read of the draft!

In section 3.1 the bullet be= fore the last one =E2=80=9Ca QUIC sender marks a packet as lost when a p= acket larger than it is acknowledged=E2=80=9D should be =E2=80=9Cwith higher packet number=E2=80=9D instead of =E2=80=9C= larger=E2=80=9D?

We've co= nsistently used "larger" packet number, so I'm inclined to st= ick with that, even if "higher" is slightly more correct?


A &quo= t;larger packet", and a "packet with a higher/larger/greater/what= ever id" are two different things. I think that's the contention.<= /div>

Cheers
--<= /div>
Matthew Kerwin=C2=A0
--001a1140feaaa1b7700558f0a3af-- From nobody Mon Sep 11 14:41:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96523132F67 for ; Mon, 11 Sep 2017 14:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 RVuWwS32EODn for ; Mon, 11 Sep 2017 14:41:32 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169341320CF for ; Mon, 11 Sep 2017 14:41:32 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id q76so2219375pfq.2 for ; Mon, 11 Sep 2017 14:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z8hvQm6gWGsfYmaqPhYNkpcvrDKxBBR1TdLnw0ya41Q=; b=MK4pDJL+aV/lXuazop7wWHmid8nWl9CWSMo3X2j8nKZgkdEzXhZ3ErcB0m9FqK8qpF psExFKgYGcd0LnX0fvPhNbi+oEmUNMmfnrlThvTYKkPv98yqaNOalR7xFuOesNh/7GXQ SXDn0m43QJr6TbniKS4pe381EpN/rVKCzO4P2wR2Zs0sLpQmtawlQWnobDAuLRvI1w9E zQKu+fhPfzny+lDQf0u1yuVh5SynqLYHaFPZkrnzF5v/5BBNfk9ueCZNGC5gz+DMycRI TgXQvgTUf8Z3CKrNSPX1F6/1OgGawcoza4FNfLqFttMJU8oeLzoAXXdLMcTzT8PtNSeo qt4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z8hvQm6gWGsfYmaqPhYNkpcvrDKxBBR1TdLnw0ya41Q=; b=k36m6WGKXIz/l57U2QOwK/tlAX1yVeev/vfaD0cS+wkcDHeUGxw4F0GHJPYl3v8CU3 ryD9cZI22yXLvhmigpvKdAyatnMZEpVR1rRG/oL4lPKxUr0UlFq9YnMkDwDYuJLSiJvc 6YrovnW6bUqfquCKSBgG1pDTKLgGm8TSHd/2KEmS4hnB+y+J4ePMAiv4EWC89N0laBFY oNSccDkkDDuBKb9gOxY+fSu109/ju+dYIDz/H1daZExsesvO7t+QMFryCtpUn/wGy58d GsBs/ZessyeNdwJu7PGOwr68DOqrxz3Fsh+5NQJKi56nFeM9AXsffVxcET46IEE2IF8J Bm4Q== X-Gm-Message-State: AHPjjUhR8oPHtuIxMXn3FcwmC/Hfq/BLoBVlX7QmLo3C1jB/wdra/2LH x3kSUjAqRr4udaFM+lXSVwKSd5YmObQ3 X-Google-Smtp-Source: ADKCNb6Q1C7jiey+/r5P5A2A5cqPs+icI9++tK/MHNzd0Ar/N767egH8HRcHj3v69yuSClRuZD6Tfni6+iOQJxTq17E= X-Received: by 10.84.211.39 with SMTP id b36mr2558327pli.330.1505166091383; Mon, 11 Sep 2017 14:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.144 with HTTP; Mon, 11 Sep 2017 14:41:30 -0700 (PDT) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD8025EC@DGGEMM506-MBX.china.huawei.com> From: Jana Iyengar Date: Mon, 11 Sep 2017 14:41:30 -0700 Message-ID: Subject: Re: nits in draft-ietf-quic-recovery-05 To: Matthew Kerwin Cc: Roni Even , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c093b2634dd5e0558f0cace" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 21:41:33 -0000 --94eb2c093b2634dd5e0558f0cace Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 11, 2017 at 2:30 PM, Matthew Kerwin wrote: > > > On 12 Sep. 2017 04:45, "Jana Iyengar" wrote: > > Hi Roni, > > Thanks for your careful read of the draft! > >> In section 3.1 the bullet before the last one =E2=80=9Ca QUIC sender mar= ks a >> packet as lost when a packet larger than it is acknowledged=E2=80=9D sho= uld be >> =E2=80=9Cwith higher packet number=E2=80=9D instead of =E2=80=9Clarger= =E2=80=9D? >> > We've consistently used "larger" packet number, so I'm inclined to stick > with that, even if "higher" is slightly more correct? > > > A "larger packet", and a "packet with a higher/larger/greater/whatever id= " > are two different things. I think that's the contention. > Oh, right, I missed that. Thanks for clarifying, I'll fix it (change to "marks a packet as lost when a packet with a larger packet number is acknowledged.") --94eb2c093b2634dd5e0558f0cace Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Sep 11, 2017 at 2:30 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:


On 12 Sep. 2017 04:45, "Jana Iyengar" <jri@google.com> wrote:=
Hi Roni,

Thanks for your careful read of t= he draft!
<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">

In section 3.1 the bullet before the last one =E2=80=9Ca QUIC sender m= arks a packet as lost when a packet larger than it is acknowledged=E2=80=9D should be =E2=80=9Cwith higher packet number=E2=80=9D instead of =E2=80=9C= larger=E2=80=9D?

We've co= nsistently used "larger" packet number, so I'm inclined to st= ick with that, even if "higher" is slightly more correct?


A "larger packet", and a "packet with a higher/larger/great= er/whatever id" are two different things. I think that's the conte= ntion.

Oh, right, I missed that= . Thanks for clarifying, I'll fix it (change to "marks a packet as= lost when a packet with a larger packet number is acknowledged.")
--94eb2c093b2634dd5e0558f0cace-- From nobody Mon Sep 11 18:10:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF3E124B18 for ; Mon, 11 Sep 2017 18:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bg8Z2JFkbArp for ; Mon, 11 Sep 2017 18:10:08 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA477120724 for ; Mon, 11 Sep 2017 18:10:07 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1drZiG-0007WK-V6 for quic@ietf.org; Tue, 12 Sep 2017 03:10:06 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1drZiE-0000Vm-4o for quic@ietf.org; Mon, 11 Sep 2017 21:10:02 -0400 Received: (qmail 12875 invoked from network); 12 Sep 2017 01:10:01 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.88]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Sep 2017 01:10:00 -0000 To: quic@ietf.org References: <6E58094ECC8D8344914996DAD28F1CCD8025EC@DGGEMM506-MBX.china.huawei.com> From: Christian Huitema Message-ID: <2269510d-90dc-483c-471b-f9b8d98dfa1b@huitema.net> Date: Mon, 11 Sep 2017 18:09:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: nits in draft-ietf-quic-recovery-05 X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.21) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYWwktM+UPDyXniaU9ttNgkND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23hQs9KZ0eOhFsp6DPA4m03WiJVgYPDZFQsui0 1rl2VbuwC2Hq5pSOhXjxEnWt4LTqYOEkjsX7F8KmpUaZQHV+SZbCEQkE+Ttak7yNVmHZUfi2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpPLwHqwRykc1ByOUA6hOga/fPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEe8XC4p8R/tfaYpdLfmOgZFKpb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/P2bHd6v+zfW0Hi0zr4G/c3fOag26sJVU91vDlVZmVFHoHOPocIAQXCXdbljHVoU+TL v3Mz7HKrwpxO8UZg9F+1KW+fKrtTAxLYZqy5vzpWhrDjTzGHpE/PwPNFuykVFHRpLIjy1xa+z15v iGur6ypSyfMpbIVENXeFOH55PGAVh6qK3hSPsI/yXHuKCW5mW6x7e6X9dJ86M2qPvneWrcSOpMRe 2A8DoXWdiHTPGMwPDlprjQPFk8m4tSTfORUp3ynKX9MPhkd8FwkdJfUs7sHA2/AsuSJe7JniZ6xP S+TFsgXf0EgYJLibecBlpmz3E0I= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 01:10:09 -0000 On 9/11/2017 2:41 PM, Jana Iyengar wrote: > > Oh, right, I missed that. Thanks for clarifying, I'll fix it (change > to "marks a packet as lost when a packet with a larger packet number > is acknowledged.") Except that's not true, because that simple statement does not take into account possible out of order deliveries. Indeed, the overview says: "A packet is marked as lost if at least one packet that was sent a threshold number of packets (kReorderingThreshold) after it has been acknowledged." But the overview is not correct either, because it does not consider time. A packet could still be marked as lost if "time_reordering_fraction + kDelayedAckTimeout" has elapsed since receiving an acknowledgement of a packet with a larger number. --=20 Christian Huitema From nobody Mon Sep 11 22:06:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C0913208E for ; Mon, 11 Sep 2017 22:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 T3MOeShIxDaL for ; Mon, 11 Sep 2017 22:06:28 -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 F18021241FC for ; Mon, 11 Sep 2017 22:06:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOK08526; Tue, 12 Sep 2017 05:06:23 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 12 Sep 2017 06:06:22 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Tue, 12 Sep 2017 13:06:16 +0800 From: Roni Even To: Jana Iyengar , Matthew Kerwin CC: IETF QUIC WG Subject: RE: nits in draft-ietf-quic-recovery-05 Thread-Topic: nits in draft-ietf-quic-recovery-05 Thread-Index: AdMqxLEU0GzdUweDRv23LwH2ULxahQAJlC8AAAXKOIAAAGBpAAAgPgfg Date: Tue, 12 Sep 2017 05:06:15 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD802A85@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD8025EC@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.153] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD802A85DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59B76B52.0010, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2d15fb9a0a1098f0bf4305fa5b8d7d75 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 05:06:30 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD802A85DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEkgSmFuYSwNClRoYW5rcywgdGhpcyB3YXMgbXkgY29tbWVudCBhYm91dCBqdXN0IHNheWluZyDi gJxsYXJnZXLigJ0NClJvbmkNCg0KRnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2ds ZS5jb21dDQpTZW50OiDXmdeV150g15IgMTIg16HXpNeY157XkdeoIDIwMTcgMDA6NDINClRvOiBN YXR0aGV3IEtlcndpbg0KQ2M6IFJvbmkgRXZlbjsgSUVURiBRVUlDIFdHDQpTdWJqZWN0OiBSZTog bml0cyBpbiBkcmFmdC1pZXRmLXF1aWMtcmVjb3ZlcnktMDUNCg0KT24gTW9uLCBTZXAgMTEsIDIw MTcgYXQgMjozMCBQTSwgTWF0dGhldyBLZXJ3aW4gPG1hdHRoZXdAa2Vyd2luLm5ldC5hdTxtYWls dG86bWF0dGhld0BrZXJ3aW4ubmV0LmF1Pj4gd3JvdGU6DQoNCg0KT24gMTIgU2VwLiAyMDE3IDA0 OjQ1LCAiSmFuYSBJeWVuZ2FyIiA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29t Pj4gd3JvdGU6DQpIaSBSb25pLA0KDQpUaGFua3MgZm9yIHlvdXIgY2FyZWZ1bCByZWFkIG9mIHRo ZSBkcmFmdCENCg0KSW4gc2VjdGlvbiAzLjEgdGhlIGJ1bGxldCBiZWZvcmUgdGhlIGxhc3Qgb25l IOKAnGEgUVVJQyBzZW5kZXIgbWFya3MgYSBwYWNrZXQgYXMgbG9zdCB3aGVuIGEgcGFja2V0IGxh cmdlciB0aGFuIGl0IGlzIGFja25vd2xlZGdlZOKAnSBzaG91bGQgYmUg4oCcd2l0aCBoaWdoZXIg cGFja2V0IG51bWJlcuKAnSBpbnN0ZWFkIG9mIOKAnGxhcmdlcuKAnT8NCldlJ3ZlIGNvbnNpc3Rl bnRseSB1c2VkICJsYXJnZXIiIHBhY2tldCBudW1iZXIsIHNvIEknbSBpbmNsaW5lZCB0byBzdGlj ayB3aXRoIHRoYXQsIGV2ZW4gaWYgImhpZ2hlciIgaXMgc2xpZ2h0bHkgbW9yZSBjb3JyZWN0Pw0K DQoNCkEgImxhcmdlciBwYWNrZXQiLCBhbmQgYSAicGFja2V0IHdpdGggYSBoaWdoZXIvbGFyZ2Vy L2dyZWF0ZXIvd2hhdGV2ZXIgaWQiIGFyZSB0d28gZGlmZmVyZW50IHRoaW5ncy4gSSB0aGluayB0 aGF0J3MgdGhlIGNvbnRlbnRpb24uDQoNCk9oLCByaWdodCwgSSBtaXNzZWQgdGhhdC4gVGhhbmtz IGZvciBjbGFyaWZ5aW5nLCBJJ2xsIGZpeCBpdCAoY2hhbmdlIHRvICJtYXJrcyBhIHBhY2tldCBh cyBsb3N0IHdoZW4gYSBwYWNrZXQgd2l0aCBhIGxhcmdlciBwYWNrZXQgbnVtYmVyIGlzIGFja25v d2xlZGdlZC4iKQ0K --_000_6E58094ECC8D8344914996DAD28F1CCD802A85DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tLTg5NTE4MDc0OTk4NDYyMDc2NTht OTMyMTg4NjA1NTA3MzYxMzA3bTQ4ODk3ODY1NDUyODkxNDE1NDhtc29wbGFpbnRleHQsIGxpLm0t ODk1MTgwNzQ5OTg0NjIwNzY1OG05MzIxODg2MDU1MDczNjEzMDdtNDg4OTc4NjU0NTI4OTE0MTU0 OG1zb3BsYWludGV4dCwgZGl2Lm0tODk1MTgwNzQ5OTg0NjIwNzY1OG05MzIxODg2MDU1MDczNjEz MDdtNDg4OTc4NjU0NTI4OTE0MTU0OG1zb3BsYWludGV4dA0KCXttc28tc3R5bGUtbmFtZTptXy04 OTUxODA3NDk5ODQ2MjA3NjU4bV85MzIxODg2MDU1MDczNjEzMDdtXzQ4ODk3ODY1NDUyODkxNDE1 NDhtc29wbGFpbnRleHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5ISSBKYW5hLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3MsIHRoaXMgd2FzIG15IGNvbW1lbnQgYWJvdXQganVzdCBzYXlpbmcg4oCcbGFyZ2Vy 4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbmk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2ds ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV 150mbmJzcDvXkiAxMiDXodek15jXnteR16ggMjAxNyAwMDo0Mjwvc3Bhbj48YnI+DQo8Yj5Ubzo8 L2I+IE1hdHRoZXcgS2Vyd2luPGJyPg0KPGI+Q2M6PC9iPiBSb25pIEV2ZW47IElFVEYgUVVJQyBX Rzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogbml0cyBpbiBkcmFmdC1pZXRmLXF1aWMtcmVjb3Zl cnktMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIFNlcCAxMSwgMjAxNyBhdCAyOjMwIFBNLCBNYXR0aGV3 IEtlcndpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hdHRoZXdAa2Vyd2luLm5ldC5hdSIgdGFyZ2V0 PSJfYmxhbmsiPm1hdHRoZXdAa2Vyd2luLm5ldC5hdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEyIFNlcC4gMjAxNyAwNDo0NSwgJnF1b3Q7SmFuYSBJ eWVuZ2FyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJvbmksPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHlvdXIgY2FyZWZ1bCByZWFkIG9mIHRo ZSBkcmFmdCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0tODk1MTgwNzQ5OTg0NjIwNzY1OG05 MzIxODg2MDU1MDczNjEzMDdtNDg4OTc4NjU0NTI4OTE0MTU0OG1zb3BsYWludGV4dCI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5JbiBzZWN0aW9uIDMuMSB0aGUgYnVsbGV0IGJlZm9yZSB0aGUgbGFzdCBvbmUg4oCc YSBRVUlDIHNlbmRlciBtYXJrcyBhIHBhY2tldCBhcyBsb3N0IHdoZW4gYSBwYWNrZXQgbGFyZ2Vy IHRoYW4gaXQgaXMgYWNrbm93bGVkZ2Vk4oCdIHNob3VsZCBiZSDigJx3aXRoIGhpZ2hlciBwYWNr ZXQgbnVtYmVy4oCdIGluc3RlYWQgb2Yg4oCcbGFyZ2Vy4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XZSd2ZSBjb25zaXN0ZW50bHkgdXNlZCAmcXVvdDtsYXJnZXImcXVvdDsg cGFja2V0IG51bWJlciwgc28gSSdtIGluY2xpbmVkIHRvIHN0aWNrIHdpdGggdGhhdCwgZXZlbiBp ZiAmcXVvdDtoaWdoZXImcXVvdDsgaXMgc2xpZ2h0bHkgbW9yZSBjb3JyZWN0PzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BICZxdW90O2xhcmdlciBwYWNrZXQmcXVvdDssIGFuZCBhICZxdW90O3Bh Y2tldCB3aXRoIGEgaGlnaGVyL2xhcmdlci9ncmVhdGVyL3doYXRldmVyIGlkJnF1b3Q7IGFyZSB0 d28gZGlmZmVyZW50IHRoaW5ncy4gSSB0aGluayB0aGF0J3MgdGhlIGNvbnRlbnRpb24uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T2gsIHJpZ2h0LCBJIG1pc3NlZCB0aGF0LiBUaGFua3MgZm9yIGNsYXJpZnlpbmcsIEknbGwgZml4 IGl0IChjaGFuZ2UgdG8gJnF1b3Q7bWFya3MgYSBwYWNrZXQgYXMgbG9zdCB3aGVuIGEgcGFja2V0 IHdpdGggYSBsYXJnZXIgcGFja2V0IG51bWJlciBpcyBhY2tub3dsZWRnZWQuJnF1b3Q7KTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E58094ECC8D8344914996DAD28F1CCD802A85DGGEMM506MBXchina_-- From nobody Tue Sep 12 16:53:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0B113318A for ; Tue, 12 Sep 2017 16:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 nR_Nfi6Pn0Ff for ; Tue, 12 Sep 2017 16:53:33 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EDC1320C9 for ; Tue, 12 Sep 2017 16:53:33 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id q76so7377175pfq.2 for ; Tue, 12 Sep 2017 16:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zw39slNvjbXrY+A/ldkmKj/K/Fa3KAQyN+bANgph9l0=; b=cFtbOH4mpL3JwOJyRAkJ+LnmQA34pCiAYe+ngZ+TVO/k85XxqgZAjZcM0l7WsLxGzY SBKIG0OXZ1hgfGbFAA2wFx9nHE/vsnL7a3N8xwOZyBZ/+dLG3WblcJlpUqdMYkYj6+4u vrjnGqy2i8EHSCHAXv8voJK1gbPrj4LaiH7+TdbhfFPuCHQ0+4/cvJoKeaPVzc2RdR3u k9xgKjrXckdCOhEatBp5/zJ2YuaLiZVQdNaA+x96cHDMjjGHrbL0yJb9aMAyCWuwvbSF z30hRLALWB2W6GDypaYIVHzlLKNg13FcHAl1B8R/CEHBCs0bBNpQKMbip/AQBU2o6JOn PEAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zw39slNvjbXrY+A/ldkmKj/K/Fa3KAQyN+bANgph9l0=; b=lJzdpn+Priad80MfmC0tKzeJKChoW3Id4bvXH+aTRK63lHSkPGAdRaJaCXfcUMWiTG IPB/FoItdaz1yPWdXqOT37WQP1tr8smlNZG6KjZvL38DKN7FgkJWESRPD7JBmXjWCq2c tVSionD8MgsYVnPZVKRgxws4R4zY+VYMdW1gilTJAX/CHjFW0ALjdUv5zuZQ0u2DgSQU b17PGfolLD8G7mgIDcxjDIDFLv6c4Jg+2njgsbTzUhpP6dcJweLzdqi+9LlLdu//t4FT Lh7D/gHkNUYonjCBrIBQOtavxksXfXEVE3ERgmjHxo4NCG4I88J40t6JenLmSDXawKPA KdGA== X-Gm-Message-State: AHPjjUhodRp+X05X+bt5DzVIdoJ2Tpoehz9jCZ0SFVL8tsl4wIOZCOrm POZquyzsPDxLb/5q2gp+i3TzvUG3Inkcf79gxYehXwZRVVA= X-Google-Smtp-Source: ADKCNb5VcVzgm7eyMsvE83VUSMEGtCpDEBI73/H6m9q/eZRt4O0bsdM902enIdjAWvk6F0ajuZyVYaKOwLn6+eDzgW0= X-Received: by 10.99.104.196 with SMTP id d187mr16343851pgc.163.1505260411950; Tue, 12 Sep 2017 16:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.144 with HTTP; Tue, 12 Sep 2017 16:53:31 -0700 (PDT) In-Reply-To: <5fafb10e-1421-537e-bf8a-5fdfdd19b439@huitema.net> References: <5fafb10e-1421-537e-bf8a-5fdfdd19b439@huitema.net> From: Jana Iyengar Date: Tue, 12 Sep 2017 16:53:31 -0700 Message-ID: Subject: Re: ACK Frame Issues To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c1404b226816e055906c083" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 23:53:35 -0000 --94eb2c1404b226816e055906c083 Content-Type: text/plain; charset="UTF-8" Related to point (2), I've filed #774 . On Wed, Sep 6, 2017 at 2:47 PM, Christian Huitema wrote: > > > On 9/6/2017 2:25 PM, Martin Duke wrote: > > ... > > (1) *The spec sorely needs more normative text.* > > ... > > (b) There are four ways to treat acks in flight on which the spec is > silent: > (i) Do not repeat them in subsequent acks > (ii) Repeat them only if they do not require additional ack blocks > (iii) Repeat them only if they require *neither *additional ack > blocks nor longer block lengths. > (iv) Always repeat them until acked > Offline, Jana suggested that (iv) is what Google does, but you'd never > guess that. I settled on (ii), for what it's worth. > > > Picoquic also does (vi). It provides redundancy, so if an ACK is lost the > next ACK will still acknowledge the received packets. > > ... > > (e) The spec is unclear if timestamps are sorted in order of arrival or > reverse order of arrival. At least it's unclear to me! BTW having to sort > new arrivals in both packet number and arrival order is unpleasant. > > > Picoquic does not attempt to sort arrivals, but maintain a SACK structure > similar to the "SACK dashboard" specified in TCP. > > > I don't think the spec should prohibit any of this behavior. However, some > normative text might indicate to implementors that they don't really need > to worry about some of this stuff. > > (2) *The relationship between timestamps and ack blocks needs a rethink* > > People are all over the map on this. On the implementer slack channel, a > lot of people are totally ignoring timestamps and don't think they're > useful. Jana seems to view as a purely advisory channel. On the other hand, > as issue #698 points out, a received timestamp means the packet has > arrived, and sending an ack block for it in the same frame seems redundant. > > > Yes. That syntax is wrong, because it creates a potential conflict. > > > Finally, timestamps are a report with a completely different syntax. > *Especially* if they are advisory, I believe there is a strong case for > just putting it in its own frame and eliminating some of the weird > dependencies (see (c) above) between largest_acked and the timestamp fields. > > > No. There would still be a conflict. For example, in Picoquic, receiving > at ACK erases the data related to the acknowledged packet -- including the > timestamps. If the proposed "timestamp frame" arrived after the ACK frame, > its information would be ignored because the packet was already marked > received and the data erased. > > > Personally, I would recommend the following: > (1) Move timestamps into a separate frame. > (2) A host that receives a timestamp frame MUST interpret a timestamp for > a packet as an acknowledgement for that packet. Packet recievers MAY omit > ack blocks for packets for which a timestamp is in flight. > (3) (possibly) make timestamps something negotiable (in each direction) at > the start of a connection. For example, a host may only want timestamps > from its peer if it is using delay-based congestion control. > > > My preference would be to have exactly one time stamp per ACK, > corresponding to the time at which the "largest acknowledged" packet was > received, and expressed as microseconds since the beginning of the > connection. 24 bits is probably OK, as long as the RTT is lower than 16 > sec. 32 bit would be fine for anything but inter-planetary communications. > > -- Christian Huitema > > -- > Christian Huitema > > --94eb2c1404b226816e055906c083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Related to point (2), I've filed #774.

On Wed, Sep 6, 2017 at 2:47 PM, Chris= tian Huitema <huitema@huitema.net> wrote:
=20 =20 =20



On 9/6/2017 2:25 PM, = Martin Duke wrote:
...

(1) The spec sorely needs more normative text.

 ...

(b) There are four ways to treat acks in flight on which the spec is silent:
=C2=A0 =C2=A0 (i) Do not repeat them in subsequent acks
=C2=A0 =C2=A0 (ii) Repeat them only if they do not require additional ack blocks
=C2=A0 =C2=A0 (iii) Repeat them only if they require neit= her additional ack blocks nor longer block lengths.
=C2=A0 =C2=A0 (iv) Always repeat them until acked
Offline, Jana suggested that (iv) is what Google does, but you'd never guess that. I settled on (ii), for what it&= #39;s worth.

Picoquic also does (vi). It provides redundancy, so if an ACK is lost the next ACK will still acknowledge the received packets.

...

(e) The spec is unclear if timestamps are sorted in order of arrival or reverse order of arrival. At least it's unclear to me! BTW having to sort new arrivals in both packet number and arrival order is unpleasant.

Picoquic does not attempt to sort arrivals, but maintain a SACK structure similar to the "SACK dashboard" specified in TCP.

I don't think the spec should prohibit any of this behavior. However, some normative text might indicate to implementors that they don't really need to worry about som= e of this stuff.

(2) The relationship between timestamps and ack blocks needs a rethink

People are all over the map on this. On the implementer slack channel, a lot of people are totally ignoring timestamps and don't think they're useful. Jana seems to view as a p= urely advisory channel. On the other hand, as issue #698 points out, a received timestamp means the packet has arrived, and sending an ack block for it in the same frame seems redundant.

Yes. That syntax is wrong, because it creates a potential conflict.


Finally, timestamps are a report with a completely different syntax. Especially if they are advisory, I believe there is a strong case for just putting it in its own frame and eliminating some of the weird dependencies (see (c) above) between largest_acked and the timestamp fields.

No. There would still be a conflict. For example, in Picoquic, receiving at ACK erases the data related to the acknowledged packet -- including the timestamps. If the proposed "timestamp frame"= ; arrived after the ACK frame, its information would be ignored because the packet was already marked received and the data erased.

Personally, I would recommend the following:
(1) Move timestamps into a separate frame.
(2) A host that receives a timestamp frame MUST interpret a timestamp for a packet as an acknowledgement for that packet. Packet recievers MAY omit ack blocks for packets for which a timestamp is in flight.
(3) (possibly) make timestamps something negotiable (in each direction) at the start of a connection. For example, a host may only want timestamps from its peer if it is using delay-based congestion control.


 My preference would be to have exactly one time stamp per ACK, corresponding to the time at which the "largest acknowledged"= packet was received, and expressed as microseconds since the beginning of the connection. 24 bits is probably OK, as long as the RTT is lower than 16 sec. 32 bit would be fine for anything but inter-planetary communications.

-- Christian Huitema
--=20
Christian Huitema

--94eb2c1404b226816e055906c083-- From nobody Tue Sep 12 17:04:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A111331A9 for ; Tue, 12 Sep 2017 17:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 KCmETtsAHS-U for ; Tue, 12 Sep 2017 17:04:25 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0127.outbound.protection.outlook.com [104.47.36.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374A31331A3 for ; Tue, 12 Sep 2017 17:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HilH6JnC0MYutcdoJWZYzlj9F6gABH6pWTxqbf3rjpw=; b=S0qy8qHnPouyk64hDJf46GV+KbQ0fhOht/sOHdghCaVzflfZD5B4D9XgJckwIG6haBNO/x+89qrEA/o4ABqRqXqZJn1nkE/Rs6t4ImGphjgoaKNdebpyFijtZj7RXTs7P7ZSmSTt1gAwlK4bPuv3olxB0bQS3ZOYQ4s2nlszsjY= Received: from BN6PR21MB0130.namprd21.prod.outlook.com (10.173.199.144) by BN6PR21MB0772.namprd21.prod.outlook.com (10.173.205.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.2; Wed, 13 Sep 2017 00:04:20 +0000 Received: from BN6PR21MB0130.namprd21.prod.outlook.com ([10.173.199.144]) by BN6PR21MB0130.namprd21.prod.outlook.com ([10.173.199.144]) with mapi id 15.20.0077.005; Wed, 13 Sep 2017 00:04:20 +0000 From: Mike Bishop To: Jana Iyengar , Martin Thomson CC: Subodh Iyengar , "Philipp S. Tiesel" , QUIC WG , Nick Harper , Victor Vasiliev Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9lu8pyhHlCkWTBQfMudDeAKKmFGeAgAASp4CAAAOOAIAA0yCAgAAOnACAAAMMAIAAAK4AgACHAwCAAI1zwIABqLWAgABJmoCAAAS/AIAANHEAgAFsKoCABhnu0A== Date: Wed, 13 Sep 2017 00:04:20 +0000 Message-ID: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:c::11d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0772; 6:bozvFZX1blQ8gtq9xA0U8UI2yM3yHL67FF1C2BirZRENMjF206qFtwX8pHebso9g65kEaGBx/oNM5Lf/DWMdd0xrsHCe4HKoGX7c5FNdmbQD2gHvucZPHIgYmfVh83xfB0GNHY2LloVfjXIfb0QKzldf7qeEMr/gWab3uD6oOapIvAttx+/XqOc71NS4xx4g4nTaS9ZLPEzsCGDPy2M6UTW+vrt4ihR04YgPblUhPTVTSoA8uLnrXWlsA8zDP+WMgpJdk8AX+dGXEhYALp76mKK/cUDzvmufS4H+TueyuCk2dmlzloVTVnj+73QLxEIDsZgnaZT7a744hSHCThI5/g==; 5:KWdAiZStHtKBhOQbsBptAObS/YA6ji9druXb/ljHYdlkx11Ek7p/OMbSC6Rpp+LNXeC9zvC0/nCOHHzttShk9cTagqqV6NlXL41VX6JN2GDnmh1D3igQW8WbX29pEqumy2Eu6UJaagf8KyVuJS5skg==; 24:MgvGNIHkNcQ8qaI3H+g4tVHNNPfuitOX+YxpK/bfZoVUCLIsROnUVT5UCtIQFj5Qt7Y8oDc/66EweoaSE7Az6SfAXhzQ0N6fYmB+paVYfTA=; 7:BI+ZoZ8nrt6zxp25sH4wZkWJghgXr0w1Vc9qSRjtszolHAmw5/LyG12DDZxxxLb4ESgzVtPEOus5t+zVc0MA3G7fcmv2NpZVDq9DYJSlE/QWYBYrM5lR2fSvZJAwTSwerNusn729+l2hdEvsXh8iu1X85PznhkeytbKQx/Vhw6/Ay0Y1+HSS57eXRzH1t2lFU9vMdGbrxsoG7qSy4NtHpHOrmzQMeT6vGAPjQ6Tq3K4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 376bb1fc-30c0-4d28-67a7-08d4fa3afba2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR21MB0772; x-ms-traffictypediagnostic: BN6PR21MB0772: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(89211679590171)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR21MB0772; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR21MB0772; x-forefront-prvs: 042957ACD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366002)(39860400002)(47760400005)(199003)(24454002)(189002)(78114003)(377454003)(51444003)(76176999)(50986999)(34040400001)(93886005)(54906002)(10090500001)(99286003)(9686003)(55016002)(54896002)(3660700001)(6306002)(478600001)(72206003)(53546010)(19609705001)(7736002)(101416001)(54356999)(8936002)(97736004)(22452003)(74316002)(10290500003)(81156014)(68736007)(14454004)(316002)(81166006)(8676002)(25786009)(189998001)(7696004)(5660300001)(2906002)(86612001)(106356001)(86362001)(33656002)(105586002)(8990500004)(790700001)(6116002)(102836003)(77096006)(4326008)(6506006)(2900100001)(229853002)(6436002)(236005)(3280700002)(2950100002)(53936002)(6246003)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0772; H:BN6PR21MB0130.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB01302C7E8A43AF9DB7A63335876E0BN6PR21MB0130namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2017 00:04:20.1916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0772 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 00:04:36 -0000 --_000_BN6PR21MB01302C7E8A43AF9DB7A63335876E0BN6PR21MB0130namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFuYSBhbmQgSSB3ZXJlIGRpc2N1c3NpbmcgdGhpcyB0b2RheSwgYW5kIHBhcnQgb2YgdGhlIGRp ZmZlcmVuY2UgY29tZXMgZG93biB0byBob3cgeW91IGNvbmNlaXZlIG9mIHRoZSBBUEkgYSBRVUlD IGltcGxlbWVudGF0aW9uIHdpbGwgZXhwb3NlLiAgTXkgbWVudGFsIG1vZGVsIGhhcyBiZWVuIHRo YXQgYSBzdHJlYW0vc3RyZWFtLXBhaXIgY29uc2lzdHMgb2YgYW4gSW5wdXRTdHJlYW0gYW5kIGFu IE91dHB1dFN0cmVhbTsgeW91IGNhbiByZWFkIG9uIG9uZSwgeW91IGNhbiB3cml0ZSBvbiB0aGUg b3RoZXIuICBGb3IgdGhlIHdyaXRlIHN0cmVhbSwgeW91IGNhbiB3cml0ZSB5b3VyIGRhdGEgdG8g Y29tcGxldGlvbiBhbmQgY2xvc2UgdGhlIHN0cmVhbSwgb3IgeW91IGNhbiBkZWNpZGUgdG8gYWJv cnQgd3JpdGluZy4gIFRoZSB3aXJlIGV4cHJlc3Npb25zIG9mIHRoZXNlIGFyZSBGSU4gYW5kIFJT VF9TVFJFQU0sIHJlc3BlY3RpdmVseS4gIEZvciB0aGUgcmVhZCBzdHJlYW0sIHlvdSBjYW4gcmVh ZCB0aGUgaW5jb21pbmcgZGF0YSB0byB0aGUgZW5kIG9yIHlvdSBjYW4gYWJvcnQgcmVhZGluZyBh bmQgZGlzY2FyZCB0aGUgcmVtYWluZGVyIG9mIHRoZSBzdHJlYW07IHRoZSB3aXJlIGV4cHJlc3Np b24gb2YgdGhpcyB3b3VsZCBiZSBmbG93IGNvbnRyb2wgdXBkYXRlcyBhbmQgU1RPUF9TRU5ESU5H LCByZXNwZWN0aXZlbHkuICBPbiB0aGUgb3RoZXIgc2lkZSwgcmVjZWlwdCBvZiBhIFJTVF9TVFJF QU0gc3VyZmFjZXMgYXMgYSByZWFkIGVycm9yIGFuZCByZWNlaXB0IG9mIGEgU1RPUF9TRU5ESU5H IHN1cmZhY2VzIGFzIGEgd3JpdGUgZXJyb3IuICAoSmFuYSBjb21tZW50ZWQgdGhhdCBpbiB0aGlz IG1lbnRhbCBtb2RlbCBpdCBtaWdodCBiZSBjbGVhcmVyIHRvIGNhbGwgdGhlIGZyYW1lcyBXUklU RV9BQk9SVCBhbmQgUkVBRF9BQk9SVC4pDQoNCklmIHdlIHRha2UgTWFydGlu4oCZcyBwcm9wb3Np dGlvbiB0aGF0IHN0cmVhbXMgb25seSBjbG9zZSBieSBhcHBsaWNhdGlvbiBhY3Rpb24sIHRoZXJl IHdvdWxkIG5ldmVyIGJlIGEgd3JpdGUgZXJyb3Igc3VyZmFjZWQgdG8gdGhlIGFwcGxpY2F0aW9u IHVubGVzcyB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQgd2VudCBhd2F5IGVudGlyZWx5LiAgSW5z dGVhZCwgaXTigJlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgYXBwbGljYXRpb24gcHJvdG9j b2wgdG8gY29tbXVuaWNhdGUgKG9uIGFub3RoZXIgc3RyZWFtLCBpbiB0aGlzIGNhc2UpIHRoYXQg eW91IHNob3VsZCBhYm9ydCB3cml0aW5nLCBldmVuIGlmIHlvdeKAmXZlIGFscmVhZHkgd3JpdHRl biB0byBjb21wbGV0aW9uLCBhbmQgdGhlbiB0byBkbyBzby4gIFRoYXQgaW1wbGllcyB0aGF0IHRo ZSBhcHBsaWNhdGlvbiBuZWVkcyB0aGUgYWJpbGl0eSB0byByZXR1cm4gdG8gc3RyZWFtcyBvbiB3 aGljaCBpdOKAmXMgZG9uZSB3cml0aW5nLCBpbiBjYXNlIGl04oCZcyBsYXRlciBhc2tlZCB0byBn byBiYWNrIGFuZCByZXNldCB0aGVtLg0KDQpNdWNoIG9mIG91ciBkaXNjdXNzaW9ucyBhcm91bmQg dW5pZGlyZWN0aW9uYWwgc3RyZWFtcywgc3RyZWFtIHN0YXRlIHRyYW5zaXRpb25zLCBldGMuIGlu Y2x1ZGluZyB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBTVE9QX1NFTkRJTkcgYmVsb25ncyBhdCB0 aGUgdHJhbnNwb3J0IGxheWVyLCBzdGVtIGZyb20gdGhlIGZhY3QgdGhhdCB3ZSBhbGwgaGF2ZSBk aWZmZXJlbnQgaW1wbGljaXQgbWVudGFsIG1vZGVscyBvZiB0aGUgZnVuY3Rpb25hbCBzdXJmYWNl IFFVSUMgZXhwb3Nlcy4gIFBlcmhhcHMgd2Ugc2hvdWxkIHRha2UgYSBzdGVwIGJhY2sgYW5kIGFn cmVlIG9uIHRoYXQgZmlyc3QsIGFzIEkgYmVsaWV2ZSBDaHJpc3RpYW4gaGFzIHN1Z2dlc3RlZCBp biB0aGUgcGFzdD8NCg0KRnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21d DQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciA4LCAyMDE3IDU6MzQgUE0NClRvOiBNYXJ0aW4gVGhv bXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KQ2M6IFN1Ym9kaCBJeWVuZ2FyIDxzdWJv ZGhAZmIuY29tPjsgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBQ aGlsaXBwIFMuIFRpZXNlbCA8cGhpbHNAaW4tcGFuaWsuZGU+OyBRVUlDIFdHIDxxdWljQGlldGYu b3JnPjsgTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT47IFZpY3RvciBWYXNpbGlldiA8 dmFzaWx2dkBnb29nbGUuY29tPg0KU3ViamVjdDogUmU6IFNwbGl0IGVycm9yIGNvZGVzIGluIHR3 bw0KDQpPbiBUaHUsIFNlcCA3LCAyMDE3IGF0IDc6NTAgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdy b3RlOg0KT24gRnJpLCBTZXAgOCwgMjAxNyBhdCA5OjQyIEFNLCBKYW5hIEl5ZW5nYXIgPGpyaUBn b29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KPiBJIGRvbid0IHRoaW5r IGl0IG1ha2VzIHNlbnNlIHRvIGRlc2lnbiBhbiBhcHAgcHJvdG9jb2wgdGhhdCBkb2Vzbid0IHNl bmQgYQ0KPiBSU1QgaW4gcmVzcG9uc2UgdG8gYSBSU1QuDQoNCkkndmUgYmVlbiB0b2xkIG5vdCB0 byBpbnZva2UgdGhpcyBwYXJ0aWN1bGFyIGRlbW9uLCBidXQgeW91IGp1c3QNCmludm9rZWQgdGhl IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgcHJvYmxlbS4gIEkgdGhpbmsgdGhhdCB3ZSBnZXQgdGhl cmUNCmJlY2F1c2Ugb2YgdGhpcyBtZW1lIHRoYXQgc2F5cyB0aGF0IGRhdGEgaW4gdGhlIG9uZSBk aXJlY3Rpb24gaXMNCnNvbWVob3cgbmVjZXNzYXJpbHkgYm91bmQgdG8gZGF0YSBpbiB0aGUgb3Ro ZXIgZGlyZWN0aW9uLiAgVGhhdCdzIGFuDQplbnRpcmVseSBjb25zdHJ1Y3RlZCBub3Rpb24uICBB IHVzZWZ1bCBjb25zdHJ1Y3QgYXQgdGltZXMsIGNlcnRhaW5seSwNCmJ1dCB0aGF0J3Mgbm90IHRo ZSBwb2ludCBoZXJlLg0KDQpJIHRoaW5rIHRoYXQncyB0aGUgbW9zdCBjb21tb24gdXNlIG9mIGEg UlNUIC0tIHRvIGNsb3NlIGJvdGggZGlyZWN0aW9ucy4NCg0KU28gSSBkaXNhZ3JlZS4gIFRoZXJl IGFyZSBtYW55IHByb3RvY29scyBpbiB3aGljaCB5b3Ugc2VuZCBtZXNzYWdlcw0KKD09IHN0cmVh bXMpIGluIG9uZSBkaXJlY3Rpb24gYnV0IG5vdCBhbm90aGVyLiAgT25lIG9mIHRoZSB3YXlzIHlv dQ0KZ2V0IGludG8gYSB1bmlkaXJlY3Rpb25hbCBzdGF0ZSBpbiB0aGUgY3VycmVudCBkcmFmdCBp cyB0byBlbmQgb25lDQpzaWRlLiAgQSBGSU4gaXMgb25seSBvbmUgd2F5IHRvIGRvIHRoYXQsIGEg dW5pZGlyZWN0aW9uYWwgUlNUIGNhbiBiZQ0KZmFzdGVyIGFuZCBldmVuIHN1cGVyaW9yIGluIG90 aGVyIHdheXMuICBUaGUgSFRUUCB1c2UgY2FzZSBjbGVhcmx5DQppbGx1c3RyYXRlcyB0aGF0Lg0K DQpGSU4gaXMgdGhlIHByaW1hcnkgd2F5IGluIHdoaWNoIGhhbGYtY2xvc2UgaXMgYWNoaWV2ZWQs IHdoaWNoIGlzIHdoYXQgeW91J3JlIHRhbGtpbmcgYWJvdXQuIFRoZSBIVFRQIHVzZSBjYXNlIGlz IGEgY29tcGxldGUgb25lLW9mZiAtLSBTVE9QX1NFTkRJTkcgaXMgYW4gb2RkIGVub3VnaCB1c2Ug Y2FzZSB0aGF0IEknbSBhbHdheXMgbGVmdCB3b25kZXJpbmcgd2hvIGFjdHVhbGx5IHVzZXMgaXQu DQoNCkFsc28sIGFzIElnb3Igb2JzZXJ2ZXMsIHdlIGRvbid0IHJlcXVpcmUgYSByZWNpcHJvY2Fs IFJTVF9TVFJFQU0gaW4NCnRoZSBjdXJyZW50IGRyYWZ0Lg0KDQpZZXMsIHdlIGRvbid0LiBSZWNh bGwgdGhhdCB0aGUgUlNUX1NUUkVBTSB3YXMsIHByaW9yIHRvIHRoZSBjaGFuZ2UgdGhhdCBkb2Vz bid0IHJlcXVpcmUgcmVjaXByb2NpdHksIGEgYmlkaXJlY3Rpb25hbCBzaWduYWwsIHdoaWNoIHdh cyBzaW1wbGlmaWVkIHRvIGEgdW5pZGlyZWN0aW9uYWwgb25lLCB3aXRoIHRoZSBnZW5lcmFsIGV4 cGVjdGF0aW9uIHRoYXQgYXBwcyB3b3VsZCBjbG9zZSB0aGUgb3RoZXIgc2lkZSB3aGVuIHRoZXkg cmVjZWl2ZSB0aGlzIHNpZ25hbCBmcm9tIFFVSUMuIEl0J3Mgc3VyZWx5IGdvaW5nIHRvIGJlIHRy dWUgb2YgSFRUUC4gSXQncyBwb3NzaWJsZSBmb3IgYW4gYXBwIHRvIHJlY2VpdmUgYSBSU1QgYW5k IHRoZW4ga2VlcCBzZW5kaW5nLCBidXQgdGhhdCBpcyBhIHVzZSBjYXNlIEkgaGF2ZW4ndCBzZWVu IGluIHByYWN0aWNlLg0KDQo= --_000_BN6PR21MB01302C7E8A43AF9DB7A63335876E0BN6PR21MB0130namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SmFuYSBhbmQgSSB3ZXJlIGRpc2N1c3NpbmcgdGhpcyB0b2RheSwgYW5kIHBhcnQg b2YgdGhlIGRpZmZlcmVuY2UgY29tZXMgZG93biB0byBob3cgeW91IGNvbmNlaXZlIG9mIHRoZSBB UEkgYSBRVUlDIGltcGxlbWVudGF0aW9uIHdpbGwgZXhwb3NlLiZuYnNwOyBNeSBtZW50YWwgbW9k ZWwgaGFzIGJlZW4gdGhhdCBhIHN0cmVhbS9zdHJlYW0tcGFpciBjb25zaXN0cyBvZiBhbiBJbnB1 dFN0cmVhbSBhbmQgYW4gT3V0cHV0U3RyZWFtOw0KIHlvdSBjYW4gcmVhZCBvbiBvbmUsIHlvdSBj YW4gd3JpdGUgb24gdGhlIG90aGVyLiZuYnNwOyBGb3IgdGhlIHdyaXRlIHN0cmVhbSwgeW91IGNh biB3cml0ZSB5b3VyIGRhdGEgdG8gY29tcGxldGlvbiBhbmQgY2xvc2UgdGhlIHN0cmVhbSwgb3Ig eW91IGNhbiBkZWNpZGUgdG8gYWJvcnQgd3JpdGluZy4mbmJzcDsgVGhlIHdpcmUgZXhwcmVzc2lv bnMgb2YgdGhlc2UgYXJlIEZJTiBhbmQgUlNUX1NUUkVBTSwgcmVzcGVjdGl2ZWx5LiZuYnNwOyBG b3IgdGhlIHJlYWQgc3RyZWFtLA0KIHlvdSBjYW4gcmVhZCB0aGUgaW5jb21pbmcgZGF0YSB0byB0 aGUgZW5kIG9yIHlvdSBjYW4gYWJvcnQgcmVhZGluZyBhbmQgZGlzY2FyZCB0aGUgcmVtYWluZGVy IG9mIHRoZSBzdHJlYW07IHRoZSB3aXJlIGV4cHJlc3Npb24gb2YgdGhpcyB3b3VsZCBiZSBmbG93 IGNvbnRyb2wgdXBkYXRlcyBhbmQgU1RPUF9TRU5ESU5HLCByZXNwZWN0aXZlbHkuJm5ic3A7IE9u IHRoZSBvdGhlciBzaWRlLCByZWNlaXB0IG9mIGEgUlNUX1NUUkVBTSBzdXJmYWNlcyBhcyBhDQog cmVhZCBlcnJvciBhbmQgcmVjZWlwdCBvZiBhIFNUT1BfU0VORElORyBzdXJmYWNlcyBhcyBhIHdy aXRlIGVycm9yLiZuYnNwOyAoSmFuYSBjb21tZW50ZWQgdGhhdCBpbiB0aGlzIG1lbnRhbCBtb2Rl bCBpdCBtaWdodCBiZSBjbGVhcmVyIHRvIGNhbGwgdGhlIGZyYW1lcyBXUklURV9BQk9SVCBhbmQg UkVBRF9BQk9SVC4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIHRha2UgTWFydGlu4oCZ cyBwcm9wb3NpdGlvbiB0aGF0IHN0cmVhbXMgb25seSBjbG9zZSBieSBhcHBsaWNhdGlvbiBhY3Rp b24sIHRoZXJlIHdvdWxkIG5ldmVyIGJlIGEgd3JpdGUgZXJyb3Igc3VyZmFjZWQgdG8gdGhlIGFw cGxpY2F0aW9uIHVubGVzcyB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQgd2VudCBhd2F5IGVudGly ZWx5LiZuYnNwOyBJbnN0ZWFkLCBpdOKAmXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBhcHBs aWNhdGlvbg0KIHByb3RvY29sIHRvIGNvbW11bmljYXRlIChvbiBhbm90aGVyIHN0cmVhbSwgaW4g dGhpcyBjYXNlKSB0aGF0IHlvdSBzaG91bGQgYWJvcnQgd3JpdGluZywgZXZlbiBpZiB5b3XigJl2 ZSBhbHJlYWR5IHdyaXR0ZW4gdG8gY29tcGxldGlvbiwgYW5kIHRoZW4gdG8gZG8gc28uJm5ic3A7 IFRoYXQgaW1wbGllcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBuZWVkcyB0aGUgYWJpbGl0eSB0byBy ZXR1cm4gdG8gc3RyZWFtcyBvbiB3aGljaCBpdOKAmXMgZG9uZSB3cml0aW5nLA0KIGluIGNhc2Ug aXTigJlzIGxhdGVyIGFza2VkIHRvIGdvIGJhY2sgYW5kIHJlc2V0IHRoZW0uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk11Y2ggb2Ygb3VyIGRpc2N1c3Npb25zIGFyb3VuZCB1bmlkaXJlY3Rpb25h bCBzdHJlYW1zLCBzdHJlYW0gc3RhdGUgdHJhbnNpdGlvbnMsIGV0Yy4gaW5jbHVkaW5nIHRoZSBx dWVzdGlvbiBvZiB3aGV0aGVyIFNUT1BfU0VORElORyBiZWxvbmdzIGF0IHRoZSB0cmFuc3BvcnQg bGF5ZXIsIHN0ZW0gZnJvbSB0aGUgZmFjdCB0aGF0IHdlIGFsbCBoYXZlIGRpZmZlcmVudCBpbXBs aWNpdCBtZW50YWwgbW9kZWxzIG9mDQogdGhlIGZ1bmN0aW9uYWwgc3VyZmFjZSBRVUlDIGV4cG9z ZXMuJm5ic3A7IFBlcmhhcHMgd2Ugc2hvdWxkIHRha2UgYSBzdGVwIGJhY2sgYW5kIGFncmVlIG9u IHRoYXQgZmlyc3QsIGFzIEkgYmVsaWV2ZSBDaHJpc3RpYW4gaGFzIHN1Z2dlc3RlZCBpbiB0aGUg cGFzdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEphbmEgSXllbmdhciBb bWFpbHRvOmpyaUBnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1i ZXIgOCwgMjAxNyA1OjM0IFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFy dGluLnRob21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU3Vib2RoIEl5ZW5nYXIg Jmx0O3N1Ym9kaEBmYi5jb20mZ3Q7OyBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWlj cm9zb2Z0LmNvbSZndDs7IFBoaWxpcHAgUy4gVGllc2VsICZsdDtwaGlsc0Bpbi1wYW5pay5kZSZn dDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBOaWNrIEhhcnBlciAmbHQ7bmhhcnBl ckBnb29nbGUuY29tJmd0OzsgVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2QGdvb2dsZS5jb20m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTcGxpdCBlcnJvciBjb2RlcyBpbiB0d288bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBTZXAgNywg MjAxNyBhdCA3OjUwIFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IFNlcCA4LCAyMDE3IGF0IDk6NDIgQU0sIEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpyaUBnb29nbGUuY29tIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsg SSBkb24ndCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBkZXNpZ24gYW4gYXBwIHByb3RvY29sIHRo YXQgZG9lc24ndCBzZW5kIGE8YnI+DQomZ3Q7IFJTVCBpbiByZXNwb25zZSB0byBhIFJTVC48YnI+ DQo8YnI+DQpJJ3ZlIGJlZW4gdG9sZCBub3QgdG8gaW52b2tlIHRoaXMgcGFydGljdWxhciBkZW1v biwgYnV0IHlvdSBqdXN0PGJyPg0KaW52b2tlZCB0aGUgVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBw cm9ibGVtLiZuYnNwOyBJIHRoaW5rIHRoYXQgd2UgZ2V0IHRoZXJlPGJyPg0KYmVjYXVzZSBvZiB0 aGlzIG1lbWUgdGhhdCBzYXlzIHRoYXQgZGF0YSBpbiB0aGUgb25lIGRpcmVjdGlvbiBpczxicj4N CnNvbWVob3cgbmVjZXNzYXJpbHkgYm91bmQgdG8gZGF0YSBpbiB0aGUgb3RoZXIgZGlyZWN0aW9u LiZuYnNwOyBUaGF0J3MgYW48YnI+DQplbnRpcmVseSBjb25zdHJ1Y3RlZCBub3Rpb24uJm5ic3A7 IEEgdXNlZnVsIGNvbnN0cnVjdCBhdCB0aW1lcywgY2VydGFpbmx5LDxicj4NCmJ1dCB0aGF0J3Mg bm90IHRoZSBwb2ludCBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0J3MgdGhlIG1vc3QgY29tbW9uIHVz ZSBvZiBhIFJTVCAtLSB0byBjbG9zZSBib3RoIGRpcmVjdGlvbnMuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBJIGRpc2FncmVlLiZuYnNwOyBUaGVyZSBh cmUgbWFueSBwcm90b2NvbHMgaW4gd2hpY2ggeW91IHNlbmQgbWVzc2FnZXM8YnI+DQooPT0gc3Ry ZWFtcykgaW4gb25lIGRpcmVjdGlvbiBidXQgbm90IGFub3RoZXIuJm5ic3A7IE9uZSBvZiB0aGUg d2F5cyB5b3U8YnI+DQpnZXQgaW50byBhIHVuaWRpcmVjdGlvbmFsIHN0YXRlIGluIHRoZSBjdXJy ZW50IGRyYWZ0IGlzIHRvIGVuZCBvbmU8YnI+DQpzaWRlLiZuYnNwOyBBIEZJTiBpcyBvbmx5IG9u ZSB3YXkgdG8gZG8gdGhhdCwgYSB1bmlkaXJlY3Rpb25hbCBSU1QgY2FuIGJlPGJyPg0KZmFzdGVy IGFuZCBldmVuIHN1cGVyaW9yIGluIG90aGVyIHdheXMuJm5ic3A7IFRoZSBIVFRQIHVzZSBjYXNl IGNsZWFybHk8YnI+DQppbGx1c3RyYXRlcyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RklOIGlzIHRoZSBwcmltYXJ5IHdh eSBpbiB3aGljaCBoYWxmLWNsb3NlIGlzIGFjaGlldmVkLCB3aGljaCBpcyB3aGF0IHlvdSdyZSB0 YWxraW5nIGFib3V0LiBUaGUgSFRUUCB1c2UgY2FzZSBpcyBhIGNvbXBsZXRlIG9uZS1vZmYgLS0g U1RPUF9TRU5ESU5HIGlzIGFuIG9kZCBlbm91Z2ggdXNlIGNhc2UgdGhhdCBJJ20gYWx3YXlzIGxl ZnQgd29uZGVyaW5nIHdobyBhY3R1YWxseSB1c2VzIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgYXMgSWdvciBvYnNlcnZlcywgd2UgZG9uJ3QgcmVxdWly ZSBhIHJlY2lwcm9jYWwgUlNUX1NUUkVBTSBpbjxicj4NCnRoZSBjdXJyZW50IGRyYWZ0LjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WWVzLCB3ZSBkb24ndC4gUmVjYWxsIHRoYXQgdGhlIFJTVF9TVFJFQU0gd2FzLCBwcmlvciB0byB0 aGUgY2hhbmdlIHRoYXQgZG9lc24ndCByZXF1aXJlIHJlY2lwcm9jaXR5LCBhIGJpZGlyZWN0aW9u YWwgc2lnbmFsLCB3aGljaCB3YXMgc2ltcGxpZmllZCB0byBhIHVuaWRpcmVjdGlvbmFsIG9uZSwg d2l0aCB0aGUgZ2VuZXJhbCBleHBlY3RhdGlvbiB0aGF0IGFwcHMgd291bGQgY2xvc2UgdGhlIG90 aGVyIHNpZGUNCiB3aGVuIHRoZXkgcmVjZWl2ZSB0aGlzIHNpZ25hbCBmcm9tIFFVSUMuIEl0J3Mg c3VyZWx5IGdvaW5nIHRvIGJlIHRydWUgb2YgSFRUUC4gSXQncyBwb3NzaWJsZSBmb3IgYW4gYXBw IHRvIHJlY2VpdmUgYSBSU1QgYW5kIHRoZW4ga2VlcCBzZW5kaW5nLCBidXQgdGhhdCBpcyBhIHVz ZSBjYXNlIEkgaGF2ZW4ndCBzZWVuIGluIHByYWN0aWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR21MB01302C7E8A43AF9DB7A63335876E0BN6PR21MB0130namp_-- From nobody Tue Sep 12 21:23:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101E3133529 for ; Tue, 12 Sep 2017 21:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 S9w7rPA6DnpZ for ; Tue, 12 Sep 2017 21:23:49 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE0A132964 for ; Tue, 12 Sep 2017 21:23:48 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8D4M2XP005653; Wed, 13 Sep 2017 05:23:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=WfA8iwfuzK8xLnijbNMmXGdpUNgxDh34zzl7NnhhwRc=; b=GkhTYOxEjmVr+/isx4iX4lVtBI53F+9I9z2fQvBT6H0e7kBLuNCunhSqKZIpOtMT1Y4n IxYNYB1eYhGLFgr8s8TPOZoEIH+sQOCXLT2+UgKkoFONUuCdvlgVaPR/kXfS3djQ41e9 Jb9K+itR0u7crBC2DvAHo6kZinogQ4tnGk8NdeJoc1t7j0uOVmluplh17Ljk3kXB6Qp+ 7dsKAaiNEgOY8vmTbqDsQyoxt3/Rfx5oEwqYGvmlVitxR+qnv6GUYKSbJNDASchz3YaS LqTbf7mwaeHvJjvJanTMDgCtXmEXZCB2wAYWIia7D64o7ZWFBSDKmn8PfExdf9B/7Mg8 ZQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2cx9sydmdb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 05:23:38 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8D4Kf7t009995; Wed, 13 Sep 2017 00:23:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cwwqk4hmf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 00:23:37 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 23:23:35 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Tue, 12 Sep 2017 23:23:35 -0500 From: "Lubashev, Igor" To: Mike Bishop , Jana Iyengar , Martin Thomson CC: "Philipp S. Tiesel" , Subodh Iyengar , Nick Harper , QUIC WG , Victor Vasiliev Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9U7CZmvfU3U+AKlwSnR9wwKKmV3WAgAASqICAAAONAIAA0yCAgAAOnACAAAMMAIAAAK4AgACXxwCAAJELAIABpR2AgABJmoCAAAS/AIAANHEAgAFsKYCABkENAP//wQ6Q Date: Wed, 13 Sep 2017 04:23:35 +0000 Message-ID: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.252] Content-Type: multipart/alternative; boundary="_000_bca00829d58049fb8a644f3787011fcaustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130066 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130066 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 04:23:52 -0000 --_000_bca00829d58049fb8a644f3787011fcaustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIHZlcnkgZ29vZCBpZGVhIHRvIGRlY2lkZSB3aGF0IHdlIHdhbnQgdG8gbW9kZWwg c3RyZWFtcyBvbi4gIFN0YXJ0aW5nIHdpdGggd2VsbC1rbm93biwgc2ltcGxlIGFic3RyYWN0aW9u cyBzZWVtcyBsaWtlIHRoZSBiZXN0IHBhdGggdG8gYWRvcHRpb24uDQoNClRoZXJlIGFyZSB0d28g c3VjaCBhYnN0cmFjdGlvbnMgdGhhdCBjb21lIHRvIG1pbmQ6DQoNCg0KICAxLiAg4oCcVENQIFN0 cmVhbSBzb2NrZXRz4oCdLiAgVGhlc2Ugb25seSBzdXBwb3J0IHNpZ25hbGluZyDigJxvcmRlcmx5 4oCdIGNsb3Npbmcgb2YgdGhlIHdyaXRlIGRpcmVjdGlvbi4gIENsb3Npbmcgb2YgdGhlIHJlYWQg ZGlyZWN0aW9uIGNhbiBvbmx5IGJlIGRvbmUgdmlhIGNsb3NlKCksIGJ1dCB0aGF0IG1heSBsZWF2 ZSB0aGUgd3JpdGUgZGlyZWN0aW9uIGluIGFuIHVuZGVmaW5lZCBzdGF0ZSAod3JpdGluZyB3aWxs IGNvbXBsZXRlLCB1bmxlc3MgdGhlcmUgd2FzIHVucmVhZCBkYXRhIGluIHRoZSByZWFkIGJ1ZmZl ciBvciBhbnkgZGF0YSBpcyByZWNlaXZlZCBhZnRlciBjbG9zZSDigJMgc2VlIFJGQyAxMTIyIDQu Mi4yLjEzICQzKS4NCg0KDQpJIHRoaW5rIHRoZSBjdXJyZW50IHNwZWMgYWxsb3dzIGZvciBRVUlD IEFQSSB0byBlbXVsYXRlIFRDUCBzdHJlYW0gc29ja2V0IGFic3RyYWN0aW9uLiAgQ3VycmVudCBz cGVjICBhbHNvIGFkZHMgc2lnbmFsaW5nIOKAnGFib3J04oCdIGNsb3Npbmcgb2YgdGhlIHdyaXRl IGRpcmVjdGlvbiAoUlNUX1NUUkVBTSBkb2VzIG5vdCByZXF1aXJlIGFuIGltbWVkaWF0ZSBSU1Rf U1RSRUFNIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24pLCBhbHRob3VnaCB0aGVyZSB3YXMgc29t ZSB0YWxrIG9mIHJlbW92aW5nIHRoaXMgZmVhdHVyZS4NCg0KDQogIDEuICDigJxBIFBPU0lYIHBp cGUgcGFpcuKAnSwgYXMgTWlrZSBpcyBwcm9wb3NpbmcgKG9uZSBwYWlyIGluIGVhY2ggZGlyZWN0 aW9uKS4gIENvbm5lY3RlZCBwaXBlcyBhcmUgdmVyeSBjbGVhbiAo4oCYc3ltbWV0cmlj4oCZKSBh YnN0cmFjdGlvbnMsIGFuZCB0aGV5IGNvbW11bmljYXRlIGNsb3NlIGV2ZW50cyAoeW91IGNsb3Nl IHRoZSDigJh3cml0ZeKAmSBwaXBlLCDigJhyZWFk4oCZIHBpcGUgZ2V0IEVPUzsgeW91IGNsb3Nl IHRoZSDigJhyZWFk4oCZIHBpcGUsIOKAmHdyaXRl4oCZIHBpcGUgZ2V0cyBhbiBleGNlcHRpb24p Lg0KDQoNCg0KV2l0aCByZWFkLWRpcmVjdGlvbiBjbG9zZSBzaWduYWxpbmcsIGhvd2V2ZXIsIGl0 IGlzIGltcG9ydGFudCB0byBub3QgdG8gY2F1c2Ugb2Z0ZW4tdW5uZWNlc3NhcnkgU1RPUF9TRU5E SU5HIGZyYW1lcyBzZW50IGZvciBldmVyeSBjb21tb24tY2FzZSBzdHJlYW0uY2xvc2UoKS4gSSB0 aGluayB0aGF0IGNvdWxkIGJlIGRvbmUgdmlhIG9uZSBvZiB0aGUgZm9sbG93aW5nIHdheXM6DQoN CiAgMS4gIFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMuIFNlbmQgU1RPUF9TRU5ESU5HIG9uIGNsb3Nl KCkgYnkgdGhlIHJlY2VpdmVyIChpZiB0aGUgc3RlYW0gaXMgb3BlbikuDQogIDIuICBBUEkgY29u dmVudGlvbjog4oCcb25seSBzZW5kIFNUT1BfU0VORElORyBvbiBzdHJlYW0uaW5wdXRTdHJlYW0o KS5jbG9zZSgp4oCdLiBPbiBzdHJlYW0uY2xvc2UoKSwgb25seSBzZW5kIFNUT1BfU0VORElORyBp ZiB0aGVyZSBpcyB1bnJlYWQgZGF0YSBvciBuZXcgZGF0YSBjb21lcyBpbiBsYXRlci4NCiAgMy4g IEFjdHVhbGx5IHNpZ25hbCB0aGF0IHJlYWQgZGlyZWN0aW9uIGlzIGNsb3NlZCBpbiBzdHJlYW0u Y2xvc2UoKSBieSBkZWZpbmluZyBTVFJFQU0td2l0aC1GSU4gZnJhbWUgYXMg4oCcY2xvc2UgYm90 aCB3cml0ZSBhbmQgcmVhZCBkaXJlY3Rpb25z4oCdIChjb21tb24gY2FzZSkuICBIYXZlIHNlcGFy YXRlIGZyYW1lIHR5cGVzIGZvciBXUklURV9DTE9TRSwgV1JJVEVfQUJPUlQgKGFrYSBSU1RfU1RS RUFNKSwgYW5kIFJFQURfQUJPUlQgKGFrYSBTVE9QX1NFTkRJTkcpLg0KDQoNCkZyb206IE1pa2Ug QmlzaG9wIFttYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbV0NClNlbnQ6IFR1ZXNk YXksIFNlcHRlbWJlciAxMiwgMjAxNyA4OjA0IFBNDQpUbzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29v Z2xlLmNvbT47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzog UGhpbGlwcCBTLiBUaWVzZWwgPHBoaWxzQGluLXBhbmlrLmRlPjsgU3Vib2RoIEl5ZW5nYXIgPHN1 Ym9kaEBmYi5jb20+OyBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPjsgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZz47IFZpY3RvciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPg0KU3Vi amVjdDogUkU6IFNwbGl0IGVycm9yIGNvZGVzIGluIHR3bw0KDQpKYW5hIGFuZCBJIHdlcmUgZGlz Y3Vzc2luZyB0aGlzIHRvZGF5LCBhbmQgcGFydCBvZiB0aGUgZGlmZmVyZW5jZSBjb21lcyBkb3du IHRvIGhvdyB5b3UgY29uY2VpdmUgb2YgdGhlIEFQSSBhIFFVSUMgaW1wbGVtZW50YXRpb24gd2ls bCBleHBvc2UuICBNeSBtZW50YWwgbW9kZWwgaGFzIGJlZW4gdGhhdCBhIHN0cmVhbS9zdHJlYW0t cGFpciBjb25zaXN0cyBvZiBhbiBJbnB1dFN0cmVhbSBhbmQgYW4gT3V0cHV0U3RyZWFtOyB5b3Ug Y2FuIHJlYWQgb24gb25lLCB5b3UgY2FuIHdyaXRlIG9uIHRoZSBvdGhlci4gIEZvciB0aGUgd3Jp dGUgc3RyZWFtLCB5b3UgY2FuIHdyaXRlIHlvdXIgZGF0YSB0byBjb21wbGV0aW9uIGFuZCBjbG9z ZSB0aGUgc3RyZWFtLCBvciB5b3UgY2FuIGRlY2lkZSB0byBhYm9ydCB3cml0aW5nLiAgVGhlIHdp cmUgZXhwcmVzc2lvbnMgb2YgdGhlc2UgYXJlIEZJTiBhbmQgUlNUX1NUUkVBTSwgcmVzcGVjdGl2 ZWx5LiAgRm9yIHRoZSByZWFkIHN0cmVhbSwgeW91IGNhbiByZWFkIHRoZSBpbmNvbWluZyBkYXRh IHRvIHRoZSBlbmQgb3IgeW91IGNhbiBhYm9ydCByZWFkaW5nIGFuZCBkaXNjYXJkIHRoZSByZW1h aW5kZXIgb2YgdGhlIHN0cmVhbTsgdGhlIHdpcmUgZXhwcmVzc2lvbiBvZiB0aGlzIHdvdWxkIGJl IGZsb3cgY29udHJvbCB1cGRhdGVzIGFuZCBTVE9QX1NFTkRJTkcsIHJlc3BlY3RpdmVseS4gIE9u IHRoZSBvdGhlciBzaWRlLCByZWNlaXB0IG9mIGEgUlNUX1NUUkVBTSBzdXJmYWNlcyBhcyBhIHJl YWQgZXJyb3IgYW5kIHJlY2VpcHQgb2YgYSBTVE9QX1NFTkRJTkcgc3VyZmFjZXMgYXMgYSB3cml0 ZSBlcnJvci4gIChKYW5hIGNvbW1lbnRlZCB0aGF0IGluIHRoaXMgbWVudGFsIG1vZGVsIGl0IG1p Z2h0IGJlIGNsZWFyZXIgdG8gY2FsbCB0aGUgZnJhbWVzIFdSSVRFX0FCT1JUIGFuZCBSRUFEX0FC T1JULikNCg0KSWYgd2UgdGFrZSBNYXJ0aW7igJlzIHByb3Bvc2l0aW9uIHRoYXQgc3RyZWFtcyBv bmx5IGNsb3NlIGJ5IGFwcGxpY2F0aW9uIGFjdGlvbiwgdGhlcmUgd291bGQgbmV2ZXIgYmUgYSB3 cml0ZSBlcnJvciBzdXJmYWNlZCB0byB0aGUgYXBwbGljYXRpb24gdW5sZXNzIHRoZSB1bmRlcmx5 aW5nIHRyYW5zcG9ydCB3ZW50IGF3YXkgZW50aXJlbHkuICBJbnN0ZWFkLCBpdOKAmXMgdGhlIHJl c3BvbnNpYmlsaXR5IG9mIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbCB0byBjb21tdW5pY2F0ZSAo b24gYW5vdGhlciBzdHJlYW0sIGluIHRoaXMgY2FzZSkgdGhhdCB5b3Ugc2hvdWxkIGFib3J0IHdy aXRpbmcsIGV2ZW4gaWYgeW914oCZdmUgYWxyZWFkeSB3cml0dGVuIHRvIGNvbXBsZXRpb24sIGFu ZCB0aGVuIHRvIGRvIHNvLiAgVGhhdCBpbXBsaWVzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIG5lZWRz IHRoZSBhYmlsaXR5IHRvIHJldHVybiB0byBzdHJlYW1zIG9uIHdoaWNoIGl04oCZcyBkb25lIHdy aXRpbmcsIGluIGNhc2UgaXTigJlzIGxhdGVyIGFza2VkIHRvIGdvIGJhY2sgYW5kIHJlc2V0IHRo ZW0uDQoNCk11Y2ggb2Ygb3VyIGRpc2N1c3Npb25zIGFyb3VuZCB1bmlkaXJlY3Rpb25hbCBzdHJl YW1zLCBzdHJlYW0gc3RhdGUgdHJhbnNpdGlvbnMsIGV0Yy4gaW5jbHVkaW5nIHRoZSBxdWVzdGlv biBvZiB3aGV0aGVyIFNUT1BfU0VORElORyBiZWxvbmdzIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIs IHN0ZW0gZnJvbSB0aGUgZmFjdCB0aGF0IHdlIGFsbCBoYXZlIGRpZmZlcmVudCBpbXBsaWNpdCBt ZW50YWwgbW9kZWxzIG9mIHRoZSBmdW5jdGlvbmFsIHN1cmZhY2UgUVVJQyBleHBvc2VzLiAgUGVy aGFwcyB3ZSBzaG91bGQgdGFrZSBhIHN0ZXAgYmFjayBhbmQgYWdyZWUgb24gdGhhdCBmaXJzdCwg YXMgSSBiZWxpZXZlIENocmlzdGlhbiBoYXMgc3VnZ2VzdGVkIGluIHRoZSBwYXN0Pw0KDQpGcm9t OiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbV0NClNlbnQ6IEZyaWRheSwgU2Vw dGVtYmVyIDgsIDIwMTcgNTozNCBQTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+DQpDYzogU3Vib2Ro IEl5ZW5nYXIgPHN1Ym9kaEBmYi5jb208bWFpbHRvOnN1Ym9kaEBmYi5jb20+PjsgTWlrZSBCaXNo b3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1p Y3Jvc29mdC5jb20+PjsgUGhpbGlwcCBTLiBUaWVzZWwgPHBoaWxzQGluLXBhbmlrLmRlPG1haWx0 bzpwaGlsc0Bpbi1wYW5pay5kZT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWlj QGlldGYub3JnPj47IE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJw ZXJAZ29vZ2xlLmNvbT4+OyBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29vZ2xlLmNvbTxtYWls dG86dmFzaWx2dkBnb29nbGUuY29tPj4NClN1YmplY3Q6IFJlOiBTcGxpdCBlcnJvciBjb2RlcyBp biB0d28NCg0KT24gVGh1LCBTZXAgNywgMjAxNyBhdCA3OjUwIFBNLCBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+ PiB3cm90ZToNCk9uIEZyaSwgU2VwIDgsIDIwMTcgYXQgOTo0MiBBTSwgSmFuYSBJeWVuZ2FyIDxq cmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PiB3cm90ZToNCj4gSSBkb24ndCB0 aGluayBpdCBtYWtlcyBzZW5zZSB0byBkZXNpZ24gYW4gYXBwIHByb3RvY29sIHRoYXQgZG9lc24n dCBzZW5kIGENCj4gUlNUIGluIHJlc3BvbnNlIHRvIGEgUlNULg0KDQpJJ3ZlIGJlZW4gdG9sZCBu b3QgdG8gaW52b2tlIHRoaXMgcGFydGljdWxhciBkZW1vbiwgYnV0IHlvdSBqdXN0DQppbnZva2Vk IHRoZSBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIHByb2JsZW0uICBJIHRoaW5rIHRoYXQgd2UgZ2V0 IHRoZXJlDQpiZWNhdXNlIG9mIHRoaXMgbWVtZSB0aGF0IHNheXMgdGhhdCBkYXRhIGluIHRoZSBv bmUgZGlyZWN0aW9uIGlzDQpzb21laG93IG5lY2Vzc2FyaWx5IGJvdW5kIHRvIGRhdGEgaW4gdGhl IG90aGVyIGRpcmVjdGlvbi4gIFRoYXQncyBhbg0KZW50aXJlbHkgY29uc3RydWN0ZWQgbm90aW9u LiAgQSB1c2VmdWwgY29uc3RydWN0IGF0IHRpbWVzLCBjZXJ0YWlubHksDQpidXQgdGhhdCdzIG5v dCB0aGUgcG9pbnQgaGVyZS4NCg0KSSB0aGluayB0aGF0J3MgdGhlIG1vc3QgY29tbW9uIHVzZSBv ZiBhIFJTVCAtLSB0byBjbG9zZSBib3RoIGRpcmVjdGlvbnMuDQoNClNvIEkgZGlzYWdyZWUuICBU aGVyZSBhcmUgbWFueSBwcm90b2NvbHMgaW4gd2hpY2ggeW91IHNlbmQgbWVzc2FnZXMNCig9PSBz dHJlYW1zKSBpbiBvbmUgZGlyZWN0aW9uIGJ1dCBub3QgYW5vdGhlci4gIE9uZSBvZiB0aGUgd2F5 cyB5b3UNCmdldCBpbnRvIGEgdW5pZGlyZWN0aW9uYWwgc3RhdGUgaW4gdGhlIGN1cnJlbnQgZHJh ZnQgaXMgdG8gZW5kIG9uZQ0Kc2lkZS4gIEEgRklOIGlzIG9ubHkgb25lIHdheSB0byBkbyB0aGF0 LCBhIHVuaWRpcmVjdGlvbmFsIFJTVCBjYW4gYmUNCmZhc3RlciBhbmQgZXZlbiBzdXBlcmlvciBp biBvdGhlciB3YXlzLiAgVGhlIEhUVFAgdXNlIGNhc2UgY2xlYXJseQ0KaWxsdXN0cmF0ZXMgdGhh dC4NCg0KRklOIGlzIHRoZSBwcmltYXJ5IHdheSBpbiB3aGljaCBoYWxmLWNsb3NlIGlzIGFjaGll dmVkLCB3aGljaCBpcyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0LiBUaGUgSFRUUCB1c2UgY2Fz ZSBpcyBhIGNvbXBsZXRlIG9uZS1vZmYgLS0gU1RPUF9TRU5ESU5HIGlzIGFuIG9kZCBlbm91Z2gg dXNlIGNhc2UgdGhhdCBJJ20gYWx3YXlzIGxlZnQgd29uZGVyaW5nIHdobyBhY3R1YWxseSB1c2Vz IGl0Lg0KDQpBbHNvLCBhcyBJZ29yIG9ic2VydmVzLCB3ZSBkb24ndCByZXF1aXJlIGEgcmVjaXBy b2NhbCBSU1RfU1RSRUFNIGluDQp0aGUgY3VycmVudCBkcmFmdC4NCg0KWWVzLCB3ZSBkb24ndC4g UmVjYWxsIHRoYXQgdGhlIFJTVF9TVFJFQU0gd2FzLCBwcmlvciB0byB0aGUgY2hhbmdlIHRoYXQg ZG9lc24ndCByZXF1aXJlIHJlY2lwcm9jaXR5LCBhIGJpZGlyZWN0aW9uYWwgc2lnbmFsLCB3aGlj aCB3YXMgc2ltcGxpZmllZCB0byBhIHVuaWRpcmVjdGlvbmFsIG9uZSwgd2l0aCB0aGUgZ2VuZXJh bCBleHBlY3RhdGlvbiB0aGF0IGFwcHMgd291bGQgY2xvc2UgdGhlIG90aGVyIHNpZGUgd2hlbiB0 aGV5IHJlY2VpdmUgdGhpcyBzaWduYWwgZnJvbSBRVUlDLiBJdCdzIHN1cmVseSBnb2luZyB0byBi ZSB0cnVlIG9mIEhUVFAuIEl0J3MgcG9zc2libGUgZm9yIGFuIGFwcCB0byByZWNlaXZlIGEgUlNU IGFuZCB0aGVuIGtlZXAgc2VuZGluZywgYnV0IHRoYXQgaXMgYSB1c2UgY2FzZSBJIGhhdmVuJ3Qg c2VlbiBpbiBwcmFjdGljZS4NCg0K --_000_bca00829d58049fb8a644f3787011fcaustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjkzMzE2 OTk5ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQz NDI0NTM2OCAtMTI1OTE4NDIyOCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUx XCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDouNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDoxLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdp bi1sZWZ0OjEuNzVpbjsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoyLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFy Z2luLWxlZnQ6Mi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVm dDozLjI1aW47DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6My43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjQuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6NC43 NWluOw0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxOTQw MTM0NzkxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox MTUxODg4NjMyIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwyDQoJe21zby1saXN0LWlkOjIwNTczODY1MjY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDQ3OTE4NTIwIC01NDcxOTQ4MzYgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhIHZlcnkgZ29vZCBpZGVh IHRvIGRlY2lkZSB3aGF0IHdlIHdhbnQgdG8gbW9kZWwgc3RyZWFtcyBvbi4mbmJzcDsgU3RhcnRp bmcgd2l0aCB3ZWxsLWtub3duLCBzaW1wbGUgYWJzdHJhY3Rpb25zIHNlZW1zIGxpa2UgdGhlIGJl c3QgcGF0aCB0byBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIHR3 byBzdWNoIGFic3RyYWN0aW9ucyB0aGF0IGNvbWUgdG8gbWluZDo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj7igJxU Q1AgU3RyZWFtIHNvY2tldHPigJ0uJm5ic3A7IFRoZXNlIG9ubHkgc3VwcG9ydCBzaWduYWxpbmcg 4oCcb3JkZXJseeKAnSBjbG9zaW5nIG9mIHRoZSB3cml0ZSBkaXJlY3Rpb24uJm5ic3A7IENsb3Np bmcgb2YgdGhlIHJlYWQgZGlyZWN0aW9uIGNhbiBvbmx5IGJlIGRvbmUgdmlhIGNsb3NlKCksIGJ1 dCB0aGF0IG1heSBsZWF2ZSB0aGUgd3JpdGUNCiBkaXJlY3Rpb24gaW4gYW4gdW5kZWZpbmVkIHN0 YXRlICh3cml0aW5nIHdpbGwgY29tcGxldGUsIHVubGVzcyB0aGVyZSB3YXMgdW5yZWFkIGRhdGEg aW4gdGhlIHJlYWQgYnVmZmVyIG9yIGFueSBkYXRhIGlzIHJlY2VpdmVkIGFmdGVyIGNsb3NlIOKA kyBzZWUgUkZDIDExMjIgNC4yLjIuMTMgJDMpLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9saT48 L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPkkgdGhpbmsgdGhlIGN1cnJlbnQgc3Bl YyBhbGxvd3MgZm9yIFFVSUMgQVBJIHRvIGVtdWxhdGUgVENQIHN0cmVhbSBzb2NrZXQgYWJzdHJh Y3Rpb24uJm5ic3A7IEN1cnJlbnQgc3BlYyAmbmJzcDthbHNvIGFkZHMgc2lnbmFsaW5nIOKAnGFi b3J04oCdIGNsb3Npbmcgb2YgdGhlIHdyaXRlIGRpcmVjdGlvbiAoUlNUX1NUUkVBTSBkb2VzIG5v dCByZXF1aXJlIGFuIGltbWVkaWF0ZSBSU1RfU1RSRUFNIGluIHRoZSBvcHBvc2l0ZQ0KIGRpcmVj dGlvbiksIGFsdGhvdWdoIHRoZXJlIHdhcyBzb21lIHRhbGsgb2YgcmVtb3ZpbmcgdGhpcyBmZWF0 dXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPuKAnEEgUE9TSVggcGlwZSBwYWly4oCdLCBhcyBNaWtlIGlzIHBy b3Bvc2luZyAob25lIHBhaXIgaW4gZWFjaCBkaXJlY3Rpb24pLiZuYnNwOyBDb25uZWN0ZWQgcGlw ZXMgYXJlIHZlcnkgY2xlYW4gKOKAmHN5bW1ldHJpY+KAmSkgYWJzdHJhY3Rpb25zLCBhbmQgdGhl eSBjb21tdW5pY2F0ZSBjbG9zZSBldmVudHMgKHlvdSBjbG9zZSB0aGUNCiDigJh3cml0ZeKAmSBw aXBlLCDigJhyZWFk4oCZIHBpcGUgZ2V0IEVPUzsgeW91IGNsb3NlIHRoZSDigJhyZWFk4oCZIHBp cGUsIOKAmHdyaXRl4oCZIHBpcGUgZ2V0cyBhbiBleGNlcHRpb24pLjxvOnA+PC9vOnA+PC9saT48 L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPldpdGggcmVhZC1kaXJlY3Rpb24gY2xvc2Ugc2ln bmFsaW5nLCBob3dldmVyLCBpdCBpcyBpbXBvcnRhbnQgdG8gbm90IHRvIGNhdXNlIG9mdGVuLXVu bmVjZXNzYXJ5IFNUT1BfU0VORElORyBmcmFtZXMgc2VudCBmb3IgZXZlcnkgY29tbW9uLWNhc2Ug c3RyZWFtLmNsb3NlKCkuIEkgdGhpbmsgdGhhdCBjb3VsZCBiZSBkb25lIHZpYSBvbmUgb2YgdGhl IGZvbGxvd2luZyB3YXlzOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlVuaWRpcmVjdGlv bmFsIHN0cmVhbXMuIFNlbmQgU1RPUF9TRU5ESU5HIG9uIGNsb3NlKCkgYnkgdGhlIHJlY2VpdmVy IChpZiB0aGUgc3RlYW0gaXMgb3BlbikuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8zIj5BUEkgY29udmVudGlvbjog4oCcb25seSBzZW5kIFNUT1BfU0VORElORyBvbiBzdHJlYW0u aW5wdXRTdHJlYW0oKS5jbG9zZSgp4oCdLiBPbiBzdHJlYW0uY2xvc2UoKSwgb25seSBzZW5kIFNU T1BfU0VORElORyBpZiB0aGVyZSBpcyB1bnJlYWQgZGF0YSBvciBuZXcgZGF0YSBjb21lcyBpbiBs YXRlci48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPkFjdHVhbGx5IHNpZ25h bCB0aGF0IHJlYWQgZGlyZWN0aW9uIGlzIGNsb3NlZCBpbiBzdHJlYW0uY2xvc2UoKSBieSBkZWZp bmluZyBTVFJFQU0td2l0aC1GSU4gZnJhbWUgYXMg4oCcY2xvc2UgYm90aCB3cml0ZSBhbmQgcmVh ZCBkaXJlY3Rpb25z4oCdIChjb21tb24gY2FzZSkuJm5ic3A7IEhhdmUgc2VwYXJhdGUgZnJhbWUg dHlwZXMNCiBmb3IgV1JJVEVfQ0xPU0UsIFdSSVRFX0FCT1JUIChha2EgUlNUX1NUUkVBTSksIGFu ZCBSRUFEX0FCT1JUIChha2EgU1RPUF9TRU5ESU5HKS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1pa2UgQmlzaG9wIFttYWls dG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTcgODowNCBQTTxicj4NCjxiPlRvOjwvYj4gSmFuYSBJeWVu Z2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQaGlsaXBwIFMuIFRpZXNlbCAmbHQ7 cGhpbHNAaW4tcGFuaWsuZGUmZ3Q7OyBTdWJvZGggSXllbmdhciAmbHQ7c3Vib2RoQGZiLmNvbSZn dDs7IE5pY2sgSGFycGVyICZsdDtuaGFycGVyQGdvb2dsZS5jb20mZ3Q7OyBRVUlDIFdHICZsdDtx dWljQGlldGYub3JnJmd0OzsgVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2QGdvb2dsZS5jb20m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBTcGxpdCBlcnJvciBjb2RlcyBpbiB0d288bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbmEgYW5kIEkgd2VyZSBkaXNj dXNzaW5nIHRoaXMgdG9kYXksIGFuZCBwYXJ0IG9mIHRoZSBkaWZmZXJlbmNlIGNvbWVzIGRvd24g dG8gaG93IHlvdSBjb25jZWl2ZSBvZiB0aGUgQVBJIGEgUVVJQyBpbXBsZW1lbnRhdGlvbiB3aWxs IGV4cG9zZS4mbmJzcDsgTXkgbWVudGFsIG1vZGVsIGhhcyBiZWVuIHRoYXQgYSBzdHJlYW0vc3Ry ZWFtLXBhaXIgY29uc2lzdHMgb2YgYW4gSW5wdXRTdHJlYW0gYW5kIGFuIE91dHB1dFN0cmVhbTsN CiB5b3UgY2FuIHJlYWQgb24gb25lLCB5b3UgY2FuIHdyaXRlIG9uIHRoZSBvdGhlci4mbmJzcDsg Rm9yIHRoZSB3cml0ZSBzdHJlYW0sIHlvdSBjYW4gd3JpdGUgeW91ciBkYXRhIHRvIGNvbXBsZXRp b24gYW5kIGNsb3NlIHRoZSBzdHJlYW0sIG9yIHlvdSBjYW4gZGVjaWRlIHRvIGFib3J0IHdyaXRp bmcuJm5ic3A7IFRoZSB3aXJlIGV4cHJlc3Npb25zIG9mIHRoZXNlIGFyZSBGSU4gYW5kIFJTVF9T VFJFQU0sIHJlc3BlY3RpdmVseS4mbmJzcDsgRm9yIHRoZSByZWFkIHN0cmVhbSwNCiB5b3UgY2Fu IHJlYWQgdGhlIGluY29taW5nIGRhdGEgdG8gdGhlIGVuZCBvciB5b3UgY2FuIGFib3J0IHJlYWRp bmcgYW5kIGRpc2NhcmQgdGhlIHJlbWFpbmRlciBvZiB0aGUgc3RyZWFtOyB0aGUgd2lyZSBleHBy ZXNzaW9uIG9mIHRoaXMgd291bGQgYmUgZmxvdyBjb250cm9sIHVwZGF0ZXMgYW5kIFNUT1BfU0VO RElORywgcmVzcGVjdGl2ZWx5LiZuYnNwOyBPbiB0aGUgb3RoZXIgc2lkZSwgcmVjZWlwdCBvZiBh IFJTVF9TVFJFQU0gc3VyZmFjZXMgYXMgYQ0KIHJlYWQgZXJyb3IgYW5kIHJlY2VpcHQgb2YgYSBT VE9QX1NFTkRJTkcgc3VyZmFjZXMgYXMgYSB3cml0ZSBlcnJvci4mbmJzcDsgKEphbmEgY29tbWVu dGVkIHRoYXQgaW4gdGhpcyBtZW50YWwgbW9kZWwgaXQgbWlnaHQgYmUgY2xlYXJlciB0byBjYWxs IHRoZSBmcmFtZXMgV1JJVEVfQUJPUlQgYW5kIFJFQURfQUJPUlQuKTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JZiB3ZSB0YWtlIE1hcnRpbuKAmXMgcHJvcG9zaXRpb24gdGhhdCBzdHJlYW1zIG9u bHkgY2xvc2UgYnkgYXBwbGljYXRpb24gYWN0aW9uLCB0aGVyZSB3b3VsZCBuZXZlciBiZSBhIHdy aXRlIGVycm9yIHN1cmZhY2VkIHRvIHRoZSBhcHBsaWNhdGlvbiB1bmxlc3MgdGhlIHVuZGVybHlp bmcgdHJhbnNwb3J0IHdlbnQgYXdheSBlbnRpcmVseS4mbmJzcDsgSW5zdGVhZCwgaXTigJlzIHRo ZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgYXBwbGljYXRpb24NCiBwcm90b2NvbCB0byBjb21tdW5p Y2F0ZSAob24gYW5vdGhlciBzdHJlYW0sIGluIHRoaXMgY2FzZSkgdGhhdCB5b3Ugc2hvdWxkIGFi b3J0IHdyaXRpbmcsIGV2ZW4gaWYgeW914oCZdmUgYWxyZWFkeSB3cml0dGVuIHRvIGNvbXBsZXRp b24sIGFuZCB0aGVuIHRvIGRvIHNvLiZuYnNwOyBUaGF0IGltcGxpZXMgdGhhdCB0aGUgYXBwbGlj YXRpb24gbmVlZHMgdGhlIGFiaWxpdHkgdG8gcmV0dXJuIHRvIHN0cmVhbXMgb24gd2hpY2ggaXTi gJlzIGRvbmUgd3JpdGluZywNCiBpbiBjYXNlIGl04oCZcyBsYXRlciBhc2tlZCB0byBnbyBiYWNr IGFuZCByZXNldCB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NdWNoIG9mIG91ciBkaXNj dXNzaW9ucyBhcm91bmQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcywgc3RyZWFtIHN0YXRlIHRyYW5z aXRpb25zLCBldGMuIGluY2x1ZGluZyB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBTVE9QX1NFTkRJ TkcgYmVsb25ncyBhdCB0aGUgdHJhbnNwb3J0IGxheWVyLCBzdGVtIGZyb20gdGhlIGZhY3QgdGhh dCB3ZSBhbGwgaGF2ZSBkaWZmZXJlbnQgaW1wbGljaXQgbWVudGFsIG1vZGVscyBvZg0KIHRoZSBm dW5jdGlvbmFsIHN1cmZhY2UgUVVJQyBleHBvc2VzLiZuYnNwOyBQZXJoYXBzIHdlIHNob3VsZCB0 YWtlIGEgc3RlcCBiYWNrIGFuZCBhZ3JlZSBvbiB0aGF0IGZpcnN0LCBhcyBJIGJlbGlldmUgQ2hy aXN0aWFuIGhhcyBzdWdnZXN0ZWQgaW4gdGhlIHBhc3Q/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBKYW5hIEl5ZW5nYXIgWzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNv bSI+bWFpbHRvOmpyaUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IFNlcHRlbWJlciA4LCAyMDE3IDU6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29u ICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gU3Vib2RoIEl5ZW5nYXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpzdWJvZGhAZmIuY29tIj5zdWJvZGhAZmIuY29tPC9hPiZndDs7IE1p a2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNv bSI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBQaGlsaXBwIFMuIFRpZXNl bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlIj5waGlsc0Bpbi1wYW5pay5k ZTwvYT4mZ3Q7OyBRVUlDIFdHDQogJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5x dWljQGlldGYub3JnPC9hPiZndDs7IE5pY2sgSGFycGVyICZsdDs8YSBocmVmPSJtYWlsdG86bmhh cnBlckBnb29nbGUuY29tIj5uaGFycGVyQGdvb2dsZS5jb208L2E+Jmd0OzsgVmljdG9yIFZhc2ls aWV2ICZsdDs8YSBocmVmPSJtYWlsdG86dmFzaWx2dkBnb29nbGUuY29tIj52YXNpbHZ2QGdvb2ds ZS5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU3BsaXQgZXJyb3IgY29kZXMg aW4gdHdvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgU2VwIDcsIDIwMTcgYXQgNzo1MCBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1h aWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gRnJpLCBTZXAgOCwgMjAxNyBhdCA5OjQyIEFNLCBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+anJpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7IEkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gZGVzaWduIGFuIGFwcCBw cm90b2NvbCB0aGF0IGRvZXNuJ3Qgc2VuZCBhPGJyPg0KJmd0OyBSU1QgaW4gcmVzcG9uc2UgdG8g YSBSU1QuPGJyPg0KPGJyPg0KSSd2ZSBiZWVuIHRvbGQgbm90IHRvIGludm9rZSB0aGlzIHBhcnRp Y3VsYXIgZGVtb24sIGJ1dCB5b3UganVzdDxicj4NCmludm9rZWQgdGhlIFVuaWRpcmVjdGlvbmFs IHN0cmVhbXMgcHJvYmxlbS4mbmJzcDsgSSB0aGluayB0aGF0IHdlIGdldCB0aGVyZTxicj4NCmJl Y2F1c2Ugb2YgdGhpcyBtZW1lIHRoYXQgc2F5cyB0aGF0IGRhdGEgaW4gdGhlIG9uZSBkaXJlY3Rp b24gaXM8YnI+DQpzb21laG93IG5lY2Vzc2FyaWx5IGJvdW5kIHRvIGRhdGEgaW4gdGhlIG90aGVy IGRpcmVjdGlvbi4mbmJzcDsgVGhhdCdzIGFuPGJyPg0KZW50aXJlbHkgY29uc3RydWN0ZWQgbm90 aW9uLiZuYnNwOyBBIHVzZWZ1bCBjb25zdHJ1Y3QgYXQgdGltZXMsIGNlcnRhaW5seSw8YnI+DQpi dXQgdGhhdCdzIG5vdCB0aGUgcG9pbnQgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCdzIHRoZSBtb3N0 IGNvbW1vbiB1c2Ugb2YgYSBSU1QgLS0gdG8gY2xvc2UgYm90aCBkaXJlY3Rpb25zLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gSSBkaXNhZ3JlZS4mbmJz cDsgVGhlcmUgYXJlIG1hbnkgcHJvdG9jb2xzIGluIHdoaWNoIHlvdSBzZW5kIG1lc3NhZ2VzPGJy Pg0KKD09IHN0cmVhbXMpIGluIG9uZSBkaXJlY3Rpb24gYnV0IG5vdCBhbm90aGVyLiZuYnNwOyBP bmUgb2YgdGhlIHdheXMgeW91PGJyPg0KZ2V0IGludG8gYSB1bmlkaXJlY3Rpb25hbCBzdGF0ZSBp biB0aGUgY3VycmVudCBkcmFmdCBpcyB0byBlbmQgb25lPGJyPg0Kc2lkZS4mbmJzcDsgQSBGSU4g aXMgb25seSBvbmUgd2F5IHRvIGRvIHRoYXQsIGEgdW5pZGlyZWN0aW9uYWwgUlNUIGNhbiBiZTxi cj4NCmZhc3RlciBhbmQgZXZlbiBzdXBlcmlvciBpbiBvdGhlciB3YXlzLiZuYnNwOyBUaGUgSFRU UCB1c2UgY2FzZSBjbGVhcmx5PGJyPg0KaWxsdXN0cmF0ZXMgdGhhdC48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZJTiBpcyB0aGUg cHJpbWFyeSB3YXkgaW4gd2hpY2ggaGFsZi1jbG9zZSBpcyBhY2hpZXZlZCwgd2hpY2ggaXMgd2hh dCB5b3UncmUgdGFsa2luZyBhYm91dC4gVGhlIEhUVFAgdXNlIGNhc2UgaXMgYSBjb21wbGV0ZSBv bmUtb2ZmIC0tIFNUT1BfU0VORElORyBpcyBhbiBvZGQgZW5vdWdoIHVzZSBjYXNlIHRoYXQgSSdt IGFsd2F5cyBsZWZ0IHdvbmRlcmluZyB3aG8gYWN0dWFsbHkgdXNlcyBpdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIGFzIElnb3Igb2JzZXJ2ZXMsIHdlIGRv bid0IHJlcXVpcmUgYSByZWNpcHJvY2FsIFJTVF9TVFJFQU0gaW48YnI+DQp0aGUgY3VycmVudCBk cmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlllcywgd2UgZG9uJ3QuIFJlY2FsbCB0aGF0IHRoZSBSU1RfU1RSRUFNIHdhcywg cHJpb3IgdG8gdGhlIGNoYW5nZSB0aGF0IGRvZXNuJ3QgcmVxdWlyZSByZWNpcHJvY2l0eSwgYSBi aWRpcmVjdGlvbmFsIHNpZ25hbCwgd2hpY2ggd2FzIHNpbXBsaWZpZWQgdG8gYSB1bmlkaXJlY3Rp b25hbCBvbmUsIHdpdGggdGhlIGdlbmVyYWwgZXhwZWN0YXRpb24gdGhhdCBhcHBzIHdvdWxkIGNs b3NlIHRoZSBvdGhlciBzaWRlDQogd2hlbiB0aGV5IHJlY2VpdmUgdGhpcyBzaWduYWwgZnJvbSBR VUlDLiBJdCdzIHN1cmVseSBnb2luZyB0byBiZSB0cnVlIG9mIEhUVFAuIEl0J3MgcG9zc2libGUg Zm9yIGFuIGFwcCB0byByZWNlaXZlIGEgUlNUIGFuZCB0aGVuIGtlZXAgc2VuZGluZywgYnV0IHRo YXQgaXMgYSB1c2UgY2FzZSBJIGhhdmVuJ3Qgc2VlbiBpbiBwcmFjdGljZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_bca00829d58049fb8a644f3787011fcaustx2exdag1mb5msgcorpak_-- From nobody Tue Sep 12 21:56:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321041330C1 for ; Tue, 12 Sep 2017 21:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 iWyAyL9Q5i4k for ; Tue, 12 Sep 2017 21:56:53 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE86133056 for ; Tue, 12 Sep 2017 21:56:53 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1drzjG-0007XA-39 for quic@ietf.org; Wed, 13 Sep 2017 06:56:51 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1drzjA-0000jB-Jc for quic@ietf.org; Wed, 13 Sep 2017 00:56:48 -0400 Received: (qmail 2212 invoked from network); 13 Sep 2017 04:56:42 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.88]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Sep 2017 04:56:41 -0000 To: quic@ietf.org References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> From: Christian Huitema Message-ID: Date: Tue, 12 Sep 2017 21:56:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9250E5E40AEFE73DDE47E969" Content-Language: en-US Subject: Re: Split error codes in two X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYoNzrMVvavOgy+9M5kGys4ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA231hK1nmLJSW+JmxcpCur4OOoI9GlgXFbGvhvB 71hlmroXtoQEv6Uiwf+T5QEY0pcOYOEkjsX7F8KmpUaZQHV+ScWIfGf9Fu8q9UhMPe0GR5O2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKs+iZ7+uSas6Kaz0EAgJQDfPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEe6z703c9jXkpRbMJi6lpuxCpb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/P2bHd6v+zfW0Hi0zr4G/c3fOag26sJVU91vDlVZmVFHoHOPocIAQXCXdbljHVoU+TL v3Mz7HKrwpxO8UZg9F+1KW+fKrtTAxLYZqy5vzpWhrDjTzGHpE/PwPNFuykVFHR/oyTcdh5JdKk+ pVaIW+GYHZhD39vvlhL3cS0Zw/VNlKqK3hSPsI/yXHuKCW5mW6x7e6X9dJ86M2qPvneWrcSOpMRe 2A8DoXWdiHTPGMwPDlprjQPFk8m4tSTfORUp3ynKX9MPhkd8FwkdJfUs7sHA2/AsuSJe7JniZ6xP S+TFsgXf0EgYJLibecBlpmz3E0I= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 04:56:56 -0000 This is a multi-part message in MIME format. --------------9250E5E40AEFE73DDE47E969 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit There is another abstraction -- streams as messages. Application pushes a message that is the entire content of the stream, and receives a message once the entire stream has been received. That's the model used by DNS over QUIC. On 9/12/2017 9:23 PM, Lubashev, Igor wrote: > > This is a very good idea to decide what we want to model streams on.  > Starting with well-known, simple abstractions seems like the best path > to adoption. > >   > > There are two such abstractions that come to mind: > >   > > 1. “TCP Stream socketsâ€.  These only support signaling “orderly†> closing of the write direction.  Closing of the read direction can > only be done via close(), but that may leave the write direction > in an undefined state (writing will complete, unless there was > unread data in the read buffer or any data is received after close > – see RFC 1122 4.2.2.13 $3). > > I think the current spec allows for QUIC API to emulate TCP stream > socket abstraction.  Current spec  also adds signaling “abort†closing > of the write direction (RST_STREAM does not require an immediate > RST_STREAM in the opposite direction), although there was some talk of > removing this feature. > >   > > 2. “A POSIX pipe pairâ€, as Mike is proposing (one pair in each > direction).  Connected pipes are very clean (‘symmetric’) > abstractions, and they communicate close events (you close the > ‘write’ pipe, ‘read’ pipe get EOS; you close the ‘read’ pipe, > ‘write’ pipe gets an exception). > >   > > With read-direction close signaling, however, it is important to not > to cause often-unnecessary STOP_SENDING frames sent for every > common-case stream.close(). I think that could be done via one of the > following ways: > > 1. Unidirectional streams. Send STOP_SENDING on close() by the > receiver (if the steam is open). > 2. API convention: “only send STOP_SENDING on > stream.inputStream().close()â€. On stream.close(), only send > STOP_SENDING if there is unread data or new data comes in later. > 3. Actually signal that read direction is closed in stream.close() by > defining STREAM-with-FIN frame as “close both write and read > directions†(common case).  Have separate frame types for > WRITE_CLOSE, WRITE_ABORT (aka RST_STREAM), and READ_ABORT (aka > STOP_SENDING). > >   > >   > > *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com] > *Sent:* Tuesday, September 12, 2017 8:04 PM > *To:* Jana Iyengar ; Martin Thomson > > *Cc:* Philipp S. Tiesel ; Subodh Iyengar > ; Nick Harper ; QUIC WG > ; Victor Vasiliev > *Subject:* RE: Split error codes in two > >   > > Jana and I were discussing this today, and part of the difference > comes down to how you conceive of the API a QUIC implementation will > expose.  My mental model has been that a stream/stream-pair consists > of an InputStream and an OutputStream; you can read on one, you can > write on the other.  For the write stream, you can write your data to > completion and close the stream, or you can decide to abort writing.  > The wire expressions of these are FIN and RST_STREAM, respectively.  > For the read stream, you can read the incoming data to the end or you > can abort reading and discard the remainder of the stream; the wire > expression of this would be flow control updates and STOP_SENDING, > respectively.  On the other side, receipt of a RST_STREAM surfaces as > a read error and receipt of a STOP_SENDING surfaces as a write error.  > (Jana commented that in this mental model it might be clearer to call > the frames WRITE_ABORT and READ_ABORT.) > >   > > If we take Martin’s proposition that streams only close by application > action, there would never be a write error surfaced to the application > unless the underlying transport went away entirely.  Instead, it’s the > responsibility of the application protocol to communicate (on another > stream, in this case) that you should abort writing, even if you’ve > already written to completion, and then to do so.  That implies that > the application needs the ability to return to streams on which it’s > done writing, in case it’s later asked to go back and reset them. > >   > > Much of our discussions around unidirectional streams, stream state > transitions, etc. including the question of whether STOP_SENDING > belongs at the transport layer, stem from the fact that we all have > different implicit mental models of the functional surface QUIC > exposes.  Perhaps we should take a step back and agree on that first, > as I believe Christian has suggested in the past? > >   > > *From:* Jana Iyengar [mailto:jri@google.com] > *Sent:* Friday, September 8, 2017 5:34 PM > *To:* Martin Thomson > > *Cc:* Subodh Iyengar >; Mike > Bishop >; Philipp S. Tiesel > >; QUIC WG >; Nick Harper >; Victor Vasiliev > > *Subject:* Re: Split error codes in two > >   > > On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson > > wrote: > > On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar > wrote: > > I don't think it makes sense to design an app protocol that > doesn't send a > > RST in response to a RST. > > I've been told not to invoke this particular demon, but you just > invoked the Unidirectional streams problem.  I think that we get there > because of this meme that says that data in the one direction is > somehow necessarily bound to data in the other direction.  That's an > entirely constructed notion.  A useful construct at times, certainly, > but that's not the point here. > >   > > I think that's the most common use of a RST -- to close both directions.  > >   > > So I disagree.  There are many protocols in which you send messages > (== streams) in one direction but not another.  One of the ways you > get into a unidirectional state in the current draft is to end one > side.  A FIN is only one way to do that, a unidirectional RST can be > faster and even superior in other ways.  The HTTP use case clearly > illustrates that. > >   > > FIN is the primary way in which half-close is achieved, which is what > you're talking about. The HTTP use case is a complete one-off -- > STOP_SENDING is an odd enough use case that I'm always left wondering > who actually uses it. > >   > > Also, as Igor observes, we don't require a reciprocal RST_STREAM in > the current draft. > >   > > Yes, we don't. Recall that the RST_STREAM was, prior to the change > that doesn't require reciprocity, a bidirectional signal, which was > simplified to a unidirectional one, with the general expectation that > apps would close the other side when they receive this signal from > QUIC. It's surely going to be true of HTTP. It's possible for an app > to receive a RST and then keep sending, but that is a use case I > haven't seen in practice. > >   > -- Christian Huitema --------------9250E5E40AEFE73DDE47E969 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

There is another abstraction -- streams as messages. Application pushes a message that is the entire content of the stream, and receives a message once the entire stream has been received. That's the model used by DNS over QUIC.


On 9/12/2017 9:23 PM, Lubashev, Igor wrote:

This is a very good idea to decide what we want to model streams on.  Starting with well-known, simple abstractions seems like the best path to adoption.

 

There are two such abstractions that come to mind:

 

  1. “TCP Stream socketsâ€.  These only support signaling “orderly†closing of the write direction.  Closing of the read direction can only be done via close(), but that may leave the write direction in an undefined state (writing will complete, unless there was unread data in the read buffer or any data is received after close – see RFC 1122 4.2.2.13 $3).

I think the current spec allows for QUIC API to emulate TCP stream socket abstraction.  Current spec  also adds signaling “abort†closing of the write direction (RST_STREAM does not require an immediate RST_STREAM in the opposite direction), although there was some talk of removing this feature.

 

  1. “A POSIX pipe pairâ€, as Mike is proposing (one pair in each direction).  Connected pipes are very clean (‘symmetric’) abstractions, and they communicate close events (you close the ‘write’ pipe, ‘read’ pipe get EOS; you close the ‘read’ pipe, ‘write’ pipe gets an exception).

 

With read-direction close signaling, however, it is important to not to cause often-unnecessary STOP_SENDING frames sent for every common-case stream.close(). I think that could be done via one of the following ways:

  1. Unidirectional streams. Send STOP_SENDING on close() by the receiver (if the steam is open).
  2. API convention: “only send STOP_SENDING on stream.inputStream().close()â€. On stream.close(), only send STOP_SENDING if there is unread data or new data comes in later.
  3. Actually signal that read direction is closed in stream.close() by defining STREAM-with-FIN frame as “close both write and read directions†(common case).  Have separate frame types for WRITE_CLOSE, WRITE_ABORT (aka RST_STREAM), and READ_ABORT (aka STOP_SENDING).

 

 

From: Mike Bishop [mailto:Michael.Bishop@microsoft.com]
Sent: Tuesday, September 12, 2017 8:04 PM
To: Jana Iyengar <jri@google.com>; Martin Thomson <martin.thomson@gmail.com>
Cc: Philipp S. Tiesel <phils@in-panik.de>; Subodh Iyengar <subodh@fb.com>; Nick Harper <nharper@google.com>; QUIC WG <quic@ietf.org>; Victor Vasiliev <vasilvv@google.com>
Subject: RE: Split error codes in two

 

Jana and I were discussing this today, and part of the difference comes down to how you conceive of the API a QUIC implementation will expose.  My mental model has been that a stream/stream-pair consists of an InputStream and an OutputStream; you can read on one, you can write on the other.  For the write stream, you can write your data to completion and close the stream, or you can decide to abort writing.  The wire expressions of these are FIN and RST_STREAM, respectively.  For the read stream, you can read the incoming data to the end or you can abort reading and discard the remainder of the stream; the wire expression of this would be flow control updates and STOP_SENDING, respectively.  On the other side, receipt of a RST_STREAM surfaces as a read error and receipt of a STOP_SENDING surfaces as a write error.  (Jana commented that in this mental model it might be clearer to call the frames WRITE_ABORT and READ_ABORT.)

 

If we take Martin’s proposition that streams only close by application action, there would never be a write error surfaced to the application unless the underlying transport went away entirely.  Instead, it’s the responsibility of the application protocol to communicate (on another stream, in this case) that you should abort writing, even if you’ve already written to completion, and then to do so.  That implies that the application needs the ability to return to streams on which it’s done writing, in case it’s later asked to go back and reset them.

 

Much of our discussions around unidirectional streams, stream state transitions, etc. including the question of whether STOP_SENDING belongs at the transport layer, stem from the fact that we all have different implicit mental models of the functional surface QUIC exposes.  Perhaps we should take a step back and agree on that first, as I believe Christian has suggested in the past?

 

From: Jana Iyengar [mailto:jri@google.com]
Sent: Friday, September 8, 2017 5:34 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Subodh Iyengar <subodh@fb.com>; Mike Bishop <Michael.Bishop@microsoft.com>; Philipp S. Tiesel <phils@in-panik.de>; QUIC WG <quic@ietf.org>; Nick Harper <nharper@google.com>; Victor Vasiliev <vasilvv@google.com>
Subject: Re: Split error codes in two

 

On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar <jri@google.com> wrote:
> I don't think it makes sense to design an app protocol that doesn't send a
> RST in response to a RST.

I've been told not to invoke this particular demon, but you just
invoked the Unidirectional streams problem.  I think that we get there
because of this meme that says that data in the one direction is
somehow necessarily bound to data in the other direction.  That's an
entirely constructed notion.  A useful construct at times, certainly,
but that's not the point here.

 

I think that's the most common use of a RST -- to close both directions. 

 

So I disagree.  There are many protocols in which you send messages
(== streams) in one direction but not another.  One of the ways you
get into a unidirectional state in the current draft is to end one
side.  A FIN is only one way to do that, a unidirectional RST can be
faster and even superior in other ways.  The HTTP use case clearly
illustrates that.

 

FIN is the primary way in which half-close is achieved, which is what you're talking about. The HTTP use case is a complete one-off -- STOP_SENDING is an odd enough use case that I'm always left wondering who actually uses it.

 

Also, as Igor observes, we don't require a reciprocal RST_STREAM in
the current draft.

 

Yes, we don't. Recall that the RST_STREAM was, prior to the change that doesn't require reciprocity, a bidirectional signal, which was simplified to a unidirectional one, with the general expectation that apps would close the other side when they receive this signal from QUIC. It's surely going to be true of HTTP. It's possible for an app to receive a RST and then keep sending, but that is a use case I haven't seen in practice.

 


-- 
Christian Huitema
--------------9250E5E40AEFE73DDE47E969-- From nobody Tue Sep 12 22:27:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8EB1330BF for ; Tue, 12 Sep 2017 22:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 FncERrj82TDh for ; Tue, 12 Sep 2017 22:27:36 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5721330D2 for ; Tue, 12 Sep 2017 22:27:36 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by m0122331.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8D5R0bn012030; Wed, 13 Sep 2017 06:27:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=+fhrgees5EbIQL3bogvdHWFSOQU7cYnz4wqGm0/81ks=; b=E2+6MgfR0wVhXqIANxnrp31hIzbrrNYetZFhwW/K7ax3HqSfHkaUWoy8RBuIJ2pSVVxT QbrUzgFVkDdX7Rtb8/Zw62Yo90qg/F6zsvZsvF8YrxardnnfsbDqlG9dz6W9SMy1jZLa N/r8uZxa7NER/3LlbK+pTPk79Q6UqZ40NmR3uaMTvhmiaVAB8talXQNWfgux/YqWPeIo /h8tg0Pgd/uUAbWBkDn4prTwsp+JPUkqBy30mK/4YUhRNQq7syHWUFTjRK3qBLO355TY qrtCDqvyVX06CbrnHO2SbfNuY4CE0LZJxQrobzRJDZcgqqHqePNaB1808HWOm2CQzMtX lA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2cxex8mcu2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 06:27:28 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8D5PpUC019161; Wed, 13 Sep 2017 01:27:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2cwwtxbbac-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 01:27:27 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 00:27:19 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Wed, 13 Sep 2017 00:27:19 -0500 From: "Lubashev, Igor" To: "quic@ietf.org" , "huitema@huitema.net" Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9U7CZmvfU3U+AKlwSnR9wwKKmV3WAgAASqICAAAONAIAA0yCAgAAOnACAAAMMAIAAAK4AgACXxwCAAJELAIABpR2AgABJmoCAAAS/AIAANHEAgAFsKYCABkENAP//wQ6QgACQnID//7TCBw== Date: Wed, 13 Sep 2017 05:27:19 +0000 Message-ID: <5fdf8fb2f4ad4b2eb2285a227c1e5b8d@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_5fdf8fb2f4ad4b2eb2285a227c1e5b8dustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130084 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130084 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 05:27:40 -0000 --_000_5fdf8fb2f4ad4b2eb2285a227c1e5b8dustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This can be accomplished in either "tcp socket" or "pipe pairs" model, give= n a sufficiently large buffer and an ability of the API to poll on "EOS rec= eived" before consuming all buffered bytes (not normally a part of traditio= nal APIs). -----Original Message----- From: Christian Huitema [huitema@huitema.net] Received: Wednesday, 13 Sep 2017, 12:57AM To: quic@ietf.org [quic@ietf.org] Subject: Re: Split error codes in two There is another abstraction -- streams as messages. Application pushes a m= essage that is the entire content of the stream, and receives a message onc= e the entire stream has been received. That's the model used by DNS over QU= IC. On 9/12/2017 9:23 PM, Lubashev, Igor wrote: This is a very good idea to decide what we want to model streams on. Start= ing with well-known, simple abstractions seems like the best path to adopti= on. There are two such abstractions that come to mind: 1. =93TCP Stream sockets=94. These only support signaling =93orderly=94= closing of the write direction. Closing of the read direction can only be= done via close(), but that may leave the write direction in an undefined s= tate (writing will complete, unless there was unread data in the read buffe= r or any data is received after close =96 see RFC 1122 4.2.2.13 $3). I think the current spec allows for QUIC API to emulate TCP stream socket a= bstraction. Current spec also adds signaling =93abort=94 closing of the w= rite direction (RST_STREAM does not require an immediate RST_STREAM in the = opposite direction), although there was some talk of removing this feature. 1. =93A POSIX pipe pair=94, as Mike is proposing (one pair in each direc= tion). Connected pipes are very clean (=91symmetric=92) abstractions, and = they communicate close events (you close the =91write=92 pipe, =91read=92 p= ipe get EOS; you close the =91read=92 pipe, =91write=92 pipe gets an except= ion). With read-direction close signaling, however, it is important to not to cau= se often-unnecessary STOP_SENDING frames sent for every common-case stream.= close(). I think that could be done via one of the following ways: 1. Unidirectional streams. Send STOP_SENDING on close() by the receiver = (if the steam is open). 2. API convention: =93only send STOP_SENDING on stream.inputStream().clo= se()=94. On stream.close(), only send STOP_SENDING if there is unread data = or new data comes in later. 3. Actually signal that read direction is closed in stream.close() by de= fining STREAM-with-FIN frame as =93close both write and read directions=94 = (common case). Have separate frame types for WRITE_CLOSE, WRITE_ABORT (aka= RST_STREAM), and READ_ABORT (aka STOP_SENDING). From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] Sent: Tuesday, September 12, 2017 8:04 PM To: Jana Iyengar ; Martin Thomson Cc: Philipp S. Tiesel ; Subodh= Iyengar ; Nick Harper ; QUIC WG ; Victor Vasiliev Subject: RE: Split error codes in two Jana and I were discussing this today, and part of the difference comes dow= n to how you conceive of the API a QUIC implementation will expose. My men= tal model has been that a stream/stream-pair consists of an InputStream and= an OutputStream; you can read on one, you can write on the other. For the= write stream, you can write your data to completion and close the stream, = or you can decide to abort writing. The wire expressions of these are FIN = and RST_STREAM, respectively. For the read stream, you can read the incomi= ng data to the end or you can abort reading and discard the remainder of th= e stream; the wire expression of this would be flow control updates and STO= P_SENDING, respectively. On the other side, receipt of a RST_STREAM surfac= es as a read error and receipt of a STOP_SENDING surfaces as a write error.= (Jana commented that in this mental model it might be clearer to call the= frames WRITE_ABORT and READ_ABORT.) If we take Martin=92s proposition that streams only close by application ac= tion, there would never be a write error surfaced to the application unless= the underlying transport went away entirely. Instead, it=92s the responsi= bility of the application protocol to communicate (on another stream, in th= is case) that you should abort writing, even if you=92ve already written to= completion, and then to do so. That implies that the application needs th= e ability to return to streams on which it=92s done writing, in case it=92s= later asked to go back and reset them. Much of our discussions around unidirectional streams, stream state transit= ions, etc. including the question of whether STOP_SENDING belongs at the tr= ansport layer, stem from the fact that we all have different implicit menta= l models of the functional surface QUIC exposes. Perhaps we should take a = step back and agree on that first, as I believe Christian has suggested in = the past? From: Jana Iyengar [mailto:jri@google.com] Sent: Friday, September 8, 2017 5:34 PM To: Martin Thomson > Cc: Subodh Iyengar >; Mike Bishop >; Philipp S. = Tiesel >; QUIC WG >; Nick Harper >; Victor Vasiliev > Subject: Re: Split error codes in two On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson > wrote: On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar > wrote: > I don't think it makes sense to design an app protocol that doesn't send = a > RST in response to a RST. I've been told not to invoke this particular demon, but you just invoked the Unidirectional streams problem. I think that we get there because of this meme that says that data in the one direction is somehow necessarily bound to data in the other direction. That's an entirely constructed notion. A useful construct at times, certainly, but that's not the point here. I think that's the most common use of a RST -- to close both directions. So I disagree. There are many protocols in which you send messages (=3D=3D streams) in one direction but not another. One of the ways you get into a unidirectional state in the current draft is to end one side. A FIN is only one way to do that, a unidirectional RST can be faster and even superior in other ways. The HTTP use case clearly illustrates that. FIN is the primary way in which half-close is achieved, which is what you'r= e talking about. The HTTP use case is a complete one-off -- STOP_SENDING is= an odd enough use case that I'm always left wondering who actually uses it= . Also, as Igor observes, we don't require a reciprocal RST_STREAM in the current draft. Yes, we don't. Recall that the RST_STREAM was, prior to the change that doe= sn't require reciprocity, a bidirectional signal, which was simplified to a= unidirectional one, with the general expectation that apps would close the= other side when they receive this signal from QUIC. It's surely going to b= e true of HTTP. It's possible for an app to receive a RST and then keep sen= ding, but that is a use case I haven't seen in practice. -- Christian Huitema --_000_5fdf8fb2f4ad4b2eb2285a227c1e5b8dustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This can be accomplished in either "tcp socket" = or "pipe pairs" model, given a sufficiently large buffer and an a= bility of the API to poll on "EOS received" before consuming all buffered bytes (not normally a part of traditional APIs).

-----Original Message-----
From: Christian Huitema [huitema@huitema.net]
Received: Wednesday, 13 Sep 2017, 12:57AM
To: quic@ietf.org [quic@ietf.org]
Subject: Re: Split error codes in two

There is another abstraction -- streams as messages. Application pushes = a message that is the entire content of the stream, and receives a message = once the entire stream has been received. That's the model used by DNS over= QUIC.


On 9/12/2017 9:23 PM, Lubashev, Igor wrote:<= br>

This is a very good idea to decide what we want to m= odel streams on.  Starting with well-known, simple abstractions seems = like the best path to adoption.

 

There are two such abstractions that come to mind:

 

  1. =93TCP Stream sock= ets=94.  These only support signaling =93orderly=94 closing of the wri= te direction.  Closing of the read direction can only be done via clos= e(), but that may leave the write direction in an undefined state (writing will complete, unless there was unread data in the read buf= fer or any data is received after close =96 see RFC 1122 4.2.2.13 $3).

I think the current spec allows for QUIC API = to emulate TCP stream socket abstraction.  Current spec  also add= s signaling =93abort=94 closing of the write direction (RST_STREAM does not= require an immediate RST_STREAM in the opposite direction), although there was some talk of removing this feature.

 

  1. =93A POSIX pipe pa= ir=94, as Mike is proposing (one pair in each direction).  Connected p= ipes are very clean (=91symmetric=92) abstractions, and they communicate cl= ose events (you close the =91write=92 pipe, =91read=92 pipe get EOS; you close the =91read=92 pipe, =91write=92 pipe gets an exception= ).

 

With read-direction close signaling, however,= it is important to not to cause often-unnecessary STOP_SENDING frames sent= for every common-case stream.close(). I think that could be done via one o= f the following ways:

  1. Unidirectional s= treams. Send STOP_SENDING on close() by the receiver (if the steam is open)= .
  2. API convent= ion: =93only send STOP_SENDING on stream.inputStream().close()=94. On strea= m.close(), only send STOP_SENDING if there is unread data or new data comes= in later.
  3. Actually si= gnal that read direction is closed in stream.close() by defining STREAM-wit= h-FIN frame as =93close both write and read directions=94 (common case).&nb= sp; Have separate frame types for WRITE_CLOSE, WRITE_ABORT (aka RST_STREAM), and READ_ABORT (aka STOP_SENDING).

 

 

From: Mike Bishop [mailto:Michael.Bishop= @microsoft.com]
Sent: Tuesday, September 12, 2017 8:04 PM
To: Jana Iyengar <jri@google.com>; Martin Thomson <martin.thomson@gmail.com>
Cc: Philipp S. Tiesel <phils@in-panik.de>; Subodh Iyengar <subodh@fb.com>; Nick Harper <nharper@google.com>; QUIC WG <quic@ietf.org>; Victor Vasiliev <vasilvv@google.com>
Subject: RE: Split error codes in two

 

Jana and I were discussing this today, and part of t= he difference comes down to how you conceive of the API a QUIC implementati= on will expose.  My mental model has been that a stream/stream-pair co= nsists of an InputStream and an OutputStream; you can read on one, you can write on the other.  For the write strea= m, you can write your data to completion and close the stream, or you can d= ecide to abort writing.  The wire expressions of these are FIN and RST= _STREAM, respectively.  For the read stream, you can read the incoming data to the end or you can abort reading and dis= card the remainder of the stream; the wire expression of this would be flow= control updates and STOP_SENDING, respectively.  On the other side, r= eceipt of a RST_STREAM surfaces as a read error and receipt of a STOP_SENDING surfaces as a write error.  = (Jana commented that in this mental model it might be clearer to call the f= rames WRITE_ABORT and READ_ABORT.)

 

If we take Martin=92s proposition that streams only = close by application action, there would never be a write error surfaced to= the application unless the underlying transport went away entirely.  = Instead, it=92s the responsibility of the application protocol to communicate (on another stream, in this case) that you should = abort writing, even if you=92ve already written to completion, and then to = do so.  That implies that the application needs the ability to return = to streams on which it=92s done writing, in case it=92s later asked to go back and reset them.

 

Much of our discussions around unidirectional stream= s, stream state transitions, etc. including the question of whether STOP_SE= NDING belongs at the transport layer, stem from the fact that we all have d= ifferent implicit mental models of the functional surface QUIC exposes.  Perhaps we should take a step b= ack and agree on that first, as I believe Christian has suggested in the pa= st?

 

From: Jana Iyengar [mailto:jri@google.com]
Sent: Friday, September 8, 2017 5:34 PM
To: Martin Thomson <m= artin.thomson@gmail.com>
Cc: Subodh Iyengar <subodh@fb.co= m>; Mike Bishop <= Michael.Bishop@microsoft.com>; Philipp S. Tiesel <phils@in-panik.de>; QUIC WG <quic@ietf.org>; Nick Harper &l= t;nharper@google.com>; Victor = Vasiliev <vasilvv@google.com&g= t;
Subject: Re: Split error codes in two

 

On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar <jri@google.com> wrote:
> I don't think it makes sense to design an app protocol that doesn't se= nd a
> RST in response to a RST.

I've been told not to invoke this particular demon, but you just
invoked the Unidirectional streams problem.  I think that we get there=
because of this meme that says that data in the one direction is
somehow necessarily bound to data in the other direction.  That's an entirely constructed notion.  A useful construct at times, certainly,<= br> but that's not the point here.

 

I think that's the most common use of a RST -- to cl= ose both directions. 

 

So I disagree.  There are many protocols in whi= ch you send messages
(=3D=3D streams) in one direction but not another.  One of the ways yo= u
get into a unidirectional state in the current draft is to end one
side.  A FIN is only one way to do that, a unidirectional RST can be faster and even superior in other ways.  The HTTP use case clearly
illustrates that.

 

FIN is the primary way in which half-close is achiev= ed, which is what you're talking about. The HTTP use case is a complete one= -off -- STOP_SENDING is an odd enough use case that I'm always left wonderi= ng who actually uses it.

 

Also, as Igor observes, we don't require a reciproca= l RST_STREAM in
the current draft.

 

Yes, we don't. Recall that the RST_STREAM was, prior= to the change that doesn't require reciprocity, a bidirectional signal, wh= ich was simplified to a unidirectional one, with the general expectation th= at apps would close the other side when they receive this signal from QUIC. It's surely going to be true of H= TTP. It's possible for an app to receive a RST and then keep sending, but t= hat is a use case I haven't seen in practice.

 


--=20
Christian Huitema
--_000_5fdf8fb2f4ad4b2eb2285a227c1e5b8dustx2exdag1mb5msgcorpak_-- From nobody Wed Sep 13 06:26:19 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D76133030 for ; Wed, 13 Sep 2017 06:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uKjaiUDo6PwS for ; Wed, 13 Sep 2017 06:26:17 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5197A13303A for ; Wed, 13 Sep 2017 06:26:17 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id v19so2231040ite.0 for ; Wed, 13 Sep 2017 06:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=c6Vb7JCH1cUyyNJl2HkvQCaBcyZ4ovqkij37JVD5Luo=; b=DOwBDLA7WlF3iiNfIBDzENKDZz7vGRHnySmr3bbmDSJwpYIDWEv+Z1g3dcUKFQBAL+ 9ePjRQfk2EI9H4zCFfdLH3Gtqk4ADERCFGoHiGXZJDGGVTLpvkagrBDISXS5/m32JpVf m5RaEJZC12V4pTwt4GL1wWNNEHim6Qeb5h5w+ppm1bx1UgMM/7aT0gcmQ1SVK5WlPkNf Jtd4Gj1BDCGurYqcMRTSrzwNLIPqcLPc4n+DDcS4peYlWapBlO/F4ZmaYR5U7LP2Wmks IcNUL8DfvjIQO3KjmhFdpK/uhA0jrAlLi9536J+gw1vEOjLx/dRvaN1iwbjjn8Uu16bn PncA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=c6Vb7JCH1cUyyNJl2HkvQCaBcyZ4ovqkij37JVD5Luo=; b=Qo3DXktBgM0deokOwuq9wiLixuPWY4OTXtwbz0+FPL2jsQBaJA114eqxtLjnugEWiM GQVO52Axnb4G07MuvNBQuoS08/33pzBtbZKmbOh/eY7UigvUi/UrWD+AX9Cfq5kyEtJC v+N+pkOriiNdOrBMMVLXDP/KgraqY1HFS0ZH6Nn+oPUKRnWYOxd2abgs6Z1TxGeVdoiM hmQbzodPB+Lx5uCNREa1eGw9OJNBkoguFrrw9JQH9TuY5veyk4LPJ8zB2bC49dw0GaXf /e5ec1GvHDQdOcjwOokOH19XdRFNCU/f586+/rJDFrfnHyeLhDcy6plMe+vFG179C7eZ dwqg== X-Gm-Message-State: AHPjjUg3bNIPnvD8Armw3Xq8UbFDd57DzlnzuJayU4b41FDZoZ+5jTOd WE+nG3ybCaFuzZTXqDlsqEwiPGcn/8u3XDLma+s= X-Google-Smtp-Source: AOwi7QClEKQpnvHTxvxiZPBCUX3iaXe3ul4c9xXR1zSDBbveu7n2Ch2vNSASfy+vcwUzXxUek+CXi+vnRppIb56fJ90= X-Received: by 10.36.86.18 with SMTP id o18mr3769287itb.32.1505309176439; Wed, 13 Sep 2017 06:26:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.148 with HTTP; Wed, 13 Sep 2017 06:26:16 -0700 (PDT) From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Wed, 13 Sep 2017 16:26:16 +0300 Message-ID: Subject: Error reporting on handshake To: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 13:26:18 -0000 Hi, how should QUIC server respond while performing TLS handshake and there is a server internal error - too many parallel authentications, no memory or other? Should it respond with ConnectionClose Frame encapsulated into LongHeader-ServerCleartext or some other? Thank you --=20 Ar cie=C5=86u, J=C4=81nis =C4=8Coders From nobody Wed Sep 13 06:42:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A60133036 for ; Wed, 13 Sep 2017 06:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 736fD-MjUUDO for ; Wed, 13 Sep 2017 06:42:33 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CCA132F31 for ; Wed, 13 Sep 2017 06:42:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3xsjX813sVzMpPR; Wed, 13 Sep 2017 15:42:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T06dkhCV3Tr9; Wed, 13 Sep 2017 15:42:30 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 13 Sep 2017 15:42:30 +0200 (CEST) Subject: Re: obsrvtaion on packet numbers To: Martin Thomson , Roni Even Cc: QUIC WG References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <5ba17907-1be7-da2d-1e2f-ae62254f2b40@tik.ee.ethz.ch> Date: Wed, 13 Sep 2017 15:42:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 13:42:36 -0000 Hi Martin, hi all, two quick comments below. On 06.09.2017 12:20, Martin Thomson wrote: > Hi Roni, > > The text about the sender clearly needs to be qualified. s/the > sender/a server/ in this case (I've made that change already). > > Let's just examine what this entails. 2^64 packets is an awful lot of > packets, even accounting for the randomized start and frequent new > connection IDs[1]. So many that we might not need to worry about this > happening for a while (that's 0.5 trillion packets per second for a > solid year if I'm reading the number correctly or 4 Pbps, that's the > one with 15 zeros). > > So it's not obvious that special attention is needed here other than > what is written (i.e., stop sending packets). We could advise the use > of CONNECTION_CLOSE, but then we have to say something about when to > send it. A graceful shutdown is even better, but that's even more > amorphous and difficult to provide concrete advice about. Better to > leave this corner unpainted in my opinion. > > What's more, it's clear that both sides know what is going on. Once > this magic value is hit, then no more packets will be sent and both > peers know it. No real need for any signaling. I'm uncertain if we need to say more but I don't think having the discussion how likely or unlikely this case is over and over again helps (also people seems to have fun going through the numbers). However, even if the case is unlikely, it needs to be fully specified. > > Note that this isn't a connection migration scenario. Any new > connection would - at best - be able to retain cryptographic keys. > Stream state would have to be lost. But it could. If there is a way to say in a new connection that you would like to resume state if the other end still has the full state (including stream and retransmission state) for this other connection, than that's probably also all you need for making multipath work :-) Mirja > > [1] On average new connection IDs would also get us here quicker > maybe, though it would still take 272 per second for the same year. > > On Wed, Sep 6, 2017 at 6:10 PM, Roni Even wrote: >> Hi, >> >> I have some observations on the new text on packet numbers >> >> >> >> “A QUIC endpoint MUST NOT reuse a packet number within the same connection >> (that is, under the same cryptographic keys). If the packet number for >> sending reaches 2^64 - 1, the sender MUST close the connection without >> sending a CONNECTION_CLOSE frame or any further packets; the sender MAY send >> a Stateless Reset packet in response to further packets that it receives.†>> >> >> >> I post them here and not in github since I am not sure where to discuss it. >> >> >> >> 1. “the sender MAY send a Stateless Reset†– I believe that only a >> sender which is a server can do it. >> >> 2. “If the packet number for sending reaches 2^64 - 1,…†Here I am >> confused. I understand that since wrap around is not allowed than the sender >> cannot send a CONNECTION_CLOSE or use the Immediate Close termination >> procedure. I am not sure about application close termination procedure since >> I assume it will also require some QUIC messages to close connection. On >> the other hand the sender may wish to continue sending using a new >> connection, so is this a connection migration ? I assume that the state of >> the open streams should be kept. I think that some text is missing here and >> for the connection migration procedure. >> >> >> >> Roni Even >> >> > From nobody Wed Sep 13 06:56:26 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC7813232C for ; Wed, 13 Sep 2017 06:56:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com 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 drHalxAI-20w for ; Wed, 13 Sep 2017 06:56:23 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6502F13208E for ; Wed, 13 Sep 2017 06:56:23 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id q8so729205qtb.5 for ; Wed, 13 Sep 2017 06:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=XXjiiANT9J5X7K6Uz/EDIfpn8/ZcT/nEg1PuI5viJ9w=; b=nomlW1zRdD55WU1xcPL0nChjgYhtzlueD9RNMOomVvVnNYLuNTbDaa/knGL8x4WFkW N/qy/ZM9gCAKXXD+sgnlq2xUxJgy3gAx3e5I1cMXqIGGIel1I1SvS5uTNyKitsME9VD/ jQ4DNyylb1TJx8M56y82Vq4m9yizBWSbtvsNq0u62wvPMED0GZC44PAuFvLuwg/PCGgv 0Mu/8mqeb0ZRTamg0ioJqyXWjVcL3tmp+yRhddYgoqbqNK0KF12ErJSiuvjuPbBhOCCB K/LVTMlHpaG1SSL+5FiElJNCXwbjo4AoG+ojLFthn/UCPPD+4iElUtA19N111QaeJII0 xelQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=XXjiiANT9J5X7K6Uz/EDIfpn8/ZcT/nEg1PuI5viJ9w=; b=KULI4ZqLwxQteb1sdo8nk1CgdLOjfInzMbRxqATZ6OdJMTePbER43+g2hUPsKLtWQF yrMUSBGvA/Tm9z1AWLPMzHI5wWfsbx9xwz1jaEzarXGQUZUeaiPSfnQjtz/5TXxYbWIC MdIn5JRkz958efIfpZUc9zP3u6Oq9haQTXglSU4PQOHNhoOJGt+hZX6fhSl6dK6kfctr Z9n6mAxoVBd7WdxXSQDhG8qAlXTFNGH4o8asqZkSUzIG7Uih8Fd55PN+RpA1G2kUZsb+ HXLShcuRf+QG95JlSXIV18SVNtyn4oYLXL8C/DJqAhHBYbVhzr9bhrQel1Xm3Zls4fp0 gs8A== X-Gm-Message-State: AHPjjUhHNbeyd6NKlRwRCDo28CSOFVi+rt+2dCWnLE5nd2mdssNELSFa 4F0wNUEJ4QDZWbDb X-Google-Smtp-Source: AOwi7QD0fOxQNUsaaZCOvgGcwOAM5UJATpEMR4cSB1KlXTnMCjRhvsYldyuN8caUKEHaD2e0VXqvrQ== X-Received: by 10.200.17.136 with SMTP id d8mr24956985qtj.26.1505310982575; Wed, 13 Sep 2017 06:56:22 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id x189sm9185060qkd.70.2017.09.13.06.56.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 06:56:22 -0700 (PDT) Date: Wed, 13 Sep 2017 09:56:15 -0400 From: Dmitri Tikhonov To: Mirja =?iso-8859-1?Q?K=FChlewind?= Cc: Martin Thomson , Roni Even , QUIC WG Subject: Re: obsrvtaion on packet numbers Message-ID: <20170913135614.GB3857@ubuntu-dmitri> References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <5ba17907-1be7-da2d-1e2f-ae62254f2b40@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5ba17907-1be7-da2d-1e2f-ae62254f2b40@tik.ee.ethz.ch> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 13:56:25 -0000 On Wed, Sep 13, 2017 at 03:42:30PM +0200, Mirja Kühlewind wrote: > I'm uncertain if we need to say more but I don't think having the discussion > how likely or unlikely this case is over and over again helps (also people > seems to have fun going through the numbers). However, even if the case is > unlikely, it needs to be fully specified. I agree. Furthermore, I think that the rationale behind some of the decisions needs to be explained, preferably in the draft. I posed these questions in a previous thread [1], but since they went unanswered, I feel justified restating them here: 1. Why are there packet number and byte offset limits? In other words, why are there limits on the duration of a connection? 2. How are particular limits chosen? - Dmitri. 1. https://www.ietf.org/mail-archive/web/quic/current/msg02144.html From nobody Wed Sep 13 07:40:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A941321C7 for ; Wed, 13 Sep 2017 07:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 GGbHpd9iCe3r for ; Wed, 13 Sep 2017 07:40:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B25124239 for ; Wed, 13 Sep 2017 07:40:31 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by m0122330.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8DEWlfG020786; Wed, 13 Sep 2017 15:40:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=6aaRSP8r1or5DV2XO8GhG4AhLKAXBRwUFLh7A8HkNWY=; b=OpL+aksIErz5mCVX404UzzZfmysp1YJ0+/zPn9AERsV+rGR7HlA1ZYLz+S1QAHPuKnES FJSfyeVAYxnaGvztFxW/YtF0yqjAFxvIrAXoc4Jl0puTmPLlkCwawGT2N7Jb7vpO3Ttd +ooKJLcnkHgGpDUsnmbqgAOktLs3oZoSZU6dtE5CR6AwtzHeMNu84EpzKC1SLqh+8sff rMTqTDGnBB/8Bz/Uq3fKNfUYqPe+TzBmbf/pK+08Fx1QVAwRmbCCFNT4ma8Razkw6U+f /ZYXagP92Um6Qidr4ovGgkWxjpXRXo72dD/rMwDXtQr9PcSxCPm7fUbPtXKNvL2x6ccA NA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2cx7rfrat9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 15:40:20 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8DEUeR9016170; Wed, 13 Sep 2017 10:40:19 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cwwqk8333-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 10:40:19 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 07:40:17 -0700 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Wed, 13 Sep 2017 09:40:17 -0500 From: "Lubashev, Igor" To: "Lubashev, Igor" , "quic@ietf.org" , "huitema@huitema.net" Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9U7CZmvfU3U+AKlwSnR9wwKKmV3WAgAASqICAAAONAIAA0yCAgAAOnACAAAMMAIAAAK4AgACXxwCAAJELAIABpR2AgABJmoCAAAS/AIAANHEAgAFsKYCABkENAP//wQ6QgACQnID//7TCB4AAkG+w Date: Wed, 13 Sep 2017 14:40:16 +0000 Message-ID: <7627246bc06b402c9352238d8a3c0c4a@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> , <5fdf8fb2f4ad4b2eb2285a227c1e5b8d@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <5fdf8fb2f4ad4b2eb2285a227c1e5b8d@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.249] Content-Type: multipart/alternative; boundary="_000_7627246bc06b402c9352238d8a3c0c4austx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130228 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130228 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:40:35 -0000 --_000_7627246bc06b402c9352238d8a3c0c4austx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thinking about this a bit more, it seems that the key difference between "t= cp socket" and "two pipe pairs" models is independence of the send and rece= ive directions. In "two pipe pairs", send and receive directions are completely independent= (they are just two unidirectional streams with some syntactic sugar that a= llows them to be opened and closed together, if needed). To be faithful to= this model, we'd need to support each direction getting closed independent= ly by either endpoint. For "tcp socket", the two directions are not independent, and streams in bo= th directions are reset if some data sent in either direction cannot be del= ivered (including when the receiver decided it does not want that data). T= o be faithful to this model, we'd need transport to send RST_STREAM in resp= onse to RST_STREAM automatically, not because it needs to reset the other d= irection (the other direction is already semantically reset) but just for f= low control accounting. And there is also no STOP_SENDING, as this is just= asking for a complete reset. I am not yet seeing what "middle ground" can be here, while maintaining a c= oherent model/philosophy behind the choices. From: Lubashev, Igor [mailto:ilubashe@akamai.com] Sent: Wednesday, September 13, 2017 1:27 AM To: quic@ietf.org; huitema@huitema.net Subject: RE: Split error codes in two This can be accomplished in either "tcp socket" or "pipe pairs" model, give= n a sufficiently large buffer and an ability of the API to poll on "EOS rec= eived" before consuming all buffered bytes (not normally a part of traditio= nal APIs). -----Original Message----- From: Christian Huitema [huitema@huitema.net] Received: Wednesday, 13 Sep 2017, 12:57AM To: quic@ietf.org [quic@ietf.org] Subject: Re: Split error codes in two There is another abstraction -- streams as messages. Application pushes a m= essage that is the entire content of the stream, and receives a message onc= e the entire stream has been received. That's the model used by DNS over QU= IC. On 9/12/2017 9:23 PM, Lubashev, Igor wrote: This is a very good idea to decide what we want to model streams on. Start= ing with well-known, simple abstractions seems like the best path to adopti= on. There are two such abstractions that come to mind: 1. "TCP Stream sockets". These only support signaling "orderly" closing= of the write direction. Closing of the read direction can only be done vi= a close(), but that may leave the write direction in an undefined state (wr= iting will complete, unless there was unread data in the read buffer or any= data is received after close - see RFC 1122 4.2.2.13 $3). I think the current spec allows for QUIC API to emulate TCP stream socket a= bstraction. Current spec also adds signaling "abort" closing of the write= direction (RST_STREAM does not require an immediate RST_STREAM in the oppo= site direction), although there was some talk of removing this feature. 1. "A POSIX pipe pair", as Mike is proposing (one pair in each direction= ). Connected pipes are very clean ('symmetric') abstractions, and they com= municate close events (you close the 'write' pipe, 'read' pipe get EOS; you= close the 'read' pipe, 'write' pipe gets an exception). With read-direction close signaling, however, it is important to not to cau= se often-unnecessary STOP_SENDING frames sent for every common-case stream.= close(). I think that could be done via one of the following ways: a. Unidirectional streams. Send STOP_SENDING on close() by the receiv= er (if the steam is open). b. API convention: "only send STOP_SENDING on stream.inputStream().cl= ose()". On stream.close(), only send STOP_SENDING if there is unread data o= r new data comes in later. c. Actually signal that read direction is closed in stream.close() by= defining STREAM-with-FIN frame as "close both write and read directions" (= common case). Have separate frame types for WRITE_CLOSE, WRITE_ABORT (aka = RST_STREAM), and READ_ABORT (aka STOP_SENDING). From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] Sent: Tuesday, September 12, 2017 8:04 PM To: Jana Iyengar ; Martin Thomson Cc: Philipp S. Tiesel ; Subodh= Iyengar ; Nick Harper ; QUIC WG ; Victor Vasiliev Subject: RE: Split error codes in two Jana and I were discussing this today, and part of the difference comes dow= n to how you conceive of the API a QUIC implementation will expose. My men= tal model has been that a stream/stream-pair consists of an InputStream and= an OutputStream; you can read on one, you can write on the other. For the= write stream, you can write your data to completion and close the stream, = or you can decide to abort writing. The wire expressions of these are FIN = and RST_STREAM, respectively. For the read stream, you can read the incomi= ng data to the end or you can abort reading and discard the remainder of th= e stream; the wire expression of this would be flow control updates and STO= P_SENDING, respectively. On the other side, receipt of a RST_STREAM surfac= es as a read error and receipt of a STOP_SENDING surfaces as a write error.= (Jana commented that in this mental model it might be clearer to call the= frames WRITE_ABORT and READ_ABORT.) If we take Martin's proposition that streams only close by application acti= on, there would never be a write error surfaced to the application unless t= he underlying transport went away entirely. Instead, it's the responsibili= ty of the application protocol to communicate (on another stream, in this c= ase) that you should abort writing, even if you've already written to compl= etion, and then to do so. That implies that the application needs the abil= ity to return to streams on which it's done writing, in case it's later ask= ed to go back and reset them. Much of our discussions around unidirectional streams, stream state transit= ions, etc. including the question of whether STOP_SENDING belongs at the tr= ansport layer, stem from the fact that we all have different implicit menta= l models of the functional surface QUIC exposes. Perhaps we should take a = step back and agree on that first, as I believe Christian has suggested in = the past? From: Jana Iyengar [mailto:jri@google.com] Sent: Friday, September 8, 2017 5:34 PM To: Martin Thomson > Cc: Subodh Iyengar >; Mike Bishop >; Philipp S. = Tiesel >; QUIC WG >; Nick Harper >; Victor Vasiliev > Subject: Re: Split error codes in two On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson > wrote: On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar > wrote: > I don't think it makes sense to design an app protocol that doesn't send = a > RST in response to a RST. I've been told not to invoke this particular demon, but you just invoked the Unidirectional streams problem. I think that we get there because of this meme that says that data in the one direction is somehow necessarily bound to data in the other direction. That's an entirely constructed notion. A useful construct at times, certainly, but that's not the point here. I think that's the most common use of a RST -- to close both directions. So I disagree. There are many protocols in which you send messages (=3D=3D streams) in one direction but not another. One of the ways you get into a unidirectional state in the current draft is to end one side. A FIN is only one way to do that, a unidirectional RST can be faster and even superior in other ways. The HTTP use case clearly illustrates that. FIN is the primary way in which half-close is achieved, which is what you'r= e talking about. The HTTP use case is a complete one-off -- STOP_SENDING is= an odd enough use case that I'm always left wondering who actually uses it= . Also, as Igor observes, we don't require a reciprocal RST_STREAM in the current draft. Yes, we don't. Recall that the RST_STREAM was, prior to the change that doe= sn't require reciprocity, a bidirectional signal, which was simplified to a= unidirectional one, with the general expectation that apps would close the= other side when they receive this signal from QUIC. It's surely going to b= e true of HTTP. It's possible for an app to receive a RST and then keep sen= ding, but that is a use case I haven't seen in practice. -- Christian Huitema --_000_7627246bc06b402c9352238d8a3c0c4austx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thinking about this a bit more, it seems that the ke= y difference between “tcp socket” and “two pipe pairsR= 21; models is independence of the send and receive directions.

 

In “two pipe pairs”, send and receive di= rections are completely independent (they are just two unidirectional strea= ms with some syntactic sugar that allows them to be opened and closed toget= her, if needed).  To be faithful to this model, we’d need to support each direction getting closed independently by = either endpoint.

 

For “tcp socket”, the two directions are= not independent, and streams in both directions are reset if some data sen= t in either direction cannot be delivered (including when the receiver deci= ded it does not want that data).  To be faithful to this model, we’d need transport to send RST_STREAM in response to= RST_STREAM automatically, not because it needs to reset the other directio= n (the other direction is already semantically reset) but just for flow con= trol accounting.  And there is also no STOP_SENDING, as this is just asking for a complete reset.

 

I am not yet seeing what “middle ground”= can be here, while maintaining a coherent model/philosophy behind the choi= ces.

 

From: Lubashev, Igor [mailto:ilubashe@akamai.= com]
Sent: Wednesday, September 13, 2017 1:27 AM
To: quic@ietf.org; huitema@huitema.net
Subject: RE: Split error codes in two

 

This can be accomplished in either "tcp socket" or "p= ipe pairs" model, given a sufficiently large buffer and an ability of = the API to poll on "EOS received" before consuming all buffered bytes (not normally a part of traditional APIs).

-----Original Message-----
From: Christian Huitema [huitema@huitema.net]
Received: Wednesday, 13 Sep 2017, 12:57AM
To: quic@ietf.org [quic@ietf.org]
Subject: Re: Split error codes in two

There is another abstraction -- streams as messages. Application pushes = a message that is the entire content of the stream, and receives a message = once the entire stream has been received. That's the model used by DNS over= QUIC.

 

On 9/12/2017 9:23 PM, Lubashev, Igor wrote:

This is a very good idea to decide what we want to m= odel streams on.  Starting with well-known, simple abstractions seems = like the best path to adoption.

 

There are two such abstractions that come to mind:

 

  1. “TCP Stream sockets”.  These only support signaling “= ;orderly” closing of the write direction.  Closing of the read d= irection can only be done via close(), but that may leave the write directi= on in an undefined state (writing will complete, unless there was unread data in the read buffer or any data is received after close –= see RFC 1122 4.2.2.13 $3).

I think the current spec allows for QUIC API = to emulate TCP stream socket abstraction.  Current spec  also add= s signaling “abort” closing of the write direction (RST_STREAM = does not require an immediate RST_STREAM in the opposite direction), although there was some talk of removing this feature.

 

  1. &= #8220;A POSIX pipe pair”, as Mike is proposing (one pair in each dire= ction).  Connected pipes are very clean (‘symmetric’) abst= ractions, and they communicate close events (you close the ‘writeR= 17; pipe, ‘read’ pipe get EOS; you close the ‘read’ pi= pe, ‘write’ pipe gets an exception).

 

With read-direction close signaling, however,= it is important to not to cause often-unnecessary STOP_SENDING frames sent= for every common-case stream.close(). I think that could be done via one o= f the following ways:

a.       Unidirectional streams. Send STOP_SENDING on close(= ) by the receiver (if the steam is open).

b.       API convention: “only send STOP_SENDING on st= ream.inputStream().close()”. On stream.close(), only send STOP_SENDIN= G if there is unread data or new data comes in later.

c.       Actually signal that read direction is closed in st= ream.close() by defining STREAM-with-FIN frame as “close both write a= nd read directions” (common case).  Have separate frame types fo= r WRITE_CLOSE, WRITE_ABORT (aka RST_STREAM), and READ_ABORT (aka STOP_SENDING).

 

 

From: Mike Bishop [mailto:Michael.Bishop@microsoft.com]
Sent: Tuesday, September 12, 2017 8:04 PM
To: Jana Iyengar <jri@google.co= m>; Martin Thomson <martin.thomson@gmail.com>= ;
Cc: Philipp S. Tiesel <phils= @in-panik.de>; Subodh Iyengar <subodh@fb.com>; Nick Harper <nharper@google.com>; QUIC WG &l= t;quic@ietf.org>; Victor Vasiliev <vasilvv@google.com>
Subject: RE: Split error codes in two

 

Jana and I were discussing this today, and part of t= he difference comes down to how you conceive of the API a QUIC implementati= on will expose.  My mental model has been that a stream/stream-pair co= nsists of an InputStream and an OutputStream; you can read on one, you can write on the other.  For the write strea= m, you can write your data to completion and close the stream, or you can d= ecide to abort writing.  The wire expressions of these are FIN and RST= _STREAM, respectively.  For the read stream, you can read the incoming data to the end or you can abort reading and dis= card the remainder of the stream; the wire expression of this would be flow= control updates and STOP_SENDING, respectively.  On the other side, r= eceipt of a RST_STREAM surfaces as a read error and receipt of a STOP_SENDING surfaces as a write error.  = (Jana commented that in this mental model it might be clearer to call the f= rames WRITE_ABORT and READ_ABORT.)

 

If we take Martin’s proposition that streams o= nly close by application action, there would never be a write error surface= d to the application unless the underlying transport went away entirely.&nb= sp; Instead, it’s the responsibility of the application protocol to communicate (on another stream, in this case) that you should = abort writing, even if you’ve already written to completion, and then= to do so.  That implies that the application needs the ability to ret= urn to streams on which it’s done writing, in case it’s later asked to go back and reset them.

 

Much of our discussions around unidirectional stream= s, stream state transitions, etc. including the question of whether STOP_SE= NDING belongs at the transport layer, stem from the fact that we all have d= ifferent implicit mental models of the functional surface QUIC exposes.  Perhaps we should take a step b= ack and agree on that first, as I believe Christian has suggested in the pa= st?

 

From: Jana Iyengar [mailto:jri@google.com]
Sent: Friday, September 8, 2017 5:34 PM
To: Martin Thomson <m= artin.thomson@gmail.com>
Cc: Subodh Iyengar <subodh@fb.co= m>; Mike Bishop <= Michael.Bishop@microsoft.com>; Philipp S. Tiesel <phils@in-panik.de>; QUIC WG <quic@ietf.org>; Nick Harper &l= t;nharper@google.com>; Victor = Vasiliev <vasilvv@google.com&g= t;
Subject: Re: Split error codes in two

 

On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar <jri@google.com> wrote:
> I don't think it makes sense to design an app protocol that doesn't se= nd a
> RST in response to a RST.

I've been told not to invoke this particular demon, but you just
invoked the Unidirectional streams problem.  I think that we get there=
because of this meme that says that data in the one direction is
somehow necessarily bound to data in the other direction.  That's an entirely constructed notion.  A useful construct at times, certainly,<= br> but that's not the point here.

 

I think that's the most common use of a RST -- to cl= ose both directions. 

 

So I disagree.  There are many protocols in whi= ch you send messages
(=3D=3D streams) in one direction but not another.  One of the ways yo= u
get into a unidirectional state in the current draft is to end one
side.  A FIN is only one way to do that, a unidirectional RST can be faster and even superior in other ways.  The HTTP use case clearly
illustrates that.

 

FIN is the primary way in which half-close is achiev= ed, which is what you're talking about. The HTTP use case is a complete one= -off -- STOP_SENDING is an odd enough use case that I'm always left wonderi= ng who actually uses it.

 

Also, as Igor observes, we don't require a reciproca= l RST_STREAM in
the current draft.

 

Yes, we don't. Recall that the RST_STREAM was, prior= to the change that doesn't require reciprocity, a bidirectional signal, wh= ich was simplified to a unidirectional one, with the general expectation th= at apps would close the other side when they receive this signal from QUIC. It's surely going to be true of H= TTP. It's possible for an app to receive a RST and then keep sending, but t= hat is a use case I haven't seen in practice.

 



-- 
Christian Huitema
--_000_7627246bc06b402c9352238d8a3c0c4austx2exdag1mb5msgcorpak_-- From nobody Wed Sep 13 12:04:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7EC132EDC for ; Wed, 13 Sep 2017 12:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=gw6ZaFi4; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Ly80tTCA 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 tqhF2QCuZwCa for ; Wed, 13 Sep 2017 12:04:45 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55105132EBB for ; Wed, 13 Sep 2017 12:04:45 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.21/8.16.0.21) with SMTP id v8DJ3MR9009515; Wed, 13 Sep 2017 12:04:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=dgMvk2Nay9HObjBN4AlHIn+kIdSlQpJkuhqLkClO3CQ=; b=gw6ZaFi4NxLiJnpKiL/F4lyyzp0llxryxOwV83KIcFc0QfcV2CJES0ueWxT3bHcgfLys wyWnAT+1RDwRvIud3TnzYdN51qrUQVnNLcF6dhcbi1hE0ULnhrp4GAVXpix2C17APRdL xQbS6nWRry5xP6jTCGLusmmGrJt9yi7rE3o= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2cy4p2hfrk-11 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Sep 2017 12:04:37 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.22) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 13 Sep 2017 12:03:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dgMvk2Nay9HObjBN4AlHIn+kIdSlQpJkuhqLkClO3CQ=; b=Ly80tTCAxwfrX4vw45+MM0D6sqFzNlQb5zXZWXq4BHJjdzSQQNpJhYOCDOv2G6ri76VobB8NrLHj4d9wq7IhZALYXHY8NjiE9eahj544yzZHWR0T1z/yugabnUmmPZ2i/RfVKUH8yEQrxpYxpg+PZvnFvVbXn/wQr7KQMxG2J8U= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1900.namprd15.prod.outlook.com (10.174.247.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Wed, 13 Sep 2017 19:03:34 +0000 Received: from DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) by DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) with mapi id 15.20.0035.021; Wed, 13 Sep 2017 19:03:34 +0000 From: Roberto Peon To: Christian Huitema , "quic@ietf.org" Subject: Re: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn+M1kPnAYJVE6/jyIPUxXdX6KmFGeAgAASp4CAAAOOAIAA0yCAgAAOnACAAAMMAIAAAK4AgACHAwCAAJELAIABpR2AgABJmoCAAAS/AIAANHEAgAFsKoCABkENAIAASG+AgAAJOoCAAHdJgA== Date: Wed, 13 Sep 2017 19:03:33 +0000 Message-ID: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:1b3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1900; 20:33e7cg0IsK/oyN080xc+HCiIDIfjey29ndNh+GMGYov2Mux4ZMpmRsMNk3wtSP7T8gCWnerLyJk++W2Ubcci7niFtsatordwljG7tJC2UjspsYpkSuua44VeBf19zXKq5wH8yBXpqMElteRMfM3vSntVSxrbm6aTYgRNjZqltCw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5aeed9fe-9688-486b-f156-08d4fada21a8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR15MB1900; x-ms-traffictypediagnostic: DM5PR15MB1900: x-exchange-antispam-report-test: UriScan:(89211679590171)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(920507026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1900; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1900; x-forefront-prvs: 042957ACD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(78114003)(51444003)(199003)(377454003)(189002)(24454002)(54356999)(50986999)(25786009)(2950100002)(76176999)(101416001)(105586002)(106356001)(236005)(99286003)(6306002)(6512007)(54896002)(53936002)(6246003)(82746002)(53546010)(36756003)(189998001)(3660700001)(6116002)(33656002)(102836003)(7736002)(86362001)(34040400001)(83716003)(3280700002)(8936002)(93886005)(8676002)(2906002)(81166006)(81156014)(229853002)(68736007)(2501003)(14454004)(6506006)(97736004)(6486002)(5660300001)(478600001)(316002)(77096006)(2900100001)(6436002)(45080400002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1900; H:DM5PR15MB1883.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E3F6F096832D4C4E8BFA5C1343F565E5fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2017 19:03:33.9367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1900 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_06:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 19:04:48 -0000 --_000_E3F6F096832D4C4E8BFA5C1343F565E5fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gbWFueSBSUEMgbW9kZWxzIGhhdmUgZmFpbGVkIHV0dGVybHkgYmVjYXVzZSB0aGV5IGNvdWxk buKAmXQgaGFuZGxlIHJlY2VpdmluZyB0aGUgZGF0YSBpbiBhIHN0cmVhbWluZyBmYXNoaW9uLg0K DQotPVINCg0KDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm IG9mIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KRGF0ZTogVHVlc2Rh eSwgU2VwdGVtYmVyIDEyLCAyMDE3IGF0IDk6NTcgUE0NClRvOiAicXVpY0BpZXRmLm9yZyIgPHF1 aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU3BsaXQgZXJyb3IgY29kZXMgaW4gdHdvDQoNCg0K VGhlcmUgaXMgYW5vdGhlciBhYnN0cmFjdGlvbiAtLSBzdHJlYW1zIGFzIG1lc3NhZ2VzLiBBcHBs aWNhdGlvbiBwdXNoZXMgYSBtZXNzYWdlIHRoYXQgaXMgdGhlIGVudGlyZSBjb250ZW50IG9mIHRo ZSBzdHJlYW0sIGFuZCByZWNlaXZlcyBhIG1lc3NhZ2Ugb25jZSB0aGUgZW50aXJlIHN0cmVhbSBo YXMgYmVlbiByZWNlaXZlZC4gVGhhdCdzIHRoZSBtb2RlbCB1c2VkIGJ5IEROUyBvdmVyIFFVSUMu DQoNCk9uIDkvMTIvMjAxNyA5OjIzIFBNLCBMdWJhc2hldiwgSWdvciB3cm90ZToNClRoaXMgaXMg YSB2ZXJ5IGdvb2QgaWRlYSB0byBkZWNpZGUgd2hhdCB3ZSB3YW50IHRvIG1vZGVsIHN0cmVhbXMg b24uICBTdGFydGluZyB3aXRoIHdlbGwta25vd24sIHNpbXBsZSBhYnN0cmFjdGlvbnMgc2VlbXMg bGlrZSB0aGUgYmVzdCBwYXRoIHRvIGFkb3B0aW9uLg0KDQpUaGVyZSBhcmUgdHdvIHN1Y2ggYWJz dHJhY3Rpb25zIHRoYXQgY29tZSB0byBtaW5kOg0KDQoNCiAgMS4gIOKAnFRDUCBTdHJlYW0gc29j a2V0c+KAnS4gIFRoZXNlIG9ubHkgc3VwcG9ydCBzaWduYWxpbmcg4oCcb3JkZXJseeKAnSBjbG9z aW5nIG9mIHRoZSB3cml0ZSBkaXJlY3Rpb24uICBDbG9zaW5nIG9mIHRoZSByZWFkIGRpcmVjdGlv biBjYW4gb25seSBiZSBkb25lIHZpYSBjbG9zZSgpLCBidXQgdGhhdCBtYXkgbGVhdmUgdGhlIHdy aXRlIGRpcmVjdGlvbiBpbiBhbiB1bmRlZmluZWQgc3RhdGUgKHdyaXRpbmcgd2lsbCBjb21wbGV0 ZSwgdW5sZXNzIHRoZXJlIHdhcyB1bnJlYWQgZGF0YSBpbiB0aGUgcmVhZCBidWZmZXIgb3IgYW55 IGRhdGEgaXMgcmVjZWl2ZWQgYWZ0ZXIgY2xvc2Ug4oCTIHNlZSBSRkMgMTEyMiA0LjIuMi4xMyAk MykuDQoNCg0KDQpJIHRoaW5rIHRoZSBjdXJyZW50IHNwZWMgYWxsb3dzIGZvciBRVUlDIEFQSSB0 byBlbXVsYXRlIFRDUCBzdHJlYW0gc29ja2V0IGFic3RyYWN0aW9uLiAgQ3VycmVudCBzcGVjICBh bHNvIGFkZHMgc2lnbmFsaW5nIOKAnGFib3J04oCdIGNsb3Npbmcgb2YgdGhlIHdyaXRlIGRpcmVj dGlvbiAoUlNUX1NUUkVBTSBkb2VzIG5vdCByZXF1aXJlIGFuIGltbWVkaWF0ZSBSU1RfU1RSRUFN IGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24pLCBhbHRob3VnaCB0aGVyZSB3YXMgc29tZSB0YWxr IG9mIHJlbW92aW5nIHRoaXMgZmVhdHVyZS4NCg0KDQogIDEuICDigJxBIFBPU0lYIHBpcGUgcGFp cuKAnSwgYXMgTWlrZSBpcyBwcm9wb3NpbmcgKG9uZSBwYWlyIGluIGVhY2ggZGlyZWN0aW9uKS4g IENvbm5lY3RlZCBwaXBlcyBhcmUgdmVyeSBjbGVhbiAo4oCYc3ltbWV0cmlj4oCZKSBhYnN0cmFj dGlvbnMsIGFuZCB0aGV5IGNvbW11bmljYXRlIGNsb3NlIGV2ZW50cyAoeW91IGNsb3NlIHRoZSDi gJh3cml0ZeKAmSBwaXBlLCDigJhyZWFk4oCZIHBpcGUgZ2V0IEVPUzsgeW91IGNsb3NlIHRoZSDi gJhyZWFk4oCZIHBpcGUsIOKAmHdyaXRl4oCZIHBpcGUgZ2V0cyBhbiBleGNlcHRpb24pLg0KDQoN Cg0KV2l0aCByZWFkLWRpcmVjdGlvbiBjbG9zZSBzaWduYWxpbmcsIGhvd2V2ZXIsIGl0IGlzIGlt cG9ydGFudCB0byBub3QgdG8gY2F1c2Ugb2Z0ZW4tdW5uZWNlc3NhcnkgU1RPUF9TRU5ESU5HIGZy YW1lcyBzZW50IGZvciBldmVyeSBjb21tb24tY2FzZSBzdHJlYW0uY2xvc2UoKS4gSSB0aGluayB0 aGF0IGNvdWxkIGJlIGRvbmUgdmlhIG9uZSBvZiB0aGUgZm9sbG93aW5nIHdheXM6DQoNCiAgMS4g IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMuIFNlbmQgU1RPUF9TRU5ESU5HIG9uIGNsb3NlKCkgYnkg dGhlIHJlY2VpdmVyIChpZiB0aGUgc3RlYW0gaXMgb3BlbikuDQogIDIuICBBUEkgY29udmVudGlv bjog4oCcb25seSBzZW5kIFNUT1BfU0VORElORyBvbiBzdHJlYW0uaW5wdXRTdHJlYW0oKS5jbG9z ZSgp4oCdLiBPbiBzdHJlYW0uY2xvc2UoKSwgb25seSBzZW5kIFNUT1BfU0VORElORyBpZiB0aGVy ZSBpcyB1bnJlYWQgZGF0YSBvciBuZXcgZGF0YSBjb21lcyBpbiBsYXRlci4NCiAgMy4gIEFjdHVh bGx5IHNpZ25hbCB0aGF0IHJlYWQgZGlyZWN0aW9uIGlzIGNsb3NlZCBpbiBzdHJlYW0uY2xvc2Uo KSBieSBkZWZpbmluZyBTVFJFQU0td2l0aC1GSU4gZnJhbWUgYXMg4oCcY2xvc2UgYm90aCB3cml0 ZSBhbmQgcmVhZCBkaXJlY3Rpb25z4oCdIChjb21tb24gY2FzZSkuICBIYXZlIHNlcGFyYXRlIGZy YW1lIHR5cGVzIGZvciBXUklURV9DTE9TRSwgV1JJVEVfQUJPUlQgKGFrYSBSU1RfU1RSRUFNKSwg YW5kIFJFQURfQUJPUlQgKGFrYSBTVE9QX1NFTkRJTkcpLg0KDQoNCkZyb206IE1pa2UgQmlzaG9w IFttYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbV0NClNlbnQ6IFR1ZXNkYXksIFNl cHRlbWJlciAxMiwgMjAxNyA4OjA0IFBNDQpUbzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNv bT48bWFpbHRvOmpyaUBnb29nbGUuY29tPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT48bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCkNjOiBQaGlsaXBw IFMuIFRpZXNlbCA8cGhpbHNAaW4tcGFuaWsuZGU+PG1haWx0bzpwaGlsc0Bpbi1wYW5pay5kZT47 IFN1Ym9kaCBJeWVuZ2FyIDxzdWJvZGhAZmIuY29tPjxtYWlsdG86c3Vib2RoQGZiLmNvbT47IE5p Y2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb20+PG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+ OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPjxtYWlsdG86cXVpY0BpZXRmLm9yZz47IFZpY3RvciBW YXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPjxtYWlsdG86dmFzaWx2dkBnb29nbGUuY29tPg0K U3ViamVjdDogUkU6IFNwbGl0IGVycm9yIGNvZGVzIGluIHR3bw0KDQpKYW5hIGFuZCBJIHdlcmUg ZGlzY3Vzc2luZyB0aGlzIHRvZGF5LCBhbmQgcGFydCBvZiB0aGUgZGlmZmVyZW5jZSBjb21lcyBk b3duIHRvIGhvdyB5b3UgY29uY2VpdmUgb2YgdGhlIEFQSSBhIFFVSUMgaW1wbGVtZW50YXRpb24g d2lsbCBleHBvc2UuICBNeSBtZW50YWwgbW9kZWwgaGFzIGJlZW4gdGhhdCBhIHN0cmVhbS9zdHJl YW0tcGFpciBjb25zaXN0cyBvZiBhbiBJbnB1dFN0cmVhbSBhbmQgYW4gT3V0cHV0U3RyZWFtOyB5 b3UgY2FuIHJlYWQgb24gb25lLCB5b3UgY2FuIHdyaXRlIG9uIHRoZSBvdGhlci4gIEZvciB0aGUg d3JpdGUgc3RyZWFtLCB5b3UgY2FuIHdyaXRlIHlvdXIgZGF0YSB0byBjb21wbGV0aW9uIGFuZCBj bG9zZSB0aGUgc3RyZWFtLCBvciB5b3UgY2FuIGRlY2lkZSB0byBhYm9ydCB3cml0aW5nLiAgVGhl IHdpcmUgZXhwcmVzc2lvbnMgb2YgdGhlc2UgYXJlIEZJTiBhbmQgUlNUX1NUUkVBTSwgcmVzcGVj dGl2ZWx5LiAgRm9yIHRoZSByZWFkIHN0cmVhbSwgeW91IGNhbiByZWFkIHRoZSBpbmNvbWluZyBk YXRhIHRvIHRoZSBlbmQgb3IgeW91IGNhbiBhYm9ydCByZWFkaW5nIGFuZCBkaXNjYXJkIHRoZSBy ZW1haW5kZXIgb2YgdGhlIHN0cmVhbTsgdGhlIHdpcmUgZXhwcmVzc2lvbiBvZiB0aGlzIHdvdWxk IGJlIGZsb3cgY29udHJvbCB1cGRhdGVzIGFuZCBTVE9QX1NFTkRJTkcsIHJlc3BlY3RpdmVseS4g IE9uIHRoZSBvdGhlciBzaWRlLCByZWNlaXB0IG9mIGEgUlNUX1NUUkVBTSBzdXJmYWNlcyBhcyBh IHJlYWQgZXJyb3IgYW5kIHJlY2VpcHQgb2YgYSBTVE9QX1NFTkRJTkcgc3VyZmFjZXMgYXMgYSB3 cml0ZSBlcnJvci4gIChKYW5hIGNvbW1lbnRlZCB0aGF0IGluIHRoaXMgbWVudGFsIG1vZGVsIGl0 IG1pZ2h0IGJlIGNsZWFyZXIgdG8gY2FsbCB0aGUgZnJhbWVzIFdSSVRFX0FCT1JUIGFuZCBSRUFE X0FCT1JULikNCg0KSWYgd2UgdGFrZSBNYXJ0aW7igJlzIHByb3Bvc2l0aW9uIHRoYXQgc3RyZWFt cyBvbmx5IGNsb3NlIGJ5IGFwcGxpY2F0aW9uIGFjdGlvbiwgdGhlcmUgd291bGQgbmV2ZXIgYmUg YSB3cml0ZSBlcnJvciBzdXJmYWNlZCB0byB0aGUgYXBwbGljYXRpb24gdW5sZXNzIHRoZSB1bmRl cmx5aW5nIHRyYW5zcG9ydCB3ZW50IGF3YXkgZW50aXJlbHkuICBJbnN0ZWFkLCBpdOKAmXMgdGhl IHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbCB0byBjb21tdW5pY2F0 ZSAob24gYW5vdGhlciBzdHJlYW0sIGluIHRoaXMgY2FzZSkgdGhhdCB5b3Ugc2hvdWxkIGFib3J0 IHdyaXRpbmcsIGV2ZW4gaWYgeW914oCZdmUgYWxyZWFkeSB3cml0dGVuIHRvIGNvbXBsZXRpb24s IGFuZCB0aGVuIHRvIGRvIHNvLiAgVGhhdCBpbXBsaWVzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIG5l ZWRzIHRoZSBhYmlsaXR5IHRvIHJldHVybiB0byBzdHJlYW1zIG9uIHdoaWNoIGl04oCZcyBkb25l IHdyaXRpbmcsIGluIGNhc2UgaXTigJlzIGxhdGVyIGFza2VkIHRvIGdvIGJhY2sgYW5kIHJlc2V0 IHRoZW0uDQoNCk11Y2ggb2Ygb3VyIGRpc2N1c3Npb25zIGFyb3VuZCB1bmlkaXJlY3Rpb25hbCBz dHJlYW1zLCBzdHJlYW0gc3RhdGUgdHJhbnNpdGlvbnMsIGV0Yy4gaW5jbHVkaW5nIHRoZSBxdWVz dGlvbiBvZiB3aGV0aGVyIFNUT1BfU0VORElORyBiZWxvbmdzIGF0IHRoZSB0cmFuc3BvcnQgbGF5 ZXIsIHN0ZW0gZnJvbSB0aGUgZmFjdCB0aGF0IHdlIGFsbCBoYXZlIGRpZmZlcmVudCBpbXBsaWNp dCBtZW50YWwgbW9kZWxzIG9mIHRoZSBmdW5jdGlvbmFsIHN1cmZhY2UgUVVJQyBleHBvc2VzLiAg UGVyaGFwcyB3ZSBzaG91bGQgdGFrZSBhIHN0ZXAgYmFjayBhbmQgYWdyZWUgb24gdGhhdCBmaXJz dCwgYXMgSSBiZWxpZXZlIENocmlzdGlhbiBoYXMgc3VnZ2VzdGVkIGluIHRoZSBwYXN0Pw0KDQpG cm9tOiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbV0NClNlbnQ6IEZyaWRheSwg U2VwdGVtYmVyIDgsIDIwMTcgNTozNCBQTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+DQpDYzogU3Vi b2RoIEl5ZW5nYXIgPHN1Ym9kaEBmYi5jb208bWFpbHRvOnN1Ym9kaEBmYi5jb20+PjsgTWlrZSBC aXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9w QG1pY3Jvc29mdC5jb20+PjsgUGhpbGlwcCBTLiBUaWVzZWwgPHBoaWxzQGluLXBhbmlrLmRlPG1h aWx0bzpwaGlsc0Bpbi1wYW5pay5kZT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpx dWljQGlldGYub3JnPj47IE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5o YXJwZXJAZ29vZ2xlLmNvbT4+OyBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29vZ2xlLmNvbTxt YWlsdG86dmFzaWx2dkBnb29nbGUuY29tPj4NClN1YmplY3Q6IFJlOiBTcGxpdCBlcnJvciBjb2Rl cyBpbiB0d28NCg0KT24gVGh1LCBTZXAgNywgMjAxNyBhdCA3OjUwIFBNLCBNYXJ0aW4gVGhvbXNv biA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20+PiB3cm90ZToNCk9uIEZyaSwgU2VwIDgsIDIwMTcgYXQgOTo0MiBBTSwgSmFuYSBJeWVuZ2Fy IDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PiB3cm90ZToNCj4gSSBkb24n dCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBkZXNpZ24gYW4gYXBwIHByb3RvY29sIHRoYXQgZG9l c24ndCBzZW5kIGENCj4gUlNUIGluIHJlc3BvbnNlIHRvIGEgUlNULg0KDQpJJ3ZlIGJlZW4gdG9s ZCBub3QgdG8gaW52b2tlIHRoaXMgcGFydGljdWxhciBkZW1vbiwgYnV0IHlvdSBqdXN0DQppbnZv a2VkIHRoZSBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIHByb2JsZW0uICBJIHRoaW5rIHRoYXQgd2Ug Z2V0IHRoZXJlDQpiZWNhdXNlIG9mIHRoaXMgbWVtZSB0aGF0IHNheXMgdGhhdCBkYXRhIGluIHRo ZSBvbmUgZGlyZWN0aW9uIGlzDQpzb21laG93IG5lY2Vzc2FyaWx5IGJvdW5kIHRvIGRhdGEgaW4g dGhlIG90aGVyIGRpcmVjdGlvbi4gIFRoYXQncyBhbg0KZW50aXJlbHkgY29uc3RydWN0ZWQgbm90 aW9uLiAgQSB1c2VmdWwgY29uc3RydWN0IGF0IHRpbWVzLCBjZXJ0YWlubHksDQpidXQgdGhhdCdz IG5vdCB0aGUgcG9pbnQgaGVyZS4NCg0KSSB0aGluayB0aGF0J3MgdGhlIG1vc3QgY29tbW9uIHVz ZSBvZiBhIFJTVCAtLSB0byBjbG9zZSBib3RoIGRpcmVjdGlvbnMuDQoNClNvIEkgZGlzYWdyZWUu ICBUaGVyZSBhcmUgbWFueSBwcm90b2NvbHMgaW4gd2hpY2ggeW91IHNlbmQgbWVzc2FnZXMNCig9 PSBzdHJlYW1zKSBpbiBvbmUgZGlyZWN0aW9uIGJ1dCBub3QgYW5vdGhlci4gIE9uZSBvZiB0aGUg d2F5cyB5b3UNCmdldCBpbnRvIGEgdW5pZGlyZWN0aW9uYWwgc3RhdGUgaW4gdGhlIGN1cnJlbnQg ZHJhZnQgaXMgdG8gZW5kIG9uZQ0Kc2lkZS4gIEEgRklOIGlzIG9ubHkgb25lIHdheSB0byBkbyB0 aGF0LCBhIHVuaWRpcmVjdGlvbmFsIFJTVCBjYW4gYmUNCmZhc3RlciBhbmQgZXZlbiBzdXBlcmlv ciBpbiBvdGhlciB3YXlzLiAgVGhlIEhUVFAgdXNlIGNhc2UgY2xlYXJseQ0KaWxsdXN0cmF0ZXMg dGhhdC4NCg0KRklOIGlzIHRoZSBwcmltYXJ5IHdheSBpbiB3aGljaCBoYWxmLWNsb3NlIGlzIGFj aGlldmVkLCB3aGljaCBpcyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0LiBUaGUgSFRUUCB1c2Ug Y2FzZSBpcyBhIGNvbXBsZXRlIG9uZS1vZmYgLS0gU1RPUF9TRU5ESU5HIGlzIGFuIG9kZCBlbm91 Z2ggdXNlIGNhc2UgdGhhdCBJJ20gYWx3YXlzIGxlZnQgd29uZGVyaW5nIHdobyBhY3R1YWxseSB1 c2VzIGl0Lg0KDQpBbHNvLCBhcyBJZ29yIG9ic2VydmVzLCB3ZSBkb24ndCByZXF1aXJlIGEgcmVj aXByb2NhbCBSU1RfU1RSRUFNIGluDQp0aGUgY3VycmVudCBkcmFmdC4NCg0KWWVzLCB3ZSBkb24n dC4gUmVjYWxsIHRoYXQgdGhlIFJTVF9TVFJFQU0gd2FzLCBwcmlvciB0byB0aGUgY2hhbmdlIHRo YXQgZG9lc24ndCByZXF1aXJlIHJlY2lwcm9jaXR5LCBhIGJpZGlyZWN0aW9uYWwgc2lnbmFsLCB3 aGljaCB3YXMgc2ltcGxpZmllZCB0byBhIHVuaWRpcmVjdGlvbmFsIG9uZSwgd2l0aCB0aGUgZ2Vu ZXJhbCBleHBlY3RhdGlvbiB0aGF0IGFwcHMgd291bGQgY2xvc2UgdGhlIG90aGVyIHNpZGUgd2hl biB0aGV5IHJlY2VpdmUgdGhpcyBzaWduYWwgZnJvbSBRVUlDLiBJdCdzIHN1cmVseSBnb2luZyB0 byBiZSB0cnVlIG9mIEhUVFAuIEl0J3MgcG9zc2libGUgZm9yIGFuIGFwcCB0byByZWNlaXZlIGEg UlNUIGFuZCB0aGVuIGtlZXAgc2VuZGluZywgYnV0IHRoYXQgaXMgYSB1c2UgY2FzZSBJIGhhdmVu J3Qgc2VlbiBpbiBwcmFjdGljZS4NCg0KDQoNCg0KLS0NCg0KQ2hyaXN0aWFuIEh1aXRlbWENCg== --_000_E3F6F096832D4C4E8BFA5C1343F565E5fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0 b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b3VyaWVyO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0 eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjkyNjI5NjI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yOTc1MDgwODg7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoyNzEzMjM5NDU7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIxMzE1MzEzODg7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3Qt aWQ6OTMzMTY5OTk4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNDM0MjQ1MzY4IC0xMjU5MTg0MjI4IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwyOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJbWFyZ2luLWxlZnQ6MS43NWluOw0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjps ZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoyLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwy OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1h cmdpbi1sZWZ0OjMuMjVpbjsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDozLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6NC4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4t bGVmdDo0Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwzDQoJe21zby1saXN0 LWlkOjEwMDgzNjM1MTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIxMjQ4MjA5MjI7fQ0KQGxp c3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTk0MDEzNDc5MTsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE1MTg4ODYzMiA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGw0Omxl dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg Ymdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBtYW55 IFJQQyBtb2RlbHMgaGF2ZSBmYWlsZWQgdXR0ZXJseSBiZWNhdXNlIHRoZXkgY291bGRu4oCZdCBo YW5kbGUgcmVjZWl2aW5nIHRoZSBkYXRhIGluIGEgc3RyZWFtaW5nIGZhc2hpb24uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNl c0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIENocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1h QGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBTZXB0ZW1iZXIgMTIs IDIwMTcgYXQgOTo1NyBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7cXVpY0BpZXRmLm9yZyZxdW90 OyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFNwbGl0IGVy cm9yIGNvZGVzIGluIHR3bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5UaGVy ZSBpcyBhbm90aGVyIGFic3RyYWN0aW9uIC0tIHN0cmVhbXMgYXMgbWVzc2FnZXMuIEFwcGxpY2F0 aW9uIHB1c2hlcyBhIG1lc3NhZ2UgdGhhdCBpcyB0aGUgZW50aXJlIGNvbnRlbnQgb2YgdGhlIHN0 cmVhbSwgYW5kIHJlY2VpdmVzIGEgbWVzc2FnZSBvbmNlIHRoZSBlbnRpcmUgc3RyZWFtIGhhcyBi ZWVuIHJlY2VpdmVkLiBUaGF0J3MgdGhlIG1vZGVsIHVzZWQgYnkgRE5TIG92ZXIgUVVJQy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDkvMTIvMjAxNyA5OjIzIFBNLCBMdWJhc2hl diwgSWdvciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGlzIGEgdmVyeSBnb29kIGlkZWEgdG8gZGVjaWRlIHdoYXQgd2Ugd2FudCB0byBt b2RlbCBzdHJlYW1zIG9uLiZuYnNwOyBTdGFydGluZyB3aXRoIHdlbGwta25vd24sIHNpbXBsZSBh YnN0cmFjdGlvbnMgc2VlbXMgbGlrZSB0aGUgYmVzdCBwYXRoIHRvIGFkb3B0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgdHdvIHN1Y2ggYWJzdHJhY3Rpb25zIHRoYXQgY29t ZSB0byBtaW5kOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsNCBsZXZlbDEgbGZvMyI+4oCcVENQIFN0cmVhbSBzb2NrZXRz4oCdLiZuYnNwOyBUaGVzZSBv bmx5IHN1cHBvcnQgc2lnbmFsaW5nIOKAnG9yZGVybHnigJ0gY2xvc2luZyBvZiB0aGUgd3JpdGUg ZGlyZWN0aW9uLiZuYnNwOyBDbG9zaW5nIG9mIHRoZSByZWFkIGRpcmVjdGlvbiBjYW4gb25seSBi ZSBkb25lIHZpYSBjbG9zZSgpLCBidXQgdGhhdCBtYXkgbGVhdmUgdGhlIHdyaXRlIGRpcmVjdGlv bg0KIGluIGFuIHVuZGVmaW5lZCBzdGF0ZSAod3JpdGluZyB3aWxsIGNvbXBsZXRlLCB1bmxlc3Mg dGhlcmUgd2FzIHVucmVhZCBkYXRhIGluIHRoZSByZWFkIGJ1ZmZlciBvciBhbnkgZGF0YSBpcyBy ZWNlaXZlZCBhZnRlciBjbG9zZSDigJMgc2VlIFJGQyAxMTIyIDQuMi4yLjEzICQzKS48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIj5JIHRoaW5rIHRoZSBjdXJyZW50IHNwZWMgYWxsb3dzIGZvciBRVUlDIEFQSSB0byBlbXVs YXRlIFRDUCBzdHJlYW0gc29ja2V0IGFic3RyYWN0aW9uLiZuYnNwOyBDdXJyZW50IHNwZWMgJm5i c3A7YWxzbyBhZGRzIHNpZ25hbGluZyDigJxhYm9ydOKAnSBjbG9zaW5nIG9mIHRoZSB3cml0ZSBk aXJlY3Rpb24gKFJTVF9TVFJFQU0gZG9lcyBub3QgcmVxdWlyZSBhbiBpbW1lZGlhdGUgUlNUX1NU UkVBTSBpbiB0aGUgb3Bwb3NpdGUNCiBkaXJlY3Rpb24pLCBhbHRob3VnaCB0aGVyZSB3YXMgc29t ZSB0YWxrIG9mIHJlbW92aW5nIHRoaXMgZmVhdHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzMiPuKAnEEgUE9TSVggcGlwZSBw YWly4oCdLCBhcyBNaWtlIGlzIHByb3Bvc2luZyAob25lIHBhaXIgaW4gZWFjaCBkaXJlY3Rpb24p LiZuYnNwOyBDb25uZWN0ZWQgcGlwZXMgYXJlIHZlcnkgY2xlYW4gKOKAmHN5bW1ldHJpY+KAmSkg YWJzdHJhY3Rpb25zLCBhbmQgdGhleSBjb21tdW5pY2F0ZSBjbG9zZSBldmVudHMgKHlvdSBjbG9z ZSB0aGUg4oCYd3JpdGXigJkNCiBwaXBlLCDigJhyZWFk4oCZIHBpcGUgZ2V0IEVPUzsgeW91IGNs b3NlIHRoZSDigJhyZWFk4oCZIHBpcGUsIOKAmHdyaXRl4oCZIHBpcGUgZ2V0cyBhbiBleGNlcHRp b24pLg0KPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+V2l0aCBy ZWFkLWRpcmVjdGlvbiBjbG9zZSBzaWduYWxpbmcsIGhvd2V2ZXIsIGl0IGlzIGltcG9ydGFudCB0 byBub3QgdG8gY2F1c2Ugb2Z0ZW4tdW5uZWNlc3NhcnkgU1RPUF9TRU5ESU5HIGZyYW1lcyBzZW50 IGZvciBldmVyeSBjb21tb24tY2FzZSBzdHJlYW0uY2xvc2UoKS4gSSB0aGluayB0aGF0IGNvdWxk IGJlIGRvbmUgdmlhIG9uZSBvZiB0aGUgZm9sbG93aW5nIHdheXM6PG86cD48L286cD48L3A+DQo8 b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluO21zby1saXN0OmwyIGxldmVsMSBs Zm83Ij5VbmlkaXJlY3Rpb25hbCBzdHJlYW1zLiBTZW5kIFNUT1BfU0VORElORyBvbiBjbG9zZSgp IGJ5IHRoZSByZWNlaXZlciAoaWYgdGhlIHN0ZWFtIGlzIG9wZW4pLg0KPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzciPkFQSSBjb252ZW50aW9uOiDigJxvbmx5IHNlbmQgU1RPUF9TRU5ESU5H IG9uIHN0cmVhbS5pbnB1dFN0cmVhbSgpLmNsb3NlKCnigJ0uIE9uIHN0cmVhbS5jbG9zZSgpLCBv bmx5IHNlbmQgU1RPUF9TRU5ESU5HIGlmIHRoZXJlIGlzIHVucmVhZCBkYXRhIG9yIG5ldyBkYXRh IGNvbWVzIGluIGxhdGVyLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzciPkFjdHVhbGx5 IHNpZ25hbCB0aGF0IHJlYWQgZGlyZWN0aW9uIGlzIGNsb3NlZCBpbiBzdHJlYW0uY2xvc2UoKSBi eSBkZWZpbmluZyBTVFJFQU0td2l0aC1GSU4gZnJhbWUgYXMg4oCcY2xvc2UgYm90aCB3cml0ZSBh bmQgcmVhZCBkaXJlY3Rpb25z4oCdIChjb21tb24gY2FzZSkuJm5ic3A7IEhhdmUgc2VwYXJhdGUg ZnJhbWUgdHlwZXMgZm9yDQogV1JJVEVfQ0xPU0UsIFdSSVRFX0FCT1JUIChha2EgUlNUX1NUUkVB TSksIGFuZCBSRUFEX0FCT1JUIChha2EgU1RPUF9TRU5ESU5HKS4gPG86cD4NCjwvbzpwPjwvbGk+ PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1pa2UgQmlz aG9wIFs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSI+bWFpbHRv Ok1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxNyA4OjA0IFBNPGJyPg0KPGI+VG86PC9iPiBKYW5hIEl5 ZW5nYXIgPGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIj4mbHQ7anJpQGdvb2dsZS5jb20m Z3Q7PC9hPjsgTWFydGluIFRob21zb24NCjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20iPiZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PC9hPjxicj4NCjxiPkNj OjwvYj4gUGhpbGlwcCBTLiBUaWVzZWwgPGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRl Ij4mbHQ7cGhpbHNAaW4tcGFuaWsuZGUmZ3Q7PC9hPjsgU3Vib2RoIEl5ZW5nYXINCjxhIGhyZWY9 Im1haWx0bzpzdWJvZGhAZmIuY29tIj4mbHQ7c3Vib2RoQGZiLmNvbSZndDs8L2E+OyBOaWNrIEhh cnBlciA8YSBocmVmPSJtYWlsdG86bmhhcnBlckBnb29nbGUuY29tIj4NCiZsdDtuaGFycGVyQGdv b2dsZS5jb20mZ3Q7PC9hPjsgUVVJQyBXRyA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+ Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PC9hPjsgVmljdG9yIFZhc2lsaWV2DQo8YSBocmVmPSJtYWls dG86dmFzaWx2dkBnb29nbGUuY29tIj4mbHQ7dmFzaWx2dkBnb29nbGUuY29tJmd0OzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFNwbGl0IGVycm9yIGNvZGVzIGluIHR3bzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFuYSBhbmQgSSB3ZXJlIGRpc2N1c3Npbmcg dGhpcyB0b2RheSwgYW5kIHBhcnQgb2YgdGhlIGRpZmZlcmVuY2UgY29tZXMgZG93biB0byBob3cg eW91IGNvbmNlaXZlIG9mIHRoZSBBUEkgYSBRVUlDIGltcGxlbWVudGF0aW9uIHdpbGwgZXhwb3Nl LiZuYnNwOyBNeSBtZW50YWwgbW9kZWwgaGFzIGJlZW4gdGhhdCBhIHN0cmVhbS9zdHJlYW0tcGFp ciBjb25zaXN0cyBvZiBhbiBJbnB1dFN0cmVhbSBhbmQgYW4gT3V0cHV0U3RyZWFtOw0KIHlvdSBj YW4gcmVhZCBvbiBvbmUsIHlvdSBjYW4gd3JpdGUgb24gdGhlIG90aGVyLiZuYnNwOyBGb3IgdGhl IHdyaXRlIHN0cmVhbSwgeW91IGNhbiB3cml0ZSB5b3VyIGRhdGEgdG8gY29tcGxldGlvbiBhbmQg Y2xvc2UgdGhlIHN0cmVhbSwgb3IgeW91IGNhbiBkZWNpZGUgdG8gYWJvcnQgd3JpdGluZy4mbmJz cDsgVGhlIHdpcmUgZXhwcmVzc2lvbnMgb2YgdGhlc2UgYXJlIEZJTiBhbmQgUlNUX1NUUkVBTSwg cmVzcGVjdGl2ZWx5LiZuYnNwOyBGb3IgdGhlIHJlYWQgc3RyZWFtLA0KIHlvdSBjYW4gcmVhZCB0 aGUgaW5jb21pbmcgZGF0YSB0byB0aGUgZW5kIG9yIHlvdSBjYW4gYWJvcnQgcmVhZGluZyBhbmQg ZGlzY2FyZCB0aGUgcmVtYWluZGVyIG9mIHRoZSBzdHJlYW07IHRoZSB3aXJlIGV4cHJlc3Npb24g b2YgdGhpcyB3b3VsZCBiZSBmbG93IGNvbnRyb2wgdXBkYXRlcyBhbmQgU1RPUF9TRU5ESU5HLCBy ZXNwZWN0aXZlbHkuJm5ic3A7IE9uIHRoZSBvdGhlciBzaWRlLCByZWNlaXB0IG9mIGEgUlNUX1NU UkVBTSBzdXJmYWNlcyBhcyBhDQogcmVhZCBlcnJvciBhbmQgcmVjZWlwdCBvZiBhIFNUT1BfU0VO RElORyBzdXJmYWNlcyBhcyBhIHdyaXRlIGVycm9yLiZuYnNwOyAoSmFuYSBjb21tZW50ZWQgdGhh dCBpbiB0aGlzIG1lbnRhbCBtb2RlbCBpdCBtaWdodCBiZSBjbGVhcmVyIHRvIGNhbGwgdGhlIGZy YW1lcyBXUklURV9BQk9SVCBhbmQgUkVBRF9BQk9SVC4pPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIHdlIHRha2UgTWFydGlu4oCZcyBwcm9wb3NpdGlvbiB0aGF0IHN0cmVhbXMgb25seSBjbG9z ZSBieSBhcHBsaWNhdGlvbiBhY3Rpb24sIHRoZXJlIHdvdWxkIG5ldmVyIGJlIGEgd3JpdGUgZXJy b3Igc3VyZmFjZWQgdG8gdGhlIGFwcGxpY2F0aW9uIHVubGVzcyB0aGUgdW5kZXJseWluZyB0cmFu c3BvcnQgd2VudCBhd2F5IGVudGlyZWx5LiZuYnNwOyBJbnN0ZWFkLCBpdOKAmXMgdGhlIHJlc3Bv bnNpYmlsaXR5IG9mIHRoZSBhcHBsaWNhdGlvbg0KIHByb3RvY29sIHRvIGNvbW11bmljYXRlIChv biBhbm90aGVyIHN0cmVhbSwgaW4gdGhpcyBjYXNlKSB0aGF0IHlvdSBzaG91bGQgYWJvcnQgd3Jp dGluZywgZXZlbiBpZiB5b3XigJl2ZSBhbHJlYWR5IHdyaXR0ZW4gdG8gY29tcGxldGlvbiwgYW5k IHRoZW4gdG8gZG8gc28uJm5ic3A7IFRoYXQgaW1wbGllcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBu ZWVkcyB0aGUgYWJpbGl0eSB0byByZXR1cm4gdG8gc3RyZWFtcyBvbiB3aGljaCBpdOKAmXMgZG9u ZSB3cml0aW5nLA0KIGluIGNhc2UgaXTigJlzIGxhdGVyIGFza2VkIHRvIGdvIGJhY2sgYW5kIHJl c2V0IHRoZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk11Y2ggb2Ygb3VyIGRpc2N1c3Npb25z IGFyb3VuZCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zLCBzdHJlYW0gc3RhdGUgdHJhbnNpdGlvbnMs IGV0Yy4gaW5jbHVkaW5nIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIFNUT1BfU0VORElORyBiZWxv bmdzIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIsIHN0ZW0gZnJvbSB0aGUgZmFjdCB0aGF0IHdlIGFs bCBoYXZlIGRpZmZlcmVudCBpbXBsaWNpdCBtZW50YWwgbW9kZWxzIG9mDQogdGhlIGZ1bmN0aW9u YWwgc3VyZmFjZSBRVUlDIGV4cG9zZXMuJm5ic3A7IFBlcmhhcHMgd2Ugc2hvdWxkIHRha2UgYSBz dGVwIGJhY2sgYW5kIGFncmVlIG9uIHRoYXQgZmlyc3QsIGFzIEkgYmVsaWV2ZSBDaHJpc3RpYW4g aGFzIHN1Z2dlc3RlZCBpbiB0aGUgcGFzdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IEphbmEgSXllbmdhciBbPGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIj5tYWls dG86anJpQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVt YmVyIDgsIDIwMTcgNTozNCBQTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0Ozxh IGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTdWJvZGggSXllbmdhciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnN1Ym9kaEBmYi5jb20iPnN1Ym9kaEBmYi5jb208L2E+Jmd0OzsgTWlrZSBCaXNo b3AgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIj5NaWNo YWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDs7IFBoaWxpcHAgUy4gVGllc2VsICZsdDs8 YSBocmVmPSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiPnBoaWxzQGluLXBhbmlrLmRlPC9hPiZn dDs7IFFVSUMgV0cNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0 Zi5vcmc8L2E+Jmd0OzsgTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpuaGFycGVyQGdv b2dsZS5jb20iPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBWaWN0b3IgVmFzaWxpZXYgJmx0 OzxhIGhyZWY9Im1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20iPnZhc2lsdnZAZ29vZ2xlLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTcGxpdCBlcnJvciBjb2RlcyBpbiB0d288 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBTZXAg NywgMjAxNyBhdCA3OjUwIFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1h cnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG cmksIFNlcCA4LCAyMDE3IGF0IDk6NDIgQU0sIEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpyaUBnb29nbGUuY29tIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsgSSBkb24ndCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBkZXNpZ24gYW4gYXBwIHByb3RvY29s IHRoYXQgZG9lc24ndCBzZW5kIGE8YnI+DQomZ3Q7IFJTVCBpbiByZXNwb25zZSB0byBhIFJTVC48 YnI+DQo8YnI+DQpJJ3ZlIGJlZW4gdG9sZCBub3QgdG8gaW52b2tlIHRoaXMgcGFydGljdWxhciBk ZW1vbiwgYnV0IHlvdSBqdXN0PGJyPg0KaW52b2tlZCB0aGUgVW5pZGlyZWN0aW9uYWwgc3RyZWFt cyBwcm9ibGVtLiZuYnNwOyBJIHRoaW5rIHRoYXQgd2UgZ2V0IHRoZXJlPGJyPg0KYmVjYXVzZSBv ZiB0aGlzIG1lbWUgdGhhdCBzYXlzIHRoYXQgZGF0YSBpbiB0aGUgb25lIGRpcmVjdGlvbiBpczxi cj4NCnNvbWVob3cgbmVjZXNzYXJpbHkgYm91bmQgdG8gZGF0YSBpbiB0aGUgb3RoZXIgZGlyZWN0 aW9uLiZuYnNwOyBUaGF0J3MgYW48YnI+DQplbnRpcmVseSBjb25zdHJ1Y3RlZCBub3Rpb24uJm5i c3A7IEEgdXNlZnVsIGNvbnN0cnVjdCBhdCB0aW1lcywgY2VydGFpbmx5LDxicj4NCmJ1dCB0aGF0 J3Mgbm90IHRoZSBwb2ludCBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0J3MgdGhlIG1vc3QgY29tbW9u IHVzZSBvZiBhIFJTVCAtLSB0byBjbG9zZSBib3RoIGRpcmVjdGlvbnMuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBJIGRpc2FncmVlLiZuYnNwOyBUaGVy ZSBhcmUgbWFueSBwcm90b2NvbHMgaW4gd2hpY2ggeW91IHNlbmQgbWVzc2FnZXM8YnI+DQooPT0g c3RyZWFtcykgaW4gb25lIGRpcmVjdGlvbiBidXQgbm90IGFub3RoZXIuJm5ic3A7IE9uZSBvZiB0 aGUgd2F5cyB5b3U8YnI+DQpnZXQgaW50byBhIHVuaWRpcmVjdGlvbmFsIHN0YXRlIGluIHRoZSBj dXJyZW50IGRyYWZ0IGlzIHRvIGVuZCBvbmU8YnI+DQpzaWRlLiZuYnNwOyBBIEZJTiBpcyBvbmx5 IG9uZSB3YXkgdG8gZG8gdGhhdCwgYSB1bmlkaXJlY3Rpb25hbCBSU1QgY2FuIGJlPGJyPg0KZmFz dGVyIGFuZCBldmVuIHN1cGVyaW9yIGluIG90aGVyIHdheXMuJm5ic3A7IFRoZSBIVFRQIHVzZSBj YXNlIGNsZWFybHk8YnI+DQppbGx1c3RyYXRlcyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RklOIGlzIHRoZSBwcmltYXJ5 IHdheSBpbiB3aGljaCBoYWxmLWNsb3NlIGlzIGFjaGlldmVkLCB3aGljaCBpcyB3aGF0IHlvdSdy ZSB0YWxraW5nIGFib3V0LiBUaGUgSFRUUCB1c2UgY2FzZSBpcyBhIGNvbXBsZXRlIG9uZS1vZmYg LS0gU1RPUF9TRU5ESU5HIGlzIGFuIG9kZCBlbm91Z2ggdXNlIGNhc2UgdGhhdCBJJ20gYWx3YXlz IGxlZnQgd29uZGVyaW5nIHdobyBhY3R1YWxseSB1c2VzIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgYXMgSWdvciBvYnNlcnZlcywgd2UgZG9uJ3QgcmVx dWlyZSBhIHJlY2lwcm9jYWwgUlNUX1NUUkVBTSBpbjxicj4NCnRoZSBjdXJyZW50IGRyYWZ0Ljxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WWVzLCB3ZSBkb24ndC4gUmVjYWxsIHRoYXQgdGhlIFJTVF9TVFJFQU0gd2FzLCBwcmlvciB0 byB0aGUgY2hhbmdlIHRoYXQgZG9lc24ndCByZXF1aXJlIHJlY2lwcm9jaXR5LCBhIGJpZGlyZWN0 aW9uYWwgc2lnbmFsLCB3aGljaCB3YXMgc2ltcGxpZmllZCB0byBhIHVuaWRpcmVjdGlvbmFsIG9u ZSwgd2l0aCB0aGUgZ2VuZXJhbCBleHBlY3RhdGlvbiB0aGF0IGFwcHMgd291bGQgY2xvc2UgdGhl IG90aGVyIHNpZGUNCiB3aGVuIHRoZXkgcmVjZWl2ZSB0aGlzIHNpZ25hbCBmcm9tIFFVSUMuIEl0 J3Mgc3VyZWx5IGdvaW5nIHRvIGJlIHRydWUgb2YgSFRUUC4gSXQncyBwb3NzaWJsZSBmb3IgYW4g YXBwIHRvIHJlY2VpdmUgYSBSU1QgYW5kIHRoZW4ga2VlcCBzZW5kaW5nLCBidXQgdGhhdCBpcyBh IHVzZSBjYXNlIEkgaGF2ZW4ndCBzZWVuIGluIHByYWN0aWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5DaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E3F6F096832D4C4E8BFA5C1343F565E5fbcom_-- From nobody Wed Sep 13 13:58:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF37132F2F for ; Wed, 13 Sep 2017 13:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com 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 fjWqwsPv0LRg for ; Wed, 13 Sep 2017 13:58:31 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92DF0132697 for ; Wed, 13 Sep 2017 13:58:31 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id b82so3457323qkc.4 for ; Wed, 13 Sep 2017 13:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=GY4x/awRpq3PqVqwmxE67v+cCU17Xx1sU/K0xE24Xo8=; b=w82GpV72qw9BcysvmTRD82D0dUfcKGpsguyBpOAuh16n7Eohbg4OCsWwy1K6PMqyFr Yq789VRy6bgvwdHR7dmc8gThYhPr8NtzvfGafU7ragZ6qaB/QcnvHQLB09I34fb+nvxS sQe53ULO3LY2CJpNFMnVpY437HnSxOc9SeSpkF85+3OOHKcBjoSxnqrbwRMWE4MmIf44 dmKkZgIcVWkPQQzlEA1JwOWmX/ZZSy/z2ewFRk90Hej0PyUgsLu+8AzsTMg3PBK5Oftu hgRlvMC4B49u9tCutiFJfFht4+kkSfag+55LNMpSf3z0i6hkaPahUJ7yxucuk7x/9MFK 7/kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=GY4x/awRpq3PqVqwmxE67v+cCU17Xx1sU/K0xE24Xo8=; b=Qb/XG1Q4znqmCO/khpo4rNlNE1O4RXAOXQlkGtpn82PcSpjEAE+11nVvrJxZ8Zs5Wv R4zoAMx1EqRhxGCSYX/Dk+qvtG5tJsgGvGy3XYgrpN61SWMDl5csF/POy+myF15/UGPO 3R4aabzGmBQjxCBxSJ8GnPjTlHYEpMpBSIKViSN6QJX1CTw8Jm3M/Sb91bdTGqJTp3yJ MzftwWnWwkxRtAhr9Uj9n6VqBhrGAe5s/ZMhrgTU4ylgIKoJjWNcoM1AsxFSgMl4/wKf 2odOqGNO5MjRquEyTmv0yyQNySZksS1lTYq+CtmFFQOb23GTw0Z5g5fN9LfxbhUk9ojQ sVtA== X-Gm-Message-State: AHPjjUhOSBcCkwY5yzlywUzN+bFu4hzFmQfzLQ872CmuYoDsIVClpHOg 6hv91HibCPn1ElUy X-Google-Smtp-Source: AOwi7QB5MgDCzWsM27Lbbdo6+4ET9gJqOw9289t1xEIYhfEC2igCBfXIFx4sVe6z6qoO3HN4JBNpVA== X-Received: by 10.55.71.79 with SMTP id u76mr26049446qka.289.1505336310435; Wed, 13 Sep 2017 13:58:30 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id g132sm9735220qke.11.2017.09.13.13.58.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 13:58:29 -0700 (PDT) Date: Wed, 13 Sep 2017 16:58:17 -0400 From: Dmitri Tikhonov To: Mirja =?iso-8859-1?Q?K=FChlewind?= Cc: Martin Thomson , Roni Even , QUIC WG Subject: Re: obsrvtaion on packet numbers Message-ID: <20170913205816.GA18476@ubuntu-dmitri> References: <6E58094ECC8D8344914996DAD28F1CCD801698@DGGEMM506-MBX.china.huawei.com> <5ba17907-1be7-da2d-1e2f-ae62254f2b40@tik.ee.ethz.ch> <20170913135614.GB3857@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170913135614.GB3857@ubuntu-dmitri> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 20:58:33 -0000 On Wed, Sep 13, 2017 at 09:56:14AM -0400, Dmitri Tikhonov wrote: > 1. Why are there packet number and byte offset limits? In > other words, why are there limits on the duration of a > connection? > > 2. How are particular limits chosen? In 2012, Jim Roskind wrote in "QUIC: Design Document and Specification Rationale" [1]: " Header: Packet Sequence Number " " In addition to sequencing packets, watching for duplicates, " and communicating what packets are missing, this number is " a critical part of the encryption. This number forms the " basis of the IV used to decrypt each packet. As a result, " it must conceptually be large, as it must never repeat during " the lifetime of the connection. That need forced this sequence " number to be conceptually large, around 2^64 (more packets than " any connection would dream of sending), but we usually don’t " need to provide all 8 bytes in each packet! And " even though we expect to support very large file transfers, it " will be rare that a stream will convey data that uses many of " the current 64 bits of maximum offset! It seems that the author of QUIC took the [pragmatic] position that these limits will never be reached. On the other hand, his goals at the time were also more modest: " The two primary support motivations for this transport are to " better support SPDY, and to further coalesce traffic. SPDY " currently runs over TCP, but has encountered a few performance " limitations. (Ibid.) This document seems to be the origin of the current limits in the IETF QUIC Draft. Now that QUIC is not just a transport for SPDY but a generic transport protocol, perhaps it is time for a reassessment. - Dmitri. 1. https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview From nobody Thu Sep 14 18:00:14 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D57132CE8 for ; Thu, 14 Sep 2017 18:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 rau95IKFqKyd for ; Thu, 14 Sep 2017 18:00:10 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF340132C2A for ; Thu, 14 Sep 2017 18:00:10 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id x78so567908pff.10 for ; Thu, 14 Sep 2017 18:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zLn8LvE+IviMZ8fWNJtWDGSkD/ftqXZU90lEC8lSnck=; b=mZH8Akbw2vElKRWyA+MD4W+NIki/F9phK6wI9K/l3feSkrwNG7QD5KqkMDzO/WRkbD cuU/4oXU7mIouAdTdvqdWPAwCP5wBX+6gPnotU8/aRskB1fXsWgh840GB8JqMsWQcE1Y So8AcDKp3uisVzh/Aw0Y6M3RjgBSyzuFWhdP/ZU5ZlTAhsPlG2NUW8ocZxGLLVTxcngn gCRC23grt2yzsBlxGdNqVavjoysLvaTkgrL8qAm1iKUK5RH1nsQvoHpu1p+YW/vgPJ9O LU+Pm3TldkaWFODWhV+QCTrhrObksNa8kY4dq4sJ9X5Nssj8hI8vtsM/4deSQUf3+QBA p6mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zLn8LvE+IviMZ8fWNJtWDGSkD/ftqXZU90lEC8lSnck=; b=HI7hMabAsLTePrO0hVxkWCjYGFZUautRBYn9OgJAIDy85lulSzNkP5G5arg4SWtv4S R5wAQBBb30yaSFRpWewlRVVar8kF5XVmhcwdvvH8PT43T57RX+pvrpNKotw7l4hhq+Xw TQFsrRVBezuilRfhMYQUyOmV1Gopub2UmGj7aYo3BjjSS6omXrUJn7l8gWD/gci9Uwqs RPVQl3oXvvzLod+452MQucKrWc9U7A6/Sjd8Zz/quOwPjfusc3okEP8Ara7k6kGNXdEq OwLRr1/YLP+N6JcK78oh1aykQenVg4Ht5+7rBDwaGPWikexSAS5mnpE9qViu1ybOXQT1 X3hQ== X-Gm-Message-State: AHPjjUjav5/1nW8G93O73v3tF9Ilds5+UOVZELYMnFEEH28hAA6HdM10 lxXD6jr1rfEJc5yc/80yh8lZojP72Yd1/AaE0C/mB/44 X-Google-Smtp-Source: ADKCNb4PYOSF5UPkegLcrVJqHfq18ME/4LLCSm7P9hzjOB9AhFhiN0QI/KlWbCtrk9gxJw06SkRiRcocUdqbqPwbpwo= X-Received: by 10.98.245.8 with SMTP id n8mr22928672pfh.108.1505437209835; Thu, 14 Sep 2017 18:00:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.144 with HTTP; Thu, 14 Sep 2017 18:00:09 -0700 (PDT) In-Reply-To: <2269510d-90dc-483c-471b-f9b8d98dfa1b@huitema.net> References: <6E58094ECC8D8344914996DAD28F1CCD8025EC@DGGEMM506-MBX.china.huawei.com> <2269510d-90dc-483c-471b-f9b8d98dfa1b@huitema.net> From: Jana Iyengar Date: Thu, 14 Sep 2017 18:00:09 -0700 Message-ID: Subject: Re: nits in draft-ietf-quic-recovery-05 To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11439c3820427405592feace" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 01:00:12 -0000 --001a11439c3820427405592feace Content-Type: text/plain; charset="UTF-8" Christian -- yes, the overview needs rework. I'll try to do a rewrite before the next set of drafts comes out. On Mon, Sep 11, 2017 at 6:09 PM, Christian Huitema wrote: > > > On 9/11/2017 2:41 PM, Jana Iyengar wrote: > > > > Oh, right, I missed that. Thanks for clarifying, I'll fix it (change > > to "marks a packet as lost when a packet with a larger packet number > > is acknowledged.") > > Except that's not true, because that simple statement does not take into > account possible out of order deliveries. Indeed, the overview says: "A > packet is marked as lost if at least one packet that was sent a > threshold number of packets (kReorderingThreshold) after it has been > acknowledged." But the overview is not correct either, because it does > not consider time. A packet could still be marked as lost if > "time_reordering_fraction + kDelayedAckTimeout" has elapsed since > receiving an acknowledgement of a packet with a larger number. > > -- > Christian Huitema > > > --001a11439c3820427405592feace Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christian -- yes, the overview needs rework. I'll try = to do a rewrite before the next set of drafts comes out.

On Mon, Sep 11, 2017 at 6:09 P= M, Christian Huitema <huitema@huitema.net> wrote:


On 9/11/2017 2:41 PM, Jana Iyengar wrote:
>
> Oh, right, I missed that. Thanks for clarifying, I'll fix it (chan= ge
> to "marks a packet as lost when a packet with a larger packet num= ber
> is acknowledged.")

Except that's not true, because that simple statement does not t= ake into
account possible out of order deliveries. Indeed, the overview says: "= A
packet is marked as lost if at least one packet that was sent a
threshold number of packets (kReorderingThreshold) after it has been
acknowledged." But the overview is not correct either, because it does=
not consider time. A packet could still be marked as lost if
"time_reordering_fraction + kDelayedAckTimeout" has elapsed since=
receiving an acknowledgement of a packet with a larger number.

--
Christian Huitema



--001a11439c3820427405592feace-- From nobody Tue Sep 19 00:22:04 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E13A133023 for ; Tue, 19 Sep 2017 00:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QcCABtjBczSx for ; Tue, 19 Sep 2017 00:22:00 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DA6126DFE for ; Tue, 19 Sep 2017 00:22:00 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id m103so7798909iod.13 for ; Tue, 19 Sep 2017 00:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=jAvoFKt07S03tDLc5Bv6enSQ1CpSMHVLoSgkbrXzMa8=; b=WHgMx3ncebW/EZvvfl6MksCA3FlcR7L+8mmCRHqQDVgfv9M0qjzabt0i0/nuuXham+ U6ZifLNEWh0vFpR2554cCwAyIVE7FyZuWxwXOSQQLkNPLAd0L0/ruHL9LO7gGIH6egoS wuR1v08fVE8wxFh300dfx+/PDgJTtXz6Kk/3qE8TW1Lhi/64FfBxMGxyNZri1QsXL0hP BPrJGFBuN98o380I/8bWfVrb4JDKvBhO6xUJ/KumvcD7ocymWYUjhNJHe2Kjl2vAGyCD rvSYioiW3qUhBK9tyQ3O7jf45iY8iV5jY1UUKes/U4+wOv36Sc0E+TVV3WKMlEeq3rxD rT3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=jAvoFKt07S03tDLc5Bv6enSQ1CpSMHVLoSgkbrXzMa8=; b=oqkoHAp9YuqYIfJktIxTVgVd90kz7TUvqsO5weR8M3FAhSwEOlFejmwiiREfUYIqUY MMHaQ6MEormnUL2ZvmJalWVPhsTz6xgOxiTiUTzBb8ATwnmzUynoJUm3uAOvN7DNN1oH KTBuY4ikamssgnbQ/Vqq+h+YexCIsImaTPB9lQOoT69F9DcvIrTD3dFgPII+7OHjaL0P gG8f4CNJkeJ8lGh7dQ93aycl47BXAnA2VGCAHF9FJZEF9YPpDFMd72rhn50NMFpINwtz l70gA9epYgfbMEjdkklZM1H97LiUIbQ3bBhQwuLPxv6444ng4KGaEsbMXPLnwe/m3prc VsXw== X-Gm-Message-State: AHPjjUjjCN15T3o1BSuGh2Kf2XcKDaYfzobOjNhKByMlkQAykcKhbfBd NWdUjgaxzAq7wxkVyKclHSe6lf3qKBTURKk92fo= X-Google-Smtp-Source: AOwi7QDmuG3eZxo411iqXvOagnk/b1i6bKDjdO/Dl/ylbPhLw81bzEmUcUIDF1dJO81L+d5CZTQ9HNQnBXzxruvmAhk= X-Received: by 10.107.186.6 with SMTP id k6mr659687iof.183.1505805719936; Tue, 19 Sep 2017 00:21:59 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Sep 2017 00:21:58 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 19 Sep 2017 00:21:58 -0700 Message-ID: Subject: partially unreliable quic streams To: anja@inet.tu-berlin.de, ott@in.tum.de, quic@ietf.org Content-Type: multipart/alternative; boundary="94eb2c076a6209a8f0055985b7b5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 07:22:02 -0000 --94eb2c076a6209a8f0055985b7b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Anja und J=C3=B6rg Regarding https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-00 I=E2=80=99m not sure where this draft fits into to the QUIC design process = process since my understanding is that unreliable streams is for a later charter in the design process. A quick read through the draft makes me wonder if you considering some partial reliable ideas that have emerged out of the currently unfinished concept of unidirectional streams and if you can incorporate these ideas into your draft? Essentially the idea is each stream is sequence of messages which are reliable but suffer head of line blocking when each message is separated by an application specific message header. In the simplest form the stream is just one message. For unreliable streams, the concept is inverted: each stream is a single message which starts an application specific unreliable stream identifier embedded in the stream/message. The ordering of messages is given by the QUIC level stream id which always increases (effectively a message id in this context) but there is no head of line blocking nor any delivery ordering because each message is independent. Thus the space consumed is the same for the two concepts but the interpretation is different. An implementation can further cooperate by not retransmitting sufficiently old or otherwise outdate messages. Currently QUIC has no way to explicitly configure this and dropping retransmission of frames might affect congestion control. Therefore in its current form QUIC cannot properly unreliable streams, only prevent head of line blocking. It is worth noting that with once message per stream there can be many messages per packet which can significantly increase the messages per second rate and therefore also requires efficiently management of stream state - such as discarding send state immediately after sending FIN (except retransmission machinery). Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --94eb2c076a6209a8f0055985b7b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

I=E2=80=99m not sure where this draft fits in= to to the QUIC design process process since my understanding is that unreli= able streams is for a later charter in the design process.

A quick read through the draft makes me wonder if y= ou considering some partial reliable ideas that have emerged out of the cur= rently unfinished concept of unidirectional streams and if you can incorpor= ate these ideas into your draft?

Es= sentially the idea is each stream is sequence of messages which are reliabl= e but suffer head of line blocking when each message is separated by an app= lication specific message header. In the simplest form the stream is just o= ne message.

For unreliable streams,= the concept is inverted: each stream is a single message which starts an a= pplication specific unreliable stream identifier embedded in the stream/mes= sage. The ordering of messages is given by the QUIC level stream id which a= lways increases (effectively a message id in this context) but there is no = head of line blocking nor any delivery ordering because each message is ind= ependent.

=
Thus the space consumed i= s the same for the two concepts but the interpretation is different.
<= div id=3D"bloop_customfont" style=3D"margin:0px">
An implementation can further cooperate b= y not retransmitting sufficiently old or otherwise outdate messages. Curren= tly QUIC has no way to explicitly configure this and dropping retransmissio= n of frames might affect congestion control. Therefore in its current form = QUIC cannot properly unreliable streams, only prevent head of line blocking= .=C2=A0

It is worth noting that wit= h once message per stream there can be many messages per packet which can s= ignificantly increase the messages per second rate and therefore also requi= res efficiently management of stream state - such as discarding send state = immediately after sending FIN (except retransmission machinery).


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

--94eb2c076a6209a8f0055985b7b5-- From nobody Tue Sep 19 00:45:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26939126DFE for ; Tue, 19 Sep 2017 00:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fb7aEw2iBcxi for ; Tue, 19 Sep 2017 00:45:00 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBEA133057 for ; Tue, 19 Sep 2017 00:44:59 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id z187so7915233ioz.12 for ; Tue, 19 Sep 2017 00:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=uBA/5EUSIl+5tSYFDd5+ejHtizpv7EgWsyGoNjAUDo4=; b=C+2b4v9LGUc1a4xfSNIP8FlQIL5h0HDn8qah7vP2Ch/s+cdo+0qKy2Tm+kM2fKWGyg rKMyEVhQdqkMR32qrRDMuCcbu5JXatSm1tjVcuHxonuLVaWylndmrunRLeyrw8x37FjN 5gtRPddH07VZyPnW+QL5eseKT0bMn0+vg+wbbn0a83dQXYPrPCAIdnPICKJLrIT9Q7Fk ZxHfxQS1jbOjeF6M5Y0O1JZPcEFRAddZJtjd4vxLJVZajF9fr2wpmcQkv89NigMqGiKI H5pISfWj2lpLwVpaJHi4KEzVhJiY9oJcdsefDDCgcQjEdViiJ/HxEliQEdA0OxsxTZB8 06wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=uBA/5EUSIl+5tSYFDd5+ejHtizpv7EgWsyGoNjAUDo4=; b=ImUXa/ve+RvbwUmuxjkIW0sFAHorsuIf2ZgmlvmD2vHl72TDQfLbdcUbCC69CmlCCn 3OhqFAtXdJfY7C4ViksDC6OuGptklX8tCeK+rXB2m+ac6MiZ2aWbC/vwUwJUJUUHpxy3 Kd+LqaMtjT5qkJF3TdVaiN3sjVmKsMPTtysP01ntANpfLJlfwqb98uIZRuFtlqRsAt8G cgFXYXpdMppqgBCTi70oQ0I/Vm9oTf3aZY8Cv0LHWecRRK1zcO4A0GU0BcwkcvLmfEgJ gVFf9zj1L8Kh0ruAWtq11Yp/nYbdH9rm/NRpXkvgYcvaEXMpS4+RECv7me6qHyW7jrL/ X0sg== X-Gm-Message-State: AHPjjUggQL6ghprMkNoaRPReZl65TnKgfdui/e71LB+W9Ol/Khntlm5g kjsuZvnYzP5+mdX8iAgxMMk8ziDxKYkb1jIlbjI= X-Google-Smtp-Source: AOwi7QAk5DQxcCpeGGtyRN5msY+2CGnER61TmUlnlj7oWV5lsZ0v8d9ChQm9NASpr0OCYe5byDsqZXYQShR+vpjG5qE= X-Received: by 10.107.166.206 with SMTP id p197mr657977ioe.63.1505807099189; Tue, 19 Sep 2017 00:44:59 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Sep 2017 00:44:58 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 19 Sep 2017 00:44:58 -0700 Message-ID: Subject: Re: partially unreliable quic streams To: ott@in.tum.de, anja@inet.tu-berlin.de, quic@ietf.org, philipp@inet.tu-berlin.de, mirko@inet.tu-berlin.de, balac@inet.tu-berlin.de Content-Type: multipart/alternative; boundary="001a1141d0823f5c4705598609ba" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 07:45:01 -0000 --001a1141d0823f5c4705598609ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, forgot all authors Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 19 September 2017 at 09.21.58, Mikkel Fahn=C3=B8e J=C3=B8rgensen ( mikkelfj@gmail.com) wrote: Hi Anja und J=C3=B6rg Regarding https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-00 I=E2=80=99m not sure where this draft fits into to the QUIC design process = process since my understanding is that unreliable streams is for a later charter in the design process. A quick read through the draft makes me wonder if you considering some partial reliable ideas that have emerged out of the currently unfinished concept of unidirectional streams and if you can incorporate these ideas into your draft? Essentially the idea is each stream is sequence of messages which are reliable but suffer head of line blocking when each message is separated by an application specific message header. In the simplest form the stream is just one message. For unreliable streams, the concept is inverted: each stream is a single message which starts an application specific unreliable stream identifier embedded in the stream/message. The ordering of messages is given by the QUIC level stream id which always increases (effectively a message id in this context) but there is no head of line blocking nor any delivery ordering because each message is independent. Thus the space consumed is the same for the two concepts but the interpretation is different. An implementation can further cooperate by not retransmitting sufficiently old or otherwise outdate messages. Currently QUIC has no way to explicitly configure this and dropping retransmission of frames might affect congestion control. Therefore in its current form QUIC cannot properly unreliable streams, only prevent head of line blocking. It is worth noting that with once message per stream there can be many messages per packet which can significantly increase the messages per second rate and therefore also requires efficiently management of stream state - such as discarding send state immediately after sending FIN (except retransmission machinery). Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --001a1141d0823f5c4705598609ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Sorry, forgot all authors

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen
<= br>

On 19 September 2017 at 09.21.5= 8, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

Hi Anja und J=C3=B6rg



I=E2=80=99m not sure wher= e this draft fits into to the QUIC design process process since my understanding is that unreliable streams is for a later charter in the design process.

A quick read through the draft makes me wonder if you considering some partial reliable ideas that have emerged out of the currently unfinished concept of unidirectional streams and if you can incorporate these ideas into your draft?

Essentially the idea is each stream is sequence of messages which are reliable but suffer head of line blocking when each message is separated by an application specific message header. In the simplest form the stream is just one message.

For unreliable streams, the concept is inverted: each stream is a single message which starts an application specific unreliable stream identifier embedded in the stream/message. The ordering of messages is given by the QUIC level stream id which always increases (effectively a message id in this context) but there is no head of line blocking nor any delivery ordering because each message is independent.

Thus the space consumed is the same for the two concepts but the interpretation is different.

An implementation can further cooperate by not retransmitting sufficiently old or otherwise outdate messages. Currently QUIC has no way to explicitly configure this and dropping retransmission of frames might affect congestion control. Therefore in its current form QUIC cannot properly unreliable streams, only prevent head of line blocking.=C2=A0

It is worth noting that with once message per stream there can be many messages per packet which can significantly increase the messages per second rate and therefore also requires efficiently management of stream state - such as discarding send state immediately after sending FIN (except retransmission machinery).


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

--001a1141d0823f5c4705598609ba-- From nobody Tue Sep 19 10:49:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB4F13429C for ; Tue, 19 Sep 2017 10:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 grffXAPBAzWS for ; Tue, 19 Sep 2017 10:49:54 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC388133085 for ; Tue, 19 Sep 2017 10:49:53 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v8JHnAEL018520 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Sep 2017 19:49:10 +0200 Received: from [2001:638:809:ff1f::8295:dc66] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1duMde-0006Jr-J6; Tue, 19 Sep 2017 19:48:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: partially unreliable quic streams From: "Philipp S. Tiesel" In-Reply-To: Date: Tue, 19 Sep 2017 19:49:10 +0200 Cc: Anja Feldmann , Joerg Ott , Mirko Palmer , QUIC WG , Balakrishnan Chandrasekaran Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 17:49:56 -0000 Hi Mikkel, as I wrote most of the draft, I=E2=80=99ll to answer your questions and = clarify some details.=20 > On 19. Sep 2017, at 09:21, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >=20 > Hi Anja und J=C3=B6rg >=20 >=20 > Regarding = https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-00 >=20 > I=E2=80=99m not sure where this draft fits into to the QUIC design = process process since my understanding is that unreliable streams is for = a later charter in the design process. I understand your criticism, but we decided to go forward and publish = our observations about unreliable streams. The QUIC WG was chartered to = exclude reliable streams from the first release to speed up the design = process. That does not mean unreliable streams are explicitly out of = scope for later releases. Therefore, I think that documenting how = unreliable streams fit into the current QUIC drafts are useful feedback = for the design process. As already stated in the draft announcement, the primary feedback is: a) unreliable streams can be added to QUIC as drafted so far =3D> No action required, current design is fine for that aspect b) one more flag bit in the stream header makes unreliable streams much = easier to implement =3D> As the problem also arose for other desirable features, = reserving a few bits in the stream frame header sounds like a good idea. > A quick read through the draft makes me wonder if you considering some = partial reliable ideas that have emerged out of the currently unfinished = concept of unidirectional streams and if you can incorporate these ideas = into your draft? >=20 > Essentially the idea is each stream is sequence of messages which are = reliable but suffer head of line blocking when each message is separated = by an application specific message header. In the simplest form the = stream is just one message. >=20 > For unreliable streams, the concept is inverted: each stream is a = single message which starts an application specific unreliable stream = identifier embedded in the stream/message. The ordering of messages is = given by the QUIC level stream id which always increases (effectively a = message id in this context) but there is no head of line blocking nor = any delivery ordering because each message is independent. >=20 > Thus the space consumed is the same for the two concepts but the = interpretation is different. I see unreliable streams and =E2=80=9Cstream as a message abstraction=E2=80= =9D as orthogonal concepts. In QUIC, streams are byte streams, not message streams. Thus, their content are completely oblivious to the transport layer. If you want a message abstraction on top of QUIC, you either send = exactly one message per stream or use your own framing. Whether the bytes of a stream are delivered reliable or not does not = change the head of line blocking problem when waiting for the message = delimiter. If the message delimiter is in =E2=80=9Ca hole" of the unreliable = stream, you either have to discard both messages or wait for = retransmission (which can still be done if the sender decides to). But with unreliable streams, you could search for complete messages in = the received parts after "a hole=E2=80=9D . =20 > An implementation can further cooperate by not retransmitting = sufficiently old or otherwise outdate messages. Currently QUIC has no = way to explicitly configure this and dropping retransmission of frames = might affect congestion control. Therefore in its current form QUIC = cannot properly unreliable streams, only prevent head of line blocking. The draft exactly discusses the design space for such a mechanism. It concludes that a mechanism to control retransmits, when = sender-controled, requires only few considerations at the wire-protocol = (e.g., requires not loosing FINs), but has much impact on the API used = by the application. I don=E2=80=99t see how dropping retransmissions effects congestion = control as the only inputs to CC are acked/lost packets and bytes send. > It is worth noting that with once message per stream there can be many = messages per packet which can significantly increase the messages per = second rate and therefore also requires efficiently management of stream = state - such as discarding send state immediately after sending FIN = (except retransmission machinery). This definitely is an issue of the =E2=80=9Cstream as a message = abstraction=E2=80=9D. It gets more ugly if combined with reliable streams as the =E2=80=9CFIN=E2= =80=9D of unreliable streams needs to be retransmitted to prevent stale = state (or =E2=80=9Czombie-streams=E2=80=9D, as we call in in the draft). As the recovery draft does not tell you how to retransmit the = retransmitable contents of a lost packet, closing a unreliable stream by = (re)transmitting the FIN only (as an empty stream frame with final = offset and FIN set) is fine. AVE! Philipp S. Tiesel From nobody Tue Sep 19 11:09:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE11342CA for ; Tue, 19 Sep 2017 11:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 f6KN4VZCK-Yw for ; Tue, 19 Sep 2017 11:09:45 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0288B134296 for ; Tue, 19 Sep 2017 11:09:44 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id g18so476986itg.5 for ; Tue, 19 Sep 2017 11:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yaeuXN3qp3VulVfehgy34QWNUyTN/W2cjVVSJoSqXCo=; b=Hl6SVBsJLKAnEMyVPwLf1rmhhqEgGBjuMjxLdDy0NKR9kcH7z7TfHlQ2DLA0dBdsah B1cpcnyA17oxNt3CWa8pMYvl6SWPU0gUdk2orTrWBjgRUn8sk8H7trXiZtia6EX/0dO7 h7cfWBgX8LzTbUuVFfTH8k1G2UfTJsT6RbTkRCPdUCZI0AMz3gcC2MhYEJDazfqvtuYM LobBYAYyx+ExJD+E25v2cDhVVrDmMBAGFwxVMKOBrpiF3zeGXmTs9K4tNeBKIg+hh0j1 ai/Ns6XImZDJ9cEJcWb1qR8TsOqUxBH7TsdL9TGQe//UkFuYnsAmFYeuDl5eECxvqKZy 6DSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yaeuXN3qp3VulVfehgy34QWNUyTN/W2cjVVSJoSqXCo=; b=Guh7YEdgwJFisweFXuAFzIT6OjJZ8loLauamh0ESc49pgRAyCCASA0OSQsS6Ws1KuL FvQSD6Q1MmxxyiQPmVqSrcZL4U4vgUCd3Ir7TdX7f6jQsmRZBas1rZr30Wev/kxqnrCt H7feQQ/F2QE/90CMR8gehwHM2jMylR35gUu6BTV9/k0/wsuAylpaUqt79/s+/ML1jHM8 7q4Wrsa2oDBgaRzT8F15avwEpdc+kVh+vDypWnwEO1qQGNmNFnXKLiX0GuUaSDlhBxV3 w8RbZI3K8AgRhVaNaatkNI2waBurhPNXS5879XZqVdQ6Ht/j60e6dw0VnXCyrixCPYiy 8R6w== X-Gm-Message-State: AHPjjUiA8RBl5jzCnB+qsQOM6v+7ahVOi2Lt3v3QfkbKGofWHpH6gCN2 RNTtfN5SsGR2+ph8UhHIqwSS6dCi6yUjuhTXnqDCABj1 X-Google-Smtp-Source: AOwi7QC6fqg4FEGWxHLLICqQG1+6AVXUivwhLLIE98WlC0k/oeakii2TifNSHDhpzolDC7VXWcqRrNqoge1GdH1ZuKs= X-Received: by 10.36.94.5 with SMTP id h5mr3075134itb.100.1505844584216; Tue, 19 Sep 2017 11:09:44 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Sep 2017 20:09:43 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 19 Sep 2017 20:09:43 +0200 Message-ID: Subject: Re: partially unreliable quic streams To: "Philipp S. Tiesel" Cc: Balakrishnan Chandrasekaran , Joerg Ott , QUIC WG , Mirko Palmer , Anja Feldmann Content-Type: multipart/alternative; boundary="001a114489a6878fab05598ec3e0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 18:09:48 -0000 --001a114489a6878fab05598ec3e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Philipp, thanks for getting back - I=E2=80=99m not really criticising no= r am I an official representative of the QUIC design body, I was just asking where this was fitting into the QUIC context. Just one clarification on message abstraction: The intention is not inherently to provide messages over streams as much as points where it makes sense to create holes as you mention (though this is also useful). However, dealing with holes in a stream, is more complicated than consider a stream broken up by messages, notably =E2=80=9Cvirtual stre= ams=E2=80=9D where each true stream is a message in the virtual, or partially reliable stream. I earlier made some design proposals on how to frame partial reliability. However, with the new unidirectional stream proposal, the same can be achieved much simpler by viewing streams as messages - where a message can be a video frame or whatever. This very transparently allows low-level machinery to deal with what is delivered and skipped because boundaries are communicated efficiently via separate streams. On the retransmission part of the message abstraction - this is definitely something that require additional protocol support to prevent zombies, as you say. The earlier design notes I added in comments can be found in these closed issues https://github.com/quicwg/base-drafts/issues/489 https://github.com/quicwg/base-drafts/issues/433 However, here each frame has a bit to indicate where a boundary in the stream begins, i.e. where a hole is permitted - the API becomes more complicated due to friction of concepts. I=E2=80=99m not saying what is the ideal solution - just that the message abstraction came out very naturally once Martin Thomson provided the unidirectional proposal. Ian Sweet hat earlier argued for similar use of light weight streams in bidi streams, but in my opinion they were to heavy weight because a sender must wait for the receiver to close the other end - with uni streams state can be purged must faster make the concept feasible at high frequencies. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 19 September 2017 at 19.49.31, Philipp S. Tiesel (phils@in-panik.de) wrote: Hi Mikkel, as I wrote most of the draft, I=E2=80=99ll to answer your questions and cla= rify some details. > On 19. Sep 2017, at 09:21, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > Hi Anja und J=C3=B6rg > > > Regarding https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-00 > > I=E2=80=99m not sure where this draft fits into to the QUIC design proces= s process since my understanding is that unreliable streams is for a later charter in the design process. I understand your criticism, but we decided to go forward and publish our observations about unreliable streams. The QUIC WG was chartered to exclude reliable streams from the first release to speed up the design process. That does not mean unreliable streams are explicitly out of scope for later releases. Therefore, I think that documenting how unreliable streams fit into the current QUIC drafts are useful feedback for the design process. As already stated in the draft announcement, the primary feedback is: a) unreliable streams can be added to QUIC as drafted so far =3D> No action required, current design is fine for that aspect b) one more flag bit in the stream header makes unreliable streams much easier to implement =3D> As the problem also arose for other desirable features, reserving a fe= w bits in the stream frame header sounds like a good idea. > A quick read through the draft makes me wonder if you considering some partial reliable ideas that have emerged out of the currently unfinished concept of unidirectional streams and if you can incorporate these ideas into your draft? > > Essentially the idea is each stream is sequence of messages which are reliable but suffer head of line blocking when each message is separated by an application specific message header. In the simplest form the stream is just one message. > > For unreliable streams, the concept is inverted: each stream is a single message which starts an application specific unreliable stream identifier embedded in the stream/message. The ordering of messages is given by the QUIC level stream id which always increases (effectively a message id in this context) but there is no head of line blocking nor any delivery ordering because each message is independent. > > Thus the space consumed is the same for the two concepts but the interpretation is different. I see unreliable streams and =E2=80=9Cstream as a message abstraction=E2=80= =9D as orthogonal concepts. In QUIC, streams are byte streams, not message streams. Thus, their content are completely oblivious to the transport layer. If you want a message abstraction on top of QUIC, you either send exactly one message per stream or use your own framing. Whether the bytes of a stream are delivered reliable or not does not change the head of line blocking problem when waiting for the message delimiter. If the message delimiter is in =E2=80=9Ca hole" of the unreliable stream, y= ou either have to discard both messages or wait for retransmission (which can still be done if the sender decides to). But with unreliable streams, you could search for complete messages in the received parts after "a hole=E2=80=9D . > An implementation can further cooperate by not retransmitting sufficiently old or otherwise outdate messages. Currently QUIC has no way to explicitly configure this and dropping retransmission of frames might affect congestion control. Therefore in its current form QUIC cannot properly unreliable streams, only prevent head of line blocking. The draft exactly discusses the design space for such a mechanism. It concludes that a mechanism to control retransmits, when sender-controled, requires only few considerations at the wire-protocol (e.g., requires not loosing FINs), but has much impact on the API used by the application. I don=E2=80=99t see how dropping retransmissions effects congestion control= as the only inputs to CC are acked/lost packets and bytes send. > It is worth noting that with once message per stream there can be many messages per packet which can significantly increase the messages per second rate and therefore also requires efficiently management of stream state - such as discarding send state immediately after sending FIN (except retransmission machinery). This definitely is an issue of the =E2=80=9Cstream as a message abstraction= =E2=80=9D. It gets more ugly if combined with reliable streams as the =E2=80=9CFIN=E2= =80=9D of unreliable streams needs to be retransmitted to prevent stale state (or =E2=80=9Czombie-streams=E2=80=9D, as we call in in the draft). As the recovery draft does not tell you how to retransmit the retransmitable contents of a lost packet, closing a unreliable stream by (re)transmitting the FIN only (as an empty stream frame with final offset and FIN set) is fine. AVE! Philipp S. Tiesel --001a114489a6878fab05598ec3e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi Philipp, thanks for getting back - I=E2=80=99m= not really criticising nor am I an official representative of the QUIC des= ign body, I was just asking where this was fitting into the QUIC context.

Just one clarification= on message abstraction:

The intention is not inherently to provide messages over streams as muc= h as points where it makes sense to create holes as you mention (though thi= s is also useful).=C2=A0 However, dealing with holes in a stream, is more c= omplicated than consider a stream broken up by messages, notably =E2=80=9Cv= irtual streams=E2=80=9D where each true stream is a message in the virtual,= or partially reliable stream.

I earlier made some design proposals on how to frame partial reli= ability. However, with the new unidirectional stream proposal, the same can= be achieved much simpler by viewing streams as messages - where a message = can be a video frame or whatever. This very transparently allows low-level = machinery to deal with what is delivered and skipped because boundaries are= communicated efficiently via separate streams.

On the retransmission part of the message abstra= ction - this is definitely something that require additional protocol suppo= rt to prevent zombies, as you say.

The earlier design notes I added in comments can be found in= these closed issues


However, here each frame has a = bit to indicate where a boundary in the stream begins, i.e. where a hole is= permitted - the API becomes more complicated due to friction of concepts.<= /div>

I=E2=80=99m not sayin= g what is the ideal solution - just that the message abstraction came out v= ery naturally once Martin Thomson provided the unidirectional proposal. Ian= Sweet hat earlier argued for similar use of light weight streams in bidi s= treams, but in my opinion they were to heavy weight because a sender must w= ait for the receiver to close the other end - with uni streams state can be= purged must faster make the concept feasible at high frequencies.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgens= en


On 19 September 2017 at = 19.49.31, Philipp S. Tiesel (phils@in-= panik.de) wrote:

Hi Mikkel,

as I wrote most of the draft, I=E2=80=99ll to answer your questions and= clarify some details. =20

> On 19. Sep 2017, at 09:21, Mikkel Fahn=C3=B8e J=C3=B8rgensen <<= a href=3D"mailto:mikkelfj@gmail.com">mikkelfj@gmail.com> wrote:
> =20
> Hi Anja und J=C3=B6rg
> =20
> =20
> Regarding https://tools.ietf.org/html/draft-tiesel-quic-unrel= iable-streams-00
> =20
> I=E2=80=99m not sure where this draft fits into to the QUIC design= process process since my understanding is that unreliable streams is for a= later charter in the design process.

I understand your criticism, but we decided to go forward and publish o= ur observations about unreliable streams. The QUIC WG was chartered to excl= ude reliable streams from the first release to speed up the design process.= That does not mean unreliable streams are explicitly out of scope for late= r releases. Therefore, I think that documenting how unreliable streams fit = into the current QUIC drafts are useful feedback for the design process.

As already stated in the draft announcement, the primary feedback is:
a) unreliable streams can be added to QUIC as drafted so far
=3D> No action required, current design is fine for that aspect
b) one more flag bit in the stream header makes unreliable streams much= easier to implement
=3D> As the problem also arose for other desirable features, rese= rving a few bits in the stream frame header sounds like a good idea.



> A quick read through the draft makes me wonder if you considering = some partial reliable ideas that have emerged out of the currently unfinish= ed concept of unidirectional streams and if you can incorporate these ideas= into your draft?
> =20
> Essentially the idea is each stream is sequence of messages which = are reliable but suffer head of line blocking when each message is separate= d by an application specific message header. In the simplest form the strea= m is just one message.
> =20
> For unreliable streams, the concept is inverted: each stream is a = single message which starts an application specific unreliable stream ident= ifier embedded in the stream/message. The ordering of messages is given by = the QUIC level stream id which always increases (effectively a message id i= n this context) but there is no head of line blocking nor any delivery orde= ring because each message is independent.
> =20
> Thus the space consumed is the same for the two concepts but the i= nterpretation is different.

I see unreliable streams and =E2=80=9Cstream as a message abstraction= =E2=80=9D as orthogonal concepts.

In QUIC, streams are byte streams, not message streams.
Thus, their content are completely oblivious to the transport layer.
If you want a message abstraction on top of QUIC, you either send exact= ly one message per stream or use your own framing.

Whether the bytes of a stream are delivered reliable or not does not ch= ange the head of line blocking problem when waiting for the message delimit= er.
If the message delimiter is in =E2=80=9Ca hole" of the unreliable = stream, you either have to discard both messages or wait for retransmission= (which can still be done if the sender decides to).
But with unreliable streams, you could search for complete messages in = the received parts after "a hole=E2=80=9D . =20


> An implementation can further cooperate by not retransmitting suff= iciently old or otherwise outdate messages. Currently QUIC has no way to ex= plicitly configure this and dropping retransmission of frames might affect = congestion control. Therefore in its current form QUIC cannot properly unre= liable streams, only prevent head of line blocking.

The draft exactly discusses the design space for such a mechanism.
It concludes that a mechanism to control retransmits, when sender-contr= oled, requires only few considerations at the wire-protocol (e.g., requires= not loosing FINs), but has much impact on the API used by the application.

I don=E2=80=99t see how dropping retransmissions effects congestion con= trol as the only inputs to CC are acked/lost packets and bytes send.



> It is worth noting that with once message per stream there can be = many messages per packet which can significantly increase the messages per = second rate and therefore also requires efficiently management of stream st= ate - such as discarding send state immediately after sending FIN (except r= etransmission machinery).

This definitely is an issue of the =E2=80=9Cstream as a message abstrac= tion=E2=80=9D.
It gets more ugly if combined with reliable streams as the =E2=80=9CFIN= =E2=80=9D of unreliable streams needs to be retransmitted to prevent stale = state (or =E2=80=9Czombie-streams=E2=80=9D, as we call in in the draft).
As the recovery draft does not tell you how to retransmit the retransmi= table contents of a lost packet, closing a unreliable stream by (re)transmi= tting the FIN only (as an empty stream frame with final offset and FIN set)= is fine.


AVE!
Philipp S. Tiesel
--001a114489a6878fab05598ec3e0-- From nobody Tue Sep 19 12:14:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4CC134378 for ; Tue, 19 Sep 2017 12:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Jv6In39PjVAp for ; Tue, 19 Sep 2017 12:14:35 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40B1134377 for ; Tue, 19 Sep 2017 12:14:34 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id o143so419800ywd.12 for ; Tue, 19 Sep 2017 12:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C0G2wfnNmPwCs4Io4qOertCBeoZol7XZnK3slvgA5A0=; b=MtP25TQNWKDx367olDd660cLe9khm45sg4LCX/xJFfZcTE5OrTGVjvjgsenDQl/1uA LXficzJ+rXgAd+gRtl4ze62FUJRe1/i1r8as6LwSDaw8pok7Un/tUF1S/BsuDnwxHPRl yhUJ/2NeZDRHUhveB7PvE3v7ker6mricDQj6y2IkywYJSFlBIunsZsfD3CveDz6vuRC/ 7PRNgWt4Jt+f5RTaC/3I+AXrRahiDUrClCPa+4ZnYL1SGxGGdzZDobhZXJqR/+DDmI+D gt2on38kRrdz/Lkq8HbcPaXCwhVhMrByYlx/pTWyvUIl+zF2iEgPfePNdzoF/6BGuzR/ q3GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C0G2wfnNmPwCs4Io4qOertCBeoZol7XZnK3slvgA5A0=; b=nKbotzgGMfAZyA6MHHStK+379q3JFRrrSD3KQ97HSFxcJQITrqZwZS3nqTf3mCDT9q qoMpgK0ElKVNZ2ItKusD7euEgCRhhyWTx4rXl5jBZq2WVoe4kIG8KqkghhLgVf/35rjP 7lNfTDcbVtWFNAvKyZRVGRWcQTVe9tiXLkxwGrtzMO1lTVOvqV4X0zfh9j47qvqMKpk6 S1gauBce47YKMBArL7eyathHT7GI5lhPlzAvrfYry5gDq2o/rHCc5Z6G4VCBTdSatlSe dKcYzhqmrmoIUf+4bfIH7OuJNe3c2gWJCMhWFg2cD5pHplYaM5ZR41hw1FraKqMgankB sUtg== X-Gm-Message-State: AHPjjUh20sCHjcfcx5HMUqDrDl1mexEPKOhe5gDO3AxEfmPPV+291qat sNTjg+esJuE/xIp2+gWBYTaRYqAfDgzJoFJ3udgWtHWt6BM= X-Google-Smtp-Source: AOwi7QC4SfUrmoRktOPDhQsMgdhMUPYEUUr0ti7LEPSCKMdbItkFpmE32okUzfaTIs8Lp78/vg1QoD0LFkxbuNsMmGQ= X-Received: by 10.13.211.67 with SMTP id v64mr1990103ywd.3.1505848473837; Tue, 19 Sep 2017 12:14:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Tue, 19 Sep 2017 12:14:33 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Tue, 19 Sep 2017 12:14:33 -0700 Message-ID: Subject: Re: Error reporting on handshake To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a114d64e65f1cca05598fab79" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 19:14:36 -0000 --001a114d64e65f1cca05598fab79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi J=C4=81nis, That's the only mechanism we have right now, so yes, a ConnectionClose frame in a Server Cleartext packet would be the way to send it. - jana On Wed, Sep 13, 2017 at 6:26 AM, J=C4=81nis =C4=8Coders wrote: > Hi, how should QUIC server respond while performing TLS handshake and > there is a server internal error - too many parallel authentications, > no memory or other? > Should it respond with ConnectionClose Frame encapsulated into > LongHeader-ServerCleartext or some other? > > Thank you > > -- > Ar cie=C5=86u, > J=C4=81nis =C4=8Coders > > --001a114d64e65f1cca05598fab79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0J=C4=81nis,

That's the only= mechanism we have right now, so yes, a ConnectionClose frame in a Server C= leartext packet would be the way to send it.

- jan= a

On W= ed, Sep 13, 2017 at 6:26 AM, J=C4=81nis =C4=8Coders <<= a href=3D"mailto:janis.coders@gmail.com" target=3D"_blank">janis.coders@gma= il.com> wrote:
Hi, how shou= ld QUIC server respond while performing TLS handshake and
there is a server internal error - too many parallel authentications,
no memory or other?
Should it respond with ConnectionClose Frame encapsulated into
LongHeader-ServerCleartext or some other?

Thank you

--
Ar cie=C5=86u,
J=C4=81nis =C4=8Coders


--001a114d64e65f1cca05598fab79-- From nobody Tue Sep 19 14:09:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BD51321CB for ; Tue, 19 Sep 2017 14:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 CiRbTSSSHDMf for ; Tue, 19 Sep 2017 14:09:25 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABC01321A4 for ; Tue, 19 Sep 2017 14:09:25 -0700 (PDT) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3FF613A0A1 for ; Tue, 19 Sep 2017 17:09:24 -0400 (EDT) Received: by mail-lf0-f54.google.com with SMTP id q132so866372lfe.5 for ; Tue, 19 Sep 2017 14:09:24 -0700 (PDT) X-Gm-Message-State: AHPjjUgQBwmD/QbHGNEL85rX7DOI4G64WYEa8ZGuJpmZtZxzDnEDGtp1 TT0APuH6w2dE9dKO/9kupyi0041HbtkczA/VDlw= X-Google-Smtp-Source: AOwi7QBPak7RqM8Z608Cf6uBv29bKlmZknYtmhhT5kFTMHpZf6uqqSnn1dxq9HnwPVLcXNCceCmERkDCg6LLBFZbcU4= X-Received: by 10.25.166.142 with SMTP id p136mr1063541lfe.213.1505855362928; Tue, 19 Sep 2017 14:09:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.200 with HTTP; Tue, 19 Sep 2017 14:09:22 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Tue, 19 Sep 2017 17:09:22 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Error reporting on handshake To: Jana Iyengar Cc: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= , QUIC WG Content-Type: multipart/alternative; boundary="001a114113e6fd966105599145f3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 21:09:26 -0000 --001a114113e6fd966105599145f3 Content-Type: text/plain; charset="UTF-8" https://github.com/quicwg/base-drafts/issues/608 --001a114113e6fd966105599145f3 Content-Type: text/html; charset="UTF-8" --001a114113e6fd966105599145f3-- From nobody Tue Sep 19 23:33:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9A013308F for ; Tue, 19 Sep 2017 23:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lax38tIyQjqD for ; Tue, 19 Sep 2017 23:33:18 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F3A1326ED for ; Tue, 19 Sep 2017 23:33:18 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id l15so3133973iol.8 for ; Tue, 19 Sep 2017 23:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8NEVoB+vE9dfRwPL2jfChmEFJigROkV1T89AKUAQ1jo=; b=SBV/LhlDxGKI3pXm9j6tNMiLb6Ml9nq4XPnRy/24OE9pak99A11eHtCie5aNSbIf6i 2KQDwbvNj2H3K8P5J7z0bqPP1WCbn5Chqya5unruB3fL/CusB6rfthfkCSGOG4LqToi5 xn/48Bobuf3ezFCQ3UV7VXiusW4f/7+/xVBnrrE+q+p8lLD+AYqSYCVt0y8j8UkSA7aC 9DCETimz95U43PdPZ5k6nMbZVG7++ArUIAEWucqc4mLFjjxKWnlC37g/NPkT0K44CCUc 8xwbNsKek1cv9zIlc82pyJnPW+513DpWQX9MNuJQ8WH951WxH4/c/hhaHDT5GLrjJ6DD 0/SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8NEVoB+vE9dfRwPL2jfChmEFJigROkV1T89AKUAQ1jo=; b=OHu5QKTfBIKKrUrc+U8NdaSO9UZW7QbSxnMqAkgbEFjHazPUNt4UG6e7U9AKpYMR+P ptq627Nz/IAsTw726dStX/wIcOPeF5E+Dv8cfgRrd1LGsDFh2e6DxmsKXpFZ8CeGP7Ub 2o34DYjqhHrZRwmcPo+eJuXLyclFRcgOQ3+mRgVUK8ujRcQhSwvppjqO9BpAsBnYXJMx W361Yvc8bJB5jBxGDqWaK3cRokudTkI+LCzZ2xUvi63mntVuhQDPzUewziJ0bAEvl4Gz U5692+QJcuHk/e8quNrZjB2qgG3BGx1SLQJByDIqXn0lEDKng/TuX8DB64JRXiHsTJub GwSw== X-Gm-Message-State: AHPjjUia4oqpvuMWhRjLyelLCRTfQHFYOehBFOBMLxpE1Wf2AqaqlZTk 58NJR5+3JEuAnIDtLhSr3yaArVeDhZZ0GZnHznA= X-Google-Smtp-Source: AOwi7QB5WiRq4QQYIEoEf4agUrFVvh2kB6byqRaSmb4sRn1dxwpLGyFEeRGUryAWUmwEF95OIb54qqp/GXLWUenok6w= X-Received: by 10.107.128.79 with SMTP id b76mr5923038iod.109.1505889197847; Tue, 19 Sep 2017 23:33:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.148 with HTTP; Tue, 19 Sep 2017 23:33:17 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Wed, 20 Sep 2017 09:33:17 +0300 Message-ID: Subject: Re: Error reporting on handshake To: Patrick McManus Cc: Jana Iyengar , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 06:33:22 -0000 Thank you On 20 September 2017 at 00:09, Patrick McManus wrote= : > https://github.com/quicwg/base-drafts/issues/608 > --=20 Ar cie=C5=86u, J=C4=81nis =C4=8Coders From nobody Wed Sep 20 01:39:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BBC133245 for ; Wed, 20 Sep 2017 01:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 iZsSvA5gUJew for ; Wed, 20 Sep 2017 01:39:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C7513307F for ; Wed, 20 Sep 2017 01:39:39 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-6c-59c2294970e9 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.2E.21299.94922C95; Wed, 20 Sep 2017 10:39:37 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 20 Sep 2017 10:39:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6iuZ4rSLiVtandSC1V//CAJa7TmELnP0MFWKejqXO74=; b=M45uSexyEbYhmCFLhlIIA2k9WZaB+Ye6YZZXyvb8YerDB8K3TWYQSIGTcazV43tYqG4GzX+RiMEtdgxPgziV0s7c9QNFJveuyMVaj+EATNiXyQY0Z6nth9BBIFuAQ+J2uShqKu5XjwZnUJTbi9ptuFzyvUzrvSyC/AgW/fR5I6E= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB0654.eurprd07.prod.outlook.com (10.141.44.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 08:39:16 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.011; Wed, 20 Sep 2017 08:39:16 +0000 From: Ingemar Johansson S To: Colin Perkins CC: QUIC IETF mailing list , Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , "Eggert, Lars (lars@netapp.com)" , marcelo bagnulo braun , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Piers O'Hanlon , "De Schepper, Koen (Nokia - BE/Antwerp)" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdMWaIZN+ofkuQeuQOGGa2om9/ikzQAFT3AABtrtZuA= Date: Wed, 20 Sep 2017 08:39:15 +0000 Message-ID: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> In-Reply-To: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB0654; 6:dFBv24aJtizvppcjg/q6iLJfE7FkFUbWa0Zn1vX69e7OQNSXjfEhP2zA4wNjw3bLIIQ2xIl3ZD7jCeUoFNZexU7Msn+Ch/a4ZY6dME66gJVsqBRHnj4bbc2RvnE9VWHL4cpJcln2sFlqrWmkXSHgnbCI7OZBtbSiJBQMuL7ikkb0PKW1lH1x82/b+tw+TpnT3nqz1OGNQyZn9PM++zgi2tTvx5PFxVE9/8kiizvoLnzccNGY7LgImWbjVikoEs+BLmXwoueX9qB5EvQJBvFJ2GJDC847AIYggHNBk8iU3QShM1X/KrI3g4R049blkvqYtQFprKM0QsvUEh14IQkzJQ==; 5:sjaz4vwBsK7WpUytFIW6ElRl6Fron6TzdAqbeCddrBbncQ+tCeDwEcX6fBYr0I17pamwFfulMXWkKgMjiTdkCJjr17ifzmtsojifR8bhqyH6Veu6fQGuxeP+NjO9alghYVINsD/ZbIqLGHCVFmFfDw==; 24:VSaQUbHDLdAsGZCZLA44WxSkPkqNNhymDEld1/6hfLezmKbfeqK7kPi2HylS1ZkPOIYv2SGsNma7lNKeTwQzMdAisvzHhGuIqGcZDrtxv7g=; 7:pbPCWSzB7maHDswVO2A/Gak6cvl4GiDvpu8DSeYk0/3CGyZKuHra3iIpxoZJyv0UHxiAdK4pbEiiv8QLgcQOngzGi4FY+V51W7zl7J5ohhu3xj2GNeIslo1Z3TQ3TmRkAYzmuCbaf+f41zA4Llj0NT9uJIh59pGQYcl2Uj/sUuApcKHJ3RGYSHOwQoNsg7LG37OzXZbmvh2DeZMh1Tq3I7bh0vF0gUwSQAujOtPKco8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ea99d325-910d-479e-7084-08d5000313d6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB0654; x-ms-traffictypediagnostic: DB4PR07MB0654: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-exchange-antispam-report-test: UriScan:(37575265505322)(89211679590171)(202460600054446)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB0654; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB0654; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(189002)(24454002)(199003)(101416001)(53546010)(53936002)(99286003)(8666007)(14454004)(106356001)(105586002)(236005)(33656002)(9686003)(55016002)(6306002)(54896002)(7736002)(3280700002)(2900100001)(3660700001)(74316002)(2906002)(81166006)(81156014)(8676002)(189998001)(66066001)(9326002)(7116003)(5660300001)(7696004)(8936002)(2950100002)(3480700004)(229853002)(6916009)(3846002)(6436002)(68736007)(6506006)(102836003)(6116002)(790700001)(4326008)(97736004)(478600001)(606006)(966005)(6246003)(45080400002)(316002)(19609705001)(54906003)(25786009)(5250100002)(50986999)(54356999)(76176999)(86362001)(15409205003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0654; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348F7E2CFAF1574F838ED8CC2610DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 08:39:15.8328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0654 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUwTURSGvZ2lU7DJtWo4oiTSiAEjoIg6MUjEp9GI8UET4AUrjEBks0UF lwjVFi2oYCgRtxbZQn0ooCBxizTKEhFRVNwbQIhsBhBQIRQ7HUh4+875/z//yc1lCMUI5ckk JKfx6mRVopJ2I4siHoD/Lj9b5IapW0q2or8ZsY2TZRL252Auyep6LTRbdbeAZGv09yh2MLcH sblmd7arUIt2yLgBezvFzVyoI7lCu53mSkv/SbjJzmqK09XPSLlrY+M0p528Q3ONIxP0PlmU W0gsn5hwnFcHhh50izcZbkhTy9tQel3rgUw01IwMiGEAB0NOm5cBuTEK/BxBd2UfaUAy59CM oKQ6UhBIfImALyZBEFxGCbQ+myLEwY7gXXkvIURoHAKVtj9I4GXYB+qbHEgwEfgcCdmFekoQ lmIAc+NViWhaAb/GdaTI26BY90QqMOkM55UVufZyHAUD73SU2JaPwGjpdwkyHAb5FytpgRH2 Avuf7649gT3g8w+TqwAwhtLHrwmRl0N/j4MSeTV8qWgiRfaCt6Yc16WA9VIwfnLMBQKgNn8Y iRwOtS9aKdHULYGv+WIz4HWgdWQi8YoYGPt0aa7hCMy8aZDM85v2YVIMv6Sg+W/enLAKHjlu S/LQ+usLLhc5Bbp/GsjrridYAi1FP5zMOPd+YH0YKFq8oSCnSyqyL+hu3pIu3JuR1IKWa3jN oaS4oE0BvDohRqNJSQ5I5tNqkPMfNtyf9qlHHUNhNoQZpFwsfx/dEKmgVMc1GUk2BAyhXCZ3 X2OLVMhjVRkneXVKtPpYIq+xoZUMqfSQhz1tj1DgOFUaf4TnU3n1vCphZJ6Z6HxXRnD64CJ6 to+xdsZvXrtiOPaGOXv0yuzhq+da9gfqx0dPff1W0vYsKOtRxkxUx+mdeNq2uHb7x1UpBYMb tWmpXFXosIe5paPud4l5OlDv++rBC8uW2dL0gaVnP2yd3pNrDfefGDJ67x01WHtad19G7mXf jp6xZFq0VdYTWTJjsZLUxKs2riPUGtV/JQ83T4MDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 08:39:43 -0000 --_000_DB4PR07MB348F7E2CFAF1574F838ED8CC2610DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KQW5kIHNvcnJ5IGZvciB0aGUgc2xvdGgtaXNoIHJlc3BvbnNlICh5b3Ugc2hvdWxkIHNl ZSBtZSB0eXBlICBhIHRleHQgbWVzc2FnZS4uKS4NClRvIHN1bW1hcml6ZSB0aGUgdHdvIG1haW4g cXVlc3Rpb25zDQoNCg0KICAxLiAgRUNOIGluIEFDSyBmcmFtZSBvciBpbiBhIHNlcGFyYXRlIGZy YW1lIDogR2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGFuZCBmZWFyIHRo YXQgdGhlIEFDSyBmcmFtZSBpcyBhbHJlYWR5IGVub3VnaCBjb21wbGV4LCBpdCBzZWVtcyB1bndp c2UgdG8gdHJ5IHRvIGNyYW0gaW4gYWRkaXRpb25hbCBpbmZvIGluIHRoZSBBQ0sgZnJhbWVzLiBT byBteSBwZXJzb25hbCBmZWVsaW5nIGlzIHRoYXQgd2Ugc2hvdWxkIHVzZSBhIHNlcGFyYXRlIGZy YW1lIHR5cGUgZm9yIEVDTiAsIGJ1dCB0aGlzIGZyYW1lIHR5cGUgbXVzdCBiZSBhIE1VU1QgdG8g aW1wbGVtZW50IGFuZCBzdXBwb3J0ICEgQ29tbWVudHMgYXJlIHZlcnkgd2VsY29tZS4NCiAgMi4g IEFzIHJlZ2FyZHMgdG8gdGhlIGxldmVsIG9mIGRldGFpbCA6IFRoZXJlIGFyZSBwcm9zIGFuZCBj b25zIHdpdGggYm90aCBhbHRlcm5hdGl2ZXMgKG1hcmtlZCBieXRlcyBvciBkZXRhaWxlZCBpbmRp Y2F0aW9uKS4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhlIG9waW5pb25zIGZyb20gb3RoZXJzIGFz IHdlbGwgb24gdGhpcyBtYXR0ZXIgLg0KDQovSW5nZW1hcg0KDQpGcm9tOiBDb2xpbiBQZXJraW5z IFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQpTZW50OiBkZW4gMTYgYXVndXN0aSAyMDE3IDEy OjUzDQpUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb20+DQpDYzogUVVJQyBJRVRGIG1haWxpbmcgbGlzdCA8cXVpY0BpZXRmLm9yZz47IE1hZ251 cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+OyBCb2IgQnJpc2Nv ZSAocmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQpIDxyZXNlYXJjaEBib2JicmlzY29lLm5ldD47IFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgRWdnZXJ0LCBMYXJz IChsYXJzQG5ldGFwcC5jb20pIDxsYXJzQG5ldGFwcC5jb20+OyBtYXJjZWxvIGJhZ251bG8gYnJh dW4gPG1hcmNlbG9AaXQudWMzbS5lcz47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdp bmRAdGlrLmVlLmV0aHouY2g+OyBQaWVycyBPJ0hhbmxvbiA8cGllcnMub2hhbmxvbkBjcy5veC5h Yy51az47IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApIDxrb2VuLmRlX3Nj aGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20+DQpTdWJqZWN0OiBSZTogRUNOIGluIFFVSUMNCg0K DQpPbiAxNiBBdWcgMjAxNywgYXQgMTA6MzMsIEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIu cy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNz c29uLmNvbT4+IHdyb3RlOg0KDQpIaQ0KDQpGaW5hbGx5IGJhY2sgZnJvbSB2YWNhdGlvbiwgYW5k IHZlcnkgZ3JhdGVmdWwgZm9yIHRoZSBzdXBwb3J0IHRvIGNvbnRpbnVlIHRoZSB3b3JrIHRvIGFk ZCBFQ04gaW4gUVVJQy4NCkp1c3QgdG8gcmVjYXAuLiB0aGVyZSB3ZXJlIHR3byBtYWluIHRvcGlj cyByYWlzZWQgYXQgdGhlIG1lZXRpbmcNCg0KMSkgRUNOIGluZm8gaW4gQUNLIGZyYW1lIG9yIGlu IGRlZGljYXRlZCBmcmFtZSA6IFRoZXJlIHdlcmUgY29uY2VybnMgYWJvdXQgYWRkaW5nIGV4dHJh IGNvbXBsZXhpdHkgaW4gYW4gYWxyZWFkeSBwb3RlbnRpYWxseSBjb21wbGV4IEFDSyBmcmFtZSwg b25lIGNhbiBoYXZlIGRpZmZlcmluZyBvcGluaW9ucyBhYm91dCB0aGUgY29tcGxleGl0eSBidXQg Y2FuIHVuZGVyc3RhbmQgdGhlIGNvbmNlcm5zLiBBcyBmYXIgYXMgSSBhbSBjb25jZXJuZWQsIGEg c2VwYXJhdGUgZnJhbWUgdHlwZSBmb3IgRUNOIGlzIHBvc3NpYmxlLCBwb3NzaWJseSBvbmUgbmVl ZCB0byBhZGQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGFtb3VudCBvZiBub3QtRUNUIG1hcmtlZCBw YWNrZXRzIGFzIHdlbGwgdG8ga2VlcCB0aGUgc2lnbmFsaW5nIHJvYnVzdCwgdGhpcyBuZWVkcyBm dXJ0aGVyIGludmVzdGlnYXRpb24gdGhvdWdoLiBPbmUgY29uY2VybiB3aXRoIGEgc2VwYXJhdGUg RUNOIGZyYW1lIGlzIHRoYXQgaXQgYmVjb21lcyBhIG5vdC1pbXBsZW1lbnRlZCBvciBvcHRpb25h bCBmZWF0dXJlLCBpcyB0aGVyZSBhbnkgcmVhc29uIHRvIGJlIHdvcnJpZWQgYWJvdXQgdGhpcyA/ DQoNCjIpIE1vcmUgZGV0YWlsZWQgRUNOIGluZm9ybWF0aW9uIDogRWFybGllciB2ZXJzaW9ucyBv ZiB0aGUgRUNOIGluIFFVSUMgZHJhZnQgKHNlZWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJh ZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dCApIHByb3ZpZGVkIHdpdGggZXhhbXBsZXMuIFdl IChNeXNlbGYsIEtvZW4sIE1pcmphIGFuZCBQcmF2ZWVuKSBkaXNjdXNzZWQgdGhpcyBhbmQgd2Ug Y291bGQgbm90IGNvbWUgdXAgd2l0aCBhbnkgdXNlIGNhc2Ugd2hlcmUgaXQgaXMgYmVuZWZpY2lh bCB0byBrbm93IGV4YWN0bHkgaG93IGVhY2ggcGFja2V0IGlzIEVDTiBtYXJrZWQuIEkga25vdyB0 aGF0IHRoaXMga2luZCBvZiBkZXRhaWxlZCBFQ04gaW5mb3JtYXRpb24gaXMgc3VnZ2VzdGVkIGZv ciB0aGUgZ2VuZXJpYyBmZWVkYmFjayBmb3IgUk1DQVQgYW5kIEkgcGVyc29uYWxseSBoYXZlIGEg cHJvYmxlbSB0byBzZWUgdGhlIGdhaW4gd2l0aCB0aGUgZGV0YWlsZWQgRUNOIGluZm9ybWF0aW9u IGFsc28gaGVyZS4gSW5wdXQgZnJvbSBvdGhlcnMgaXMgdmVyeSB3ZWxjb21lIGhlcmUuDQoNCkZv ciB0aGUgUk1DQVQgZm9ybWF0LCB3ZSB3YW50ZWQgcGVyLXBhY2tldCBsb3NzIGFuZCB0aW1pbmcg aW5mb3JtYXRpb24sIGFuZCBpdCB3YXMgYXMgZWFzeSB0byBmZWVkYmFjayBwZXItcGFja2V0IEVD TiBpbmZvcm1hdGlvbiBhbG9uZyB3aXRoIGl0IGFzIHRvIGRlc2lnbiBzb21ldGhpbmcgZGlmZmVy ZW50Lg0KDQpBIGJlbmVmaXQgb2YgcGVyLXBhY2tldCBFQ04gbWFya2luZyBjb3VsZCBiZSB0byBh bGxvdyBhIGNvbmdlc3Rpb24gY29udHJvbGxlciB0aGF0IHJlYWN0ZWQgZGlmZmVyZW50bHkgdG8g YnVyc3RzIG9mIGNvbnNlY3V0aXZlIEVDTiBtYXJrcyB0aGFuIGl0IGRpZCB0byBpc29sYXRlZCBF Q04gbWFya3MsIGdpdmVuIHRoZSBzYW1lIGZyYWN0aW9uIG9mIG1hcmtlZCBwYWNrZXRzIChpLmUu LCB0aGF0IHJlYWN0ZWQgdG8gRUNOIG1hcmtpbmcgZXZlbnRzIHJhdGhlciB0aGFuIEVDTiBtYXJr aW5nIHJhdGUsIGxpa2UgaG93IFRDUCByZXNwb25kcyB0byBsb3NzIGV2ZW50cykuIEkgZG9u4oCZ dCB0aGluayB3ZSBoYXZlIHN1Y2ggYSB0aGluZywgYnV0IGNlcnRhaW5seSBpbiB0aGUgY29udGV4 dCBvZiBSTUNBVCB3aGVyZSB3ZeKAmXJlIGV4cGVyaW1lbnRpbmcgd2l0aCBub3ZlbCBjb25nZXN0 aW9uIGNvbnRyb2wgc2NoZW1lcyBmb3IgdHJhZmZpYyB0aGF0IGhhcyB2ZXJ5IGRpZmZlcmVudCBj aGFyYWN0ZXJpc3RpY3MgdG8gdHJhZGl0aW9uYWwgYnVsayBmbG93cywgaXQgbWlnaHQgYmUgcGxh dXNpYmxlLiBQZXItcGFja2V0IG1hcmtpbmcgaW5mb3JtYXRpb24gaXMgYWxzbyB1c2VmdWwgZm9y IHRyb3VibGVzaG9vdGluZy4NCg0KQ2VydGFpbmx5IHdlIG5lZWQgdG8ga25vdyBudW1iZXIgb2Yg Tm90RUNULCBFQ1QoMCksIEVDVCgxKSwgYW5kIEVDTi1DRSBtYXJrcyBzaW5jZSB0aGUgbGFzdCBy ZXBvcnQsIGJ1dCBJIGd1ZXNzIHRoYXTigJlzIGFscmVhZHkgcG9zc2libGUuDQoNCkNoZWVycywN CkNvbGluDQoNCg0KDQoNCg0KVGhlcmUgYXJlIGEgY29uc2VxdWVuY2VzIHdpdGggZGV0YWlsZWQg RUNOIG1hcmtpbmcgaW5mb3JtYXRpb24uDQphKSBuZWNlc3NhcnkgdG8gY29ycmVsYXRlIHdpdGgg dGhlIGxpc3Qgb2YgdHJhbnNtaXR0ZWQgcGFja2V0cywgdGhpcyBpbmNyZWFzZXMgYW1vdW50IG9m IGNvZGUgb24gc2VuZGVyIHNpZGUsIG5vdCBzdXJlIG9mIHRoYXQgaXMgYSBsYXJnZSBjb25jZXJu IGFzIGxvb2t1cCBpcyBhbnl3YXkgbmVlZGVkIHRvIHByb2Nlc3MgaW5jb21pbmcgQUNLcw0KYikg bmVjZXNzYXJ5IHRvIGVtYmVkIEVDTiBpbmZvcm1hdGlvbiBpbiBBQ0sgZnJhbWUgPywgYXQgbGVh c3QgdGhpcyB3YXMgbXkgY29uY2x1c2lvbiB3aGVuIEkgZGV2aXNlZCB0aGUgZGV0YWlsZWQgRUNO IG1hcmtpbmcgaW5mbyBpbiB0aGUgMDEgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQoNCkNvbW1lbnRz IGFyZSB3ZWxjb21lDQovSW5nZW1hcg0KDQoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KSW5nZW1hciBKb2hhbnNzb24gIE0uU2MuDQpNYXN0ZXIgUmVzZWFyY2hlcg0KDQpF cmljc3NvbiBBQg0KV2lyZWxlc3MgQWNjZXNzIE5ldHdvcmtzDQpMYWJyYXRvcmllZ3LDpG5kIDEx DQo5NzEgMjgsIEx1bGXDpSwgU3dlZGVuDQpQaG9uZSArNDYtMTA3MSA0MzA0Mg0KU01TL01NUyAr NDYtNzMgMDc4IDMyODkNCmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpp bmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCnd3dy5lcmljc3Nvbi5jb208eC1tc2c6 Ly8xMDMvd3d3LmVyaWNzc29uLmNvbT4NCg0KQSBtaXN0YWtlIGlzIHRvIGNvbW1pdCBhIG1pc3Vu ZGVyc3RhbmRpbmcNCiAgICAgICAgICAgICAgICAgICAgIEJvYiBEeWxhbg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KLS0NCkNvbGluIFBlcmtpbnMNCmh0dHBzOi8v Y3NwZXJraW5zLm9yZy8NCg0KDQoNCg== --_000_DB4PR07MB348F7E2CFAF1574F838ED8CC2610DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjIwMzAxMzIyNTc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4NjQwMjMxMDQgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmQgc29ycnkgZm9yIHRoZSBzbG90aC1pc2ggcmVzcG9uc2UgKHlvdSBzaG91 bGQgc2VlIG1lIHR5cGUmbmJzcDsgYSB0ZXh0IG1lc3NhZ2UuLikuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBzdW1tYXJpemUgdGhlIHR3byBtYWluIHF1ZXN0aW9uczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPkVDTiBpbiBBQ0sgZnJhbWUgb3IgaW4gYSBzZXBhcmF0ZSBmcmFtZSA6IEdp dmVuIHRoZSByZWNlbnQgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBhbmQgZmVhciB0aGF0IHRoZSBB Q0sgZnJhbWUgaXMgYWxyZWFkeSBlbm91Z2ggY29tcGxleCwgaXQgc2VlbXMgdW53aXNlIHRvIHRy eSB0byBjcmFtIGluIGFkZGl0aW9uYWwNCiBpbmZvIGluIHRoZSBBQ0sgZnJhbWVzLiBTbyBteSBw ZXJzb25hbCBmZWVsaW5nIGlzIHRoYXQgd2Ugc2hvdWxkIHVzZSBhIHNlcGFyYXRlIGZyYW1lIHR5 cGUgZm9yIEVDTiAsIGJ1dCB0aGlzIGZyYW1lIHR5cGUgbXVzdCBiZSBhIE1VU1QgdG8gaW1wbGVt ZW50IGFuZCBzdXBwb3J0ICEgQ29tbWVudHMgYXJlIHZlcnkgd2VsY29tZS48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj5BcyByZWdhcmRzIHRvIHRoZSBsZXZlbCBvZiBkZXRhaWwg OiBUaGVyZSBhcmUgcHJvcyBhbmQgY29ucyB3aXRoIGJvdGggYWx0ZXJuYXRpdmVzIChtYXJrZWQg Ynl0ZXMgb3IgZGV0YWlsZWQgaW5kaWNhdGlvbikuIEkgd291bGQgbGlrZSB0byBoZWFyIHRoZSBv cGluaW9ucyBmcm9tIG90aGVycyBhcyB3ZWxsIG9uIHRoaXMNCiBtYXR0ZXIgLjxvOnA+PC9vOnA+ PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IENvbGluIFBl cmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10gPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAx NiBhdWd1c3RpIDIwMTcgMTI6NTM8YnI+DQo8Yj5Ubzo8L2I+IEluZ2VtYXIgSm9oYW5zc29uIFMg Jmx0O2luZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g UVVJQyBJRVRGIG1haWxpbmcgbGlzdCAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hZ251cyBXZXN0 ZXJsdW5kICZsdDttYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20mZ3Q7OyBCb2IgQnJpc2Nv ZSAocmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQpICZsdDtyZXNlYXJjaEBib2JicmlzY29lLm5ldCZn dDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0Ozsg RWdnZXJ0LCBMYXJzIChsYXJzQG5ldGFwcC5jb20pICZsdDtsYXJzQG5ldGFwcC5jb20mZ3Q7Ow0K IG1hcmNlbG8gYmFnbnVsbyBicmF1biAmbHQ7bWFyY2Vsb0BpdC51YzNtLmVzJmd0OzsgTWlyamEg S8O8aGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCZndDs7IFBpZXJz IE8nSGFubG9uICZsdDtwaWVycy5vaGFubG9uQGNzLm94LmFjLnVrJmd0OzsgRGUgU2NoZXBwZXIs IEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCkgJmx0O2tvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVs bC1sYWJzLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEVDTiBpbiBRVUlDPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNiBBdWcgMjAxNywgYXQg MTA6MzMsIEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFyLnMu am9oYW5zc29uQGVyaWNzc29uLmNvbSI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IlNWIj5IaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaW5hbGx5 IGJhY2sgZnJvbSB2YWNhdGlvbiwgYW5kIHZlcnkgZ3JhdGVmdWwgZm9yIHRoZSBzdXBwb3J0IHRv IGNvbnRpbnVlIHRoZSB3b3JrIHRvIGFkZCBFQ04gaW4gUVVJQy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3QgdG8gcmVjYXAuLiB0aGVyZSB3 ZXJlIHR3byBtYWluIHRvcGljcyByYWlzZWQgYXQgdGhlIG1lZXRpbmc8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgRUNOIGluZm8gaW4gQUNL IGZyYW1lIG9yIGluIGRlZGljYXRlZCBmcmFtZSA6IFRoZXJlIHdlcmUgY29uY2VybnMgYWJvdXQg YWRkaW5nIGV4dHJhIGNvbXBsZXhpdHkgaW4gYW4gYWxyZWFkeSBwb3RlbnRpYWxseSBjb21wbGV4 IEFDSyBmcmFtZSwgb25lIGNhbiBoYXZlIGRpZmZlcmluZyBvcGluaW9ucyBhYm91dCB0aGUgY29t cGxleGl0eSBidXQgY2FuIHVuZGVyc3RhbmQgdGhlIGNvbmNlcm5zLiBBcyBmYXINCiBhcyBJIGFt IGNvbmNlcm5lZCwgYSBzZXBhcmF0ZSBmcmFtZSB0eXBlIGZvciBFQ04gaXMgcG9zc2libGUsIHBv c3NpYmx5IG9uZSBuZWVkIHRvIGFkZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYW1vdW50IG9mIG5v dC1FQ1QgbWFya2VkIHBhY2tldHMgYXMgd2VsbCB0byBrZWVwIHRoZSBzaWduYWxpbmcgcm9idXN0 LCB0aGlzIG5lZWRzIGZ1cnRoZXIgaW52ZXN0aWdhdGlvbiB0aG91Z2guIE9uZSBjb25jZXJuIHdp dGggYSBzZXBhcmF0ZSBFQ04gZnJhbWUNCiBpcyB0aGF0IGl0IGJlY29tZXMgYSBub3QtaW1wbGVt ZW50ZWQgb3Igb3B0aW9uYWwgZmVhdHVyZSwgaXMgdGhlcmUgYW55IHJlYXNvbiB0byBiZSB3b3Jy aWVkIGFib3V0IHRoaXMgPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4yKSBNb3JlIGRldGFpbGVkIEVDTiBpbmZvcm1hdGlvbiA6IEVhcmxpZXIg dmVyc2lvbnMgb2YgdGhlIEVDTiBpbiBRVUlDIGRyYWZ0IChzZWU8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtam9oYW5z c29uLXF1aWMtZWNuLTAxLnR4dDwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPikNCiBwcm92aWRlZCB3aXRoIGV4YW1wbGVzLiBXZSAoTXlz ZWxmLCBLb2VuLCBNaXJqYSBhbmQgUHJhdmVlbikgZGlzY3Vzc2VkIHRoaXMgYW5kIHdlIGNvdWxk IG5vdCBjb21lIHVwIHdpdGggYW55IHVzZSBjYXNlIHdoZXJlIGl0IGlzIGJlbmVmaWNpYWwgdG8g a25vdyBleGFjdGx5IGhvdyBlYWNoIHBhY2tldCBpcyBFQ04gbWFya2VkLiBJIGtub3cgdGhhdCB0 aGlzIGtpbmQgb2YgZGV0YWlsZWQgRUNOIGluZm9ybWF0aW9uIGlzIHN1Z2dlc3RlZCBmb3INCiB0 aGUgZ2VuZXJpYyBmZWVkYmFjayBmb3IgUk1DQVQgYW5kIEkgcGVyc29uYWxseSBoYXZlIGEgcHJv YmxlbSB0byBzZWUgdGhlIGdhaW4gd2l0aCB0aGUgZGV0YWlsZWQgRUNOIGluZm9ybWF0aW9uIGFs c28gaGVyZS4gSW5wdXQgZnJvbSBvdGhlcnMgaXMgdmVyeSB3ZWxjb21lIGhlcmUuDQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Gb3IgdGhlIFJNQ0FUIGZvcm1hdCwgd2Ugd2FudGVkIHBlci1wYWNrZXQg bG9zcyBhbmQgdGltaW5nIGluZm9ybWF0aW9uLCBhbmQgaXQgd2FzIGFzIGVhc3kgdG8gZmVlZGJh Y2sgcGVyLXBhY2tldCBFQ04gaW5mb3JtYXRpb24gYWxvbmcgd2l0aCBpdCBhcyB0byBkZXNpZ24g c29tZXRoaW5nIGRpZmZlcmVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QSBiZW5lZml0IG9mIHBlci1wYWNrZXQgRUNOIG1hcmtpbmcgY291 bGQgYmUgdG8gYWxsb3cgYSBjb25nZXN0aW9uIGNvbnRyb2xsZXIgdGhhdCByZWFjdGVkIGRpZmZl cmVudGx5IHRvIGJ1cnN0cyBvZiBjb25zZWN1dGl2ZSBFQ04gbWFya3MgdGhhbiBpdCBkaWQgdG8g aXNvbGF0ZWQgRUNOIG1hcmtzLCBnaXZlbiB0aGUgc2FtZSBmcmFjdGlvbiBvZiBtYXJrZWQgcGFj a2V0cyAoaS5lLiwgdGhhdCByZWFjdGVkIHRvDQogRUNOIG1hcmtpbmcgZXZlbnRzIHJhdGhlciB0 aGFuIEVDTiBtYXJraW5nIHJhdGUsIGxpa2UgaG93IFRDUCByZXNwb25kcyB0byBsb3NzIGV2ZW50 cykuIEkgZG9u4oCZdCB0aGluayB3ZSBoYXZlIHN1Y2ggYSB0aGluZywgYnV0IGNlcnRhaW5seSBp biB0aGUgY29udGV4dCBvZiBSTUNBVCB3aGVyZSB3ZeKAmXJlIGV4cGVyaW1lbnRpbmcgd2l0aCBu b3ZlbCBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lcyBmb3IgdHJhZmZpYyB0aGF0IGhhcyB2ZXJ5 IGRpZmZlcmVudA0KIGNoYXJhY3RlcmlzdGljcyB0byB0cmFkaXRpb25hbCBidWxrIGZsb3dzLCBp dCBtaWdodCBiZSBwbGF1c2libGUuIFBlci1wYWNrZXQgbWFya2luZyBpbmZvcm1hdGlvbiBpcyBh bHNvIHVzZWZ1bCBmb3IgdHJvdWJsZXNob290aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DZXJ0YWlubHkgd2UgbmVlZCB0byBrbm93IG51 bWJlciBvZiBOb3RFQ1QsIEVDVCgwKSwgRUNUKDEpLCBhbmQgRUNOLUNFIG1hcmtzIHNpbmNlIHRo ZSBsYXN0IHJlcG9ydCwgYnV0IEkgZ3Vlc3MgdGhhdOKAmXMgYWxyZWFkeSBwb3NzaWJsZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29s aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlcmUgYXJlIGEgY29uc2VxdWVuY2VzIHdpdGggZGV0YWlsZWQgRUNOIG1hcmtpbmcg aW5mb3JtYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5hKSBuZWNlc3NhcnkgdG8gY29ycmVsYXRlIHdpdGggdGhlIGxpc3Qgb2YgdHJhbnNt aXR0ZWQgcGFja2V0cywgdGhpcyBpbmNyZWFzZXMgYW1vdW50IG9mIGNvZGUgb24gc2VuZGVyIHNp ZGUsIG5vdCBzdXJlIG9mIHRoYXQgaXMgYSBsYXJnZSBjb25jZXJuIGFzIGxvb2t1cCBpcyBhbnl3 YXkgbmVlZGVkIHRvIHByb2Nlc3MgaW5jb21pbmcgQUNLczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YikgbmVjZXNzYXJ5IHRvIGVtYmVkIEVDTiBp bmZvcm1hdGlvbiBpbiBBQ0sgZnJhbWUgPywgYXQgbGVhc3QgdGhpcyB3YXMgbXkgY29uY2x1c2lv biB3aGVuIEkgZGV2aXNlZCB0aGUgZGV0YWlsZWQgRUNOIG1hcmtpbmcgaW5mbyBpbiB0aGUgMDEg dmVyc2lvbiBvZiB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzIGFyZSB3ZWxjb21lPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hcjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5JbmdlbWFyIEpvaGFuc3NvbiZuYnNwOyBNLlNjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1hc3Rl ciBSZXNlYXJjaGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+RXJp Y3Nzb24gQUI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XaXJlbGVzcyBBY2Nlc3MgTmV0d29ya3M8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5MYWJyYXRvcmllZ3LDpG5kIDExPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+OTcxIDI4LCBM dWxlw6UsIFN3ZWRlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlBob25lICYjNDM7NDYtMTA3MSA0MzA0Mjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlNNUy9NTVMgJiM0Mzs0Ni03MyAwNzggMzI4OTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1h aWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ieC1tc2c6Ly8xMDMv d3d3LmVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+d3d3LmVyaWNzc29uLmNvbTwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6I0NDQ0NERCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMzMzMzMzO2JhY2tncm91bmQ6d2hpdGUiPkEgbWlzdGFrZSBpcyB0byBjb21taXQgYSBt aXN1bmRlcnN0YW5kaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+PGJyPg0K PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCb2IgRHlsYW48YnI+DQo8L3Nw YW4+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KLS0mbmJzcDs8YnI+DQpD b2xpbiBQZXJraW5zPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jc3BlcmtpbnMub3JnLyI+aHR0cHM6 Ly9jc3BlcmtpbnMub3JnLzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB4PR07MB348F7E2CFAF1574F838ED8CC2610DB4PR07MB348eurprd_-- From nobody Wed Sep 20 05:41:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF8F13314B for ; Wed, 20 Sep 2017 05:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 7lgXqEAuL9DZ for ; Wed, 20 Sep 2017 05:41:26 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4F6132D8A for ; Wed, 20 Sep 2017 05:41:26 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id q80so1787438ywg.2 for ; Wed, 20 Sep 2017 05:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LbBn38hE6seJc43f56mwFAMBxFTtvWqBR6+3Xyq5xUQ=; b=M8TAxyvYw6thFpbfm2dFu3qFYABaGxgt3U4gQh9uIclYvnjflJ9nexSaWxrGdTAE18 m5rVjsVFd4hgXbrJ3zFkolpSKvX5KyBMkj0bi7Q1UtFMnzdbqbZqV6M0ZC1T8nt4ZfYy CipkrGCoJjaTi2XQupckIoKI9e6SV+CBSEZTXY8oNSFNyMQEApTHiLgaLcuG4Wdtug7T wjNX7MvUR49jDmxOs2zhfzp8KGGuMCwFaCOLWfWCs2eCMxPbqKXBTP0evbvX/98I+Ags 343sxYA1T1Z8rN8/YQWI7L1CGfMT8TC31oar93oalrgUyATRANDlnvYi7aj913riHhMg EKSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LbBn38hE6seJc43f56mwFAMBxFTtvWqBR6+3Xyq5xUQ=; b=Ib2+jtsQFB1cc8mFNnFT256Nrh1WUl7zuJBczEC3Rv19DIbog942aGUAeuT8w7K/+w SeWRycSj/+rikFm0KjE2TFl21HY15U5BVLbnFirrD0HuHpSjRF15pfl2YGle0WAPTUeU 0fHfymiKjniWeLiD85BsRVKjgmRHzrg95Y1edZzOy0dnMGjeIu+jH70kRkKSQqRzxppe cYA/pQhkOmDzZpdbxOGa3/t/EkxJtWNsf3Y1zZpk2fy9yOBK3H1vq7LSQxanCympYyPk hv6C6YaSbkxAASVOvyl0mjq6JMUAUKHet/7QGtP2yXITyoVgyQ+IAuIB7+wuOBj+0aMw StZw== X-Gm-Message-State: AHPjjUhUwssbq+AWFBXyCDHO0JmvB5Iww6U2kEIevbBjOZxPduIFWu9b 4kWzj0s8r1qZPd1SSh4/CRrA35EY+8PkDgL1Gr8GGw== X-Google-Smtp-Source: AOwi7QCGCIxXnkBAbh0Sk22MCqZfAh9zNqoiWn1cZMMwTR3oZnYpFqajZgLPyqd8Qib69Yan7XjsuDg9LPMQfvsEmNU= X-Received: by 10.37.51.130 with SMTP id z124mr3543613ybz.154.1505911285193; Wed, 20 Sep 2017 05:41:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.4 with HTTP; Wed, 20 Sep 2017 05:41:04 -0700 (PDT) In-Reply-To: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> From: Ian Swett Date: Wed, 20 Sep 2017 08:41:04 -0400 Message-ID: Subject: Re: ECN in QUIC To: Ingemar Johansson S Cc: Colin Perkins , Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , "Eggert, Lars (lars@netapp.com)" , marcelo bagnulo braun , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Piers O'Hanlon" , QUIC IETF mailing list , "De Schepper, Koen (Nokia - BE/Antwerp)" Content-Type: multipart/alternative; boundary="001a11489f1638440005599e4b90" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 12:41:29 -0000 --001a11489f1638440005599e4b90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > And sorry for the sloth-ish response (you should see me type a text > message..). > > To summarize the two main questions > > > > 1. ECN in ACK frame or in a separate frame : Given the recent > discussion on the list and fear that the ACK frame is already enough > complex, it seems unwise to try to cram in additional info in the ACK > frames. So my personal feeling is that we should use a separate frame = type > for ECN , but this frame type must be a MUST to implement and support = ! > Comments are very welcome. > > I was neutral on this before, but I started thinking about implementing this, and separating the frames makes it more complex, and potentially really, really difficult to get the implementation correct. As an example, if the frames were accidentally sent in two separate packets, I would count the packet as acked, and potentially increase the congestion window and other state variables. I might even send an extra packet based on this information. Then in the next packet I'd realize that packet had an ECN marking, and actually should have been treated as lost from a congestion controller perspective. In order to do this correctly, I'd have to undo a bunch of things. My experience with undo is that it's terribly error prone, and I would never recommend it. Alternately, the ack could get lost, and the next packet would convey ECN marking information for packets that hadn't been acknowledged yet. Which is just weird. If we require support for ECN, then the implementation has a certain extra level of complexity. As illustrated above, putting it in one frame is actually simpler overall if the congestion controller needs to use all the information at once to be implemented correctly. This same logic applies to timestamps as well, in my opinion. > > 1. > 2. As regards to the level of detail : There are pros and cons with > both alternatives (marked bytes or detailed indication). I would like = to > hear the opinions from others as well on this matter . > > > > /Ingemar > > > > *From:* Colin Perkins [mailto:csp@csperkins.org] > *Sent:* den 16 augusti 2017 12:53 > *To:* Ingemar Johansson S > *Cc:* QUIC IETF mailing list ; Magnus Westerlund < > magnus.westerlund@ericsson.com>; Bob Briscoe (research@bobbriscoe.net) < > research@bobbriscoe.net>; Praveen Balasubramanian ; > Eggert, Lars (lars@netapp.com) ; marcelo bagnulo braun < > marcelo@it.uc3m.es>; Mirja K=C3=BChlewind ; > Piers O'Hanlon ; De Schepper, Koen (Nokia - > BE/Antwerp) > *Subject:* Re: ECN in QUIC > > > > > > On 16 Aug 2017, at 10:33, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > > > Hi > > > > Finally back from vacation, and very grateful for the support to continue > the work to add ECN in QUIC. > > Just to recap.. there were two main topics raised at the meeting > > > > 1) ECN info in ACK frame or in dedicated frame : There were concerns abou= t > adding extra complexity in an already potentially complex ACK frame, one > can have differing opinions about the complexity but can understand the > concerns. As far as I am concerned, a separate frame type for ECN is > possible, possibly one need to add information about the amount of not-EC= T > marked packets as well to keep the signaling robust, this needs further > investigation though. One concern with a separate ECN frame is that it > becomes a not-implemented or optional feature, is there any reason to be > worried about this ? > > > > 2) More detailed ECN information : Earlier versions of the ECN in QUIC > draft (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt ) > provided with examples. We (Myself, Koen, Mirja and Praveen) discussed th= is > and we could not come up with any use case where it is beneficial to know > exactly how each packet is ECN marked. I know that this kind of detailed > ECN information is suggested for the generic feedback for RMCAT and I > personally have a problem to see the gain with the detailed ECN informati= on > also here. Input from others is very welcome here. > > > > For the RMCAT format, we wanted per-packet loss and timing information, > and it was as easy to feedback per-packet ECN information along with it a= s > to design something different. > > > > A benefit of per-packet ECN marking could be to allow a congestion > controller that reacted differently to bursts of consecutive ECN marks th= an > it did to isolated ECN marks, given the same fraction of marked packets > (i.e., that reacted to ECN marking events rather than ECN marking rate, > like how TCP responds to loss events). I don=E2=80=99t think we have such= a thing, > but certainly in the context of RMCAT where we=E2=80=99re experimenting w= ith novel > congestion control schemes for traffic that has very different > characteristics to traditional bulk flows, it might be plausible. > Per-packet marking information is also useful for troubleshooting. > > > > Certainly we need to know number of NotECT, ECT(0), ECT(1), and ECN-CE > marks since the last report, but I guess that=E2=80=99s already possible. > > > > Cheers, > > Colin > > > > > > > > > > There are a consequences with detailed ECN marking information. > > a) necessary to correlate with the list of transmitted packets, this > increases amount of code on sender side, not sure of that is a large > concern as lookup is anyway needed to process incoming ACKs > > b) necessary to embed ECN information in ACK frame ?, at least this was m= y > conclusion when I devised the detailed ECN marking info in the 01 version > of the draft. > > > > Comments are welcome > > /Ingemar > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 <+46%2073%20078%2032%2089> > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > A mistake is to commit a misunderstanding > Bob Dylan > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > --001a11489f1638440005599e4b90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S <= ingem= ar.s.johansson@ericsson.com> wrote:

Hi

=C2=A0

And sorry for the sloth-ish response (you should see= me type=C2=A0 a text message..).

To summarize the two main questions

=C2=A0

  1. ECN in ACK frame or in a separate frame : Given the recent discussion o= n the list and fear that the ACK frame is already enough complex, it seems = unwise to try to cram in additional info in the ACK frames. So my personal feeling is that we should use a sep= arate frame type for ECN , but this frame type must be a MUST to implement = and support ! Comments are very welcome.
=
I was neutral on this before, but I started thinking about implementin= g this, and separating the frames makes it more complex, and potentially re= ally, really difficult to get the implementation correct.=C2=A0 As an examp= le, if the frames were accidentally sent in two separate packets, I would c= ount the packet as acked, and potentially increase the congestion window an= d other state variables.=C2=A0 I might even send an extra packet based on t= his information.=C2=A0 Then in the next packet I'd realize that packet = had an ECN marking, and actually should have been treated as lost from a co= ngestion controller perspective.=C2=A0 In order to do this correctly, I'= ;d have to undo a bunch of things.=C2=A0 My experience with undo is that it= 's terribly error prone, and I would never recommend it.=C2=A0=C2=A0

Alternately, the ack could get lost, and the next pa= cket would convey ECN marking information for packets that hadn't been = acknowledged yet.=C2=A0 Which is just weird.

If we= require support for ECN, then the implementation has a certain extra level= of complexity.=C2=A0 As illustrated above, putting it in one frame is actu= ally simpler overall if the congestion controller needs to use all the info= rmation at once to be implemented correctly.=C2=A0 This same logic applies = to timestamps as well, in my opinion.
=C2=A0
  2. As regards to the level of de= tail : There are pros and cons with both alternatives (marked bytes or deta= iled indication). I would like to hear the opinions from others as well on = this matter .

=C2=A0

/Ingemar

=C2=A0

From: Colin Perkins [mailto:csp@csperkins.org]
Sent: den 16 augusti 2017 12:53
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>=
Cc: QUIC IETF mailing list <quic@ietf.org>; Magnus Westerlund <magnus.westerlund@erics= son.com>; Bob Briscoe (research@bobbriscoe.net) <research@bobbriscoe.net>; Pr= aveen Balasubramanian <pravb@microsoft.com>; Eggert, Lars (lars@netapp.com) <lars@netapp.com>; marcelo bagnulo braun <marcelo@it.uc3m.es>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik= .ee.ethz.ch>; Piers O'Hanlon <piers.ohanlon@cs.ox.ac.uk>; De = Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-lab= s.com>
Subject: Re: ECN in QUIC

=C2=A0

=C2=A0

On 16 Aug 2017, at 10:33, Ingemar Johansson S <ingemar= .s.johansson@ericsson.com> wrote:

=C2=A0

Hi

=C2=A0

Finally back from vacation, and very grateful for th= e support to continue the work to add ECN in QUIC.

Just to recap.. there were two main topics raised at= the meeting

=C2=A0

1) ECN info in ACK frame or in dedicated frame : The= re were concerns about adding extra complexity in an already potentially co= mplex ACK frame, one can have differing opinions about the complexity but c= an understand the concerns. As far as I am concerned, a separate frame type for ECN is possible, possibly one= need to add information about the amount of not-ECT marked packets as well= to keep the signaling robust, this needs further investigation though. One= concern with a separate ECN frame is that it becomes a not-implemented or optional feature, is there any rea= son to be worried about this ?

=C2=A0

2) More detailed ECN information : Earlier versions = of the ECN in QUIC draft (seehttp= s://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt<= span class=3D"m_-4533685310870236821apple-converted-space">=C2=A0) provided with examples. We (Myself, Koen, Mirja and Praveen) discussed thi= s and we could not come up with any use case where it is beneficial to know= exactly how each packet is ECN marked. I know that this kind of detailed E= CN information is suggested for the generic feedback for RMCAT and I personally have a problem to see the = gain with the detailed ECN information also here. Input from others is very= welcome here.

=C2=A0

For the RMCAT format, we wanted per-packet loss and = timing information, and it was as easy to feedback per-packet ECN informati= on along with it as to design something different.

=C2=A0

A benefit of per-packet ECN marking could be to allo= w a congestion controller that reacted differently to bursts of consecutive= ECN marks than it did to isolated ECN marks, given the same fraction of ma= rked packets (i.e., that reacted to ECN marking events rather than ECN marking rate, like how TCP responds to = loss events). I don=E2=80=99t think we have such a thing, but certainly in = the context of RMCAT where we=E2=80=99re experimenting with novel congestio= n control schemes for traffic that has very different characteristics to traditional bulk flows, it might be plausible. Per-pack= et marking information is also useful for troubleshooting.

=C2=A0

Certainly we need to know number of NotECT, ECT(0), = ECT(1), and ECN-CE marks since the last report, but I guess that=E2=80=99s = already possible.

=C2=A0

Cheers,

Colin

=C2=A0

=C2=A0

=C2=A0



There are a consequences with detailed ECN marking i= nformation.

a) necessary to correlate with the list of transmitt= ed packets, this increases amount of code on sender side, not sure of that = is a large concern as lookup is anyway needed to process incoming ACKs

b) necessary to embed ECN information in ACK frame ?= , at least this was my conclusion when I devised the detailed ECN marking i= nfo in the 01 version of the draft.

=C2=A0

Comments are welcome

/Ingemar

=C2=A0

=C2=A0

=C2=A0

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

Ingemar Johansson=C2=A0 M.Sc.

Master Researcher

=C2=A0

Ericsson AB

Wireless Access Networks

Labratoriegr=C3=A4nd 11

971 28, Lule=C3=A5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

=C2=A0

A mistake is to commit= a misunderstanding
=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 Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0



--=C2=A0
Colin Perkins
https://csperkins.org/=


=C2=A0


--001a11489f1638440005599e4b90-- From nobody Wed Sep 20 06:28:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B5134223 for ; Wed, 20 Sep 2017 06:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 nwJn6BN-6KKj for ; Wed, 20 Sep 2017 06:28:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE66C134212 for ; Wed, 20 Sep 2017 06:28:29 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-9b-59c26cfb059f Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.15.21299.BFC62C95; Wed, 20 Sep 2017 15:28:27 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 20 Sep 2017 15:28:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SHFBTYKdX3te+Gy75IcyYsV3qIyB5U3wCLpn5l2tIiU=; b=SH//KinMDo60Qk0d7yXN11k95KVQKTXaPHuENg44CstLDo2lvwkl91hOjIp0UdKRiCcQDvL8ENfd/M39F/YN8TYb29C2o4Ue+QSiHfBKlLNyMcymwiu+X60jwN+AgqIBl6jayhdl2I+tjVsi5Hn/9WdXKqT1HdXlVcKXXLeprU4= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB0765.eurprd07.prod.outlook.com (10.141.44.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 13:27:59 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.011; Wed, 20 Sep 2017 13:27:59 +0000 From: Ingemar Johansson S To: Ian Swett CC: Colin Perkins , Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , "Eggert, Lars (lars@netapp.com)" , marcelo bagnulo braun , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Piers O'Hanlon , QUIC IETF mailing list , "De Schepper, Koen (Nokia - BE/Antwerp)" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdMWaIZN+ofkuQeuQOGGa2om9/ikzQAFT3AABtrtZuAACQ/IAAABYVFw Date: Wed, 20 Sep 2017 13:27:58 +0000 Message-ID: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB0765; 6:1KkjPgcG5dw0EUAK6AWo15paMFtB+WF9FtTndotWO6aDTqilmaVaGS4vGnAvkwLA72Xcva2k+Ro51wT9oEzvhPHlo7gXjMXoD/RQZVK7Hqvm4sgxrF5MxUijtNuzYQIf0mDmJB4oDX6t0VGGDRRUjkPAsBHF79yqyHsv86ErV1kQHLpEshQD6HPSsW6x+Df20iZqWbhiAgoyofyhofz0yHqubZp6OSpUWiRWrXU7xNAHnfL/j6ImNh7CtJxpLfKfmvuuj+8TKIu5qbqqQl8RvaSZ7m+ICfpfbn/ios61al1rsk3kFY3D0CRhgO/NaK3cZpAE+vNMJNKGWUbqVXzpxA==; 5:FzUfhl9A2bxOpzJ8ymDIJiEEBNgCy+of1Jvoff+/0ULAxtaW7s7svEEkPZ3lO9Q3McVJEvo5smdRhUcR8o4rOi7Xnpy6TN5432R1e8pQvMHGdmNy2XUj75qvfsX1nlEptMCoCntFaANcwCVt35e/vg==; 24:hMdwpr6aQZwv3xKmm8Ka7L9EIus9v89PbJSFRC7y7EHBlX9Yy+qDCpmPRaVS1pBNAPisQWv/3HSEkb4BRLgyNv1B+TLNSR5O8WyIbD2wb5A=; 7:X3UqgmL/QxdqlrEeUPlub7hDx/aCabnRwfClf0N/8xjjsrJ0gN+VTJTEsFRFQOMfyXDekWqazGy1fHwtHSsEosmb3PWNnOth7iLDyydNPDzZB4tKxCSyTS8shRBwMjQ4nHsuaX/Bz2FGu0stIYp4CNhMehp1gcVqkcG0Q+dFOP6tSIw+9sMhUQNx/NhnOlkzTP5TgiRC0cJF3QDk2taNz7IIrs/bmXsyHngcC9znN6w= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: baef0bd9-b6b1-4a45-027c-08d5002b692c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB0765; x-ms-traffictypediagnostic: DB4PR07MB0765: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-exchange-antispam-report-test: UriScan:(37575265505322)(89211679590171)(211936372134217)(202460600054446)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(920507026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB0765; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB0765; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(199003)(377454003)(24454002)(189002)(3660700001)(3280700002)(76176999)(54356999)(50986999)(7696004)(25786009)(101416001)(7736002)(966005)(229853002)(478600001)(106356001)(606006)(93886005)(7116003)(53546010)(105586002)(66066001)(14454004)(5660300001)(189998001)(33656002)(316002)(19609705001)(53386004)(53936002)(68736007)(34040400001)(45080400002)(8676002)(6306002)(6246003)(86362001)(5250100002)(6436002)(7416002)(2906002)(74316002)(54896002)(9686003)(97736004)(236005)(1680700002)(4326008)(81166006)(8666007)(2900100001)(81156014)(6506006)(54906003)(2950100002)(55016002)(6916009)(3480700004)(8936002)(99286003)(6116002)(790700001)(102836003)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0765; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348D95672E48A338758E32DC2610DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 13:27:58.8535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0765 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUYRSG++4218mJr0nxVFo5JViUmm2XiKh+xBUJWn6kYtmotzLHMe6M lVIQ4pi4gIm0USppmoparpVr41ZGaZqGFk2uZKaF2lgNSc7cCfz3fOd9zznvgY8llb/oVWyE Vi+IWrVGxcip2wE127ZYNMZAn5GbHFcw/gJxvz89pbk28wOC+zKRSnGG0SKGe1ScSXHliRU0 N5E6jLjUnKXc4I14tE/OfzV10fzfpGqKv2EyMXxOeQyfl/eb4M3vH9O84clfGX9repbh4833 Gb7tx0/msDxIvidc0ERcEETvvafkZycTaunzHY3EpabmGeYqultDJCMHFvB2yOp9wyQjOavE LQiaX7bZBCV+gWA6088qUDiNhLGSX0hyZRJQZSmSSQ8TgsaOdFsLg/dAoXEOWdkJr4fWjxm2 DhLnU/DHXGkzrcAAOW0ZhGRaCVOzBkrig9BYWyGzMoU9wPTWyFhZgYNg2NxMSdsKCagfn1sQ WNYBH4HaFt7qQdgNTHOfbHNI7AIDI9n24zDk1XWSEjvD+PA8LfE6+FDQTknsBt3ZKbaggBNl 0Hmz3N7gBVXXJ5HEhyD1W66dhwiYrLPzJhioHCOlEGEw3Z9GW7MBvgwNJcGSJRL6p3sZaX4f DaVNZfYQrlA7n0Wko813FuWWOBpSHuZSd2z3L4eXt0cWmF2ob4SyZ96SxR0yUwZlEnuC4e49 2eJ6DpIVIWedoAuNOuO7zUsQI8J0umitl1bQl6OF//i80uLxBPV8229EmEUqR0VvyPNAJa2+ oIuNMiJgSZWTIiPSGKhUhKtj4wQxOkSM0Qg6I1rNUioXxf6GrgAlPqPWC5GCcF4Q/6sE67Dq Koobc8nyL9bGOLpWKdbQVaf9S69YlvkmfXcucJ7x61JXwIn2WMdRodc1ONab1PSITaMy9vhX v90xYWEHOgy5+b7Hzr2aIi2Fo4NOQ0Eh4jW5/+fs4fq1F5/uWNcf+m5r69Hwlur+nV8mPPVL 3ONz9T0Fu25d2zB08PXJ7kS6us8nQUXpzqq3biJFnfofCG8vnIsDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:28:38 -0000 --_000_DB4PR07MB348D95672E48A338758E32DC2610DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIElhbiBmb3IgdGhlIHByb21wdCByZXNwb25zZS4NCkkgbXVzdCBhZG1pdCB0aGF0IEkg aGF2ZSBwZXJoYXBzIG92ZXJsb29rZWQgcG9zc2libGUgY29tYm9zIG9mIGxvc3MgYW5kIEVDTiwg dGhlIHByaWNlIHlvdSBwYXkgZm9yIHdvcmtpbmcgdG9vIG11Y2ggd2l0aCBzaW11bGF0b3JzLiBZ b3VyIGFyZ3VtZW50cyBhcmUgdmVyeSBzdHJvbmcgaW5kZWVkLg0KDQpJbiB0aGUgU0NSZUFNIGNv bmdlc3Rpb24gY29udHJvbCAoUk1DQVQgd29yaykgdGhlIEVDTiBhbmQgbG9zcyBpbmZvIGNvbWVz IGluIHRoZSBzYW1lIGZlZWRiYWNrIGFuZCB0aGUgaGFuZGxpbmcgb2YgbG9zcyBhbmQgRUNOIGlz IHN0cmFpZ2h0Zm9yd2FyZCB0aGVyZS4gUGVyc29uYWxseSBJIHdvdWxkIHByZWZlciBFQ04gaW4g dGhlIEFDSyBmcmFtZXMgYW5kIHRoZSBlYXJsaWVyIGRyYWZ0cyBzdWdnZXN0ZWQgZm9ybWF0cyBm b3IgdGhhdCwgSSBob3dldmVyIGdvdCB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoZXJlIGlzIGEgY2Vy dGFpbiByZXNpc3RhbmNlIGFnYWluc3QgYWRkaXRpb25hbCB0aGluZ3MgaW4gdGhlIEFDSyBmcmFt ZSA/Lg0KDQovSW5nZW1hcg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29n bGUuY29tXQ0KU2VudDogZGVuIDIwIHNlcHRlbWJlciAyMDE3IDE0OjQxDQpUbzogSW5nZW1hciBK b2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQpDYzogQ29saW4g UGVya2lucyA8Y3NwQGNzcGVya2lucy5vcmc+OyBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tPjsgQm9iIEJyaXNjb2UgKHJlc2VhcmNoQGJvYmJyaXNjb2Uu bmV0KSA8cmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQ+OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8 cHJhdmJAbWljcm9zb2Z0LmNvbT47IEVnZ2VydCwgTGFycyAobGFyc0BuZXRhcHAuY29tKSA8bGFy c0BuZXRhcHAuY29tPjsgbWFyY2VsbyBiYWdudWxvIGJyYXVuIDxtYXJjZWxvQGl0LnVjM20uZXM+ OyBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgUGll cnMgTydIYW5sb24gPHBpZXJzLm9oYW5sb25AY3Mub3guYWMudWs+OyBRVUlDIElFVEYgbWFpbGlu ZyBsaXN0IDxxdWljQGlldGYub3JnPjsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50 d2VycCkgPGtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbT4NClN1YmplY3Q6IFJl OiBFQ04gaW4gUVVJQw0KDQoNCk9uIFdlZCwgU2VwIDIwLCAyMDE3IGF0IDQ6MzkgQU0sIEluZ2Vt YXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpp bmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkNCg0KQW5kIHNvcnJ5 IGZvciB0aGUgc2xvdGgtaXNoIHJlc3BvbnNlICh5b3Ugc2hvdWxkIHNlZSBtZSB0eXBlICBhIHRl eHQgbWVzc2FnZS4uKS4NClRvIHN1bW1hcml6ZSB0aGUgdHdvIG1haW4gcXVlc3Rpb25zDQoNCg0K ICAxLiAgRUNOIGluIEFDSyBmcmFtZSBvciBpbiBhIHNlcGFyYXRlIGZyYW1lIDogR2l2ZW4gdGhl IHJlY2VudCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGFuZCBmZWFyIHRoYXQgdGhlIEFDSyBmcmFt ZSBpcyBhbHJlYWR5IGVub3VnaCBjb21wbGV4LCBpdCBzZWVtcyB1bndpc2UgdG8gdHJ5IHRvIGNy YW0gaW4gYWRkaXRpb25hbCBpbmZvIGluIHRoZSBBQ0sgZnJhbWVzLiBTbyBteSBwZXJzb25hbCBm ZWVsaW5nIGlzIHRoYXQgd2Ugc2hvdWxkIHVzZSBhIHNlcGFyYXRlIGZyYW1lIHR5cGUgZm9yIEVD TiAsIGJ1dCB0aGlzIGZyYW1lIHR5cGUgbXVzdCBiZSBhIE1VU1QgdG8gaW1wbGVtZW50IGFuZCBz dXBwb3J0ICEgQ29tbWVudHMgYXJlIHZlcnkgd2VsY29tZS4NCkkgd2FzIG5ldXRyYWwgb24gdGhp cyBiZWZvcmUsIGJ1dCBJIHN0YXJ0ZWQgdGhpbmtpbmcgYWJvdXQgaW1wbGVtZW50aW5nIHRoaXMs IGFuZCBzZXBhcmF0aW5nIHRoZSBmcmFtZXMgbWFrZXMgaXQgbW9yZSBjb21wbGV4LCBhbmQgcG90 ZW50aWFsbHkgcmVhbGx5LCByZWFsbHkgZGlmZmljdWx0IHRvIGdldCB0aGUgaW1wbGVtZW50YXRp b24gY29ycmVjdC4gIEFzIGFuIGV4YW1wbGUsIGlmIHRoZSBmcmFtZXMgd2VyZSBhY2NpZGVudGFs bHkgc2VudCBpbiB0d28gc2VwYXJhdGUgcGFja2V0cywgSSB3b3VsZCBjb3VudCB0aGUgcGFja2V0 IGFzIGFja2VkLCBhbmQgcG90ZW50aWFsbHkgaW5jcmVhc2UgdGhlIGNvbmdlc3Rpb24gd2luZG93 IGFuZCBvdGhlciBzdGF0ZSB2YXJpYWJsZXMuICBJIG1pZ2h0IGV2ZW4gc2VuZCBhbiBleHRyYSBw YWNrZXQgYmFzZWQgb24gdGhpcyBpbmZvcm1hdGlvbi4gIFRoZW4gaW4gdGhlIG5leHQgcGFja2V0 IEknZCByZWFsaXplIHRoYXQgcGFja2V0IGhhZCBhbiBFQ04gbWFya2luZywgYW5kIGFjdHVhbGx5 IHNob3VsZCBoYXZlIGJlZW4gdHJlYXRlZCBhcyBsb3N0IGZyb20gYSBjb25nZXN0aW9uIGNvbnRy b2xsZXIgcGVyc3BlY3RpdmUuICBJbiBvcmRlciB0byBkbyB0aGlzIGNvcnJlY3RseSwgSSdkIGhh dmUgdG8gdW5kbyBhIGJ1bmNoIG9mIHRoaW5ncy4gIE15IGV4cGVyaWVuY2Ugd2l0aCB1bmRvIGlz IHRoYXQgaXQncyB0ZXJyaWJseSBlcnJvciBwcm9uZSwgYW5kIEkgd291bGQgbmV2ZXIgcmVjb21t ZW5kIGl0Lg0KDQpBbHRlcm5hdGVseSwgdGhlIGFjayBjb3VsZCBnZXQgbG9zdCwgYW5kIHRoZSBu ZXh0IHBhY2tldCB3b3VsZCBjb252ZXkgRUNOIG1hcmtpbmcgaW5mb3JtYXRpb24gZm9yIHBhY2tl dHMgdGhhdCBoYWRuJ3QgYmVlbiBhY2tub3dsZWRnZWQgeWV0LiAgV2hpY2ggaXMganVzdCB3ZWly ZC4NCg0KSWYgd2UgcmVxdWlyZSBzdXBwb3J0IGZvciBFQ04sIHRoZW4gdGhlIGltcGxlbWVudGF0 aW9uIGhhcyBhIGNlcnRhaW4gZXh0cmEgbGV2ZWwgb2YgY29tcGxleGl0eS4gIEFzIGlsbHVzdHJh dGVkIGFib3ZlLCBwdXR0aW5nIGl0IGluIG9uZSBmcmFtZSBpcyBhY3R1YWxseSBzaW1wbGVyIG92 ZXJhbGwgaWYgdGhlIGNvbmdlc3Rpb24gY29udHJvbGxlciBuZWVkcyB0byB1c2UgYWxsIHRoZSBp bmZvcm1hdGlvbiBhdCBvbmNlIHRvIGJlIGltcGxlbWVudGVkIGNvcnJlY3RseS4gIFRoaXMgc2Ft ZSBsb2dpYyBhcHBsaWVzIHRvIHRpbWVzdGFtcHMgYXMgd2VsbCwgaW4gbXkgb3Bpbmlvbi4NCg0K DQogIDEuDQogIDIuICBBcyByZWdhcmRzIHRvIHRoZSBsZXZlbCBvZiBkZXRhaWwgOiBUaGVyZSBh cmUgcHJvcyBhbmQgY29ucyB3aXRoIGJvdGggYWx0ZXJuYXRpdmVzIChtYXJrZWQgYnl0ZXMgb3Ig ZGV0YWlsZWQgaW5kaWNhdGlvbikuIEkgd291bGQgbGlrZSB0byBoZWFyIHRoZSBvcGluaW9ucyBm cm9tIG90aGVycyBhcyB3ZWxsIG9uIHRoaXMgbWF0dGVyIC4NCg0KL0luZ2VtYXINCg0KRnJvbTog Q29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnPG1haWx0bzpjc3BAY3NwZXJr aW5zLm9yZz5dDQpTZW50OiBkZW4gMTYgYXVndXN0aSAyMDE3IDEyOjUzDQpUbzogSW5nZW1hciBK b2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4NCkNjOiBRVUlDIElFVEYgbWFpbGluZyBsaXN0 IDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IE1hZ251cyBXZXN0ZXJsdW5k IDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbT4+OyBCb2IgQnJpc2NvZSAocmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQ8bWFp bHRvOnJlc2VhcmNoQGJvYmJyaXNjb2UubmV0PikgPHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0PG1h aWx0bzpyZXNlYXJjaEBib2JicmlzY29lLm5ldD4+OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8 cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+OyBFZ2dlcnQs IExhcnMgKGxhcnNAbmV0YXBwLmNvbTxtYWlsdG86bGFyc0BuZXRhcHAuY29tPikgPGxhcnNAbmV0 YXBwLmNvbTxtYWlsdG86bGFyc0BuZXRhcHAuY29tPj47IG1hcmNlbG8gYmFnbnVsbyBicmF1biA8 bWFyY2Vsb0BpdC51YzNtLmVzPG1haWx0bzptYXJjZWxvQGl0LnVjM20uZXM+PjsgTWlyamEgS8O8 aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDxtYWlsdG86bWlyamEua3Vl aGxld2luZEB0aWsuZWUuZXRoei5jaD4+OyBQaWVycyBPJ0hhbmxvbiA8cGllcnMub2hhbmxvbkBj cy5veC5hYy51azxtYWlsdG86cGllcnMub2hhbmxvbkBjcy5veC5hYy51az4+OyBEZSBTY2hlcHBl ciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxs LWxhYnMuY29tPG1haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20+Pg0K U3ViamVjdDogUmU6IEVDTiBpbiBRVUlDDQoNCg0KT24gMTYgQXVnIDIwMTcsIGF0IDEwOjMzLCBJ bmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWls dG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGkNCg0KRmlu YWxseSBiYWNrIGZyb20gdmFjYXRpb24sIGFuZCB2ZXJ5IGdyYXRlZnVsIGZvciB0aGUgc3VwcG9y dCB0byBjb250aW51ZSB0aGUgd29yayB0byBhZGQgRUNOIGluIFFVSUMuDQpKdXN0IHRvIHJlY2Fw Li4gdGhlcmUgd2VyZSB0d28gbWFpbiB0b3BpY3MgcmFpc2VkIGF0IHRoZSBtZWV0aW5nDQoNCjEp IEVDTiBpbmZvIGluIEFDSyBmcmFtZSBvciBpbiBkZWRpY2F0ZWQgZnJhbWUgOiBUaGVyZSB3ZXJl IGNvbmNlcm5zIGFib3V0IGFkZGluZyBleHRyYSBjb21wbGV4aXR5IGluIGFuIGFscmVhZHkgcG90 ZW50aWFsbHkgY29tcGxleCBBQ0sgZnJhbWUsIG9uZSBjYW4gaGF2ZSBkaWZmZXJpbmcgb3Bpbmlv bnMgYWJvdXQgdGhlIGNvbXBsZXhpdHkgYnV0IGNhbiB1bmRlcnN0YW5kIHRoZSBjb25jZXJucy4g QXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCBhIHNlcGFyYXRlIGZyYW1lIHR5cGUgZm9yIEVDTiBp cyBwb3NzaWJsZSwgcG9zc2libHkgb25lIG5lZWQgdG8gYWRkIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBhbW91bnQgb2Ygbm90LUVDVCBtYXJrZWQgcGFja2V0cyBhcyB3ZWxsIHRvIGtlZXAgdGhlIHNp Z25hbGluZyByb2J1c3QsIHRoaXMgbmVlZHMgZnVydGhlciBpbnZlc3RpZ2F0aW9uIHRob3VnaC4g T25lIGNvbmNlcm4gd2l0aCBhIHNlcGFyYXRlIEVDTiBmcmFtZSBpcyB0aGF0IGl0IGJlY29tZXMg YSBub3QtaW1wbGVtZW50ZWQgb3Igb3B0aW9uYWwgZmVhdHVyZSwgaXMgdGhlcmUgYW55IHJlYXNv biB0byBiZSB3b3JyaWVkIGFib3V0IHRoaXMgPw0KDQoyKSBNb3JlIGRldGFpbGVkIEVDTiBpbmZv cm1hdGlvbiA6IEVhcmxpZXIgdmVyc2lvbnMgb2YgdGhlIEVDTiBpbiBRVUlDIGRyYWZ0IChzZWVo dHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQg KSBwcm92aWRlZCB3aXRoIGV4YW1wbGVzLiBXZSAoTXlzZWxmLCBLb2VuLCBNaXJqYSBhbmQgUHJh dmVlbikgZGlzY3Vzc2VkIHRoaXMgYW5kIHdlIGNvdWxkIG5vdCBjb21lIHVwIHdpdGggYW55IHVz ZSBjYXNlIHdoZXJlIGl0IGlzIGJlbmVmaWNpYWwgdG8ga25vdyBleGFjdGx5IGhvdyBlYWNoIHBh Y2tldCBpcyBFQ04gbWFya2VkLiBJIGtub3cgdGhhdCB0aGlzIGtpbmQgb2YgZGV0YWlsZWQgRUNO IGluZm9ybWF0aW9uIGlzIHN1Z2dlc3RlZCBmb3IgdGhlIGdlbmVyaWMgZmVlZGJhY2sgZm9yIFJN Q0FUIGFuZCBJIHBlcnNvbmFsbHkgaGF2ZSBhIHByb2JsZW0gdG8gc2VlIHRoZSBnYWluIHdpdGgg dGhlIGRldGFpbGVkIEVDTiBpbmZvcm1hdGlvbiBhbHNvIGhlcmUuIElucHV0IGZyb20gb3RoZXJz IGlzIHZlcnkgd2VsY29tZSBoZXJlLg0KDQpGb3IgdGhlIFJNQ0FUIGZvcm1hdCwgd2Ugd2FudGVk IHBlci1wYWNrZXQgbG9zcyBhbmQgdGltaW5nIGluZm9ybWF0aW9uLCBhbmQgaXQgd2FzIGFzIGVh c3kgdG8gZmVlZGJhY2sgcGVyLXBhY2tldCBFQ04gaW5mb3JtYXRpb24gYWxvbmcgd2l0aCBpdCBh cyB0byBkZXNpZ24gc29tZXRoaW5nIGRpZmZlcmVudC4NCg0KQSBiZW5lZml0IG9mIHBlci1wYWNr ZXQgRUNOIG1hcmtpbmcgY291bGQgYmUgdG8gYWxsb3cgYSBjb25nZXN0aW9uIGNvbnRyb2xsZXIg dGhhdCByZWFjdGVkIGRpZmZlcmVudGx5IHRvIGJ1cnN0cyBvZiBjb25zZWN1dGl2ZSBFQ04gbWFy a3MgdGhhbiBpdCBkaWQgdG8gaXNvbGF0ZWQgRUNOIG1hcmtzLCBnaXZlbiB0aGUgc2FtZSBmcmFj dGlvbiBvZiBtYXJrZWQgcGFja2V0cyAoaS5lLiwgdGhhdCByZWFjdGVkIHRvIEVDTiBtYXJraW5n IGV2ZW50cyByYXRoZXIgdGhhbiBFQ04gbWFya2luZyByYXRlLCBsaWtlIGhvdyBUQ1AgcmVzcG9u ZHMgdG8gbG9zcyBldmVudHMpLiBJIGRvbuKAmXQgdGhpbmsgd2UgaGF2ZSBzdWNoIGEgdGhpbmcs IGJ1dCBjZXJ0YWlubHkgaW4gdGhlIGNvbnRleHQgb2YgUk1DQVQgd2hlcmUgd2XigJlyZSBleHBl cmltZW50aW5nIHdpdGggbm92ZWwgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZXMgZm9yIHRyYWZm aWMgdGhhdCBoYXMgdmVyeSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzIHRvIHRyYWRpdGlvbmFs IGJ1bGsgZmxvd3MsIGl0IG1pZ2h0IGJlIHBsYXVzaWJsZS4gUGVyLXBhY2tldCBtYXJraW5nIGlu Zm9ybWF0aW9uIGlzIGFsc28gdXNlZnVsIGZvciB0cm91Ymxlc2hvb3RpbmcuDQoNCkNlcnRhaW5s eSB3ZSBuZWVkIHRvIGtub3cgbnVtYmVyIG9mIE5vdEVDVCwgRUNUKDApLCBFQ1QoMSksIGFuZCBF Q04tQ0UgbWFya3Mgc2luY2UgdGhlIGxhc3QgcmVwb3J0LCBidXQgSSBndWVzcyB0aGF04oCZcyBh bHJlYWR5IHBvc3NpYmxlLg0KDQpDaGVlcnMsDQpDb2xpbg0KDQoNCg0KDQpUaGVyZSBhcmUgYSBj b25zZXF1ZW5jZXMgd2l0aCBkZXRhaWxlZCBFQ04gbWFya2luZyBpbmZvcm1hdGlvbi4NCmEpIG5l Y2Vzc2FyeSB0byBjb3JyZWxhdGUgd2l0aCB0aGUgbGlzdCBvZiB0cmFuc21pdHRlZCBwYWNrZXRz LCB0aGlzIGluY3JlYXNlcyBhbW91bnQgb2YgY29kZSBvbiBzZW5kZXIgc2lkZSwgbm90IHN1cmUg b2YgdGhhdCBpcyBhIGxhcmdlIGNvbmNlcm4gYXMgbG9va3VwIGlzIGFueXdheSBuZWVkZWQgdG8g cHJvY2VzcyBpbmNvbWluZyBBQ0tzDQpiKSBuZWNlc3NhcnkgdG8gZW1iZWQgRUNOIGluZm9ybWF0 aW9uIGluIEFDSyBmcmFtZSA/LCBhdCBsZWFzdCB0aGlzIHdhcyBteSBjb25jbHVzaW9uIHdoZW4g SSBkZXZpc2VkIHRoZSBkZXRhaWxlZCBFQ04gbWFya2luZyBpbmZvIGluIHRoZSAwMSB2ZXJzaW9u IG9mIHRoZSBkcmFmdC4NCg0KQ29tbWVudHMgYXJlIHdlbGNvbWUNCi9JbmdlbWFyDQoNCg0KDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpJbmdlbWFyIEpvaGFuc3NvbiAgTS5T Yy4NCk1hc3RlciBSZXNlYXJjaGVyDQoNCkVyaWNzc29uIEFCDQpXaXJlbGVzcyBBY2Nlc3MgTmV0 d29ya3MNCkxhYnJhdG9yaWVncsOkbmQgMTENCjk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NClBob25l ICs0Ni0xMDcxIDQzMDQyDQpTTVMvTU1TICs0Ni03MyAwNzggMzI4OTx0ZWw6KzQ2JTIwNzMlMjAw NzglMjAzMiUyMDg5Pg0KaW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmlu Z2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0Kd3d3LmVyaWNzc29uLmNvbTxodHRwOi8v d3d3LmVyaWNzc29uLmNvbT4NCg0KQSBtaXN0YWtlIGlzIHRvIGNvbW1pdCBhIG1pc3VuZGVyc3Rh bmRpbmcNCiAgICAgICAgICAgICAgICAgICAgIEJvYiBEeWxhbg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQoNCg0KLS0NCkNvbGluIFBlcmtpbnMNCmh0dHBzOi8vY3NwZXJr aW5zLm9yZy8NCg0KDQoNCg== --_000_DB4PR07MB348D95672E48A338758E32DC2610DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubS00NTMzNjg1MzEwODcwMjM2 ODIxYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOm1fLTQ1MzM2ODUzMTA4 NzAyMzY4MjFhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo4NzU4MzU0MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzU2MjU0MzkwO30NCkBsaXN0 IGwxDQoJe21zby1saXN0LWlkOjIwMTQ0NTUzOTc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0 MTkzODc1Mjg7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBJYW4gZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgbXVzdCBhZG1pdCB0aGF0IEkgaGF2ZSBwZXJoYXBzIG92ZXJsb29rZWQgcG9zc2libGUgY29t Ym9zIG9mIGxvc3MgYW5kIEVDTiwgdGhlIHByaWNlIHlvdSBwYXkgZm9yIHdvcmtpbmcgdG9vIG11 Y2ggd2l0aCBzaW11bGF0b3JzLiBZb3VyIGFyZ3VtZW50cyBhcmUgdmVyeSBzdHJvbmcgaW5kZWVk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgU0NSZUFNIGNvbmdlc3Rpb24gY29udHJv bCAoUk1DQVQgd29yaykgdGhlIEVDTiBhbmQgbG9zcyBpbmZvIGNvbWVzIGluIHRoZSBzYW1lIGZl ZWRiYWNrIGFuZCB0aGUgaGFuZGxpbmcgb2YgbG9zcyBhbmQgRUNOIGlzIHN0cmFpZ2h0Zm9yd2Fy ZCB0aGVyZS4gUGVyc29uYWxseSBJIHdvdWxkIHByZWZlciBFQ04gaW4gdGhlIEFDSyBmcmFtZXMg YW5kIHRoZSBlYXJsaWVyIGRyYWZ0cyBzdWdnZXN0ZWQgZm9ybWF0cw0KIGZvciB0aGF0LCBJIGhv d2V2ZXIgZ290IHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlcmUgaXMgYSBjZXJ0YWluIHJlc2lzdGFu Y2UgYWdhaW5zdCBhZGRpdGlvbmFsIHRoaW5ncyBpbiB0aGUgQUNLIGZyYW1lID8uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb21dIDxicj4NCjxiPlNl bnQ6PC9iPiBkZW4gMjAgc2VwdGVtYmVyIDIwMTcgMTQ6NDE8YnI+DQo8Yj5Ubzo8L2I+IEluZ2Vt YXIgSm9oYW5zc29uIFMgJmx0O2luZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gQ29saW4gUGVya2lucyAmbHQ7Y3NwQGNzcGVya2lucy5vcmcmZ3Q7OyBN YWdudXMgV2VzdGVybHVuZCAmbHQ7bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tJmd0Ozsg Qm9iIEJyaXNjb2UgKHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0KSAmbHQ7cmVzZWFyY2hAYm9iYnJp c2NvZS5uZXQmZ3Q7OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0 LmNvbSZndDs7IEVnZ2VydCwgTGFycyAobGFyc0BuZXRhcHAuY29tKSAmbHQ7bGFyc0BuZXRhcHAu Y29tJmd0OzsNCiBtYXJjZWxvIGJhZ251bG8gYnJhdW4gJmx0O21hcmNlbG9AaXQudWMzbS5lcyZn dDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gm Z3Q7OyBQaWVycyBPJ0hhbmxvbiAmbHQ7cGllcnMub2hhbmxvbkBjcy5veC5hYy51ayZndDs7IFFV SUMgSUVURiBtYWlsaW5nIGxpc3QgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBEZSBTY2hlcHBlciwg S29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKSAmbHQ7a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxs LWxhYnMuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRUNOIGluIFFVSUM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBTZXAgMjAs IDIwMTcgYXQgNDozOSBBTSwgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+aW5nZW1h ci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBzb3JyeSBmb3IgdGhlIHNsb3RoLWlzaCByZXNw b25zZSAoeW91IHNob3VsZCBzZWUgbWUgdHlwZSZuYnNwOyBhIHRleHQgbWVzc2FnZS4uKS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gc3VtbWFyaXplIHRoZSB0d28g bWFpbiBxdWVzdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KRUNO IGluIEFDSyBmcmFtZSBvciBpbiBhIHNlcGFyYXRlIGZyYW1lIDogR2l2ZW4gdGhlIHJlY2VudCBk aXNjdXNzaW9uIG9uIHRoZSBsaXN0IGFuZCBmZWFyIHRoYXQgdGhlIEFDSyBmcmFtZSBpcyBhbHJl YWR5IGVub3VnaCBjb21wbGV4LCBpdCBzZWVtcyB1bndpc2UgdG8gdHJ5IHRvIGNyYW0gaW4gYWRk aXRpb25hbCBpbmZvIGluIHRoZSBBQ0sgZnJhbWVzLiBTbyBteSBwZXJzb25hbCBmZWVsaW5nIGlz IHRoYXQgd2Ugc2hvdWxkIHVzZSBhIHNlcGFyYXRlDQogZnJhbWUgdHlwZSBmb3IgRUNOICwgYnV0 IHRoaXMgZnJhbWUgdHlwZSBtdXN0IGJlIGEgTVVTVCB0byBpbXBsZW1lbnQgYW5kIHN1cHBvcnQg ISBDb21tZW50cyBhcmUgdmVyeSB3ZWxjb21lLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdh cyBuZXV0cmFsIG9uIHRoaXMgYmVmb3JlLCBidXQgSSBzdGFydGVkIHRoaW5raW5nIGFib3V0IGlt cGxlbWVudGluZyB0aGlzLCBhbmQgc2VwYXJhdGluZyB0aGUgZnJhbWVzIG1ha2VzIGl0IG1vcmUg Y29tcGxleCwgYW5kIHBvdGVudGlhbGx5IHJlYWxseSwgcmVhbGx5IGRpZmZpY3VsdCB0byBnZXQg dGhlIGltcGxlbWVudGF0aW9uIGNvcnJlY3QuJm5ic3A7IEFzIGFuIGV4YW1wbGUsIGlmIHRoZSBm cmFtZXMgd2VyZQ0KIGFjY2lkZW50YWxseSBzZW50IGluIHR3byBzZXBhcmF0ZSBwYWNrZXRzLCBJ IHdvdWxkIGNvdW50IHRoZSBwYWNrZXQgYXMgYWNrZWQsIGFuZCBwb3RlbnRpYWxseSBpbmNyZWFz ZSB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgYW5kIG90aGVyIHN0YXRlIHZhcmlhYmxlcy4mbmJzcDsg SSBtaWdodCBldmVuIHNlbmQgYW4gZXh0cmEgcGFja2V0IGJhc2VkIG9uIHRoaXMgaW5mb3JtYXRp b24uJm5ic3A7IFRoZW4gaW4gdGhlIG5leHQgcGFja2V0IEknZCByZWFsaXplIHRoYXQNCiBwYWNr ZXQgaGFkIGFuIEVDTiBtYXJraW5nLCBhbmQgYWN0dWFsbHkgc2hvdWxkIGhhdmUgYmVlbiB0cmVh dGVkIGFzIGxvc3QgZnJvbSBhIGNvbmdlc3Rpb24gY29udHJvbGxlciBwZXJzcGVjdGl2ZS4mbmJz cDsgSW4gb3JkZXIgdG8gZG8gdGhpcyBjb3JyZWN0bHksIEknZCBoYXZlIHRvIHVuZG8gYSBidW5j aCBvZiB0aGluZ3MuJm5ic3A7IE15IGV4cGVyaWVuY2Ugd2l0aCB1bmRvIGlzIHRoYXQgaXQncyB0 ZXJyaWJseSBlcnJvciBwcm9uZSwgYW5kIEkgd291bGQgbmV2ZXINCiByZWNvbW1lbmQgaXQuJm5i c3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFsdGVybmF0ZWx5LCB0aGUgYWNrIGNvdWxkIGdldCBsb3N0LCBhbmQgdGhlIG5leHQg cGFja2V0IHdvdWxkIGNvbnZleSBFQ04gbWFya2luZyBpbmZvcm1hdGlvbiBmb3IgcGFja2V0cyB0 aGF0IGhhZG4ndCBiZWVuIGFja25vd2xlZGdlZCB5ZXQuJm5ic3A7IFdoaWNoIGlzIGp1c3Qgd2Vp cmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIHdlIHJlcXVpcmUgc3VwcG9ydCBmb3IgRUNOLCB0aGVuIHRoZSBpbXBsZW1lbnRhdGlvbiBo YXMgYSBjZXJ0YWluIGV4dHJhIGxldmVsIG9mIGNvbXBsZXhpdHkuJm5ic3A7IEFzIGlsbHVzdHJh dGVkIGFib3ZlLCBwdXR0aW5nIGl0IGluIG9uZSBmcmFtZSBpcyBhY3R1YWxseSBzaW1wbGVyIG92 ZXJhbGwgaWYgdGhlIGNvbmdlc3Rpb24gY29udHJvbGxlciBuZWVkcyB0byB1c2UgYWxsIHRoZSBp bmZvcm1hdGlvbiBhdA0KIG9uY2UgdG8gYmUgaW1wbGVtZW50ZWQgY29ycmVjdGx5LiZuYnNwOyBU aGlzIHNhbWUgbG9naWMgYXBwbGllcyB0byB0aW1lc3RhbXBzIGFzIHdlbGwsIGluIG15IG9waW5p b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEg bGZvMiI+DQpBcyByZWdhcmRzIHRvIHRoZSBsZXZlbCBvZiBkZXRhaWwgOiBUaGVyZSBhcmUgcHJv cyBhbmQgY29ucyB3aXRoIGJvdGggYWx0ZXJuYXRpdmVzIChtYXJrZWQgYnl0ZXMgb3IgZGV0YWls ZWQgaW5kaWNhdGlvbikuIEkgd291bGQgbGlrZSB0byBoZWFyIHRoZSBvcGluaW9ucyBmcm9tIG90 aGVycyBhcyB3ZWxsIG9uIHRoaXMgbWF0dGVyIC48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9i PiBDb2xpbiBQZXJraW5zIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNzcEBjc3BlcmtpbnMub3Jn IiB0YXJnZXQ9Il9ibGFuayI+Y3NwQGNzcGVya2lucy5vcmc8L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IGRlbiAxNiBhdWd1c3RpIDIwMTcgMTI6NTM8YnI+DQo8Yj5Ubzo8L2I+IEluZ2VtYXIgSm9o YW5zc29uIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+IFFVSUMgSUVURiBtYWlsaW5nIGxpc3QgJmx0OzxhIGhyZWY9 Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4m Z3Q7OyBNYWdudXMgV2VzdGVybHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNz c29uLmNvbTwvYT4mZ3Q7OyBCb2IgQnJpc2NvZSAoPGEgaHJlZj0ibWFpbHRvOnJlc2VhcmNoQGJv YmJyaXNjb2UubmV0IiB0YXJnZXQ9Il9ibGFuayI+cmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQ8L2E+ KQ0KICZsdDs8YSBocmVmPSJtYWlsdG86cmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQiIHRhcmdldD0i X2JsYW5rIj5yZXNlYXJjaEBib2JicmlzY29lLm5ldDwvYT4mZ3Q7OyBQcmF2ZWVuIEJhbGFzdWJy YW1hbmlhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IEVnZ2VydCwgTGFycyAoPGEgaHJl Zj0ibWFpbHRvOmxhcnNAbmV0YXBwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxhcnNAbmV0YXBwLmNv bTwvYT4pDQogJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5ldGFwcC5jb20iIHRhcmdldD0iX2Js YW5rIj5sYXJzQG5ldGFwcC5jb208L2E+Jmd0OzsgbWFyY2VsbyBiYWdudWxvIGJyYXVuICZsdDs8 YSBocmVmPSJtYWlsdG86bWFyY2Vsb0BpdC51YzNtLmVzIiB0YXJnZXQ9Il9ibGFuayI+bWFyY2Vs b0BpdC51YzNtLmVzPC9hPiZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0 bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFuayI+bWlyamEu a3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDwvYT4mZ3Q7Ow0KIFBpZXJzIE8nSGFubG9uICZsdDs8 YSBocmVmPSJtYWlsdG86cGllcnMub2hhbmxvbkBjcy5veC5hYy51ayIgdGFyZ2V0PSJfYmxhbmsi PnBpZXJzLm9oYW5sb25AY3Mub3guYWMudWs8L2E+Jmd0OzsgRGUgU2NoZXBwZXIsIEtvZW4gKE5v a2lhIC0gQkUvQW50d2VycCkgJmx0OzxhIGhyZWY9Im1haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5v a2lhLWJlbGwtbGFicy5jb20iIHRhcmdldD0iX2JsYW5rIj5rb2VuLmRlX3NjaGVwcGVyQG5va2lh LWJlbGwtbGFicy5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRUNOIGluIFFV SUM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gMTYgQXVnIDIwMTcsIGF0IDEwOjMzLCBJbmdlbWFyIEpvaGFuc3NvbiBTICZs dDs8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIj5IaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RmluYWxseSBiYWNr IGZyb20gdmFjYXRpb24sIGFuZCB2ZXJ5IGdyYXRlZnVsIGZvciB0aGUgc3VwcG9ydCB0byBjb250 aW51ZSB0aGUgd29yayB0byBhZGQgRUNOIGluIFFVSUMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkp1c3QgdG8gcmVjYXAuLiB0aGVyZSB3ZXJl IHR3byBtYWluIHRvcGljcyByYWlzZWQgYXQgdGhlIG1lZXRpbmc8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEpIEVDTiBpbmZvIGluIEFD SyBmcmFtZSBvciBpbiBkZWRpY2F0ZWQgZnJhbWUgOiBUaGVyZSB3ZXJlIGNvbmNlcm5zIGFib3V0 IGFkZGluZyBleHRyYSBjb21wbGV4aXR5IGluIGFuIGFscmVhZHkgcG90ZW50aWFsbHkgY29tcGxl eCBBQ0sgZnJhbWUsIG9uZSBjYW4gaGF2ZSBkaWZmZXJpbmcgb3BpbmlvbnMgYWJvdXQNCiB0aGUg Y29tcGxleGl0eSBidXQgY2FuIHVuZGVyc3RhbmQgdGhlIGNvbmNlcm5zLiBBcyBmYXIgYXMgSSBh bSBjb25jZXJuZWQsIGEgc2VwYXJhdGUgZnJhbWUgdHlwZSBmb3IgRUNOIGlzIHBvc3NpYmxlLCBw b3NzaWJseSBvbmUgbmVlZCB0byBhZGQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGFtb3VudCBvZiBu b3QtRUNUIG1hcmtlZCBwYWNrZXRzIGFzIHdlbGwgdG8ga2VlcCB0aGUgc2lnbmFsaW5nIHJvYnVz dCwgdGhpcyBuZWVkcyBmdXJ0aGVyIGludmVzdGlnYXRpb24NCiB0aG91Z2guIE9uZSBjb25jZXJu IHdpdGggYSBzZXBhcmF0ZSBFQ04gZnJhbWUgaXMgdGhhdCBpdCBiZWNvbWVzIGEgbm90LWltcGxl bWVudGVkIG9yIG9wdGlvbmFsIGZlYXR1cmUsIGlzIHRoZXJlIGFueSByZWFzb24gdG8gYmUgd29y cmllZCBhYm91dCB0aGlzID88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjIpIE1vcmUgZGV0YWlsZWQgRUNOIGluZm9ybWF0aW9uIDogRWFy bGllciB2ZXJzaW9ucyBvZiB0aGUgRUNOIGluIFFVSUMgZHJhZnQgKHNlZTxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dCIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dDwvc3Bhbj48L2E+PHNwYW4g Y2xhc3M9Im0tNDUzMzY4NTMxMDg3MDIzNjgyMWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPikNCiBwcm92aWRlZCB3aXRoIGV4YW1wbGVzLiBXZSAoTXlzZWxmLCBLb2VuLCBNaXJq YSBhbmQgUHJhdmVlbikgZGlzY3Vzc2VkIHRoaXMgYW5kIHdlIGNvdWxkIG5vdCBjb21lIHVwIHdp dGggYW55IHVzZSBjYXNlIHdoZXJlIGl0IGlzIGJlbmVmaWNpYWwgdG8ga25vdyBleGFjdGx5IGhv dyBlYWNoIHBhY2tldCBpcyBFQ04gbWFya2VkLiBJIGtub3cgdGhhdCB0aGlzIGtpbmQgb2YgZGV0 YWlsZWQgRUNOIGluZm9ybWF0aW9uIGlzIHN1Z2dlc3RlZCBmb3INCiB0aGUgZ2VuZXJpYyBmZWVk YmFjayBmb3IgUk1DQVQgYW5kIEkgcGVyc29uYWxseSBoYXZlIGEgcHJvYmxlbSB0byBzZWUgdGhl IGdhaW4gd2l0aCB0aGUgZGV0YWlsZWQgRUNOIGluZm9ybWF0aW9uIGFsc28gaGVyZS4gSW5wdXQg ZnJvbSBvdGhlcnMgaXMgdmVyeSB3ZWxjb21lIGhlcmUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Rm9yIHRoZSBSTUNBVCBmb3JtYXQsIHdlIHdhbnRlZCBwZXItcGFja2V0IGxvc3MgYW5kIHRp bWluZyBpbmZvcm1hdGlvbiwgYW5kIGl0IHdhcyBhcyBlYXN5IHRvIGZlZWRiYWNrIHBlci1wYWNr ZXQgRUNOIGluZm9ybWF0aW9uIGFsb25nIHdpdGggaXQgYXMgdG8gZGVzaWduIHNvbWV0aGluZyBk aWZmZXJlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5BIGJlbmVmaXQgb2YgcGVyLXBhY2tldCBFQ04gbWFya2luZyBjb3VsZCBiZSB0 byBhbGxvdyBhIGNvbmdlc3Rpb24gY29udHJvbGxlciB0aGF0IHJlYWN0ZWQgZGlmZmVyZW50bHkg dG8gYnVyc3RzIG9mIGNvbnNlY3V0aXZlIEVDTiBtYXJrcyB0aGFuIGl0IGRpZCB0byBpc29sYXRl ZCBFQ04gbWFya3MsIGdpdmVuDQogdGhlIHNhbWUgZnJhY3Rpb24gb2YgbWFya2VkIHBhY2tldHMg KGkuZS4sIHRoYXQgcmVhY3RlZCB0byBFQ04gbWFya2luZyBldmVudHMgcmF0aGVyIHRoYW4gRUNO IG1hcmtpbmcgcmF0ZSwgbGlrZSBob3cgVENQIHJlc3BvbmRzIHRvIGxvc3MgZXZlbnRzKS4gSSBk b27igJl0IHRoaW5rIHdlIGhhdmUgc3VjaCBhIHRoaW5nLCBidXQgY2VydGFpbmx5IGluIHRoZSBj b250ZXh0IG9mIFJNQ0FUIHdoZXJlIHdl4oCZcmUgZXhwZXJpbWVudGluZyB3aXRoIG5vdmVsDQog Y29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZXMgZm9yIHRyYWZmaWMgdGhhdCBoYXMgdmVyeSBkaWZm ZXJlbnQgY2hhcmFjdGVyaXN0aWNzIHRvIHRyYWRpdGlvbmFsIGJ1bGsgZmxvd3MsIGl0IG1pZ2h0 IGJlIHBsYXVzaWJsZS4gUGVyLXBhY2tldCBtYXJraW5nIGluZm9ybWF0aW9uIGlzIGFsc28gdXNl ZnVsIGZvciB0cm91Ymxlc2hvb3RpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DZXJ0YWlubHkgd2UgbmVlZCB0byBrbm93IG51bWJl ciBvZiBOb3RFQ1QsIEVDVCgwKSwgRUNUKDEpLCBhbmQgRUNOLUNFIG1hcmtzIHNpbmNlIHRoZSBs YXN0IHJlcG9ydCwgYnV0IEkgZ3Vlc3MgdGhhdOKAmXMgYWxyZWFkeSBwb3NzaWJsZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoZWVy cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Q29saW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoZXJlIGFyZSBhIGNvbnNlcXVlbmNlcyB3aXRoIGRldGFpbGVkIEVDTiBtYXJraW5n IGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5hKSBuZWNlc3NhcnkgdG8gY29ycmVsYXRlIHdpdGggdGhlIGxpc3Qgb2YgdHJh bnNtaXR0ZWQgcGFja2V0cywgdGhpcyBpbmNyZWFzZXMgYW1vdW50IG9mIGNvZGUgb24gc2VuZGVy IHNpZGUsIG5vdCBzdXJlIG9mIHRoYXQgaXMgYSBsYXJnZSBjb25jZXJuIGFzIGxvb2t1cCBpcyBh bnl3YXkgbmVlZGVkIHRvIHByb2Nlc3MNCiBpbmNvbWluZyBBQ0tzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmIpIG5lY2Vzc2FyeSB0byBlbWJl ZCBFQ04gaW5mb3JtYXRpb24gaW4gQUNLIGZyYW1lID8sIGF0IGxlYXN0IHRoaXMgd2FzIG15IGNv bmNsdXNpb24gd2hlbiBJIGRldmlzZWQgdGhlIGRldGFpbGVkIEVDTiBtYXJraW5nIGluZm8gaW4g dGhlIDAxIHZlcnNpb24gb2YgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29tbWVudHMgYXJlIHdlbGNvbWU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+L0luZ2VtYXI8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkluZ2VtYXIgSm9oYW5zc29uJm5ic3A7IE0uU2Mu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj5NYXN0ZXIgUmVzZWFyY2hlcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Fcmljc3NvbiBBQjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ V2lyZWxlc3MgQWNjZXNzIE5ldHdvcmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5MYWJyYXRvcmllZ3LD pG5kIDExPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj45NzEgMjgsIEx1bGXDpSwgU3dlZGVuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5QaG9uZSAmIzQzOzQ2LTEwNzEgNDMwNDI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNN Uy9NTVMNCjxhIGhyZWY9InRlbDomIzQzOzQ2JTIwNzMlMjAwNzglMjAzMiUyMDg5IiB0YXJnZXQ9 Il9ibGFuayI+JiM0Mzs0Ni03MyAwNzggMzI4OTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Im1haWx0bzppbmdl bWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+PGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20iPnd3dy5lcmljc3Nvbi5jb208L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6I0NDQ0NERCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMzMzMzMzM7YmFja2dyb3VuZDp3aGl0ZSI+QSBtaXN0YWtlIGlzIHRvIGNv bW1pdCBhIG1pc3VuZGVyc3RhbmRpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMz Ij48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJvYiBEeWxhbjxi cj4NCjwvc3Bhbj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCjxicj4NCi0tJm5ic3A7PGJyPg0KQ29saW4gUGVya2luczxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vY3NwZXJraW5zLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NzcGVy a2lucy5vcmcvPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB348D95672E48A338758E32DC2610DB4PR07MB348eurprd_-- From nobody Wed Sep 20 07:09:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E911331E7 for ; Wed, 20 Sep 2017 07:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 OeHKTf-WqzhN for ; Wed, 20 Sep 2017 07:08:58 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810B7129A89 for ; Wed, 20 Sep 2017 07:08:58 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id t127so1967585ywg.4 for ; Wed, 20 Sep 2017 07:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QtRH2kJpU/PkVPpeCUfWvYIJTZOZDhvA5z5G4H/yN+I=; b=qHbScege8qVIywmu9F7k2GOKaXamOCaM5Q0cAal2+uOKqDsgUaLXLkzbVut572q1Rl 5zPLVYlVuQVWgwDz48LxotR4dk956Wn5sE3Xa9SSoZbLsP+CXmlxHxRz8UGTT219LK5U q4Z2bo8uMKoKRL01fosaMlBLaMrhesLgLAfj6LDATr/dtYY/PIa9Ve6/bPmNBECCf5NS rHluPBtw9xjYj2+WynagVWPNZOKPf/TmKr5Kr56slsy6ZGBtCgdLx1CHqnAwQdEu+Zr9 wFsREuEp8Uc6vPZF3URPlgz0YSOs0bkS8fKB34PuBMQsz+gYh7/z6xKf/zfR7uT1bFZL X+AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QtRH2kJpU/PkVPpeCUfWvYIJTZOZDhvA5z5G4H/yN+I=; b=Z/d4pq41ArBsEaDijZG6mrfrJ769CVhG6NYgAacYhcEObB6J6GzqvAIu+2FS0kTcdV Gwam7/gnBCa9sNAjpliHZ0+cS0ccGeGMAX4BM72S5lpGMa84eiRPogExShOqN7nTyhjl I/5RFQHCh73yoduliaNuv+f0t5/NqIJocuGIqUNFwRMsyygGguuP3sIBxy4Q1CGrR5KV Aq4Ogc5LZ68kRF9zHYTpUMDF0oCGLqbVftewzKF+cZ2YjW9ii4gxcWljnRGtBoKN96zP Twi0QBtnZsiKX9Ts22kfW9OJdb5RRVkbSlXCqPDt5/ybsdeUtW4aGLssfJT1FCnuL/9b fz9A== X-Gm-Message-State: AHPjjUiqeWjvIFmpF1WG5Pdmkhft3RYtd0+woBrij1Q1xn2GUf/MhOS2 l1l4bx87ECxSdrAzG8RHwxqNcDZDR/FPLeIZFrjUMQ== X-Google-Smtp-Source: AOwi7QBikYEvqh8FLKravL2wFnqih6LAdoAKe5XQrTYv753q1bIIPPP7rgVY0iSuaB/ukThbJfSsN2x94X7l3AphFPE= X-Received: by 10.37.51.130 with SMTP id z124mr3816372ybz.154.1505916537337; Wed, 20 Sep 2017 07:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.4 with HTTP; Wed, 20 Sep 2017 07:08:36 -0700 (PDT) In-Reply-To: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> From: Ian Swett Date: Wed, 20 Sep 2017 10:08:36 -0400 Message-ID: Subject: Re: ECN in QUIC To: Ingemar Johansson S Cc: Colin Perkins , Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , "Eggert, Lars (lars@netapp.com)" , marcelo bagnulo braun , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Piers O'Hanlon" , QUIC IETF mailing list , "De Schepper, Koen (Nokia - BE/Antwerp)" Content-Type: multipart/alternative; boundary="001a11489f16459da005599f8498" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:09:02 -0000 --001a11489f16459da005599f8498 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think there are good reasons to keep frames smaller and simpler in general. But in this particular case, I think there are strong arguments for putting ECN in the ACK frames. I suspect this would have come up as soon as someone implemented ECN in QUIC. On Wed, Sep 20, 2017 at 9:27 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Thanks Ian for the prompt response. > > I must admit that I have perhaps overlooked possible combos of loss and > ECN, the price you pay for working too much with simulators. Your argumen= ts > are very strong indeed. > > > > In the SCReAM congestion control (RMCAT work) the ECN and loss info comes > in the same feedback and the handling of loss and ECN is straightforward > there. Personally I would prefer ECN in the ACK frames and the earlier > drafts suggested formats for that, I however got the impression that ther= e > is a certain resistance against additional things in the ACK frame ?. > > > > /Ingemar > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* den 20 september 2017 14:41 > *To:* Ingemar Johansson S > *Cc:* Colin Perkins ; Magnus Westerlund < > magnus.westerlund@ericsson.com>; Bob Briscoe (research@bobbriscoe.net) < > research@bobbriscoe.net>; Praveen Balasubramanian ; > Eggert, Lars (lars@netapp.com) ; marcelo bagnulo braun < > marcelo@it.uc3m.es>; Mirja K=C3=BChlewind ; > Piers O'Hanlon ; QUIC IETF mailing list < > quic@ietf.org>; De Schepper, Koen (Nokia - BE/Antwerp) < > koen.de_schepper@nokia-bell-labs.com> > > *Subject:* Re: ECN in QUIC > > > > > > On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > Hi > > > > And sorry for the sloth-ish response (you should see me type a text > message..). > > To summarize the two main questions > > > > 1. ECN in ACK frame or in a separate frame : Given the recent > discussion on the list and fear that the ACK frame is already enough > complex, it seems unwise to try to cram in additional info in the ACK > frames. So my personal feeling is that we should use a separate frame = type > for ECN , but this frame type must be a MUST to implement and support = ! > Comments are very welcome. > > I was neutral on this before, but I started thinking about implementing > this, and separating the frames makes it more complex, and potentially > really, really difficult to get the implementation correct. As an exampl= e, > if the frames were accidentally sent in two separate packets, I would cou= nt > the packet as acked, and potentially increase the congestion window and > other state variables. I might even send an extra packet based on this > information. Then in the next packet I'd realize that packet had an ECN > marking, and actually should have been treated as lost from a congestion > controller perspective. In order to do this correctly, I'd have to undo = a > bunch of things. My experience with undo is that it's terribly error > prone, and I would never recommend it. > > > > Alternately, the ack could get lost, and the next packet would convey ECN > marking information for packets that hadn't been acknowledged yet. Which > is just weird. > > > > If we require support for ECN, then the implementation has a certain extr= a > level of complexity. As illustrated above, putting it in one frame is > actually simpler overall if the congestion controller needs to use all th= e > information at once to be implemented correctly. This same logic applies > to timestamps as well, in my opinion. > > > > > 1. > 2. As regards to the level of detail : There are pros and cons with > both alternatives (marked bytes or detailed indication). I would like = to > hear the opinions from others as well on this matter . > > > > /Ingemar > > > > *From:* Colin Perkins [mailto:csp@csperkins.org] > *Sent:* den 16 augusti 2017 12:53 > *To:* Ingemar Johansson S > *Cc:* QUIC IETF mailing list ; Magnus Westerlund < > magnus.westerlund@ericsson.com>; Bob Briscoe (research@bobbriscoe.net) < > research@bobbriscoe.net>; Praveen Balasubramanian ; > Eggert, Lars (lars@netapp.com) ; marcelo bagnulo braun < > marcelo@it.uc3m.es>; Mirja K=C3=BChlewind ; > Piers O'Hanlon ; De Schepper, Koen (Nokia - > BE/Antwerp) > *Subject:* Re: ECN in QUIC > > > > > > On 16 Aug 2017, at 10:33, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > > > Hi > > > > Finally back from vacation, and very grateful for the support to continue > the work to add ECN in QUIC. > > Just to recap.. there were two main topics raised at the meeting > > > > 1) ECN info in ACK frame or in dedicated frame : There were concerns abou= t > adding extra complexity in an already potentially complex ACK frame, one > can have differing opinions about the complexity but can understand the > concerns. As far as I am concerned, a separate frame type for ECN is > possible, possibly one need to add information about the amount of not-EC= T > marked packets as well to keep the signaling robust, this needs further > investigation though. One concern with a separate ECN frame is that it > becomes a not-implemented or optional feature, is there any reason to be > worried about this ? > > > > 2) More detailed ECN information : Earlier versions of the ECN in QUIC > draft (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt ) > provided with examples. We (Myself, Koen, Mirja and Praveen) discussed th= is > and we could not come up with any use case where it is beneficial to know > exactly how each packet is ECN marked. I know that this kind of detailed > ECN information is suggested for the generic feedback for RMCAT and I > personally have a problem to see the gain with the detailed ECN informati= on > also here. Input from others is very welcome here. > > > > For the RMCAT format, we wanted per-packet loss and timing information, > and it was as easy to feedback per-packet ECN information along with it a= s > to design something different. > > > > A benefit of per-packet ECN marking could be to allow a congestion > controller that reacted differently to bursts of consecutive ECN marks th= an > it did to isolated ECN marks, given the same fraction of marked packets > (i.e., that reacted to ECN marking events rather than ECN marking rate, > like how TCP responds to loss events). I don=E2=80=99t think we have such= a thing, > but certainly in the context of RMCAT where we=E2=80=99re experimenting w= ith novel > congestion control schemes for traffic that has very different > characteristics to traditional bulk flows, it might be plausible. > Per-packet marking information is also useful for troubleshooting. > > > > Certainly we need to know number of NotECT, ECT(0), ECT(1), and ECN-CE > marks since the last report, but I guess that=E2=80=99s already possible. > > > > Cheers, > > Colin > > > > > > > > > > There are a consequences with detailed ECN marking information. > > a) necessary to correlate with the list of transmitted packets, this > increases amount of code on sender side, not sure of that is a large > concern as lookup is anyway needed to process incoming ACKs > > b) necessary to embed ECN information in ACK frame ?, at least this was m= y > conclusion when I devised the detailed ECN marking info in the 01 version > of the draft. > > > > Comments are welcome > > /Ingemar > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 <+46%2073%20078%2032%2089> > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > A mistake is to commit a misunderstanding > Bob Dylan > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a11489f16459da005599f8498 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think there are good reasons to keep frames smaller and = simpler in general.=C2=A0 But in this particular case, I think there are st= rong arguments for putting ECN in the ACK frames.=C2=A0 I suspect this woul= d have come up as soon as someone implemented ECN in QUIC.

On Wed, Sep 20, 2017 at 9:2= 7 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com= > wrote:

Thanks Ian for the prompt response.

I must admit that I have perhaps overlooked possible= combos of loss and ECN, the price you pay for working too much with simula= tors. Your arguments are very strong indeed.

=C2=A0

In the SCReAM congestion control (RMCAT work) the EC= N and loss info comes in the same feedback and the handling of loss and ECN= is straightforward there. Personally I would prefer ECN in the ACK frames = and the earlier drafts suggested formats for that, I however got the impression that there is a certain resistance = against additional things in the ACK frame ?.

=C2=A0

/Ingemar

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: den 20 september 2017 14:41
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>=
Cc: Colin Perkins <csp@csperkins.org>; Magnus Westerlund <magnus.westerlund= @ericsson.com>; Bob Briscoe (research@bobbriscoe.net) <research@bobbriscoe.net&g= t;; Praveen Balasubramanian <pravb@microsoft.com>; Eggert, Lars (lars@netapp.com) <lars@netapp.com>; marcelo bagnulo braun <marcelo@it.uc3m.es>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik= .ee.ethz.ch>; Piers O'Hanlon <piers.ohanlon@cs.ox.ac.uk>; QUI= C IETF mailing list <= quic@ietf.org>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_= schepper@nokia-bell-labs.com>


Subject: Re: ECN in QUIC

=C2=A0

=C2=A0

On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S= <= ingemar.s.johansson@ericsson.com> wrote:

Hi

=C2=A0

And sorry for the sloth-ish response (you should see= me type=C2=A0 a text message..).

To summarize the two main questions

=C2=A0

  1. ECN in ACK frame or in a separate frame : Given the recent discussion on th= e list and fear that the ACK frame is already enough complex, it seems unwi= se to try to cram in additional info in the ACK frames. So my personal feel= ing is that we should use a separate frame type for ECN , but this frame type must be a MUST to implement and s= upport ! Comments are very welcome.

I was neutral on this before, but I started thinking= about implementing this, and separating the frames makes it more complex, = and potentially really, really difficult to get the implementation correct.= =C2=A0 As an example, if the frames were accidentally sent in two separate packets, I would count the packet as ack= ed, and potentially increase the congestion window and other state variable= s.=C2=A0 I might even send an extra packet based on this information.=C2=A0= Then in the next packet I'd realize that packet had an ECN marking, and actually should have been treated as lost f= rom a congestion controller perspective.=C2=A0 In order to do this correctl= y, I'd have to undo a bunch of things.=C2=A0 My experience with undo is= that it's terribly error prone, and I would never recommend it.=C2=A0=C2=A0

=C2=A0

Alternately, the ack could get lost, and the next pa= cket would convey ECN marking information for packets that hadn't been = acknowledged yet.=C2=A0 Which is just weird.

=C2=A0

If we require support for ECN, then the implementati= on has a certain extra level of complexity.=C2=A0 As illustrated above, put= ting it in one frame is actually simpler overall if the congestion controll= er needs to use all the information at once to be implemented correctly.=C2=A0 This same logic applies to timesta= mps as well, in my opinion.

=C2=A0

  1. =C2=A0
  2. As regards to the level of detail : There are pros and cons with both alter= natives (marked bytes or detailed indication). I would like to hear the opi= nions from others as well on this matter .

=C2=A0

/Ingemar

=C2=A0

From: Colin Perkins [mailto:csp@csperkins.org]
Sent: den 16 augusti 2017 12:53
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>=
Cc: QUIC IETF mailing list <quic@ietf.org>; Magnus Westerlund <magnus.westerlund@erics= son.com>; Bob Briscoe (research@bobbriscoe.net) <research@= bobbriscoe.net>; Praveen Balasubramanian <pravb@microsoft.com>; Eggert, Lars= (lars@netapp.com) <lars@netapp.com>; marcelo bagnulo braun <marcelo@it.uc3m.es>; Mirja K=C3=BChlewind <mirja.kuehlew= ind@tik.ee.ethz.ch>; Piers O'Hanlon <piers.ohanlon@cs.ox.ac.uk>; De Schepper, Koen (Nokia - B= E/Antwerp) <koen.de_schepper@nokia-bell-labs.com>
Subject: Re: ECN in QUIC

=C2=A0

=C2=A0

On 16 Aug 2017, at 10:33, Ingemar Johansson S <ingemar= .s.johansson@ericsson.com> wrote:

=C2=A0

Hi

=C2=A0

Finally back from vacation, and very grateful for th= e support to continue the work to add ECN in QUIC.

Just to recap.. there were two main topics raised at= the meeting

=C2=A0

1) ECN info in ACK frame or in dedicated frame : The= re were concerns about adding extra complexity in an already potentially co= mplex ACK frame, one can have differing opinions about the complexity but can understand the concerns. As far as I am concerned, = a separate frame type for ECN is possible, possibly one need to add informa= tion about the amount of not-ECT marked packets as well to keep the signali= ng robust, this needs further investigation though. One concern with a separate ECN frame is that it becomes a not-imp= lemented or optional feature, is there any reason to be worried about this = ?

=C2=A0

2) More detailed ECN information : Earlier versions = of the ECN in QUIC draft (seehttp= s://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt<= span class=3D"m_-1966900277889375114m-4533685310870236821apple-converted-sp= ace">=C2=A0) provided with examples. We (Myself, Koen, Mirja and Praveen) discussed thi= s and we could not come up with any use case where it is beneficial to know= exactly how each packet is ECN marked. I know that this kind of detailed E= CN information is suggested for the generic feedback for RMCAT and I personally have a problem to see the = gain with the detailed ECN information also here. Input from others is very= welcome here.

=C2=A0

For the RMCAT format, we wanted per-packet loss and = timing information, and it was as easy to feedback per-packet ECN informati= on along with it as to design something different.

=C2=A0

A benefit of per-packet ECN marking could be to allo= w a congestion controller that reacted differently to bursts of consecutive= ECN marks than it did to isolated ECN marks, given the same fraction of marked packets (i.e., that reacted to ECN marking eve= nts rather than ECN marking rate, like how TCP responds to loss events). I = don=E2=80=99t think we have such a thing, but certainly in the context of R= MCAT where we=E2=80=99re experimenting with novel congestion control schemes for traffic that has very different characteris= tics to traditional bulk flows, it might be plausible. Per-packet marking i= nformation is also useful for troubleshooting.

=C2=A0

Certainly we need to know number of NotECT, ECT(0), = ECT(1), and ECN-CE marks since the last report, but I guess that=E2=80=99s = already possible.

=C2=A0

Cheers,

Colin

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

There are a consequences with detailed ECN marking i= nformation.

a) necessary to correlate with the list of transmitt= ed packets, this increases amount of code on sender side, not sure of that = is a large concern as lookup is anyway needed to process incoming ACKs

b) necessary to embed ECN information in ACK frame ?= , at least this was my conclusion when I devised the detailed ECN marking i= nfo in the 01 version of the draft.

=C2=A0

Comments are welcome

/Ingemar

=C2=A0

=C2=A0

=C2=A0

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

Ingemar Johansson=C2=A0 M.Sc.

Master Researcher

=C2=A0

Ericsson AB

Wireless Access Networks

Labratoriegr=C3=A4nd 11

971 28, Lule=C3=A5, Sweden

Phone +46-1071 43042

=C2=A0

A mistake is to commit= a misunderstanding
=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 Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0



--=C2=A0
Colin Perkins
https://csperkins.org/=

=C2=A0

=C2=A0


--001a11489f16459da005599f8498-- From nobody Wed Sep 20 07:15:01 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F04A134216 for ; Wed, 20 Sep 2017 07:15:00 -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 autolearn_force=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 vjfeHk0bheLv for ; Wed, 20 Sep 2017 07:14:57 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BAA13320B for ; Wed, 20 Sep 2017 07:14:57 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id AD7A3340D5A; Wed, 20 Sep 2017 16:14:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.15064); Wed, 20 Sep 2017 16:14:55 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 20 Sep 2017 16:14:55 +0200 (CEST) Received: from [195.176.111.14] (account ietf@trammell.ch HELO public-docking-cx-0363.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 30260619; Wed, 20 Sep 2017 16:14:55 +0200 From: "Brian Trammell (IETF)" Message-Id: <77BE2627-FAF0-4347-8DFF-60D190119ACC@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_E2322C38-47CF-4C49-80CA-AA257783CDB6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ECN in QUIC Date: Wed, 20 Sep 2017 16:14:54 +0200 In-Reply-To: Cc: QUIC IETF mailing list To: Ian Swett References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:15:00 -0000 --Apple-Mail=_E2322C38-47CF-4C49-80CA-AA257783CDB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Ian, all, delurking momentarily to say... > On 20 Sep 2017, at 14:41, Ian Swett wrote: >=20 >=20 > On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S = wrote: >> Hi >>=20 >>=20 >>=20 >> And sorry for the sloth-ish response (you should see me type a text = message..). >>=20 >> To summarize the two main questions >>=20 >> =E2=80=A2 ECN in ACK frame or in a separate frame : Given the = recent discussion on the list and fear that the ACK frame is already = enough complex, it seems unwise to try to cram in additional info in the = ACK frames. So my personal feeling is that we should use a separate = frame type for ECN , but this frame type must be a MUST to implement and = support ! Comments are very welcome. >=20 > I was neutral on this before, but I started thinking about = implementing this, and separating the frames makes it more complex, and = potentially really, really difficult to get the implementation correct. = As an example, if the frames were accidentally sent in two separate = packets, I would count the packet as acked, and potentially increase the = congestion window and other state variables. I might even send an extra = packet based on this information. Then in the next packet I'd realize = that packet had an ECN marking, and actually should have been treated as = lost from a congestion controller perspective. In order to do this = correctly, I'd have to undo a bunch of things. My experience with undo = is that it's terribly error prone, and I would never recommend it. What Ian said. This is a tradeoff between complexity in frame structure = (and therefore frame parsing) and complexity in handling congestion = control dynamics in an environment in which we'll be receiving both loss = and explicit congestion control signaling. Careful design of the frame = structure and decent testing can mitigate the risk that the former will = cause problems. The latter is a scary swamp filled with nightmares no = matter what you do. Cheers, Brian > Alternately, the ack could get lost, and the next packet would convey = ECN marking information for packets that hadn't been acknowledged yet. = Which is just weird. >=20 > If we require support for ECN, then the implementation has a certain = extra level of complexity. As illustrated above, putting it in one = frame is actually simpler overall if the congestion controller needs to = use all the information at once to be implemented correctly. This same = logic applies to timestamps as well, in my opinion. >=20 > =E2=80=A2 As regards to the level of detail : There are pros and = cons with both alternatives (marked bytes or detailed indication). I = would like to hear the opinions from others as well on this matter . >=20 >=20 > /Ingemar >=20 >=20 >=20 >=20 > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: den 16 augusti 2017 12:53 > To: Ingemar Johansson S > Cc: QUIC IETF mailing list ; Magnus Westerlund = ; Bob Briscoe (research@bobbriscoe.net) = ; Praveen Balasubramanian = ; Eggert, Lars (lars@netapp.com) ; = marcelo bagnulo braun ; Mirja K=C3=BChlewind = ; Piers O'Hanlon = ; De Schepper, Koen (Nokia - BE/Antwerp) = > Subject: Re: ECN in QUIC >=20 >=20 >=20 >=20 >=20 > On 16 Aug 2017, at 10:33, Ingemar Johansson S = wrote: >=20 >=20 >=20 > Hi >=20 >=20 >=20 > Finally back from vacation, and very grateful for the support to = continue the work to add ECN in QUIC. >=20 > Just to recap.. there were two main topics raised at the meeting >=20 >=20 >=20 > 1) ECN info in ACK frame or in dedicated frame : There were concerns = about adding extra complexity in an already potentially complex ACK = frame, one can have differing opinions about the complexity but can = understand the concerns. As far as I am concerned, a separate frame type = for ECN is possible, possibly one need to add information about the = amount of not-ECT marked packets as well to keep the signaling robust, = this needs further investigation though. One concern with a separate ECN = frame is that it becomes a not-implemented or optional feature, is there = any reason to be worried about this ? >=20 >=20 >=20 > 2) More detailed ECN information : Earlier versions of the ECN in QUIC = draft (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt ) = provided with examples. We (Myself, Koen, Mirja and Praveen) discussed = this and we could not come up with any use case where it is beneficial = to know exactly how each packet is ECN marked. I know that this kind of = detailed ECN information is suggested for the generic feedback for RMCAT = and I personally have a problem to see the gain with the detailed ECN = information also here. Input from others is very welcome here. >=20 >=20 >=20 > For the RMCAT format, we wanted per-packet loss and timing = information, and it was as easy to feedback per-packet ECN information = along with it as to design something different. >=20 >=20 >=20 > A benefit of per-packet ECN marking could be to allow a congestion = controller that reacted differently to bursts of consecutive ECN marks = than it did to isolated ECN marks, given the same fraction of marked = packets (i.e., that reacted to ECN marking events rather than ECN = marking rate, like how TCP responds to loss events). I don=E2=80=99t = think we have such a thing, but certainly in the context of RMCAT where = we=E2=80=99re experimenting with novel congestion control schemes for = traffic that has very different characteristics to traditional bulk = flows, it might be plausible. Per-packet marking information is also = useful for troubleshooting. >=20 >=20 >=20 > Certainly we need to know number of NotECT, ECT(0), ECT(1), and ECN-CE = marks since the last report, but I guess that=E2=80=99s already = possible. >=20 >=20 >=20 > Cheers, >=20 > Colin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > There are a consequences with detailed ECN marking information. >=20 > a) necessary to correlate with the list of transmitted packets, this = increases amount of code on sender side, not sure of that is a large = concern as lookup is anyway needed to process incoming ACKs >=20 > b) necessary to embed ECN information in ACK frame ?, at least this = was my conclusion when I devised the detailed ECN marking info in the 01 = version of the draft. >=20 >=20 >=20 > Comments are welcome >=20 > /Ingemar >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Ingemar Johansson M.Sc. >=20 > Master Researcher >=20 >=20 >=20 > Ericsson AB >=20 > Wireless Access Networks >=20 > Labratoriegr=C3=A4nd 11 >=20 > 971 28, Lule=C3=A5, Sweden >=20 > Phone +46-1071 43042 >=20 > SMS/MMS +46-73 078 3289 >=20 > ingemar.s.johansson@ericsson.com >=20 > www.ericsson.com >=20 >=20 >=20 > A mistake is to commit a misunderstanding > Bob Dylan > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_E2322C38-47CF-4C49-80CA-AA257783CDB6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZwnffAAoJEIoSt78L6kajs44QAKBXgWqLG0NkQvacikLDKqUL gUqwMEz9hdkPRHVJxD860Ia9E1S9Zt0xv5vI2IxC662wVvwFEcrlxSItVIWg8MlI 6WphirwnjdaE6iDD8Qsf3xGBN9nHyJu4LO164nzK4BHVALwQtxlTVmA8x2FiIo5a 0KaXyJjL5F+uPif+yP2Rc/5LFhqkqiI9ZisaLH1K21T/or5NCjc6YlbFlDfKiXmw 6BiP44guCYVzrOxPtqK1Y33u9Yk0YaBzNIQlNpYJHr07e9qOUvfVA7GHMQIX/k9W gwIv4VkEudPDDt1KK/aRx8g38vXZkqUaMysdb2tzSER54G8B0zfbgXyTxTn6dMKa 5qwK3WrdonT2oxdfwXRo838RVQn+Ep1LL1kiE6Xo5MVuRA6l8pmraad1HsJdtxQN q2dFlvy4cYn92ORJ0Y/Nxg04tEj3EuM8cnSTXQ9CKVV5dwbCrhQIgaFi1ZrA2uJz Hx3/4RWGHDCFTaG3KO7EJMtuePIE2pXID6erVES6T4fyIdxcQCQwH5Aj7grIPANj iLwjexz8IDQ/2A1UwktXUJeQfiwO/HMhGbswGLES+PolMDjm3nNBPVHhNWe6GBM1 Ili9gxczDkFfEAYyasXewgMAHzmsGvSv23TKFRtciIOgJETJgdTjJP5hRKVQkZaj dJqByRJoq98iGa9vp7p1 =yt1y -----END PGP SIGNATURE----- --Apple-Mail=_E2322C38-47CF-4C49-80CA-AA257783CDB6-- From nobody Wed Sep 20 07:22:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DBD133053 for ; Wed, 20 Sep 2017 07:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 fx4Y9vsayl26 for ; Wed, 20 Sep 2017 07:22:04 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB3E13293A for ; Wed, 20 Sep 2017 07:22:03 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id x54so2902353qth.12 for ; Wed, 20 Sep 2017 07:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=46NN4loN1AD9F6+gYn8JREifyW+cdhZGT/FU+JuqvMc=; b=WFJkFDfMJ3/DmoVI1bBD+dyzEFh5wSoFaN5XQD+rnl+hiByiy3W4ZgwZjgAbge1xNV zm9+drfX4pKvwGqO1SGPL34i2cmWVm0isPnK7X9tFOl9Sn6IMLaBOySM8p+gQ72FkHx+ /fipI+xcvX4y54iABSo6YNshIfE6Tr0B4n3opjcq4RQLoJ+Zj1fhj3/HZPLM8kXZjlR2 PZDePzSuOrfb/gTpG5ysAPUa0CaZM45uc4So5hm1IAGjzehFKJpHPxlJgrzbCCszPY3d mbPze2T4XlFL+57JzdkghzbFlZlCptgNQLjqi7y9zhrB5I9ZJW6wbKm+76hC1jE7fdSU RtHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=46NN4loN1AD9F6+gYn8JREifyW+cdhZGT/FU+JuqvMc=; b=MsunTHvkk0cXo6hJDyGneqGmqtyTyIeo7mUqZuZc+SaBEXdBCovckkbnD+/KXyNkd4 /s55kZVHhvA4YA/+a4zLhliLzSVyt6eilSFce6gbClKwknBqII4GU+WiUX0g088Wsdcf WTfSLbPK1zNaqPwugfFoWAaB/TMbE3dU0r5cEk1aL7pVLBK8oFEApPduCDX5nWmeHivc l7NzvaNIFFldsw/mZqdK8T7akqAhaFlNhFiU3tNKO7DmYlz4LPdp+F7+5au6W/bI63zd wFK8BH92Wnx35W7Dg+yWMKim/30CbApN0NmADJUaSiI8GnQlVGxoyuTWX4xsbZx6KGN9 O8LA== X-Gm-Message-State: AHPjjUhg1hG9LBVf8nYydLHfkTsZeYnPueYUZreOU6TZD3dXtGthZbMc ZnG32DdUbqyRzV+O2pm9YnfvWNJrFd6Ygqz5Kx8PoQ== X-Google-Smtp-Source: AOwi7QBfwL4lC785k3/TKP8KDNWJwOFwEEMoX98nuaV02YZ74+hMkq8fmRB6Isn+ixrxruWyd7/MVDawFCu6UNA+DD4= X-Received: by 10.200.52.117 with SMTP id v50mr1832066qtb.333.1505917322671; Wed, 20 Sep 2017 07:22:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.144.129 with HTTP; Wed, 20 Sep 2017 07:21:42 -0700 (PDT) In-Reply-To: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> From: Frank Kastenholz Date: Wed, 20 Sep 2017 10:21:42 -0400 Message-ID: Subject: Re: ECN in QUIC To: Ingemar Johansson S Cc: Ian Swett , Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , "Eggert, Lars (lars@netapp.com)" , marcelo bagnulo braun , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Piers O'Hanlon" , QUIC IETF mailing list , Colin Perkins , "De Schepper, Koen (Nokia - BE/Antwerp)" Content-Type: multipart/alternative; boundary="001a11394a3614ea5b05599fb3da" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:22:08 -0000 --001a11394a3614ea5b05599fb3da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi I wonder if the ACK can be kept simple by including only the ECN information from the most recently received packet, or maybe N (where N is fairly small) most recently received packets? This would reduce the amount of information to be carried as well as the complexity of including it. I confess that I am not familiar with the various congestion control algorithms ... but I would imagine that more recent ECN information would be more useful than older ECN info. No? Frank Kastenholz On Wed, Sep 20, 2017 at 9:27 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Thanks Ian for the prompt response. > > I must admit that I have perhaps overlooked possible combos of loss and > ECN, the price you pay for working too much with simulators. Your argumen= ts > are very strong indeed. > > > > In the SCReAM congestion control (RMCAT work) the ECN and loss info comes > in the same feedback and the handling of loss and ECN is straightforward > there. Personally I would prefer ECN in the ACK frames and the earlier > drafts suggested formats for that, I however got the impression that ther= e > is a certain resistance against additional things in the ACK frame ?. > > > > /Ingemar > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* den 20 september 2017 14:41 > *To:* Ingemar Johansson S > *Cc:* Colin Perkins ; Magnus Westerlund < > magnus.westerlund@ericsson.com>; Bob Briscoe (research@bobbriscoe.net) < > research@bobbriscoe.net>; Praveen Balasubramanian ; > Eggert, Lars (lars@netapp.com) ; marcelo bagnulo braun < > marcelo@it.uc3m.es>; Mirja K=C3=BChlewind ; > Piers O'Hanlon ; QUIC IETF mailing list < > quic@ietf.org>; De Schepper, Koen (Nokia - BE/Antwerp) < > koen.de_schepper@nokia-bell-labs.com> > > *Subject:* Re: ECN in QUIC > > > > > > On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > Hi > > > > And sorry for the sloth-ish response (you should see me type a text > message..). > > To summarize the two main questions > > > > 1. ECN in ACK frame or in a separate frame : Given the recent > discussion on the list and fear that the ACK frame is already enough > complex, it seems unwise to try to cram in additional info in the ACK > frames. So my personal feeling is that we should use a separate frame = type > for ECN , but this frame type must be a MUST to implement and support = ! > Comments are very welcome. > > I was neutral on this before, but I started thinking about implementing > this, and separating the frames makes it more complex, and potentially > really, really difficult to get the implementation correct. As an exampl= e, > if the frames were accidentally sent in two separate packets, I would cou= nt > the packet as acked, and potentially increase the congestion window and > other state variables. I might even send an extra packet based on this > information. Then in the next packet I'd realize that packet had an ECN > marking, and actually should have been treated as lost from a congestion > controller perspective. In order to do this correctly, I'd have to undo = a > bunch of things. My experience with undo is that it's terribly error > prone, and I would never recommend it. > > > > Alternately, the ack could get lost, and the next packet would convey ECN > marking information for packets that hadn't been acknowledged yet. Which > is just weird. > > > > If we require support for ECN, then the implementation has a certain extr= a > level of complexity. As illustrated above, putting it in one frame is > actually simpler overall if the congestion controller needs to use all th= e > information at once to be implemented correctly. This same logic applies > to timestamps as well, in my opinion. > > > > > 1. > 2. As regards to the level of detail : There are pros and cons with > both alternatives (marked bytes or detailed indication). I would like = to > hear the opinions from others as well on this matter . > > > > /Ingemar > > > > *From:* Colin Perkins [mailto:csp@csperkins.org] > *Sent:* den 16 augusti 2017 12:53 > *To:* Ingemar Johansson S > *Cc:* QUIC IETF mailing list ; Magnus Westerlund < > magnus.westerlund@ericsson.com>; Bob Briscoe (research@bobbriscoe.net) < > research@bobbriscoe.net>; Praveen Balasubramanian ; > Eggert, Lars (lars@netapp.com) ; marcelo bagnulo braun < > marcelo@it.uc3m.es>; Mirja K=C3=BChlewind ; > Piers O'Hanlon ; De Schepper, Koen (Nokia - > BE/Antwerp) > *Subject:* Re: ECN in QUIC > > > > > > On 16 Aug 2017, at 10:33, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > > > Hi > > > > Finally back from vacation, and very grateful for the support to continue > the work to add ECN in QUIC. > > Just to recap.. there were two main topics raised at the meeting > > > > 1) ECN info in ACK frame or in dedicated frame : There were concerns abou= t > adding extra complexity in an already potentially complex ACK frame, one > can have differing opinions about the complexity but can understand the > concerns. As far as I am concerned, a separate frame type for ECN is > possible, possibly one need to add information about the amount of not-EC= T > marked packets as well to keep the signaling robust, this needs further > investigation though. One concern with a separate ECN frame is that it > becomes a not-implemented or optional feature, is there any reason to be > worried about this ? > > > > 2) More detailed ECN information : Earlier versions of the ECN in QUIC > draft (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt ) > provided with examples. We (Myself, Koen, Mirja and Praveen) discussed th= is > and we could not come up with any use case where it is beneficial to know > exactly how each packet is ECN marked. I know that this kind of detailed > ECN information is suggested for the generic feedback for RMCAT and I > personally have a problem to see the gain with the detailed ECN informati= on > also here. Input from others is very welcome here. > > > > For the RMCAT format, we wanted per-packet loss and timing information, > and it was as easy to feedback per-packet ECN information along with it a= s > to design something different. > > > > A benefit of per-packet ECN marking could be to allow a congestion > controller that reacted differently to bursts of consecutive ECN marks th= an > it did to isolated ECN marks, given the same fraction of marked packets > (i.e., that reacted to ECN marking events rather than ECN marking rate, > like how TCP responds to loss events). I don=E2=80=99t think we have such= a thing, > but certainly in the context of RMCAT where we=E2=80=99re experimenting w= ith novel > congestion control schemes for traffic that has very different > characteristics to traditional bulk flows, it might be plausible. > Per-packet marking information is also useful for troubleshooting. > > > > Certainly we need to know number of NotECT, ECT(0), ECT(1), and ECN-CE > marks since the last report, but I guess that=E2=80=99s already possible. > > > > Cheers, > > Colin > > > > > > > > > > There are a consequences with detailed ECN marking information. > > a) necessary to correlate with the list of transmitted packets, this > increases amount of code on sender side, not sure of that is a large > concern as lookup is anyway needed to process incoming ACKs > > b) necessary to embed ECN information in ACK frame ?, at least this was m= y > conclusion when I devised the detailed ECN marking info in the 01 version > of the draft. > > > > Comments are welcome > > /Ingemar > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 <+46%2073%20078%2032%2089> > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > A mistake is to commit a misunderstanding > Bob Dylan > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --=20 Thanks Frank Kastenholz --001a11394a3614ea5b05599fb3da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

I wonder if the ACK can be kept simp= le by including only the ECN information from the most recently received pa= cket, or maybe N (where N is fairly small) most recently received packets? = This would reduce the amount of information to be carried as well as the co= mplexity of including it.

I confess that I am not = familiar with the various congestion control algorithms ... but I would ima= gine that more recent ECN information would be more useful than older ECN i= nfo. No?

Frank Kastenholz

On Wed, Sep 20, 2017 at 9:27 A= M, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Thanks Ian for the prompt response.

I must admit that I have perhaps overlooked possible= combos of loss and ECN, the price you pay for working too much with simula= tors. Your arguments are very strong indeed.

=C2=A0

In the SCReAM congestion control (RMCAT work) the EC= N and loss info comes in the same feedback and the handling of loss and ECN= is straightforward there. Personally I would prefer ECN in the ACK frames = and the earlier drafts suggested formats for that, I however got the impression that there is a certain resistance = against additional things in the ACK frame ?.

=C2=A0

/Ingemar

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: den 20 september 2017 14:41
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>=
Cc: Colin Perkins <csp@csperkins.org>; Magnus Westerlund <magnus.westerlund= @ericsson.com>; Bob Briscoe (research@bobbriscoe.net) <research@bobbriscoe.net&g= t;; Praveen Balasubramanian <pravb@microsoft.com>; Eggert, Lars (lars@netapp.com) <lars@netapp.com>; marcelo bagnulo braun <marcelo@it.uc3m.es>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik= .ee.ethz.ch>; Piers O'Hanlon <piers.ohanlon@cs.ox.ac.uk>; QUI= C IETF mailing list <= quic@ietf.org>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_= schepper@nokia-bell-labs.com>


Subject: Re: ECN in QUIC

=C2=A0

=C2=A0

On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S= <= ingemar.s.johansson@ericsson.com> wrote:

Hi

=C2=A0

And sorry for the sloth-ish response (you should see= me type=C2=A0 a text message..).

To summarize the two main questions

=C2=A0

  1. ECN in ACK frame or in a separate frame : Given the recent discussion on th= e list and fear that the ACK frame is already enough complex, it seems unwi= se to try to cram in additional info in the ACK frames. So my personal feel= ing is that we should use a separate frame type for ECN , but this frame type must be a MUST to implement and s= upport ! Comments are very welcome.

I was neutral on this before, but I started thinking= about implementing this, and separating the frames makes it more complex, = and potentially really, really difficult to get the implementation correct.= =C2=A0 As an example, if the frames were accidentally sent in two separate packets, I would count the packet as ack= ed, and potentially increase the congestion window and other state variable= s.=C2=A0 I might even send an extra packet based on this information.=C2=A0= Then in the next packet I'd realize that packet had an ECN marking, and actually should have been treated as lost f= rom a congestion controller perspective.=C2=A0 In order to do this correctl= y, I'd have to undo a bunch of things.=C2=A0 My experience with undo is= that it's terribly error prone, and I would never recommend it.=C2=A0=C2=A0

=C2=A0

Alternately, the ack could get lost, and the next pa= cket would convey ECN marking information for packets that hadn't been = acknowledged yet.=C2=A0 Which is just weird.

=C2=A0

If we require support for ECN, then the implementati= on has a certain extra level of complexity.=C2=A0 As illustrated above, put= ting it in one frame is actually simpler overall if the congestion controll= er needs to use all the information at once to be implemented correctly.=C2=A0 This same logic applies to timesta= mps as well, in my opinion.

=C2=A0

  1. =C2=A0
  2. As regards to the level of detail : There are pros and cons with both alter= natives (marked bytes or detailed indication). I would like to hear the opi= nions from others as well on this matter .

=C2=A0

/Ingemar

=C2=A0

From: Colin Perkins [mailto:csp@csperkins.org]
Sent: den 16 augusti 2017 12:53
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>=
Cc: QUIC IETF mailing list <quic@ietf.org>; Magnus Westerlund <magnus.westerlund@erics= son.com>; Bob Briscoe (research@bobbriscoe.net) <research@= bobbriscoe.net>; Praveen Balasubramanian <pravb@microsoft.com>; Eggert, Lars= (lars@netapp.com) <lars@netapp.com>; marcelo bagnulo braun <marcelo@it.uc3m.es>; Mirja K=C3=BChlewind <mirja.kuehlew= ind@tik.ee.ethz.ch>; Piers O'Hanlon <piers.ohanlon@cs.ox.ac.uk>; De Schepper, Koen (Nokia - B= E/Antwerp) <koen.de_schepper@nokia-bell-labs.com>
Subject: Re: ECN in QUIC

=C2=A0

=C2=A0

On 16 Aug 2017, at 10:33, Ingemar Johansson S <ingemar= .s.johansson@ericsson.com> wrote:

=C2=A0

Hi

=C2=A0

Finally back from vacation, and very grateful for th= e support to continue the work to add ECN in QUIC.

Just to recap.. there were two main topics raised at= the meeting

=C2=A0

1) ECN info in ACK frame or in dedicated frame : The= re were concerns about adding extra complexity in an already potentially co= mplex ACK frame, one can have differing opinions about the complexity but can understand the concerns. As far as I am concerned, = a separate frame type for ECN is possible, possibly one need to add informa= tion about the amount of not-ECT marked packets as well to keep the signali= ng robust, this needs further investigation though. One concern with a separate ECN frame is that it becomes a not-imp= lemented or optional feature, is there any reason to be worried about this = ?

=C2=A0

2) More detailed ECN information : Earlier versions = of the ECN in QUIC draft (seehttp= s://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt<= span class=3D"m_-2377138829691516824m-4533685310870236821apple-converted-sp= ace">=C2=A0) provided with examples. We (Myself, Koen, Mirja and Praveen) discussed thi= s and we could not come up with any use case where it is beneficial to know= exactly how each packet is ECN marked. I know that this kind of detailed E= CN information is suggested for the generic feedback for RMCAT and I personally have a problem to see the = gain with the detailed ECN information also here. Input from others is very= welcome here.

=C2=A0

For the RMCAT format, we wanted per-packet loss and = timing information, and it was as easy to feedback per-packet ECN informati= on along with it as to design something different.

=C2=A0

A benefit of per-packet ECN marking could be to allo= w a congestion controller that reacted differently to bursts of consecutive= ECN marks than it did to isolated ECN marks, given the same fraction of marked packets (i.e., that reacted to ECN marking eve= nts rather than ECN marking rate, like how TCP responds to loss events). I = don=E2=80=99t think we have such a thing, but certainly in the context of R= MCAT where we=E2=80=99re experimenting with novel congestion control schemes for traffic that has very different characteris= tics to traditional bulk flows, it might be plausible. Per-packet marking i= nformation is also useful for troubleshooting.

=C2=A0

Certainly we need to know number of NotECT, ECT(0), = ECT(1), and ECN-CE marks since the last report, but I guess that=E2=80=99s = already possible.

=C2=A0

Cheers,

Colin

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

There are a consequences with detailed ECN marking i= nformation.

a) necessary to correlate with the list of transmitt= ed packets, this increases amount of code on sender side, not sure of that = is a large concern as lookup is anyway needed to process incoming ACKs

b) necessary to embed ECN information in ACK frame ?= , at least this was my conclusion when I devised the detailed ECN marking i= nfo in the 01 version of the draft.

=C2=A0

Comments are welcome

/Ingemar

=C2=A0

=C2=A0

=C2=A0

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

Ingemar Johansson=C2=A0 M.Sc.

Master Researcher

=C2=A0

Ericsson AB

Wireless Access Networks

Labratoriegr=C3=A4nd 11

971 28, Lule=C3=A5, Sweden

Phone +46-1071 43042

=C2=A0

A mistake is to commit= a misunderstanding
=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 Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0



--=C2=A0
Colin Perkins
https://csperkins.org/=

=C2=A0

=C2=A0




--
Thanks
Fra= nk Kastenholz

--001a11394a3614ea5b05599fb3da-- From nobody Wed Sep 20 07:31:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982A113217D for ; Wed, 20 Sep 2017 07:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 K6HcORwGoro7 for ; Wed, 20 Sep 2017 07:31:10 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id A7C9013219B for ; Wed, 20 Sep 2017 07:31:02 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 113AC1B001C9; Wed, 20 Sep 2017 15:30:25 +0100 (BST) Message-ID: <59C27B81.2020609@erg.abdn.ac.uk> Date: Wed, 20 Sep 2017 15:30:25 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Frank Kastenholz CC: Ingemar Johansson S , Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , Ian Swett , "Eggert, Lars \(lars@netapp.com\)" , marcelo bagnulo braun , =?UTF-8?B?TWlyamEgS8O8aGxld2k=?= =?UTF-8?B?bmQ=?= , Piers O'Hanlon , QUIC IETF mailing list , Colin Perkins , "De Schepper, Koen \(Nokia - BE/Antwerp\)" Subject: Re: ECN in QUIC References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:31:17 -0000 On 20/09/2017, 15:21, Frank Kastenholz wrote: > Hi > > I wonder if the ACK can be kept simple by including only the ECN > information from the most recently received packet, or maybe N (where > N is fairly small) most recently received packets? This would reduce > the amount of information to be carried as well as the complexity of > including it. > > I confess that I am not familiar with the various congestion control > algorithms ... but I would imagine that more recent ECN information > would be more useful than older ECN info. No? No - there are two styles of ECN CC. The more recent requires accurate feedback of the ECN marks - think of this more as understanding the "rate of marking from the bottleneck" and in some case "was this (test) packet marked". This requires per-packet ECN info - at least one bit per received packet, and preferably 2 bits. Gorry > > Frank Kastenholz > > On Wed, Sep 20, 2017 at 9:27 AM, Ingemar Johansson S > > wrote: > > Thanks Ian for the prompt response. > > I must admit that I have perhaps overlooked possible combos of > loss and ECN, the price you pay for working too much with > simulators. Your arguments are very strong indeed. > > In the SCReAM congestion control (RMCAT work) the ECN and loss > info comes in the same feedback and the handling of loss and ECN > is straightforward there. Personally I would prefer ECN in the ACK > frames and the earlier drafts suggested formats for that, I > however got the impression that there is a certain resistance > against additional things in the ACK frame ?. > > /Ingemar > > *From:* Ian Swett [mailto:ianswett@google.com > ] > *Sent:* den 20 september 2017 14:41 > *To:* Ingemar Johansson S > > *Cc:* Colin Perkins >; Magnus Westerlund > >; Bob Briscoe > (research@bobbriscoe.net ) > >; > Praveen Balasubramanian >; Eggert, Lars (lars@netapp.com > ) >; marcelo bagnulo braun > >; Mirja Kühlewind > >; Piers O'Hanlon > >; > QUIC IETF mailing list >; De > Schepper, Koen (Nokia - BE/Antwerp) > > > > > *Subject:* Re: ECN in QUIC > > On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S > > wrote: > > Hi > > And sorry for the sloth-ish response (you should see me type > a text message..). > > To summarize the two main questions > > 1. ECN in ACK frame or in a separate frame : Given the recent > discussion on the list and fear that the ACK frame is > already enough complex, it seems unwise to try to cram in > additional info in the ACK frames. So my personal feeling > is that we should use a separate frame type for ECN , but > this frame type must be a MUST to implement and support ! > Comments are very welcome. > > I was neutral on this before, but I started thinking about > implementing this, and separating the frames makes it more > complex, and potentially really, really difficult to get the > implementation correct. As an example, if the frames were > accidentally sent in two separate packets, I would count the > packet as acked, and potentially increase the congestion window > and other state variables. I might even send an extra packet > based on this information. Then in the next packet I'd realize > that packet had an ECN marking, and actually should have been > treated as lost from a congestion controller perspective. In > order to do this correctly, I'd have to undo a bunch of things. > My experience with undo is that it's terribly error prone, and I > would never recommend it. > > Alternately, the ack could get lost, and the next packet would > convey ECN marking information for packets that hadn't been > acknowledged yet. Which is just weird. > > If we require support for ECN, then the implementation has a > certain extra level of complexity. As illustrated above, putting > it in one frame is actually simpler overall if the congestion > controller needs to use all the information at once to be > implemented correctly. This same logic applies to timestamps as > well, in my opinion. > > 1. > 2. As regards to the level of detail : There are pros and > cons with both alternatives (marked bytes or detailed > indication). I would like to hear the opinions from others > as well on this matter . > > /Ingemar > > *From:* Colin Perkins [mailto:csp@csperkins.org > ] > *Sent:* den 16 augusti 2017 12:53 > *To:* Ingemar Johansson S > > *Cc:* QUIC IETF mailing list >; Magnus Westerlund > >; Bob Briscoe > (research@bobbriscoe.net ) > >; > Praveen Balasubramanian >; Eggert, Lars (lars@netapp.com > ) >; marcelo bagnulo braun > >; Mirja > Kühlewind >; Piers O'Hanlon > >; De Schepper, Koen (Nokia > - BE/Antwerp) > > *Subject:* Re: ECN in QUIC > > On 16 Aug 2017, at 10:33, Ingemar Johansson S > > wrote: > > Hi > > Finally back from vacation, and very grateful for the > support to continue the work to add ECN in QUIC. > > Just to recap.. there were two main topics raised at the > meeting > > 1) ECN info in ACK frame or in dedicated frame : There > were concerns about adding extra complexity in an already > potentially complex ACK frame, one can have differing > opinions about the complexity but can understand the > concerns. As far as I am concerned, a separate frame type > for ECN is possible, possibly one need to add information > about the amount of not-ECT marked packets as well to keep > the signaling robust, this needs further investigation > though. One concern with a separate ECN frame is that it > becomes a not-implemented or optional feature, is there > any reason to be worried about this ? > > 2) More detailed ECN information : Earlier versions of the > ECN in QUIC draft > (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt > ) > provided with examples. We (Myself, Koen, Mirja and > Praveen) discussed this and we could not come up with any > use case where it is beneficial to know exactly how each > packet is ECN marked. I know that this kind of detailed > ECN information is suggested for the generic feedback for > RMCAT and I personally have a problem to see the gain with > the detailed ECN information also here. Input from others > is very welcome here. > > For the RMCAT format, we wanted per-packet loss and timing > information, and it was as easy to feedback per-packet ECN > information along with it as to design something different. > > A benefit of per-packet ECN marking could be to allow a > congestion controller that reacted differently to bursts of > consecutive ECN marks than it did to isolated ECN marks, given > the same fraction of marked packets (i.e., that reacted to ECN > marking events rather than ECN marking rate, like how TCP > responds to loss events). I don’t think we have such a thing, > but certainly in the context of RMCAT where we’re > experimenting with novel congestion control schemes for > traffic that has very different characteristics to traditional > bulk flows, it might be plausible. Per-packet marking > information is also useful for troubleshooting. > > Certainly we need to know number of NotECT, ECT(0), ECT(1), > and ECN-CE marks since the last report, but I guess that’s > already possible. > > Cheers, > > Colin > > There are a consequences with detailed ECN marking > information. > > a) necessary to correlate with the list of transmitted > packets, this increases amount of code on sender side, not > sure of that is a large concern as lookup is anyway needed > to process incoming ACKs > > b) necessary to embed ECN information in ACK frame ?, at > least this was my conclusion when I devised the detailed > ECN marking info in the 01 version of the draft. > > Comments are welcome > > /Ingemar > > ================================== > > Ingemar Johansson M.Sc. > > Master Researcher > > Ericsson AB > > Wireless Access Networks > > Labratoriegränd 11 > > 971 28, Luleå, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > > www.ericsson.com > > A mistake is to commit a misunderstanding > Bob Dylan > ================================== > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > -- > Thanks > Frank Kastenholz > From nobody Wed Sep 20 07:57:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6FF13207A for ; Wed, 20 Sep 2017 07:57: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 autolearn_force=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 gMRI6WAiQy1C for ; Wed, 20 Sep 2017 07:57:51 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB72124F57 for ; Wed, 20 Sep 2017 07:57:50 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 22EB2340A45; Wed, 20 Sep 2017 16:57:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.22864); Wed, 20 Sep 2017 16:57:48 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 20 Sep 2017 16:57:44 +0200 (CEST) Received: from [195.176.111.14] (account ietf@trammell.ch HELO public-docking-cx-0363.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 30266344; Wed, 20 Sep 2017 16:57:44 +0200 From: "Brian Trammell (IETF)" Message-Id: <08876D99-50DC-466A-ADB1-53A06C921664@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_71311556-3F32-4AAA-9359-6F94364BA640"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ECN in QUIC Date: Wed, 20 Sep 2017 16:57:44 +0200 In-Reply-To: <59C27B81.2020609@erg.abdn.ac.uk> Cc: Frank Kastenholz , Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , Ian Swett , Ingemar Johansson S , "Eggert, Lars (lars@netapp.com)" , marcelo bagnulo braun , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Piers O'Hanlon , QUIC IETF mailing list , Colin Perkins , "De Schepper, Koen (Nokia - BE/Antwerp)" To: Gorry Fairhurst References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:57:55 -0000 --Apple-Mail=_71311556-3F32-4AAA-9359-6F94364BA640 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Sep 2017, at 16:30, Gorry Fairhurst = wrote: >=20 > On 20/09/2017, 15:21, Frank Kastenholz wrote: >> Hi >>=20 >> I wonder if the ACK can be kept simple by including only the ECN = information from the most recently received packet, or maybe N (where N = is fairly small) most recently received packets? This would reduce the = amount of information to be carried as well as the complexity of = including it. >>=20 >> I confess that I am not familiar with the various congestion control = algorithms ... but I would imagine that more recent ECN information = would be more useful than older ECN info. No? > No - there are two styles of ECN CC. The more recent requires accurate = feedback of the ECN marks - think of this more as understanding the = "rate of marking from the bottleneck" and in some case "was this (test) = packet marked". This requires per-packet ECN info - at least one bit per = received packet, and preferably 2 bits. I'll also note that AccECN (draft-ietf-tcpm-accurate-ecn) would seem to = be far easier to add to QUIC than to TCP. In the TCP case, it needs to = reallocate a flag bit and add an option, both of which need to be = defensively specified against path interference, *all* of which simply = go away when the information is carried in encrypted QUIC ACK frames. AccECN also shows the way to handle the recency of information issues = raised above: the counters echoed are all the least significant N bits = of a cumulative counter, which is both recent and robust against ACK = loss. Cheers, Brian > Gorry >=20 >>=20 >> Frank Kastenholz >>=20 >> On Wed, Sep 20, 2017 at 9:27 AM, Ingemar Johansson S = > wrote: >>=20 >> Thanks Ian for the prompt response. >>=20 >> I must admit that I have perhaps overlooked possible combos of >> loss and ECN, the price you pay for working too much with >> simulators. Your arguments are very strong indeed. >>=20 >> In the SCReAM congestion control (RMCAT work) the ECN and loss >> info comes in the same feedback and the handling of loss and ECN >> is straightforward there. Personally I would prefer ECN in the ACK >> frames and the earlier drafts suggested formats for that, I >> however got the impression that there is a certain resistance >> against additional things in the ACK frame ?. >>=20 >> /Ingemar >>=20 >> *From:* Ian Swett [mailto:ianswett@google.com >> ] >> *Sent:* den 20 september 2017 14:41 >> *To:* Ingemar Johansson S > > >> *Cc:* Colin Perkins > >; Magnus Westerlund >> > >; Bob Briscoe >> (research@bobbriscoe.net ) >> >; >> Praveen Balasubramanian > >; Eggert, Lars (lars@netapp.com >> ) > >; marcelo bagnulo braun >> >; Mirja K=C3=BChlewi= nd >> > >; Piers O'Hanlon >> >; >> QUIC IETF mailing list >; De >> Schepper, Koen (Nokia - BE/Antwerp) >> > > >>=20 >>=20 >> *Subject:* Re: ECN in QUIC >>=20 >> On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S >> > > wrote: >>=20 >> Hi >>=20 >> And sorry for the sloth-ish response (you should see me type = a text message..). >>=20 >> To summarize the two main questions >>=20 >> 1. ECN in ACK frame or in a separate frame : Given the recent >> discussion on the list and fear that the ACK frame is >> already enough complex, it seems unwise to try to cram in >> additional info in the ACK frames. So my personal feeling >> is that we should use a separate frame type for ECN , but >> this frame type must be a MUST to implement and support ! >> Comments are very welcome. >>=20 >> I was neutral on this before, but I started thinking about >> implementing this, and separating the frames makes it more >> complex, and potentially really, really difficult to get the >> implementation correct. As an example, if the frames were >> accidentally sent in two separate packets, I would count the >> packet as acked, and potentially increase the congestion window >> and other state variables. I might even send an extra packet >> based on this information. Then in the next packet I'd realize >> that packet had an ECN marking, and actually should have been >> treated as lost from a congestion controller perspective. In >> order to do this correctly, I'd have to undo a bunch of things. = My experience with undo is that it's terribly error prone, and I >> would never recommend it. >>=20 >> Alternately, the ack could get lost, and the next packet would >> convey ECN marking information for packets that hadn't been >> acknowledged yet. Which is just weird. >>=20 >> If we require support for ECN, then the implementation has a >> certain extra level of complexity. As illustrated above, putting >> it in one frame is actually simpler overall if the congestion >> controller needs to use all the information at once to be >> implemented correctly. This same logic applies to timestamps as >> well, in my opinion. >>=20 >> 1. >> 2. As regards to the level of detail : There are pros and >> cons with both alternatives (marked bytes or detailed >> indication). I would like to hear the opinions from others >> as well on this matter . >>=20 >> /Ingemar >>=20 >> *From:* Colin Perkins [mailto:csp@csperkins.org >> ] >> *Sent:* den 16 augusti 2017 12:53 >> *To:* Ingemar Johansson S > > >> *Cc:* QUIC IETF mailing list > >; Magnus Westerlund >> > >; Bob Briscoe >> (research@bobbriscoe.net ) >> >; >> Praveen Balasubramanian > >; Eggert, Lars (lars@netapp.com >> ) > >; marcelo bagnulo braun >> >; Mirja >> K=C3=BChlewind > >; Piers O'Hanlon >> > >; De Schepper, Koen (Nokia >> - BE/Antwerp) > > >> *Subject:* Re: ECN in QUIC >>=20 >> On 16 Aug 2017, at 10:33, Ingemar Johansson S >> > > wrote: >>=20 >> Hi >>=20 >> Finally back from vacation, and very grateful for the >> support to continue the work to add ECN in QUIC. >>=20 >> Just to recap.. there were two main topics raised at the >> meeting >>=20 >> 1) ECN info in ACK frame or in dedicated frame : There >> were concerns about adding extra complexity in an already >> potentially complex ACK frame, one can have differing >> opinions about the complexity but can understand the >> concerns. As far as I am concerned, a separate frame type >> for ECN is possible, possibly one need to add information >> about the amount of not-ECT marked packets as well to keep >> the signaling robust, this needs further investigation >> though. One concern with a separate ECN frame is that it >> becomes a not-implemented or optional feature, is there >> any reason to be worried about this ? >>=20 >> 2) More detailed ECN information : Earlier versions of the >> ECN in QUIC draft >> = (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt >> = ) >> provided with examples. We (Myself, Koen, Mirja and >> Praveen) discussed this and we could not come up with any >> use case where it is beneficial to know exactly how each >> packet is ECN marked. I know that this kind of detailed >> ECN information is suggested for the generic feedback for >> RMCAT and I personally have a problem to see the gain with >> the detailed ECN information also here. Input from others >> is very welcome here. >>=20 >> For the RMCAT format, we wanted per-packet loss and timing >> information, and it was as easy to feedback per-packet ECN >> information along with it as to design something different. >>=20 >> A benefit of per-packet ECN marking could be to allow a >> congestion controller that reacted differently to bursts of >> consecutive ECN marks than it did to isolated ECN marks, given >> the same fraction of marked packets (i.e., that reacted to ECN >> marking events rather than ECN marking rate, like how TCP >> responds to loss events). I don=E2=80=99t think we have such a = thing, >> but certainly in the context of RMCAT where we=E2=80=99re >> experimenting with novel congestion control schemes for >> traffic that has very different characteristics to traditional >> bulk flows, it might be plausible. Per-packet marking >> information is also useful for troubleshooting. >>=20 >> Certainly we need to know number of NotECT, ECT(0), ECT(1), >> and ECN-CE marks since the last report, but I guess that=E2=80=99= s >> already possible. >>=20 >> Cheers, >>=20 >> Colin >>=20 >> There are a consequences with detailed ECN marking >> information. >>=20 >> a) necessary to correlate with the list of transmitted >> packets, this increases amount of code on sender side, not >> sure of that is a large concern as lookup is anyway needed >> to process incoming ACKs >>=20 >> b) necessary to embed ECN information in ACK frame ?, at >> least this was my conclusion when I devised the detailed >> ECN marking info in the 01 version of the draft. >>=20 >> Comments are welcome >>=20 >> /Ingemar >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Ingemar Johansson M.Sc. >>=20 >> Master Researcher >>=20 >> Ericsson AB >>=20 >> Wireless Access Networks >>=20 >> Labratoriegr=C3=A4nd 11 >>=20 >> 971 28, Lule=C3=A5, Sweden >>=20 >> Phone +46-1071 43042 >>=20 >> SMS/MMS +46-73 078 3289 >>=20 >> ingemar.s.johansson@ericsson.com >> >>=20 >> www.ericsson.com >>=20 >> A mistake is to commit a misunderstanding >> Bob Dylan >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >> -- Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >> -- >> Thanks >> Frank Kastenholz >>=20 >=20 --Apple-Mail=_71311556-3F32-4AAA-9359-6F94364BA640 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZwoHoAAoJEIoSt78L6kaj0U8QAMOmxgj6CL2Nvi7ZcdJgcXuS iiZSGwcHMKf+cLVY6JhqyJFHoTc9p0bZZUFsMTGq2q98UW8gUXB1mgdCGZIeOqlJ jPHxQDFCmzwEuQvTnF4of/MYonYZqd2LNGFrQ0k+v5DD7sZWM2fLKnlbOJb9C4j4 GWrd/u/cNadQStuhuaHdiFxr/PYfpamAbpSlRjadCJqBb44cs9JoExz0TF6Np+4F dFfEMQMJHbO4n0OmUZ4XMJjM9cR4LsYqIHuDWiy3WKCyNfAdkAnwsnW2jx+BTK6R UQfsoqAyXSX2ROzEFEdbItkWbnqg04hNDEBGoK5Xmx0Mq12vNzNX4ExAuWQ5G7c7 CE5aqeor2IeyYODRhW3VytqWiN3FdJ3Jmn5Fdz1AJiEmsK4a8m1MNpU2q6VLuN7N sjZh+IUVIofg1ld/1kdplnFJuFcpNgwg/XcQTDrQSDeDNSU29dfhz+bjyHyuLMqI 2SgckayZPNipt3u0QB5O4IrA0S5UCppmxwLT+hzHyWyQ0w4XbyjStCA4WMLz3doO R0m4LDnCYIP/+jVI8PJTRVpc0n97/2vMSDVGA+vClUYfWtUW+F9ywUuN4Cab89fT p3xIHZJPzetTzh/PqYcxu5blwADZQhpgYvO/dJJrlyE+79Us8Amvs7dTZFgvNnq7 mFHqoqz4/wv6+Y6HM+9R =vh/L -----END PGP SIGNATURE----- --Apple-Mail=_71311556-3F32-4AAA-9359-6F94364BA640-- From nobody Wed Sep 20 09:52:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51701331BA for ; Wed, 20 Sep 2017 09:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 mF6vuwg7RLJy for ; Wed, 20 Sep 2017 09:52:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7078713319E for ; Wed, 20 Sep 2017 09:52:04 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-69-59c29cb20ada Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8C.98.21299.2BC92C95; Wed, 20 Sep 2017 18:52:02 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 20 Sep 2017 18:51:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1ZHORvRbxTLE5WENCfjvjDf1V3zYtpZB3Pb2D5nRfEo=; b=lQKDBujR+YeDsGcRKyDEJAYiER79rLEzII6B4BNHOCfUktYO6gOc0bjMmCsAkxDzxUF6/YZdQ4NLvFRNCrd3hdmalM1SyMDm/HiBMAaveJ7TkmjLyNN3v6s9p3N7SAmByWp+CMPtUx+wnJZYINlitKF8k5iSsyJTt+keifod4Sk= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 16:51:14 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.011; Wed, 20 Sep 2017 16:51:14 +0000 From: Ingemar Johansson S To: "gorry@erg.abdn.ac.uk" , Frank Kastenholz CC: Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , Ian Swett , "Eggert, Lars (lars@netapp.com)" , marcelo bagnulo braun , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Piers O'Hanlon , QUIC IETF mailing list , "Colin Perkins" , "De Schepper, Koen (Nokia - BE/Antwerp)" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdMWaIZN+ofkuQeuQOGGa2om9/ikzQAFT3AABtrtZuAACQ/IAAABYVFwAAIiawAAAE3vgAAEz4gg Date: Wed, 20 Sep 2017 16:51:14 +0000 Message-ID: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> In-Reply-To: <59C27B81.2020609@erg.abdn.ac.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [213.113.27.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:J8Co49p7l4PNAQ/oIEiA04DQWU0SwIkQeJ6ELXG32g+RklV/uL6vRyUt3WiNGsP2lHWnW9ljGNYRlhVHweBo46rPKOSW8WE9qUinyxBSnZR5yPbIR8LD5yf8FhonLKigWxx/zNh232s3xAoWTgXgHUblgP2Sptx7Pe5kRlm7HnR8Izh6JBGqY6wc2nWtLLV7b6+r0XRcoJETeExjbFMpsid99YXa2t856ejcVA7oIhhEDSvBvX6H29ADdjc33AfC2UrVZeJ6PBnWRxd3R6eRNUk+yfY89tzDQ6miMyaa5wCTerAXLykYTUNFXlkRUHB6a51aWkrPmVafAe504KkRmQ==; 5:32PV0eE7JDjJHR+WJmgZWfSKEgsUmJZjxQJ2YHdF6n6Nb6ycvp51m7Mx0AwEcP6xacU+17mvFKu4sGkVNY3rkdtyzZbFJbfqZ19X9PK2HkBv2PHfdpjlYVdz15aM98ueToW0xQ3NoposbCZSTiGtww==; 24:u0FsEuKGNKADCXq2/NrbuIXh/XDSYc7r3XkxwuruP7uN6E6A7oNm8TynB7sHtO55+fZZ7KEEJQmSAlBkDJSZrM5S4wtEnMVxusvjzM5dfgM=; 7:UJNbfFNq+6cxNRUh2rVh2B18UOsXyMIVwCp6DT9bqX5EOR1EwxIWxdg/UiMnHCMBm48VHY/Qc8hTh1YTIjmbYhhiIgdnNZkwMwtZcZUBu03luvkgxLKEaIKcmqxf9JD5VTPhFNfahiinH1R8e7uwxdem8323oCJZ/gv4qMA9/U0QU0y5bFepOY4GGC6pkwf9yDr0RHZpupPAL4HG6EINXHvj5aAS3aeN594pee/YRCo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 939fef2d-8add-44aa-6321-08d50047ce3e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB348; x-ms-traffictypediagnostic: DB4PR07MB348: x-exchange-antispam-report-test: UriScan:(37575265505322)(89211679590171)(211936372134217)(202460600054446)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(920507026)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB348; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(39860400002)(376002)(377454003)(24454002)(199003)(54094003)(13464003)(189002)(101416001)(97736004)(54356999)(305945005)(3846002)(25786009)(74316002)(34040400001)(102836003)(68736007)(50986999)(76176999)(7696004)(5660300001)(229853002)(7736002)(6436002)(54906003)(6116002)(33656002)(6506006)(110136005)(316002)(189998001)(7116003)(53546010)(93886005)(8676002)(106356001)(966005)(2950100002)(478600001)(4326008)(8936002)(66066001)(53936002)(3480700004)(6246003)(81166006)(14454004)(81156014)(8666007)(3280700002)(2501003)(105586002)(55016002)(99286003)(3660700001)(9686003)(2900100001)(2906002)(7416002)(6306002)(5250100002)(15974865002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 16:51:14.4260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH/d3XrrPBdSmeXBIusjTSXtCNJHoQXQIryD80Ilt6UUnNdtdj SSXGyuZWac50hUrYayGmVmoLzVVmRCRuPQnXUnM+sjCnRGhtuwv673PO+Z7vOb/Dj8blLjKS zs7T8Oo8VY6SkhJVKS3LlzVdtaUuP2tWsDeHuxFr5NjRM1cQ+6uvjWS7pq5jrHvUQLC6QQvF 3r1TTrBNZ5pJdtTQj1hDbQjrqihCG+ZwI84ekpspfkBwFU4nxRl+ujGutukwV1f3C+Om3jWS nK51RsJVTkxSXNHUNYrr+uGhdobsliZm8DnZR3h1wvp90qxnHV+I/Efn0TGjZ2shcuuRHgXT wKyG77ZiSo+ktJx5imDS/RiJQTeChpobpC8gGCMOFwdfBWQmDEyVnwKBE0GvZVLiM6OYRLht m/YbhzF7ofTJE9wnwpmXBIw7DLivMJcBqO0qw0TRPBif1BEi7wb7RL9fQzCLoL5sgPKxzJu3 FlZh4rRBHMbPVfobgpl4aBmr8zNiosA53ednnImAjwM1mPg8BuoevcZFDofh/llS1KfDxAej l2lvPhqelh8VJVHQW1PiPwAwOgk0e1oCZ4qH+6XfApwExaaKgKcLgxdDuSLHQlvNNCHyCXj7 zrenzz8bTPVZoqeDhAuXuylRMx+ss9XYRbTM/N/aZm8L7rVqeJggpqOhvMQlMftPEQovqgaI WkRYULjAC/tzM1euiufV2emCcDAvPo/XNCHvx+u893tRK7KPbbQhhkbKObI3aZ2pclJ1RNDm 2hDQuDJMZjHbUuWyDJX2OK8+mKY+nMMLNqSgCWWEbGN7T4qcyVRp+AM8n8+r/1UxOjiyEF16 /0zuyn/YsWR/39dwevtARNHiA4dyl1bHRZKbhmajTj7XvHZvDtLuCfvsuLnulj26kQ5iw7cl FQjpkrgfMWmn9J1CsF1nmVqT7D49rHW3yyhgq5d61o7HloxtyUhoD2VH2tN3Gv4s3KW4Iy9Y 7NiW3PKRiPFYFdZ1OxZscLUpCSFLtSIOVwuqv4NmGod0AwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 16:52:08 -0000 SGkNCkRldGFpbGVkIGluZm8gYWJvdXQgd2hpY2ggcGFja2V0cyBhcmUgRUNOIG1hcmtlZCBjYW4g YmUgdXNlZnVsIGJ1dCBhcmUgbm90IHN0cmlja3RseSBuZWNlc3NhcnkuIE9uZSBhbHRlcm5hdGl2 ZSwgdGhhdCBpcyBwcmVzZW50ZWQgaW4gdGhlIEVDTi1RVUlDIGRyYWZ0IGlzIHRvIGNvdW50IG51 bWJlciBvZiBtYXJrZWQgYnl0ZXMuIA0KVGhhdCBzYWlkLCBzb21lIGxpa2UgdGhlIGRldGFpbGVk IHBhY2tldC1sZXZlbCBpbmZvcm1hdGlvbiB0eXBlIGJldHRlci4gSSBoYXZlIG5vdCB5ZXQgYmVl biBjb252aW5jZWQgdGhhdCB0aGF0IHRoaXMgbGV2ZWwgb2YgZGV0YWlsIGlzIG5lY2Vzc2FyeSB0 aG91Z2guIA0KDQovSW5nZW1hcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEdvcnJ5IEZhaXJodXJzdCBbbWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrXQ0KPiBTZW50 OiBkZW4gMjAgc2VwdGVtYmVyIDIwMTcgMTY6MzANCj4gVG86IEZyYW5rIEthc3RlbmhvbHogPGZr YXN0ZW5ob2x6QGdvb2dsZS5jb20+DQo+IENjOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT47IE1hZ251cw0KPiBXZXN0ZXJsdW5kIDxtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20+OyBCb2IgQnJpc2NvZQ0KPiAocmVzZWFyY2hAYm9iYnJp c2NvZS5uZXQpIDxyZXNlYXJjaEBib2JicmlzY29lLm5ldD47IFByYXZlZW4NCj4gQmFsYXN1YnJh bWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgSWFuIFN3ZXR0DQo+IDxpYW5zd2V0dEBnb29n bGUuY29tPjsgRWdnZXJ0LCBMYXJzIChsYXJzQG5ldGFwcC5jb20pDQo+IDxsYXJzQG5ldGFwcC5j b20+OyBtYXJjZWxvIGJhZ251bG8gYnJhdW4gPG1hcmNlbG9AaXQudWMzbS5lcz47IE1pcmphDQo+ IEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+OyBQaWVycyBPJ0hh bmxvbg0KPiA8cGllcnMub2hhbmxvbkBjcy5veC5hYy51az47IFFVSUMgSUVURiBtYWlsaW5nIGxp c3QgPHF1aWNAaWV0Zi5vcmc+OyBDb2xpbg0KPiBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9yZz47 IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApDQo+IDxrb2VuLmRlX3NjaGVw cGVyQG5va2lhLWJlbGwtbGFicy5jb20+DQo+IFN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQw0KPiAN Cj4gT24gMjAvMDkvMjAxNywgMTU6MjEsIEZyYW5rIEthc3RlbmhvbHogd3JvdGU6DQo+ID4gSGkN Cj4gPg0KPiA+IEkgd29uZGVyIGlmIHRoZSBBQ0sgY2FuIGJlIGtlcHQgc2ltcGxlIGJ5IGluY2x1 ZGluZyBvbmx5IHRoZSBFQ04NCj4gPiBpbmZvcm1hdGlvbiBmcm9tIHRoZSBtb3N0IHJlY2VudGx5 IHJlY2VpdmVkIHBhY2tldCwgb3IgbWF5YmUgTiAod2hlcmUNCj4gPiBOIGlzIGZhaXJseSBzbWFs bCkgbW9zdCByZWNlbnRseSByZWNlaXZlZCBwYWNrZXRzPyBUaGlzIHdvdWxkIHJlZHVjZQ0KPiA+ IHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gdG8gYmUgY2FycmllZCBhcyB3ZWxsIGFzIHRoZSBj b21wbGV4aXR5IG9mDQo+ID4gaW5jbHVkaW5nIGl0Lg0KPiA+DQo+ID4gSSBjb25mZXNzIHRoYXQg SSBhbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgdmFyaW91cyBjb25nZXN0aW9uIGNvbnRyb2wNCj4g PiBhbGdvcml0aG1zIC4uLiBidXQgSSB3b3VsZCBpbWFnaW5lIHRoYXQgbW9yZSByZWNlbnQgRUNO IGluZm9ybWF0aW9uDQo+ID4gd291bGQgYmUgbW9yZSB1c2VmdWwgdGhhbiBvbGRlciBFQ04gaW5m by4gTm8/DQo+IE5vIC0gdGhlcmUgYXJlIHR3byBzdHlsZXMgb2YgRUNOIENDLiBUaGUgbW9yZSBy ZWNlbnQgcmVxdWlyZXMgYWNjdXJhdGUNCj4gZmVlZGJhY2sgb2YgdGhlIEVDTiBtYXJrcyAtIHRo aW5rIG9mIHRoaXMgbW9yZSBhcyB1bmRlcnN0YW5kaW5nIHRoZSAicmF0ZSBvZg0KPiBtYXJraW5n IGZyb20gdGhlIGJvdHRsZW5lY2siIGFuZCBpbiBzb21lIGNhc2UgIndhcyB0aGlzICh0ZXN0KSBw YWNrZXQNCj4gbWFya2VkIi4gVGhpcyByZXF1aXJlcyBwZXItcGFja2V0IEVDTiBpbmZvIC0gYXQg bGVhc3Qgb25lIGJpdCBwZXIgcmVjZWl2ZWQNCj4gcGFja2V0LCBhbmQgcHJlZmVyYWJseSAyIGJp dHMuDQo+IA0KPiBHb3JyeQ0KPiANCj4gPg0KPiA+IEZyYW5rIEthc3RlbmhvbHoNCj4gPg0KPiA+ IE9uIFdlZCwgU2VwIDIwLCAyMDE3IGF0IDk6MjcgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMNCj4g PiA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPiA8bWFpbHRvOmluZ2VtYXIu cy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgVGhhbmtzIElh biBmb3IgdGhlIHByb21wdCByZXNwb25zZS4NCj4gPg0KPiA+ICAgICBJIG11c3QgYWRtaXQgdGhh dCBJIGhhdmUgcGVyaGFwcyBvdmVybG9va2VkIHBvc3NpYmxlIGNvbWJvcyBvZg0KPiA+ICAgICBs b3NzIGFuZCBFQ04sIHRoZSBwcmljZSB5b3UgcGF5IGZvciB3b3JraW5nIHRvbyBtdWNoIHdpdGgN Cj4gPiAgICAgc2ltdWxhdG9ycy4gWW91ciBhcmd1bWVudHMgYXJlIHZlcnkgc3Ryb25nIGluZGVl ZC4NCj4gPg0KPiA+ICAgICBJbiB0aGUgU0NSZUFNIGNvbmdlc3Rpb24gY29udHJvbCAoUk1DQVQg d29yaykgdGhlIEVDTiBhbmQgbG9zcw0KPiA+ICAgICBpbmZvIGNvbWVzIGluIHRoZSBzYW1lIGZl ZWRiYWNrIGFuZCB0aGUgaGFuZGxpbmcgb2YgbG9zcyBhbmQgRUNODQo+ID4gICAgIGlzIHN0cmFp Z2h0Zm9yd2FyZCB0aGVyZS4gUGVyc29uYWxseSBJIHdvdWxkIHByZWZlciBFQ04gaW4gdGhlIEFD Sw0KPiA+ICAgICBmcmFtZXMgYW5kIHRoZSBlYXJsaWVyIGRyYWZ0cyBzdWdnZXN0ZWQgZm9ybWF0 cyBmb3IgdGhhdCwgSQ0KPiA+ICAgICBob3dldmVyIGdvdCB0aGUgaW1wcmVzc2lvbiB0aGF0IHRo ZXJlIGlzIGEgY2VydGFpbiByZXNpc3RhbmNlDQo+ID4gICAgIGFnYWluc3QgYWRkaXRpb25hbCB0 aGluZ3MgaW4gdGhlIEFDSyBmcmFtZSA/Lg0KPiA+DQo+ID4gICAgIC9JbmdlbWFyDQo+ID4NCj4g PiAgICAgKkZyb206KiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tDQo+ID4g ICAgIDxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT5dDQo+ID4gICAgICpTZW50OiogZGVuIDIw IHNlcHRlbWJlciAyMDE3IDE0OjQxDQo+ID4gICAgICpUbzoqIEluZ2VtYXIgSm9oYW5zc29uIFMg PGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tDQo+ID4gICAgIDxtYWlsdG86aW5nZW1h ci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+Pg0KPiA+ICAgICAqQ2M6KiBDb2xpbiBQZXJraW5z IDxjc3BAY3NwZXJraW5zLm9yZw0KPiA+ICAgICA8bWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnPj47 IE1hZ251cyBXZXN0ZXJsdW5kDQo+ID4gICAgIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5j b20NCj4gPiAgICAgPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+PjsgQm9i IEJyaXNjb2UNCj4gPiAgICAgKHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0IDxtYWlsdG86cmVzZWFy Y2hAYm9iYnJpc2NvZS5uZXQ+KQ0KPiA+ICAgICA8cmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQgPG1h aWx0bzpyZXNlYXJjaEBib2JicmlzY29lLm5ldD4+Ow0KPiA+ICAgICBQcmF2ZWVuIEJhbGFzdWJy YW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbQ0KPiA+ICAgICA8bWFpbHRvOnByYXZiQG1pY3Jv c29mdC5jb20+PjsgRWdnZXJ0LCBMYXJzIChsYXJzQG5ldGFwcC5jb20NCj4gPiAgICAgPG1haWx0 bzpsYXJzQG5ldGFwcC5jb20+KSA8bGFyc0BuZXRhcHAuY29tDQo+ID4gICAgIDxtYWlsdG86bGFy c0BuZXRhcHAuY29tPj47IG1hcmNlbG8gYmFnbnVsbyBicmF1bg0KPiA+ICAgICA8bWFyY2Vsb0Bp dC51YzNtLmVzIDxtYWlsdG86bWFyY2Vsb0BpdC51YzNtLmVzPj47IE1pcmphIEvDvGhsZXdpbmQN Cj4gPiAgICAgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gNCj4gPiAgICAgPG1haWx0 bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPj47IFBpZXJzIE8nSGFubG9uDQo+ID4g ICAgIDxwaWVycy5vaGFubG9uQGNzLm94LmFjLnVrIDxtYWlsdG86cGllcnMub2hhbmxvbkBjcy5v eC5hYy51az4+Ow0KPiA+ICAgICBRVUlDIElFVEYgbWFpbGluZyBsaXN0IDxxdWljQGlldGYub3Jn IDxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBEZQ0KPiA+ICAgICBTY2hlcHBlciwgS29lbiAoTm9r aWEgLSBCRS9BbnR3ZXJwKQ0KPiA+ICAgICA8a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxh YnMuY29tDQo+ID4gICAgIDxtYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMu Y29tPj4NCj4gPg0KPiA+DQo+ID4gICAgICpTdWJqZWN0OiogUmU6IEVDTiBpbiBRVUlDDQo+ID4N Cj4gPiAgICAgT24gV2VkLCBTZXAgMjAsIDIwMTcgYXQgNDozOSBBTSwgSW5nZW1hciBKb2hhbnNz b24gUw0KPiA+ICAgICA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPiAgICAg PG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPiA+DQo+ ID4gICAgICAgICBIaQ0KPiA+DQo+ID4gICAgICAgICBBbmQgc29ycnkgZm9yIHRoZSBzbG90aC1p c2ggcmVzcG9uc2UgKHlvdSBzaG91bGQgc2VlIG1lIHR5cGUNCj4gPiAgICAgICAgIGEgdGV4dCBt ZXNzYWdlLi4pLg0KPiA+DQo+ID4gICAgICAgICBUbyBzdW1tYXJpemUgdGhlIHR3byBtYWluIHF1 ZXN0aW9ucw0KPiA+DQo+ID4gICAgICAgICAgMS4gRUNOIGluIEFDSyBmcmFtZSBvciBpbiBhIHNl cGFyYXRlIGZyYW1lIDogR2l2ZW4gdGhlIHJlY2VudA0KPiA+ICAgICAgICAgICAgIGRpc2N1c3Np b24gb24gdGhlIGxpc3QgYW5kIGZlYXIgdGhhdCB0aGUgQUNLIGZyYW1lIGlzDQo+ID4gICAgICAg ICAgICAgYWxyZWFkeSBlbm91Z2ggY29tcGxleCwgaXQgc2VlbXMgdW53aXNlIHRvIHRyeSB0byBj cmFtIGluDQo+ID4gICAgICAgICAgICAgYWRkaXRpb25hbCBpbmZvIGluIHRoZSBBQ0sgZnJhbWVz LiBTbyBteSBwZXJzb25hbCBmZWVsaW5nDQo+ID4gICAgICAgICAgICAgaXMgdGhhdCB3ZSBzaG91 bGQgdXNlIGEgc2VwYXJhdGUgZnJhbWUgdHlwZSBmb3IgRUNOICwgYnV0DQo+ID4gICAgICAgICAg ICAgdGhpcyBmcmFtZSB0eXBlIG11c3QgYmUgYSBNVVNUIHRvIGltcGxlbWVudCBhbmQgc3VwcG9y dCAhDQo+ID4gICAgICAgICAgICAgQ29tbWVudHMgYXJlIHZlcnkgd2VsY29tZS4NCj4gPg0KPiA+ ICAgICBJIHdhcyBuZXV0cmFsIG9uIHRoaXMgYmVmb3JlLCBidXQgSSBzdGFydGVkIHRoaW5raW5n IGFib3V0DQo+ID4gICAgIGltcGxlbWVudGluZyB0aGlzLCBhbmQgc2VwYXJhdGluZyB0aGUgZnJh bWVzIG1ha2VzIGl0IG1vcmUNCj4gPiAgICAgY29tcGxleCwgYW5kIHBvdGVudGlhbGx5IHJlYWxs eSwgcmVhbGx5IGRpZmZpY3VsdCB0byBnZXQgdGhlDQo+ID4gICAgIGltcGxlbWVudGF0aW9uIGNv cnJlY3QuICBBcyBhbiBleGFtcGxlLCBpZiB0aGUgZnJhbWVzIHdlcmUNCj4gPiAgICAgYWNjaWRl bnRhbGx5IHNlbnQgaW4gdHdvIHNlcGFyYXRlIHBhY2tldHMsIEkgd291bGQgY291bnQgdGhlDQo+ ID4gICAgIHBhY2tldCBhcyBhY2tlZCwgYW5kIHBvdGVudGlhbGx5IGluY3JlYXNlIHRoZSBjb25n ZXN0aW9uIHdpbmRvdw0KPiA+ICAgICBhbmQgb3RoZXIgc3RhdGUgdmFyaWFibGVzLiAgSSBtaWdo dCBldmVuIHNlbmQgYW4gZXh0cmEgcGFja2V0DQo+ID4gICAgIGJhc2VkIG9uIHRoaXMgaW5mb3Jt YXRpb24uICBUaGVuIGluIHRoZSBuZXh0IHBhY2tldCBJJ2QgcmVhbGl6ZQ0KPiA+ICAgICB0aGF0 IHBhY2tldCBoYWQgYW4gRUNOIG1hcmtpbmcsIGFuZCBhY3R1YWxseSBzaG91bGQgaGF2ZSBiZWVu DQo+ID4gICAgIHRyZWF0ZWQgYXMgbG9zdCBmcm9tIGEgY29uZ2VzdGlvbiBjb250cm9sbGVyIHBl cnNwZWN0aXZlLiAgSW4NCj4gPiAgICAgb3JkZXIgdG8gZG8gdGhpcyBjb3JyZWN0bHksIEknZCBo YXZlIHRvIHVuZG8gYSBidW5jaCBvZiB0aGluZ3MuDQo+ID4gICAgIE15IGV4cGVyaWVuY2Ugd2l0 aCB1bmRvIGlzIHRoYXQgaXQncyB0ZXJyaWJseSBlcnJvciBwcm9uZSwgYW5kIEkNCj4gPiAgICAg d291bGQgbmV2ZXIgcmVjb21tZW5kIGl0Lg0KPiA+DQo+ID4gICAgIEFsdGVybmF0ZWx5LCB0aGUg YWNrIGNvdWxkIGdldCBsb3N0LCBhbmQgdGhlIG5leHQgcGFja2V0IHdvdWxkDQo+ID4gICAgIGNv bnZleSBFQ04gbWFya2luZyBpbmZvcm1hdGlvbiBmb3IgcGFja2V0cyB0aGF0IGhhZG4ndCBiZWVu DQo+ID4gICAgIGFja25vd2xlZGdlZCB5ZXQuICBXaGljaCBpcyBqdXN0IHdlaXJkLg0KPiA+DQo+ ID4gICAgIElmIHdlIHJlcXVpcmUgc3VwcG9ydCBmb3IgRUNOLCB0aGVuIHRoZSBpbXBsZW1lbnRh dGlvbiBoYXMgYQ0KPiA+ICAgICBjZXJ0YWluIGV4dHJhIGxldmVsIG9mIGNvbXBsZXhpdHkuICBB cyBpbGx1c3RyYXRlZCBhYm92ZSwgcHV0dGluZw0KPiA+ICAgICBpdCBpbiBvbmUgZnJhbWUgaXMg YWN0dWFsbHkgc2ltcGxlciBvdmVyYWxsIGlmIHRoZSBjb25nZXN0aW9uDQo+ID4gICAgIGNvbnRy b2xsZXIgbmVlZHMgdG8gdXNlIGFsbCB0aGUgaW5mb3JtYXRpb24gYXQgb25jZSB0byBiZQ0KPiA+ ICAgICBpbXBsZW1lbnRlZCBjb3JyZWN0bHkuICBUaGlzIHNhbWUgbG9naWMgYXBwbGllcyB0byB0 aW1lc3RhbXBzIGFzDQo+ID4gICAgIHdlbGwsIGluIG15IG9waW5pb24uDQo+ID4NCj4gPiAgICAg ICAgIDEuDQo+ID4gICAgICAgICAgMi4gQXMgcmVnYXJkcyB0byB0aGUgbGV2ZWwgb2YgZGV0YWls IDogVGhlcmUgYXJlIHByb3MgYW5kDQo+ID4gICAgICAgICAgICAgY29ucyB3aXRoIGJvdGggYWx0 ZXJuYXRpdmVzIChtYXJrZWQgYnl0ZXMgb3IgZGV0YWlsZWQNCj4gPiAgICAgICAgICAgICBpbmRp Y2F0aW9uKS4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhlIG9waW5pb25zIGZyb20gb3RoZXJzDQo+ ID4gICAgICAgICAgICAgYXMgd2VsbCBvbiB0aGlzIG1hdHRlciAuDQo+ID4NCj4gPiAgICAgICAg IC9JbmdlbWFyDQo+ID4NCj4gPiAgICAgICAgICpGcm9tOiogQ29saW4gUGVya2lucyBbbWFpbHRv OmNzcEBjc3BlcmtpbnMub3JnDQo+ID4gICAgICAgICA8bWFpbHRvOmNzcEBjc3BlcmtpbnMub3Jn Pl0NCj4gPiAgICAgICAgICpTZW50OiogZGVuIDE2IGF1Z3VzdGkgMjAxNyAxMjo1Mw0KPiA+ICAg ICAgICAgKlRvOiogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20NCj4gPiAgICAgICAgIDxtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb20+Pg0KPiA+ICAgICAgICAgKkNjOiogUVVJQyBJRVRGIG1haWxpbmcgbGlzdCA8cXVpY0Bp ZXRmLm9yZw0KPiA+ICAgICAgICAgPG1haWx0bzpxdWljQGlldGYub3JnPj47IE1hZ251cyBXZXN0 ZXJsdW5kDQo+ID4gICAgICAgICA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+ID4g ICAgICAgICA8bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4+OyBCb2IgQnJp c2NvZQ0KPiA+ICAgICAgICAgKHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0IDxtYWlsdG86cmVzZWFy Y2hAYm9iYnJpc2NvZS5uZXQ+KQ0KPiA+ICAgICAgICAgPHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0 IDxtYWlsdG86cmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQ+PjsNCj4gPiAgICAgICAgIFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tDQo+ID4gICAgICAgICA8bWFpbHRv OnByYXZiQG1pY3Jvc29mdC5jb20+PjsgRWdnZXJ0LCBMYXJzIChsYXJzQG5ldGFwcC5jb20NCj4g PiAgICAgICAgIDxtYWlsdG86bGFyc0BuZXRhcHAuY29tPikgPGxhcnNAbmV0YXBwLmNvbQ0KPiA+ ICAgICAgICAgPG1haWx0bzpsYXJzQG5ldGFwcC5jb20+PjsgbWFyY2VsbyBiYWdudWxvIGJyYXVu DQo+ID4gICAgICAgICA8bWFyY2Vsb0BpdC51YzNtLmVzIDxtYWlsdG86bWFyY2Vsb0BpdC51YzNt LmVzPj47IE1pcmphDQo+ID4gICAgICAgICBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRp ay5lZS5ldGh6LmNoDQo+ID4gICAgICAgICA8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVl LmV0aHouY2g+PjsgUGllcnMgTydIYW5sb24NCj4gPiAgICAgICAgIDxwaWVycy5vaGFubG9uQGNz Lm94LmFjLnVrDQo+ID4gICAgICAgICA8bWFpbHRvOnBpZXJzLm9oYW5sb25AY3Mub3guYWMudWs+ PjsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhDQo+ID4gICAgICAgICAtIEJFL0FudHdlcnApIDxr b2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20NCj4gPiAgICAgICAgIDxtYWlsdG86 a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPj4NCj4gPiAgICAgICAgICpTdWJq ZWN0OiogUmU6IEVDTiBpbiBRVUlDDQo+ID4NCj4gPiAgICAgICAgICAgICBPbiAxNiBBdWcgMjAx NywgYXQgMTA6MzMsIEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gPiAgICAgICAgICAgICA8aW5nZW1h ci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPiAgICAgICAgICAgICA8bWFpbHRvOmluZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgICAgICAg ICBIaQ0KPiA+DQo+ID4gICAgICAgICAgICAgRmluYWxseSBiYWNrIGZyb20gdmFjYXRpb24sIGFu ZCB2ZXJ5IGdyYXRlZnVsIGZvciB0aGUNCj4gPiAgICAgICAgICAgICBzdXBwb3J0IHRvIGNvbnRp bnVlIHRoZSB3b3JrIHRvIGFkZCBFQ04gaW4gUVVJQy4NCj4gPg0KPiA+ICAgICAgICAgICAgIEp1 c3QgdG8gcmVjYXAuLiB0aGVyZSB3ZXJlIHR3byBtYWluIHRvcGljcyByYWlzZWQgYXQgdGhlDQo+ ID4gICAgICAgICAgICAgbWVldGluZw0KPiA+DQo+ID4gICAgICAgICAgICAgMSkgRUNOIGluZm8g aW4gQUNLIGZyYW1lIG9yIGluIGRlZGljYXRlZCBmcmFtZSA6IFRoZXJlDQo+ID4gICAgICAgICAg ICAgd2VyZSBjb25jZXJucyBhYm91dCBhZGRpbmcgZXh0cmEgY29tcGxleGl0eSBpbiBhbiBhbHJl YWR5DQo+ID4gICAgICAgICAgICAgcG90ZW50aWFsbHkgY29tcGxleCBBQ0sgZnJhbWUsIG9uZSBj YW4gaGF2ZSBkaWZmZXJpbmcNCj4gPiAgICAgICAgICAgICBvcGluaW9ucyBhYm91dCB0aGUgY29t cGxleGl0eSBidXQgY2FuIHVuZGVyc3RhbmQgdGhlDQo+ID4gICAgICAgICAgICAgY29uY2VybnMu IEFzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCwgYSBzZXBhcmF0ZSBmcmFtZSB0eXBlDQo+ID4gICAg ICAgICAgICAgZm9yIEVDTiBpcyBwb3NzaWJsZSwgcG9zc2libHkgb25lIG5lZWQgdG8gYWRkIGlu Zm9ybWF0aW9uDQo+ID4gICAgICAgICAgICAgYWJvdXQgdGhlIGFtb3VudCBvZiBub3QtRUNUIG1h cmtlZCBwYWNrZXRzIGFzIHdlbGwgdG8ga2VlcA0KPiA+ICAgICAgICAgICAgIHRoZSBzaWduYWxp bmcgcm9idXN0LCB0aGlzIG5lZWRzIGZ1cnRoZXIgaW52ZXN0aWdhdGlvbg0KPiA+ICAgICAgICAg ICAgIHRob3VnaC4gT25lIGNvbmNlcm4gd2l0aCBhIHNlcGFyYXRlIEVDTiBmcmFtZSBpcyB0aGF0 IGl0DQo+ID4gICAgICAgICAgICAgYmVjb21lcyBhIG5vdC1pbXBsZW1lbnRlZCBvciBvcHRpb25h bCBmZWF0dXJlLCBpcyB0aGVyZQ0KPiA+ICAgICAgICAgICAgIGFueSByZWFzb24gdG8gYmUgd29y cmllZCBhYm91dCB0aGlzID8NCj4gPg0KPiA+ICAgICAgICAgICAgIDIpIE1vcmUgZGV0YWlsZWQg RUNOIGluZm9ybWF0aW9uIDogRWFybGllciB2ZXJzaW9ucyBvZiB0aGUNCj4gPiAgICAgICAgICAg ICBFQ04gaW4gUVVJQyBkcmFmdA0KPiA+ICAgICAgICAgICAgIChzZWVodHRwczovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQNCj4gPiAgICAgICAgICAg ICA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDEu dHh0PikNCj4gPiAgICAgICAgICAgICBwcm92aWRlZCB3aXRoIGV4YW1wbGVzLiBXZSAoTXlzZWxm LCBLb2VuLCBNaXJqYSBhbmQNCj4gPiAgICAgICAgICAgICBQcmF2ZWVuKSBkaXNjdXNzZWQgdGhp cyBhbmQgd2UgY291bGQgbm90IGNvbWUgdXAgd2l0aCBhbnkNCj4gPiAgICAgICAgICAgICB1c2Ug Y2FzZSB3aGVyZSBpdCBpcyBiZW5lZmljaWFsIHRvIGtub3cgZXhhY3RseSBob3cgZWFjaA0KPiA+ ICAgICAgICAgICAgIHBhY2tldCBpcyBFQ04gbWFya2VkLiBJIGtub3cgdGhhdCB0aGlzIGtpbmQg b2YgZGV0YWlsZWQNCj4gPiAgICAgICAgICAgICBFQ04gaW5mb3JtYXRpb24gaXMgc3VnZ2VzdGVk IGZvciB0aGUgZ2VuZXJpYyBmZWVkYmFjayBmb3INCj4gPiAgICAgICAgICAgICBSTUNBVCBhbmQg SSBwZXJzb25hbGx5IGhhdmUgYSBwcm9ibGVtIHRvIHNlZSB0aGUgZ2FpbiB3aXRoDQo+ID4gICAg ICAgICAgICAgdGhlIGRldGFpbGVkIEVDTiBpbmZvcm1hdGlvbiBhbHNvIGhlcmUuIElucHV0IGZy b20gb3RoZXJzDQo+ID4gICAgICAgICAgICAgaXMgdmVyeSB3ZWxjb21lIGhlcmUuDQo+ID4NCj4g PiAgICAgICAgIEZvciB0aGUgUk1DQVQgZm9ybWF0LCB3ZSB3YW50ZWQgcGVyLXBhY2tldCBsb3Nz IGFuZCB0aW1pbmcNCj4gPiAgICAgICAgIGluZm9ybWF0aW9uLCBhbmQgaXQgd2FzIGFzIGVhc3kg dG8gZmVlZGJhY2sgcGVyLXBhY2tldCBFQ04NCj4gPiAgICAgICAgIGluZm9ybWF0aW9uIGFsb25n IHdpdGggaXQgYXMgdG8gZGVzaWduIHNvbWV0aGluZyBkaWZmZXJlbnQuDQo+ID4NCj4gPiAgICAg ICAgIEEgYmVuZWZpdCBvZiBwZXItcGFja2V0IEVDTiBtYXJraW5nIGNvdWxkIGJlIHRvIGFsbG93 IGENCj4gPiAgICAgICAgIGNvbmdlc3Rpb24gY29udHJvbGxlciB0aGF0IHJlYWN0ZWQgZGlmZmVy ZW50bHkgdG8gYnVyc3RzIG9mDQo+ID4gICAgICAgICBjb25zZWN1dGl2ZSBFQ04gbWFya3MgdGhh biBpdCBkaWQgdG8gaXNvbGF0ZWQgRUNOIG1hcmtzLCBnaXZlbg0KPiA+ICAgICAgICAgdGhlIHNh bWUgZnJhY3Rpb24gb2YgbWFya2VkIHBhY2tldHMgKGkuZS4sIHRoYXQgcmVhY3RlZCB0byBFQ04N Cj4gPiAgICAgICAgIG1hcmtpbmcgZXZlbnRzIHJhdGhlciB0aGFuIEVDTiBtYXJraW5nIHJhdGUs IGxpa2UgaG93IFRDUA0KPiA+ICAgICAgICAgcmVzcG9uZHMgdG8gbG9zcyBldmVudHMpLiBJIGRv buKAmXQgdGhpbmsgd2UgaGF2ZSBzdWNoIGEgdGhpbmcsDQo+ID4gICAgICAgICBidXQgY2VydGFp bmx5IGluIHRoZSBjb250ZXh0IG9mIFJNQ0FUIHdoZXJlIHdl4oCZcmUNCj4gPiAgICAgICAgIGV4 cGVyaW1lbnRpbmcgd2l0aCBub3ZlbCBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lcyBmb3INCj4g PiAgICAgICAgIHRyYWZmaWMgdGhhdCBoYXMgdmVyeSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNz IHRvIHRyYWRpdGlvbmFsDQo+ID4gICAgICAgICBidWxrIGZsb3dzLCBpdCBtaWdodCBiZSBwbGF1 c2libGUuIFBlci1wYWNrZXQgbWFya2luZw0KPiA+ICAgICAgICAgaW5mb3JtYXRpb24gaXMgYWxz byB1c2VmdWwgZm9yIHRyb3VibGVzaG9vdGluZy4NCj4gPg0KPiA+ICAgICAgICAgQ2VydGFpbmx5 IHdlIG5lZWQgdG8ga25vdyBudW1iZXIgb2YgTm90RUNULCBFQ1QoMCksIEVDVCgxKSwNCj4gPiAg ICAgICAgIGFuZCBFQ04tQ0UgbWFya3Mgc2luY2UgdGhlIGxhc3QgcmVwb3J0LCBidXQgSSBndWVz cyB0aGF04oCZcw0KPiA+ICAgICAgICAgYWxyZWFkeSBwb3NzaWJsZS4NCj4gPg0KPiA+ICAgICAg ICAgQ2hlZXJzLA0KPiA+DQo+ID4gICAgICAgICBDb2xpbg0KPiA+DQo+ID4gICAgICAgICAgICAg VGhlcmUgYXJlIGEgY29uc2VxdWVuY2VzIHdpdGggZGV0YWlsZWQgRUNOIG1hcmtpbmcNCj4gPiAg ICAgICAgICAgICBpbmZvcm1hdGlvbi4NCj4gPg0KPiA+ICAgICAgICAgICAgIGEpIG5lY2Vzc2Fy eSB0byBjb3JyZWxhdGUgd2l0aCB0aGUgbGlzdCBvZiB0cmFuc21pdHRlZA0KPiA+ICAgICAgICAg ICAgIHBhY2tldHMsIHRoaXMgaW5jcmVhc2VzIGFtb3VudCBvZiBjb2RlIG9uIHNlbmRlciBzaWRl LCBub3QNCj4gPiAgICAgICAgICAgICBzdXJlIG9mIHRoYXQgaXMgYSBsYXJnZSBjb25jZXJuIGFz IGxvb2t1cCBpcyBhbnl3YXkgbmVlZGVkDQo+ID4gICAgICAgICAgICAgdG8gcHJvY2VzcyBpbmNv bWluZyBBQ0tzDQo+ID4NCj4gPiAgICAgICAgICAgICBiKSBuZWNlc3NhcnkgdG8gZW1iZWQgRUNO IGluZm9ybWF0aW9uIGluIEFDSyBmcmFtZSA/LCBhdA0KPiA+ICAgICAgICAgICAgIGxlYXN0IHRo aXMgd2FzIG15IGNvbmNsdXNpb24gd2hlbiBJIGRldmlzZWQgdGhlIGRldGFpbGVkDQo+ID4gICAg ICAgICAgICAgRUNOIG1hcmtpbmcgaW5mbyBpbiB0aGUgMDEgdmVyc2lvbiBvZiB0aGUgZHJhZnQu DQo+ID4NCj4gPiAgICAgICAgICAgICBDb21tZW50cyBhcmUgd2VsY29tZQ0KPiA+DQo+ID4gICAg ICAgICAgICAgL0luZ2VtYXINCj4gPg0KPiA+ICAgICAgICAgICAgID09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCj4gPg0KPiA+ICAgICAgICAgICAgIEluZ2VtYXIgSm9oYW5zc29u ICBNLlNjLg0KPiA+DQo+ID4gICAgICAgICAgICAgTWFzdGVyIFJlc2VhcmNoZXINCj4gPg0KPiA+ ICAgICAgICAgICAgIEVyaWNzc29uIEFCDQo+ID4NCj4gPiAgICAgICAgICAgICBXaXJlbGVzcyBB Y2Nlc3MgTmV0d29ya3MNCj4gPg0KPiA+ICAgICAgICAgICAgIExhYnJhdG9yaWVncsOkbmQgMTEN Cj4gPg0KPiA+ICAgICAgICAgICAgIDk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NCj4gPg0KPiA+ICAg ICAgICAgICAgIFBob25lICs0Ni0xMDcxIDQzMDQyDQo+ID4NCj4gPiAgICAgICAgICAgICBTTVMv TU1TICs0Ni03MyAwNzggMzI4OSA8dGVsOis0NiUyMDczJTIwMDc4JTIwMzIlMjA4OT4NCj4gPg0K PiA+ICAgICAgICAgICAgIGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tDQo+ID4gICAg ICAgICAgICAgPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPg0K PiA+ICAgICAgICAgICAgIHd3dy5lcmljc3Nvbi5jb20gPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29t Pg0KPiA+DQo+ID4gICAgICAgICAgICAgQSBtaXN0YWtlIGlzIHRvIGNvbW1pdCBhIG1pc3VuZGVy c3RhbmRpbmcNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCb2IgRHlsYW4N Cj4gPiAgICAgICAgICAgICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4N Cj4gPg0KPiA+DQo+ID4gICAgICAgICAtLQ0KPiA+ICAgICAgICAgQ29saW4gUGVya2lucw0KPiA+ ICAgICAgICAgaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4g LS0NCj4gPiBUaGFua3MNCj4gPiBGcmFuayBLYXN0ZW5ob2x6DQo+ID4NCg0K From nobody Wed Sep 20 12:02:59 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37736132A1A for ; Wed, 20 Sep 2017 12:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vauRxsmRCrcn for ; Wed, 20 Sep 2017 12:02:56 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F201342EE for ; Wed, 20 Sep 2017 12:02:55 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dukGr-0000E8-FN for quic@ietf.org; Wed, 20 Sep 2017 21:02:54 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dukGn-0005Cu-Gv for quic@ietf.org; Wed, 20 Sep 2017 15:02:50 -0400 Received: (qmail 15510 invoked from network); 20 Sep 2017 19:02:46 -0000 Received: from unknown (HELO [192.168.51.25]) (Authenticated-user:_huitema@huitema.net@[109.7.15.233]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 20 Sep 2017 19:02:46 -0000 To: quic@ietf.org References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> From: Christian Huitema Message-ID: <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> Date: Wed, 20 Sep 2017 12:02:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: ECN in QUIC X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.08) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYWea6pBBugJdVQWCV6zgcsND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23tcgVKugMr1WLubMBeqiDNhPRttk4Bp/8JqNz G6qOjoe2nofwiui/LHOXwJfOc9AQYOEkjsX7F8KmpUaZQHV+SU9tg6wnJ2lrZSUCZrKFYsG2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKrrXdhf8mmRqp8CWMEqUPffPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEexzatEraFXUUFPPHNtr4oMCpb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/NIE2fA2moNt4Hv5HnFO+CGfOag26sJVU91vDlVZmVFHlb9244bECKiKR/hrY05iAlD HFuZKzT7NacHCQpEukcT98CnEMYGJXeX2FPBX4nK+/THZmy0ZTLuqb6sDTSWX94wNWXck/0zJbGG SpWW4N15Yc5lGptZ6vZcmaurYnT/NhklgDtVC2Xqa4QCRhTuoCmXPUJkXUk8tGhJsBnmMDbaKcNO SCytRyeT1c4b6jF7fwEPC4qKgjHZeZ4K8UP0yUn1sqaV91XNHFeI9TJDSE4FAkTIlsBpxG8LmrQ7 lfux3WGbBR2kuqsho5UgYYyTxFU= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 19:02:58 -0000 On 9/20/2017 9:51 AM, Ingemar Johansson S wrote: > Detailed info about which packets are ECN marked can be useful but are = not stricktly necessary. One alternative, that is presented in the ECN-QU= IC draft is to count number of marked bytes.=20 > That said, some like the detailed packet-level information type better.= I have not yet been convinced that that this level of detail is necessar= y though.=20 The problem is whether you can define a one size fit all ECN processing, that if possible should be compatible with ACK compression. There are at least two: * RFC 3168 says, echo ECN=3D1 if at least one of the acked packets had EC= N set. * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction of packet acked with ECN in 1RTT is the same as the fraction of packets with ECN set. So, which one? --Christian Huitema From nobody Wed Sep 20 12:53:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC41342E1 for ; Wed, 20 Sep 2017 12:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 TVZCcQhpCuVy for ; Wed, 20 Sep 2017 12:53:26 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D874132C32 for ; Wed, 20 Sep 2017 12:53:26 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id q80so2677847ywg.2 for ; Wed, 20 Sep 2017 12:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t8AYL4g5nKx2R/TqS8qPSJa9lRQzdlv2li8NFR17g3I=; b=knSr8v2Q3I6+tr57itafM/3Ja3M2xHoRlzw52xgdL+RIx06M+3LcyA1vhIhJPqkTkk kUyuk5iTf6cKLQ3Npy2iWcHh/O+5xwdwSqNsYN81u+nFhX65p4R1Be0CSncV6tjp9CJH BExq5F8V+exHPM5CkFS0tQUJnPVL910pQDAJHr/lIVMNEGm2qYuIlvi0OCa8/y4YpzGq kuUeHoKyhix6013T7wjBX8+q6MuHmZdrLy6qN3G2qDKr5t8IRONifxoLzpf5ZTf46fS4 FcHsuheuLj9bieEixgtEcr3q2oGCQO5MwFMxgoRP86PHmEegDRLkMFpBUxXu/2yl6j1j mXSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t8AYL4g5nKx2R/TqS8qPSJa9lRQzdlv2li8NFR17g3I=; b=l26+c1IW+kDnwrvkzjk9en4VEMbtLnwyDiFnty2mdR8zO3gAWQxfwNaisCs8Juzu0y qL7P55ja600IJ+d9LU9+DStFV6I0eJzI2n+tZHBDtqel2Lwym4EhZ9KEAjHucK7BfwCZ nBHMJ4km/okEqlSFxOxeWV3Jv6W5pRU5WyvJzYZSB8kMbNNE7+/7INCGQLvMRubxGsfi 4AN430tDHjH8WjMl8JKK9J72yzkOwO8AUurj22/wVbuHOPhLTOn9Q98mgOVbZxQvn4iI gkbOxYyh4UzlkYfRL2qr/TiFxxa+FyMD+lAlkU5i3ih1/PZXJ65ouM+ADNXhElp9Dd4L bBWw== X-Gm-Message-State: AHPjjUgaOAsK0oTFsME4L7ltT8zvpXYsYUAPC1mWgpgHQs/28mrf8SCf BHxQj3w5+Mh4NeqRpDfWJdbFiMFyDYyyDPLmZj+BmBJv X-Google-Smtp-Source: AOwi7QCTn4LEH3s+tdt961XeA76fryjzsSbNxd/Pcc9X7GIPwIZsjSSBMWbsk+fXnNc6UQAVRH9V5fQyV3hLTdnhs4Q= X-Received: by 10.129.199.13 with SMTP id m13mr4770474ywi.140.1505937205488; Wed, 20 Sep 2017 12:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Wed, 20 Sep 2017 12:53:24 -0700 (PDT) In-Reply-To: <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> From: Jana Iyengar Date: Wed, 20 Sep 2017 12:53:24 -0700 Message-ID: Subject: Re: ECN in QUIC To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e0821fc0c306ae90559a454a5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 19:53:28 -0000 --089e0821fc0c306ae90559a454a5 Content-Type: text/plain; charset="UTF-8" If you have an ECN bit per acked packet, like with timestamps, you don't have to choose. That can be a sender-side decision of what to do with the signal. On Wed, Sep 20, 2017 at 12:02 PM, Christian Huitema wrote: > > > On 9/20/2017 9:51 AM, Ingemar Johansson S wrote: > > Detailed info about which packets are ECN marked can be useful but are > not stricktly necessary. One alternative, that is presented in the ECN-QUIC > draft is to count number of marked bytes. > > That said, some like the detailed packet-level information type better. > I have not yet been convinced that that this level of detail is necessary > though. > > The problem is whether you can define a one size fit all ECN processing, > that if possible should be compatible with ACK compression. There are at > least two: > > * RFC 3168 says, echo ECN=1 if at least one of the acked packets had ECN > set. > > * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction of > packet acked with ECN in 1RTT is the same as the fraction of packets > with ECN set. > > So, which one? > > --Christian Huitema > > --089e0821fc0c306ae90559a454a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you have an ECN bit per acked packet, like with timesta= mps, you don't have to choose. That can be a sender-side decision of wh= at to do with the signal.

On Wed, Sep 20, 2017 at 12:02 PM, Christian Huitema <huite= ma@huitema.net> wrote:


On 9/20/2017 9:51 AM, Ingemar Johansson S wrote:
> Detailed info about which packets are ECN marked can be useful but are= not stricktly necessary. One alternative, that is presented in the ECN-QUI= C draft is to count number of marked bytes.
> That said, some like the detailed packet-level information type better= . I have not yet been convinced that that this level of detail is necessary= though.

The problem is whether you can define a one size fit all ECN process= ing,
that if possible should be compatible with ACK compression. There are at least two:

* RFC 3168 says, echo ECN=3D1 if at least one of the acked packets had ECN<= br> set.

* draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction of
packet acked with ECN in 1RTT is the same as the fraction of packets
with ECN set.

So, which one?

--Christian Huitema


--089e0821fc0c306ae90559a454a5-- From nobody Wed Sep 20 21:43:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20071342F3 for ; Wed, 20 Sep 2017 21:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uJhW7jJeDvea for ; Wed, 20 Sep 2017 21:43:54 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901DD124239 for ; Wed, 20 Sep 2017 21:43:54 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dutL6-0003hC-3P for quic@ietf.org; Thu, 21 Sep 2017 06:43:52 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dutL3-0003LQ-GI for quic@ietf.org; Thu, 21 Sep 2017 00:43:50 -0400 Received: (qmail 26943 invoked from network); 21 Sep 2017 04:43:47 -0000 Received: from unknown (HELO [192.168.51.25]) (Authenticated-user:_huitema@huitema.net@[109.7.15.233]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Sep 2017 04:43:47 -0000 To: quic@ietf.org References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> From: Christian Huitema Message-ID: <0a9f93a9-248a-d41e-d638-d42a9b0648cc@huitema.net> Date: Wed, 20 Sep 2017 21:43:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------506A39801BC0C8B3E12D1EB7" Subject: Re: ECN in QUIC X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJY8hyefn/FOeAH6Zsqubs62ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA235LfxwvSgl6bAziyf8AvmJzCwsQwWQaOhgSJE qnWSx1A68/fInWC5JGrxf60J5TodYOEkjsX7F8KmpUaZQHV+SWsC1ltxhvDAAiytf1zpGXO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKOHi0RYvlOYvJoUtCbvS/bfPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEe+k+fP9t9M+z5v31harRrHapb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/MrWVhqgmvP+ZFPzpqryle+fOag26sJVU91vDlVZmVFHoHOPocIAQXCXdbljHVoU+TL v3Mz7HKrwpxO8UZg9F+1Q0pmjPr72MdmVGuYwG34EPPZ3XKOQW/bgFNkq8wJDYT3qFaOjI5/dzuM 8BN6ByZkP5VR2wwx3je26eGjWD/UlHB/3WCT/ywxqGyDcX7ymo81pn6M7II0pBZMP8Q2yl7HZ8cC 5NCzOtKFVG2OgcPUMeKVse1sVhWabI0/+PN3sILCmP4sL9m2Y1BvIAo6egCemilw+ioChJ5n7tfm eH2kchap9/JGM7LGxIWWH81zEGo= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 04:43:56 -0000 This is a multi-part message in MIME format. --------------506A39801BC0C8B3E12D1EB7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/20/2017 12:53 PM, Jana Iyengar wrote: > If you have an ECN bit per acked packet, like with timestamps, you > don't have to choose. That can be a sender-side decision of what to do > with the signal. > Yes, but if you want to do that you need the ACK to convey the list of each acknowledged packet, with information like time stamp and ECN bit. This is different from carrying information about the ranges of acknowledged packet, which in the simplest form is "received up to largest, size of range". You also have to worry about ACK compression, ACK losses, and out of order delivery of ACK. That will be a big departure from the current spec. -- Christian Huitema --------------506A39801BC0C8B3E12D1EB7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 9/20/2017 12:53 PM, Jana Iyengar wrote:

If you have an ECN bit per acked packet, like with timestamps, you don't have to choose. That can be a sender-side decision of what to do with the signal.


Yes, but if you want to do that you need the ACK to convey the list of each acknowledged packet, with information like time stamp and ECN bit. This is different from carrying information about the ranges of acknowledged packet, which in the simplest form is "received up to largest, size of range". You also have to worry about ACK compression, ACK losses, and out of order delivery of ACK. That will be a big departure from the current spec.

-- Christian Huitema
--------------506A39801BC0C8B3E12D1EB7-- From nobody Thu Sep 21 06:53:51 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1703B13307E for ; Thu, 21 Sep 2017 06:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 5n63XcR0TI46 for ; Thu, 21 Sep 2017 06:53:49 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0979F1321C7 for ; Thu, 21 Sep 2017 06:53:49 -0700 (PDT) Received: from [130.209.247.112] (port=57656 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dv1vF-0005LJ-Cf; Thu, 21 Sep 2017 14:53:46 +0100 From: Colin Perkins Message-Id: <5C04F568-534E-4990-B79D-DCCB725F84F2@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_35D44AC0-0F31-4632-9D1B-F966C9FDA2E5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ECN in QUIC Date: Thu, 21 Sep 2017 14:53:42 +0100 In-Reply-To: Cc: Christian Huitema , IETF QUIC WG To: Jana Iyengar References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 13:53:51 -0000 --Apple-Mail=_35D44AC0-0F31-4632-9D1B-F966C9FDA2E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, but note that you need to echo two ECN bits per acked packet. Colin > On 20 Sep 2017, at 20:53, Jana Iyengar wrote: >=20 > If you have an ECN bit per acked packet, like with timestamps, you = don't have to choose. That can be a sender-side decision of what to do = with the signal. >=20 > On Wed, Sep 20, 2017 at 12:02 PM, Christian Huitema = > wrote: >=20 >=20 > On 9/20/2017 9:51 AM, Ingemar Johansson S wrote: > > Detailed info about which packets are ECN marked can be useful but = are not stricktly necessary. One alternative, that is presented in the = ECN-QUIC draft is to count number of marked bytes. > > That said, some like the detailed packet-level information type = better. I have not yet been convinced that that this level of detail is = necessary though. >=20 > The problem is whether you can define a one size fit all ECN = processing, > that if possible should be compatible with ACK compression. There are = at > least two: >=20 > * RFC 3168 says, echo ECN=3D1 if at least one of the acked packets had = ECN > set. >=20 > * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction = of > packet acked with ECN in 1RTT is the same as the fraction of packets > with ECN set. >=20 > So, which one? >=20 > --Christian Huitema >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_35D44AC0-0F31-4632-9D1B-F966C9FDA2E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, but note that you need to echo two ECN bits per acked = packet.
Colin


On 20 Sep 2017, at 20:53, Jana = Iyengar <jri@google.com> wrote:

If you have an ECN bit per acked packet, like with = timestamps, you don't have to choose. That can be a sender-side decision = of what to do with the signal.

On Wed, Sep 20, 2017 at 12:02 PM, = Christian Huitema <huitema@huitema.net> wrote:


On 9/20/2017 9:51 AM, Ingemar Johansson S wrote:
> Detailed info about which packets are ECN marked can be useful but = are not stricktly necessary. One alternative, that is presented in the = ECN-QUIC draft is to count number of marked bytes.
> That said, some like the detailed packet-level information type = better. I have not yet been convinced that that this level of detail is = necessary though.

The problem is whether you can define a one size fit all ECN = processing,
that if possible should be compatible with ACK compression. There are = at
least two:

* RFC 3168 says, echo ECN=3D1 if at least one of the acked packets had = ECN
set.

* draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction = of
packet acked with ECN in 1RTT is the same as the fraction of packets
with ECN set.

So, which one?

--Christian Huitema





-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_35D44AC0-0F31-4632-9D1B-F966C9FDA2E5-- From nobody Fri Sep 22 00:20:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844701342AC for ; Fri, 22 Sep 2017 00:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 sUygSZxqoIOS for ; Fri, 22 Sep 2017 00:20:30 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32698133187 for ; Fri, 22 Sep 2017 00:20:30 -0700 (PDT) X-AuditID: c1b4fb30-66bff70000007145-41-59c4b9bcf7e7 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6B.4C.28997.CB9B4C95; Fri, 22 Sep 2017 09:20:28 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 22 Sep 2017 09:20:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y0TMUFGW2fNfYkTaaDLBk+2dwcoSnGKE7fp3fqgm0p8=; b=Z7cPxbRYc55eeopadjUgujFR20o4cdsXan2x5EeJXYHUSdjlBF1hXVI5AemFo9WcKK70tIzIwtgAtArBOFy8wfpvZa01XYuZdwhHLTEYDXJUfBw3mXd12OUy8lADD2kEp3tc3BfVvzcakWApTjuKeXrSCB+cN6+d2l5ZvNbo5c0= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 22 Sep 2017 07:20:26 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.011; Fri, 22 Sep 2017 07:20:25 +0000 From: Ingemar Johansson S To: Colin Perkins , Jana Iyengar , Christian Huitema CC: IETF QUIC WG , Ingemar Johansson S Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdMWaIZN+ofkuQeuQOGGa2om9/ikzaLAfgOw Date: Fri, 22 Sep 2017 07:20:25 +0000 Message-ID: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> <5C04F568-534E-4990-B79D-DCCB725F84F2@csperkins.org> In-Reply-To: <5C04F568-534E-4990-B79D-DCCB725F84F2@csperkins.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 6:Fj37iG2Jv8I6To/g7b16Cr2pZS1678y8nK1uEYZU1y1bkE0Sqy655CxmCRfLuA+0wlGZMFVAq0S0M9tOkvvN43GA3e3xclhEpZURkO3O6dt6OwUkhAK4I/9eASKHLMtTH5XcM36lcES92pujhF29GY/mETw45HDmDGtXtbOLpb/K/VhZOC1UcSMcbd1i3jPdYtoAggaqYfGMTE5pcaX7AwUT/swmoXTxiD4gcCLyqxt6dsbhJzz1UyZuiETWu+2pLB9uTdU30zb7/sxRY9cUJ8rmdoxPdceM8tzQtfqiewR9I594gvE5mDlnoftp6TSs3whuoi59Ku3KUDwd9jlyHw==; 5:Sg9pQHIk741MDexV7EySa0+OrgSf1i/82Qh39QOgYVqmrlTJwexrP1sfnwLQ88DrCjOaFyPQoyz1IrMgk+epUQELD6qwB6GWTVScXsCT6N4wLCSI8ynoAdxB3/ckYWhW9zn0RZZOCV4TzprF1YV68w==; 24:RiLWWLp+zGmY5zQvFFICUC64tHUfPFhpX5iGsBT6sbeMZvLDkI7O0k0QYALwp7lxytRYrr2iNFcVMZ6j8rPdptNG8kZXeTv7GOJBI7Rl7kw=; 7:Z78Ge9PpHajlCDzTdVbzcnvp50mcTY2CcRxJ+kRCaNPplTHlygFNhFw2QWDKv42Kn1NQodpVh89Ov8yaaWtvZbJPWuQGS4/RYtmxVErltZPfslVAi5y8YFMHYD/sqspzv+Ud9QZgUhg62z7Uuaqf04/WtCM58WGKe3nulkM3uhI1ubCGNtMRLG6eCJumXuWEooI0otYFoZvmtPdyp4cE8wgaadZ0t2ioYUHkt3+rql8= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(24454002)(377454003)(189002)(199003)(105586002)(236005)(6506006)(9326002)(229853002)(3660700001)(106356001)(3846002)(102836003)(53936002)(74316002)(790700001)(54906003)(34040400001)(19609705001)(110136005)(7736002)(6116002)(97736004)(6436002)(5250100002)(189998001)(316002)(2900100001)(2950100002)(101416001)(606006)(3480700004)(8936002)(81166006)(55016002)(25786009)(33656002)(76176999)(54356999)(6306002)(86362001)(93886005)(14454004)(7696004)(81156014)(478600001)(9686003)(99286003)(54896002)(7116003)(5660300001)(50986999)(8676002)(966005)(66066001)(4326008)(107886003)(53546010)(3280700002)(6246003)(2906002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: bc6986e5-2a95-4256-843f-08d5018a64fd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB346; x-ms-traffictypediagnostic: DB4PR07MB346: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(920507026)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB346; x-forefront-prvs: 0438F90F17 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348D1CC062A72262337F06FC2670DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2017 07:20:25.2368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe885246z0WnTfDREGRlZ5mVJjBJL+tD8ENiN1K5LD7rSTTe1 jASFlrQSRDNviZsub4WVKBZOyzVTy2ioYGo4zUusi8QwNBRp7lXw2+///z+X94GXJoWdHB9a ocxg1Up5ipjLp8pj28/tN722xIUW67dJ6+19SFqcV8mTFvUYKOkDvftRSvbIZuPK9C2ZsrGy D5TMaPxHxFDx/IhENkWRxapDIq/wk83lDUTapOxmsaOHl4tqI3XIjQYmHJ7OtvJ0iE8LGQuC 8ZEpCos+BKW1jeSaoJgCEvKbmxBOSgiYMHasCxuCsSYrWhvGZSKg0bzoYg9GBc9/L5BrTDLx 0LJU5fJFDID+fRGBa7xhfkFLYZZA8/yIiykmACq+zLp6Bc7elcezBF5m50C1btkVuDFRkFdS 52LE+IJtcYLCy7xgbKaawNcxYDR9JjF7gn16lYPrE8AxWsDBvj+M1/dSmH1hsPq+6zJgtDyY G37Mw8EB0BWaODgY5oLjhRbh4AS8u9u23jFFgHluxbmOdopAsE4exjUXYLxTy8O2AiwG9/U5 HOjsHuQUoqCKTQ/HrIIayy8XC5jt0F8+Q2E/CPQdDi7mfVBn+Elu8MDbaWKzr0e8JuSpYTVX U5MkkmBWrUjQaFTKYCWb0YKcn6q7dTn0FbJ/jzIjhkbirQKL3hIn5MizNNmpZgQ0KfYQ3Hji tASJ8uxbrFp1WZ2ZwmrMaCdNib0EUV3WWCGTJM9gr7NsGqveSAnazScX7X6pNNYMnpKs3u76 uOus5aHo0vlR9di9Z9H9i2xO84/Ts3yd8E5c2UWTPPOQHzp+LUxRmqXvagw/c3LL15yYdNOf pejAfv8pmzzd99jKX/sOv/biIwGVbdY+dLCtsyghLKkwpDeqVDTwyTC4NLIwXJU0NPTtTU5+ u3eHe8PCnh6RmNIky8P2kmqN/D+aOSL4UAMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 07:20:32 -0000 --_000_DB4PR07MB348D1CC062A72262337F06FC2670DB4PR07MB348eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yes, I agree with Colin and Jana. If you have one (or two) bits per ACKed packet then there should not be any= problem. See page 5 and 6 in https://tools.ietf.org/id/draft-johansson-quic-ecn-01.t= xt for possible encodings One can discuss if it is necessary with 2 bits, one benefit with 2 bits is = that it is more versatile and gives a possibility to track possible "unlawf= ul" remarking of the ECN bits in the network. With that said, as mentioned earlier, one can echo the number of marked byt= es as shown in section 2.3 in https://tools.ietf.org/id/draft-johansson-qui= c-ecn-03.txt Of course, one lose the ability to see which packets are marked how, the be= nefit is that the format becomes more compact. /Ingemar From: Colin Perkins [mailto:csp@csperkins.org] Sent: den 21 september 2017 15:54 To: Jana Iyengar Cc: Christian Huitema ; IETF QUIC WG Subject: Re: ECN in QUIC Yes, but note that you need to echo two ECN bits per acked packet. Colin On 20 Sep 2017, at 20:53, Jana Iyengar > wrote: If you have an ECN bit per acked packet, like with timestamps, you don't ha= ve to choose. That can be a sender-side decision of what to do with the sig= nal. On Wed, Sep 20, 2017 at 12:02 PM, Christian Huitema > wrote: On 9/20/2017 9:51 AM, Ingemar Johansson S wrote: > Detailed info about which packets are ECN marked can be useful but are no= t stricktly necessary. One alternative, that is presented in the ECN-QUIC d= raft is to count number of marked bytes. > That said, some like the detailed packet-level information type better. I= have not yet been convinced that that this level of detail is necessary th= ough. The problem is whether you can define a one size fit all ECN processing, that if possible should be compatible with ACK compression. There are at least two: * RFC 3168 says, echo ECN=3D1 if at least one of the acked packets had ECN set. * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction of packet acked with ECN in 1RTT is the same as the fraction of packets with ECN set. So, which one? --Christian Huitema -- Colin Perkins https://csperkins.org/ --_000_DB4PR07MB348D1CC062A72262337F06FC2670DB4PR07MB348eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

Yes, I agree with Colin and Jana.

If you have one (or two) bits per ACKed packet then = there should not be any problem.

See page 5 and 6 in https://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt   f= or possible encodings

One can discuss if it is necessary with 2 bits, one = benefit with 2 bits is that it is more versatile and gives a possibility to= track possible “unlawful” remarking of the ECN bits in the net= work.

 

With that said, as mentioned earlier, one can echo t= he number of marked bytes as shown in section 2.3 in https= ://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt

Of course, one lose the ability to see which packets= are marked how, the benefit is that the format becomes more compact.<= /o:p>

 

/Ingemar

 

From: Colin Perkins [mailto:csp@csperkins.org= ]
Sent: den 21 september 2017 15:54
To: Jana Iyengar <jri@google.com>
Cc: Christian Huitema <huitema@huitema.net>; IETF QUIC WG <= quic@ietf.org>
Subject: Re: ECN in QUIC

 

Yes, but note that you need to echo two ECN bits per= acked packet.

Colin

 

 

On 20 Sep 2017, at 20:53, Jana Iyengar <jri@google.com> wrote:

 

If you have an ECN bit per acked packet, like with t= imestamps, you don't have to choose. That can be a sender-side decision of = what to do with the signal.

 

On Wed, Sep 20, 2017 at 12:02 PM, Christian Huitema = <huitema@huitem= a.net> wrote:



On 9/20/2017 9:51 AM, Ingemar Johansson S wrote:
> Detailed info about which packets are ECN marked can be useful but are= not stricktly necessary. One alternative, that is presented in the ECN-QUI= C draft is to count number of marked bytes.
> That said, some like the detailed packet-level information type better= . I have not yet been convinced that that this level of detail is necessary= though.

The problem is whether you can define a one size fit all ECN processing, that if possible should be compatible with ACK compression. There are at least two:

* RFC 3168 says, echo ECN=3D1 if at least one of the acked packets had ECN<= br> set.

* draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction of
packet acked with ECN in 1RTT is the same as the fraction of packets
with ECN set.

So, which one?

--Christian Huitema

 

 



-- 
Colin Perkins
https://csperkins.org/


 

--_000_DB4PR07MB348D1CC062A72262337F06FC2670DB4PR07MB348eurprd_-- From nobody Fri Sep 22 17:11:17 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A15133085; Fri, 22 Sep 2017 17:11:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150612546970.22274.12743291788800546047@ietfa.amsl.com> Date: Fri, 22 Sep 2017 17:11:09 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 00:11:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-06.txt Pages : 20 Date : 2017-09-22 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic . Working Group information can be found at https://github.com/quicwg ; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/recovery . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-06 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-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 Fri Sep 22 17:11:38 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEB713320B; Fri, 22 Sep 2017 17:11:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150612548486.22260.5127184201297121994@ietfa.amsl.com> Date: Fri, 22 Sep 2017 17:11:24 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 00:11:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-06.txt Pages : 80 Date : 2017-09-22 Abstract: This document defines the core of the QUIC transport protocol. This document describes connection establishment, packet format, multiplexing and reliability. Accompanying documents describe the cryptographic handshake and loss detection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-06 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-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 Fri Sep 22 17:11:49 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3C5133245; Fri, 22 Sep 2017 17:11:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150612549872.22278.10318537796755039283@ietfa.amsl.com> Date: Fri, 22 Sep 2017 17:11:38 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 00:11:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-06.txt Pages : 34 Date : 2017-09-22 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-06 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-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 Fri Sep 22 18:16:53 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29C133073; Fri, 22 Sep 2017 18:16:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150612940607.22295.5886066860383752287@ietfa.amsl.com> Date: Fri, 22 Sep 2017 18:16:46 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 01:16:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-06.txt Pages : 38 Date : 2017-09-22 Abstract: This document describes how Transport Layer Security (TLS) is used to secure QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic . Working Group information can be found at https://github.com/quicwg ; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/tls . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-06 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-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 Sun Sep 24 21:03:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93001124F57 for ; Sun, 24 Sep 2017 21:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uZnUtliD_zNE for ; Sun, 24 Sep 2017 21:03:12 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368B1124207 for ; Sun, 24 Sep 2017 21:03:12 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id j126so5213173oia.10 for ; Sun, 24 Sep 2017 21:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SD+Y6yxMQ3fi5dHUWPHkpmlGjJnoaygw8YbAzlYr760=; b=PBfmVVrxtRHRgu+uk+Zq0NUBmwiAQtRINDJdGf30FjK5mJNyST2UP0SBHLGNGTnPfO hOC+mpzVj9JZSRYfcJB7eYvpks+qgw7TY4nJZAeNZF9iJrWJSzj5CViPkzXMexvNZ63m P1cjStNPQdl8za887BohbmmrrB8vsY1rCUr1V3Z6RBKP2CkmHN0Aof4O5V1VxCDhdOZK X7DUZuloyAI4Hj89uu/a4kH1R3flTZwtHENYDQQUs6Ic1jbOtijUd2cJNbav+vylmw42 A3I/kXKC+ZFf4z+I8h5hc/qzsaY4paquNv8Us1V5/HZoOoEzfeBMVdoxYtRnTJnq69zL Ha1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SD+Y6yxMQ3fi5dHUWPHkpmlGjJnoaygw8YbAzlYr760=; b=oOmFB1U0D1JZu3VALwplz6Elaya8ANVKUPrKS6RroPH9IPo85bxPh7nKd7c08+8H2O mOT/j3sR9uQK1Et+jGhXcUc8p8OVizluMO6sI/czhtU1T2TQ6GusP+Z81iS/ttPF4Rl6 bIA9X5VJdqTBQHYvOPex6gEQOaPp7auLZE5AYNGcIBlptwJBvrWYuCCoYrHdypVQT8vo ImvoVfNdwJ846m69OO1zyUXDbj5ZfmBVtRDbm1bvzq3fzzy7h5r2JxCIsHMdtCunNAOh /ygCr7FYnJrBi0lOaGU5HTzBm5uiMN1JFC6vcP00aJ4tY+cOIBlvsafw30WTFNWE1rmZ jYDA== X-Gm-Message-State: AHPjjUgA1v/5t/ZQzwvvOZCSbhI993A24RCF0ecPeSvTpH794xTEMJrK 2FCd/hJov894ItkmXryVMN+uT4NQfrhT5aPKAgQ= X-Google-Smtp-Source: AOwi7QAvrlbVw+K1guLoYXtQ48zY4J/lYLGAqe734NzLZ3uf3OFu9R4yPam9CHR7ZZqjzlkkSsKqBImLeLRdeV+QMao= X-Received: by 10.202.229.203 with SMTP id c194mr8037881oih.92.1506312191426; Sun, 24 Sep 2017 21:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Sun, 24 Sep 2017 21:03:10 -0700 (PDT) In-Reply-To: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> From: Martin Thomson Date: Mon, 25 Sep 2017 14:03:10 +1000 Message-ID: Subject: Re: Split error codes in two To: Roberto Peon Cc: Christian Huitema , "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 04:03:13 -0000 On Thu, Sep 14, 2017 at 12:40 AM, Lubashev, Igor wrot= e: > Thinking about this a bit more, it seems that the key difference between > =E2=80=9Ctcp socket=E2=80=9D and =E2=80=9Ctwo pipe pairs=E2=80=9D models = is independence of the send and > receive directions. I prefer Christian's analogy of streams as messages. That's what motivated the design that I proposed. Then you don't get "pipe pairs" you get "messages and (optionally) response messages". On Thu, Sep 14, 2017 at 5:03 AM, Roberto Peon wrote: > So many RPC models have failed utterly because they couldn=E2=80=99t hand= le > receiving the data in a streaming fashion. That doesn't invalidate the streams-are-messages model, it just recognizes that the messages cannot be sent and received as a single unit (unless they are 0 length, I guess). Flow control, multiplexing, etc, etc... ~ I want to come back to the original question in light of what we learned: -> what is the transport going to **do** with a STOP_SENDING? I can't think of anything other than to tell the application. That makes the answer pretty clear to me. I don't think that this discussion - valuable as it is been - has changed my position on this much. Ideally I would like to enable all the various viewpoints on the question to be equally valid. Building a protocol that can provide something that looks like a TCP socket is challenging though, because the complete close of a coupled pair cannot be done generically - I think that we all agree that this is impossible in the general case. I can appreciate the desire to build some of the pieces that might be needed to build a bidirectional close, but I think that is more dangerous than useful and would prefer to leave this to application protocols. From nobody Mon Sep 25 04:26:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AD0132944 for ; Mon, 25 Sep 2017 04:26:41 -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 autolearn_force=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 jPFKgaQsW30j for ; Mon, 25 Sep 2017 04:26:40 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF16E1342D3 for ; Mon, 25 Sep 2017 04:26:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3y11xk2KVSzMqkR; Mon, 25 Sep 2017 13:26:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEHqQJdliGbZ; Mon, 25 Sep 2017 13:26:33 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC2ADB.dip0.t-ipconnect.de [93.236.42.219]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 25 Sep 2017 13:26:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ECN in QUIC From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> Date: Mon, 25 Sep 2017 13:26:32 +0200 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <88460A72-DFEF-4CD8-8A41-C8684EC65C09@tik.ee.ethz.ch> References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 11:26:42 -0000 There is Accurate ECN (draft-ietf-tcpm-accurate-ecn) in tcpm that = changes the feedback defined in RFC3168 because we believe more accurate = information in needed in future. Mirja > Am 20.09.2017 um 21:02 schrieb Christian Huitema = : >=20 >=20 >=20 > On 9/20/2017 9:51 AM, Ingemar Johansson S wrote: >> Detailed info about which packets are ECN marked can be useful but = are not stricktly necessary. One alternative, that is presented in the = ECN-QUIC draft is to count number of marked bytes.=20 >> That said, some like the detailed packet-level information type = better. I have not yet been convinced that that this level of detail is = necessary though.=20 >=20 > The problem is whether you can define a one size fit all ECN = processing, > that if possible should be compatible with ACK compression. There are = at > least two: >=20 > * RFC 3168 says, echo ECN=3D1 if at least one of the acked packets had = ECN > set. >=20 > * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction = of > packet acked with ECN in 1RTT is the same as the fraction of packets > with ECN set. >=20 > So, which one? >=20 > --Christian Huitema >=20 From nobody Mon Sep 25 04:31:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95031332DA for ; Mon, 25 Sep 2017 04:31: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] autolearn=ham autolearn_force=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 tOs3El-9uRB3 for ; Mon, 25 Sep 2017 04:31:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 95C5613420E for ; Mon, 25 Sep 2017 04:31:39 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 094181B001A7; Mon, 25 Sep 2017 12:31:13 +0100 (BST) Message-ID: <59C8E900.20409@erg.abdn.ac.uk> Date: Mon, 25 Sep 2017 12:31:12 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= CC: Christian Huitema , quic@ietf.org Subject: Re: ECN in QUIC References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> <88460A72-DFEF-4CD8-8A41-C8684EC65C09@tik.ee.ethz.ch> In-Reply-To: <88460A72-DFEF-4CD8-8A41-C8684EC65C09@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 11:31:44 -0000 +1 DCTP is not IETF standard - it's documenting a solution that is deployed in data centres - as it says - my hope is QUIC receives wider deployment. I suggest you start from AccECN, or examine the feedback discussed in RMCAT - which I think strove for equivalence to this. Gorry On 25/09/2017, 12:26, Mirja Kühlewind wrote: > There is Accurate ECN (draft-ietf-tcpm-accurate-ecn) in tcpm that changes the feedback defined in RFC3168 because we believe more accurate information in needed in future. > > Mirja > > >> Am 20.09.2017 um 21:02 schrieb Christian Huitema: >> >> >> >> On 9/20/2017 9:51 AM, Ingemar Johansson S wrote: >>> Detailed info about which packets are ECN marked can be useful but are not stricktly necessary. One alternative, that is presented in the ECN-QUIC draft is to count number of marked bytes. >>> That said, some like the detailed packet-level information type better. I have not yet been convinced that that this level of detail is necessary though. >> The problem is whether you can define a one size fit all ECN processing, >> that if possible should be compatible with ACK compression. There are at >> least two: >> >> * RFC 3168 says, echo ECN=1 if at least one of the acked packets had ECN >> set. >> >> * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction of >> packet acked with ECN in 1RTT is the same as the fraction of packets >> with ECN set. >> >> So, which one? >> >> --Christian Huitema >> From nobody Mon Sep 25 12:15:13 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A3D134562 for ; Mon, 25 Sep 2017 12:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 J5FIfLVtemxo for ; Mon, 25 Sep 2017 12:15:10 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0090.outbound.protection.outlook.com [104.47.40.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C003B134556 for ; Mon, 25 Sep 2017 12:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C3PIU6RxK+wkjIbbCuLSY77mULnI0g/gGLF6TDxfoJ4=; b=ZDyImSfuhEcT+/EfRkaqv7Y8CxGuD0W4HL9VWx4JvtUYieXYPHTOYIEmR0Z+GyA1UksIkwrMd014c4/RI3eBqtuvOgvrHsD4FptLdG1hZZt9c8A+/CXI9c1xgAKPhfEQ8j+34w4otSKY3ic6HuW4uXmHWxro0TE0K7O7n1WF0BE= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0640.namprd21.prod.outlook.com (10.175.141.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.98.3; Mon, 25 Sep 2017 19:15:08 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0098.003; Mon, 25 Sep 2017 19:15:08 +0000 From: Mike Bishop To: QUIC WG CC: Charles 'Buck' Krasic Subject: Header Compression in HTTP/QUIC Thread-Topic: Header Compression in HTTP/QUIC Thread-Index: AdM2McAvn6UDT8T/RZyu5+rv1jQU8Q== Date: Mon, 25 Sep 2017 19:15:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::62] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0640; 6:ntMFGDrAutPruyOmulPAE7h4d4RvoXxNuvDsc300XUzqFrNrNs8URGnyxUXsyJYGdTL0RVE/y0tD9LFL1sP1HzrRxR0J59nYSrN29Iw05CQZ/YGOi/KWYIMPYY0oDt1n0BZVz0vDDvZPW40uhgy6h98QYgWCFFDua1Nn+q4np50B5H93vdMi4UXydKlnXORYe1ymL1pplidS4hTSSjFHgYP6eF5VySSog2JQn3Wh25fGg1XI9Kr5QUbARlYkyuCvX/eo5vTcCKUGWv0AxICr1eC00NS77Bh0y0B86dOMBGQAXocAbvMF39UEJjdATCy3mcaU4KfM7r/IeHe109GGqw==; 5:OcszAXILiFMxfNH5XRKaxj5lzbgT6FcZA4QDHP6p/TxAVxB7H6LUccjzD2Fr1bY4aOo1hC5YGg/AxY2BVpPw+CYptmuJqaBi4kBDAynwhbP8O3SFqJGp9qTuYp1o++3fUy1wSekVwrwAUH4OFlfAcA==; 24:x+01d5ErWY55jaAXmLwMIwWtIFrvwbMA2HkSyYdfh554IAMbTXKHuLUvN9u5QcuWloduZahItJEkVp/hx1Thv8uZJHJ2EzkBdlKEpXWz4xQ=; 7:Piak7GsKfvbZzRwilDs5Z0nxSM4ktA3RsKp7jxfC05K1aLon4UfwX+1QQVg2qEc64j/j4YD9Wkba3Xnoqs7nxQVj3E70NIfwJzrztarp59kKrtHn+lAIwiAqxU4FmCc6AtiEAQcZ4A99WNNPO8nyBiJ61Xd6213iOLcdSGTHbICF+Zbtd7xXr6n7tJ2/sZ2KuwKa5pltGSZe2VYqha4HesC6qZLeyltw1Woz0sd6vhU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 92fcf8e5-8fb9-4727-604c-08d50449bc98 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0640; x-ms-traffictypediagnostic: MWHPR21MB0640: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0640; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0640; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(47760400005)(199003)(51694002)(189002)(6916009)(97736004)(106356001)(53936002)(10090500001)(55016002)(54896002)(22452003)(6306002)(99286003)(68736007)(606006)(102836003)(236005)(6116002)(2900100001)(81156014)(33656002)(81166006)(8936002)(105586002)(3280700002)(8676002)(8990500004)(316002)(790700001)(478600001)(77096006)(86362001)(72206003)(74316002)(2906002)(4326008)(6506006)(25786009)(10290500003)(5660300001)(86612001)(7736002)(101416001)(9686003)(189998001)(54356999)(3660700001)(6436002)(50986999)(14454004)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0640; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0141064E3168946762E46289877A0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 19:15:08.4457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0640 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:15:13 -0000 --_000_MWHPR21MB0141064E3168946762E46289877A0MWHPR21MB0141namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just wanted to call folks' attention to the fact that there's a dedicated s= lot at the end of the interim next week to discuss header compression in HT= TP/QUIC. I've just updated the QPACK draft, and Buck updated the QCRAM draft recently. Please familiarize yo= urselves with the latest versions of the drafts so our discussion can be as= productive as a Thursday late-afternoon can be. Thanks! --_000_MWHPR21MB0141064E3168946762E46289877A0MWHPR21MB0141namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just wanted to call folks’ attention to the fa= ct that there’s a dedicated slot at the end of the interim next week = to discuss header compression in HTTP/QUIC.  I’ve just updated t= he QP= ACK draft, and Buck updated the QCRAM draft= recently.  Please familiarize yourselves with the latest versions= of the drafts so our discussion can be as productive as a Thursday late-af= ternoon can be.

 

Thanks!

--_000_MWHPR21MB0141064E3168946762E46289877A0MWHPR21MB0141namp_-- From nobody Mon Sep 25 16:10:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5F01344FF for ; Mon, 25 Sep 2017 16:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 EFemJuKHnMfC for ; Mon, 25 Sep 2017 16:10:49 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9C2132397 for ; Mon, 25 Sep 2017 16:10:49 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8PN6e2n027922; Tue, 26 Sep 2017 00:10:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=kNq4NdVGGucP2ObenlOfOalJE0mpQYLTsXgydcJ/+Rc=; b=nNnYZuFOhM99GW+pHQsRrJL+91yNIOaa3dEckuyqwVPgnLSC82YtGwJfVmQ/NqvZRkD2 KV0pWzF+BBv9Te5QoBuAwewpk2CiNNCsaVVNcj2VgofcVzwcW3FHloYxQ7CsQXLhfKux TlR4rBzUVeJS175zjV5E9SUVuzrA1gEbJECzwSt7hYTkYVaAMVyPz4VHakyqrl3dJ/lI RzaGzCfMAbDC/B5T1wJMWG0auqFQYx5wA3lt7JAAhz+zlJwtlNdaee9LDxMVf67Q6Vja 7nypuJZDRxfXjEp6ongj51Dz5qCCBqPFQpX3iKiwzsU3pFaYUesi9YwcWAfz3thPNbnx qw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2d761bu0h9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Sep 2017 00:10:39 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8PLJaDx016270; Mon, 25 Sep 2017 19:10:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2d7730gkm1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Sep 2017 19:10:38 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 25 Sep 2017 19:10:37 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Mon, 25 Sep 2017 19:10:37 -0400 From: "Lubashev, Igor" To: Martin Thomson , Roberto Peon CC: "quic@ietf.org" , Christian Huitema Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9U7CZmvfU3U+AKlwSnR9wwKKmV3WAgAASqICAAAONAIAA0yCAgAAOnACAAAMMAIAAAK4AgACXxwCAAJELAIABpR2AgABJmoCAAAS/AIAANHEAgAFsKYCABkENAP//wQ6QgACQnICAAOyhgIARz6YAgADx2lA= Date: Mon, 25 Sep 2017 23:10:37 +0000 Message-ID: <022d9f140d9b4306a959e0dacac788e7@usma1ex-dag1mb5.msg.corp.akamai.com> References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=5800 signatures=585085 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709250277 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-25_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709250342 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 23:10:51 -0000 SSBhZ3JlZSB0aGF0IGluIG1hbnkgY2FzZXMsICJzdHJlYW1zLWFzLW1lc3NhZ2VzIiBtb2RlbCBm aXRzIHdlbGwgaW4gdGhlIGFwcGxpY2F0aW9uIHVzZSBjYXNlIChub3QgSFRUUCBTdHJlYW0gMSwg dGhvdWdoKS4gIEl0IHNlZW1zIHJlYXNvbmFibGUgdG8gc3VwcG9zZSB0aGF0IGFuIGFwcGxpY2F0 aW9uIHdvdWxkIG9jY2FzaW9uYWxseSBsaWtlIHRvIHNlbmQgYSB2ZXJ5IGxhcmdlICgxMDBNQj8p IG1lc3NhZ2UsIGFuZCBpdCBnaXZlcyBpdCB0byB0aGUgdHJhbnNwb3J0IGluIG9uZSBzaG90IC0t IG1heWJlIHVzaW5nIHNvbWV0aGluZyBsaWtlIExpbnV4IHNlbmRmaWxlKCkgQVBJIGNhbGwuDQoN ClNvIG5vdyB0byB5b3VyIHF1ZXN0aW9uOg0KPiAgIC0+IHdoYXQgaXMgdGhlIHRyYW5zcG9ydCBn b2luZyB0byAqKmRvKiogd2l0aCBhIFNUT1BfU0VORElORz8NCg0KVGhlIGFuc3dlciBzZWVtcyBv cnRob2dvbmFsIHRvIGJpZGlyZWN0aW9uYWxpdHkuICBJdCB3b3VsZCBtYWtlIHNlbnNlIGZvciB0 aGUgdHJhbnNwb3J0IHRvIHN0b3Agc2VuZGluZyB0aGUgbWVzc2FnZSBhbmQgbm90aWZ5IHRoZSBh cHBsaWNhdGlvbiB0aGF0IGl0IGRpZCBzby4gIFRoZSBhbHRlcm5hdGl2ZSBpcyB0byBjb250aW51 ZSBzZW5kaW5nIHRoZSBsYXJnZSBmaWxlLCBzcGVuZGluZyBzaWduaWZpY2FudCBuZXR3b3JrIGFu ZCBDUFUgcmVzb3VyY2VzIGRvaW5nIHNvLCBhbmQgaG9waW5nIHRoZSBhcHBsaWNhdGlvbiB3b3Vs ZCBiZSBwcm9tcHQgYXQgcmVjZWl2aW5nIHRoZSBub3RpZmljYXRpb24gYW5kIGFza2luZyB0aGUg dHJhbnNwb3J0IHRvIGNhbmNlbCB0aGUgdHJhbnNmZXIuICBCb3RoIGFsdGVybmF0aXZlcyBhY2hp ZXZlIHRoZSBzYW1lIHNlbWFudGljczogImFuIGFwcCBpcyBub3RpZmllZCB0aGF0IHRoYXQgdGhl IHJlY2VpdmVyIHJlZnVzZWQgdG8gcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gaXRzIGVudGlyZXR5 Ii4gIFRoZSBmb3JtZXIgb3B0aW9uIGFsbG93cyBzYXZpbmcgbmV0d29yayBhbmQgc3lzdGVtcyBy ZXNvdXJjZXMgb24gdGhlIHByb3RvY29sIGxldmVsLg0KDQpJbiB0aGUgInBpcGUiIG1vZGVsICh1 bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsKSwgdGhpcyBpcyBhIHF1ZXN0aW9uIG9mIHdo ZXRoZXIgb25seSB0aGUgc2VuZGVyIGlzIGFsbG93ZWQgdG8gY2xvc2UgdGhlIHBpcGUsIG9yIHRo ZSByZWNlaXZlciBpcyBhbHNvIGFsbG93ZWQgdG8gY2xvc2UuDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25A Z21haWwuY29tXSANClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI1LCAyMDE3IDEyOjAzIEFNDQpU bzogUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQpDYzogcXVpY0BpZXRmLm9yZzsgQ2hyaXN0 aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpTdWJqZWN0OiBSZTogU3BsaXQgZXJy b3IgY29kZXMgaW4gdHdvDQoNCk9uIFRodSwgU2VwIDE0LCAyMDE3IGF0IDEyOjQwIEFNLCBMdWJh c2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4gd3JvdGU6DQo+IFRoaW5raW5nIGFib3V0 IHRoaXMgYSBiaXQgbW9yZSwgaXQgc2VlbXMgdGhhdCB0aGUga2V5IGRpZmZlcmVuY2UgDQo+IGJl dHdlZW4g4oCcdGNwIHNvY2tldOKAnSBhbmQg4oCcdHdvIHBpcGUgcGFpcnPigJ0gbW9kZWxzIGlz IGluZGVwZW5kZW5jZSBvZiANCj4gdGhlIHNlbmQgYW5kIHJlY2VpdmUgZGlyZWN0aW9ucy4NCg0K SSBwcmVmZXIgQ2hyaXN0aWFuJ3MgYW5hbG9neSBvZiBzdHJlYW1zIGFzIG1lc3NhZ2VzLiAgVGhh dCdzIHdoYXQgbW90aXZhdGVkIHRoZSBkZXNpZ24gdGhhdCBJIHByb3Bvc2VkLiAgVGhlbiB5b3Ug ZG9uJ3QgZ2V0ICJwaXBlIHBhaXJzIg0KeW91IGdldCAibWVzc2FnZXMgYW5kIChvcHRpb25hbGx5 KSByZXNwb25zZSBtZXNzYWdlcyIuDQoNCk9uIFRodSwgU2VwIDE0LCAyMDE3IGF0IDU6MDMgQU0s IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPiB3cm90ZToNCj4gU28gbWFueSBSUEMgbW9kZWxz IGhhdmUgZmFpbGVkIHV0dGVybHkgYmVjYXVzZSB0aGV5IGNvdWxkbuKAmXQgaGFuZGxlIA0KPiBy ZWNlaXZpbmcgdGhlIGRhdGEgaW4gYSBzdHJlYW1pbmcgZmFzaGlvbi4NCg0KVGhhdCBkb2Vzbid0 IGludmFsaWRhdGUgdGhlIHN0cmVhbXMtYXJlLW1lc3NhZ2VzIG1vZGVsLCBpdCBqdXN0IHJlY29n bml6ZXMgdGhhdCB0aGUgbWVzc2FnZXMgY2Fubm90IGJlIHNlbnQgYW5kIHJlY2VpdmVkIGFzIGEg c2luZ2xlIHVuaXQgKHVubGVzcyB0aGV5IGFyZSAwIGxlbmd0aCwgSSBndWVzcykuICBGbG93IGNv bnRyb2wsIG11bHRpcGxleGluZywgZXRjLCBldGMuLi4NCg0Kfg0KDQpJIHdhbnQgdG8gY29tZSBi YWNrIHRvIHRoZSBvcmlnaW5hbCBxdWVzdGlvbiBpbiBsaWdodCBvZiB3aGF0IHdlIGxlYXJuZWQ6 DQoNCiAtPiB3aGF0IGlzIHRoZSB0cmFuc3BvcnQgZ29pbmcgdG8gKipkbyoqIHdpdGggYSBTVE9Q X1NFTkRJTkc/DQoNCkkgY2FuJ3QgdGhpbmsgb2YgYW55dGhpbmcgb3RoZXIgdGhhbiB0byB0ZWxs IHRoZSBhcHBsaWNhdGlvbi4gIFRoYXQgbWFrZXMgdGhlIGFuc3dlciBwcmV0dHkgY2xlYXIgdG8g bWUuDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGRpc2N1c3Npb24gLSB2YWx1YWJsZSBhcyBp dCBpcyBiZWVuIC0gaGFzIGNoYW5nZWQgbXkgcG9zaXRpb24gb24gdGhpcyBtdWNoLiAgSWRlYWxs eSBJIHdvdWxkIGxpa2UgdG8gZW5hYmxlIGFsbCB0aGUgdmFyaW91cyB2aWV3cG9pbnRzIG9uIHRo ZSBxdWVzdGlvbiB0byBiZSBlcXVhbGx5IHZhbGlkLiAgQnVpbGRpbmcgYSBwcm90b2NvbCB0aGF0 IGNhbiBwcm92aWRlIHNvbWV0aGluZyB0aGF0IGxvb2tzIGxpa2UgYSBUQ1Agc29ja2V0IGlzIGNo YWxsZW5naW5nIHRob3VnaCwgYmVjYXVzZSB0aGUgY29tcGxldGUgY2xvc2Ugb2YgYSBjb3VwbGVk IHBhaXIgY2Fubm90IGJlIGRvbmUgZ2VuZXJpY2FsbHkgLSBJIHRoaW5rIHRoYXQgd2UgYWxsIGFn cmVlIHRoYXQgdGhpcyBpcyBpbXBvc3NpYmxlIGluIHRoZSBnZW5lcmFsIGNhc2UuDQoNCkkgY2Fu IGFwcHJlY2lhdGUgdGhlIGRlc2lyZSB0byBidWlsZCBzb21lIG9mIHRoZSBwaWVjZXMgdGhhdCBt aWdodCBiZSBuZWVkZWQgdG8gYnVpbGQgYSBiaWRpcmVjdGlvbmFsIGNsb3NlLCBidXQgSSB0aGlu ayB0aGF0IGlzIG1vcmUgZGFuZ2Vyb3VzIHRoYW4gdXNlZnVsIGFuZCB3b3VsZCBwcmVmZXIgdG8g bGVhdmUgdGhpcyB0byBhcHBsaWNhdGlvbiBwcm90b2NvbHMuDQoNCg== From nobody Mon Sep 25 16:35:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B44132355 for ; Mon, 25 Sep 2017 16:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 li5NQ7vN-jOU for ; Mon, 25 Sep 2017 16:35:08 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20226134602 for ; Mon, 25 Sep 2017 16:35:08 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id b1so9462684oih.4 for ; Mon, 25 Sep 2017 16:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=80kNhgsNHiV7/fGNN/lWaext/rHjFrYVcqqo+7mis9w=; b=bQ0QPZ49+9EdRF+G5nBkkU5N8yLzSfpOY0bRYb5V79MMhE6cuK2zwkvNO8+/8vO3CO xhAnGSl0eOgtfd/VoaqeGg0IDyZnE8AS+aVWdoV+nCwHsZ2EiUX0h3sdIsVEPKF3FmHv LUXt7MdtzMKgeKgVNDS6hGtBrJWivmaxyf4V5sY2V3VGdVu7qVMEVSel4JkAoIcvshPf YGPiUyW1tC+hTxCYxoYjmqoPbnEAJWHRrJeeSZZQku0gllGn0pRcUtxpuxmwJnmXm+bb 0YPMKqfsl2AqEPUcZGJPkjzlXZthN4AbJdoromsQAOoWCC4Z1Tkk6mjWjIt4LbKvaL6v kdwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=80kNhgsNHiV7/fGNN/lWaext/rHjFrYVcqqo+7mis9w=; b=XsLlw+kXo8AtBs7PiQturZSY2nuK0qoPPb/B1saLrCIT51hhK4ziHK47NiF8n3gWaQ fyYWsb3IHbKzyh0xEcIGZKNVR7Rl3st/ca0GOtXUTSiPl7Kb6/QQRCBnbU4LbUVf3lmU eHFHU8J8JsUT6eXYM7q2tem0o++RU8M859TmbL4UWdxve6+ZqC8W676MVqGkfxATdVkY HvQYAWfVNBR85QXVI2vCyjNj6aQvbyipEsHbDPm0jum3SDa7qsA+/uVfhIJqkn7fGaaa N3hn7IkIk61JKRV7DA8AZPsfwfEuAuHyokdklD3hMtmwg79WcgRonwx4pAkHNEglhZ9e +1LQ== X-Gm-Message-State: AHPjjUhnjdZ3tccB5N9QeanDGmF/3hSEFU6Ko5MQQUHQWF+BIheoIZQe Lo2HXCHxvkrnndLNYsa4ePyMunrddiAqFZOHahI= X-Google-Smtp-Source: AOwi7QAlUquCQ2vV4GjSDPhlRHB9/drChdTs8lz/MYoTdPD0QNYTyRfOjbjFWEB4hoVNyBe14x/YuKAfLmug8s5L9Pg= X-Received: by 10.202.79.68 with SMTP id d65mr11445602oib.246.1506382507439; Mon, 25 Sep 2017 16:35:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Mon, 25 Sep 2017 16:35:06 -0700 (PDT) In-Reply-To: <022d9f140d9b4306a959e0dacac788e7@usma1ex-dag1mb5.msg.corp.akamai.com> References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> <022d9f140d9b4306a959e0dacac788e7@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Tue, 26 Sep 2017 09:35:06 +1000 Message-ID: Subject: Re: Split error codes in two To: "Lubashev, Igor" Cc: Roberto Peon , "quic@ietf.org" , Christian Huitema Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 23:35:10 -0000 We've drifted dangerously close to defining an API. You are suggesting an upcall that says "I've received a WRITE_ABORT on stream X. (optionally: I've stopped sending stream X.) Should I (a) reset, or (b) continue?" Alternatively, you could configure the answer on streams with defaults, or when you start writing. That's a pretty well-defined notion in the abstract, but if we had a transport-layer message, every generic QUIC stack would need to have one or other mechanism. On Tue, Sep 26, 2017 at 9:10 AM, Lubashev, Igor wrote= : > I agree that in many cases, "streams-as-messages" model fits well in the = application use case (not HTTP Stream 1, though). It seems reasonable to s= uppose that an application would occasionally like to send a very large (10= 0MB?) message, and it gives it to the transport in one shot -- maybe using = something like Linux sendfile() API call. > > So now to your question: >> -> what is the transport going to **do** with a STOP_SENDING? > > The answer seems orthogonal to bidirectionality. It would make sense for= the transport to stop sending the message and notify the application that = it did so. The alternative is to continue sending the large file, spending= significant network and CPU resources doing so, and hoping the application= would be prompt at receiving the notification and asking the transport to = cancel the transfer. Both alternatives achieve the same semantics: "an app= is notified that that the receiver refused to receive this message in its = entirety". The former option allows saving network and systems resources o= n the protocol level. > > In the "pipe" model (unidirectional or bidirectional), this is a question= of whether only the sender is allowed to close the pipe, or the receiver i= s also allowed to close. > > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, September 25, 2017 12:03 AM > To: Roberto Peon > Cc: quic@ietf.org; Christian Huitema > Subject: Re: Split error codes in two > > On Thu, Sep 14, 2017 at 12:40 AM, Lubashev, Igor wr= ote: >> Thinking about this a bit more, it seems that the key difference >> between =E2=80=9Ctcp socket=E2=80=9D and =E2=80=9Ctwo pipe pairs=E2=80= =9D models is independence of >> the send and receive directions. > > I prefer Christian's analogy of streams as messages. That's what motivat= ed the design that I proposed. Then you don't get "pipe pairs" > you get "messages and (optionally) response messages". > > On Thu, Sep 14, 2017 at 5:03 AM, Roberto Peon wrote: >> So many RPC models have failed utterly because they couldn=E2=80=99t han= dle >> receiving the data in a streaming fashion. > > That doesn't invalidate the streams-are-messages model, it just recognize= s that the messages cannot be sent and received as a single unit (unless th= ey are 0 length, I guess). Flow control, multiplexing, etc, etc... > > ~ > > I want to come back to the original question in light of what we learned: > > -> what is the transport going to **do** with a STOP_SENDING? > > I can't think of anything other than to tell the application. That makes= the answer pretty clear to me. > > I don't think that this discussion - valuable as it is been - has changed= my position on this much. Ideally I would like to enable all the various = viewpoints on the question to be equally valid. Building a protocol that c= an provide something that looks like a TCP socket is challenging though, be= cause the complete close of a coupled pair cannot be done generically - I t= hink that we all agree that this is impossible in the general case. > > I can appreciate the desire to build some of the pieces that might be nee= ded to build a bidirectional close, but I think that is more dangerous than= useful and would prefer to leave this to application protocols. > From nobody Mon Sep 25 16:44:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B08134602 for ; Mon, 25 Sep 2017 16:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 37N7BECEkc6k for ; Mon, 25 Sep 2017 16:43:58 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0107.outbound.protection.outlook.com [104.47.37.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09F11345FF for ; Mon, 25 Sep 2017 16:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ySjVsRZCaBswn0QnV07Jr3vDOc3+ZoGV4BVOm0mIJJ8=; b=G2hXqLIQs1+06RO17p8F1NTU2xGqpW1K10ZGaYXYUX+K/w1M8979x7S2NcQUpexTRr8sx1Z0z2qVDfqe2AVFez9TMTj5cquxk0xbBfraHUgy0rZNrA5mVQs0Ge3+fRJI6Q8IDlPiKzIIr9ov7qLcpZAYmPbBC8vgsL2J4DF9BUI= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0845.namprd21.prod.outlook.com (10.173.51.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.98.0; Mon, 25 Sep 2017 23:43:55 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0098.003; Mon, 25 Sep 2017 23:43:55 +0000 From: Mike Bishop To: Martin Thomson , "Lubashev, Igor" CC: "quic@ietf.org" , huitema , "Roberto Peon" Subject: RE: Split error codes in two Thread-Topic: Split error codes in two Thread-Index: AQHTJTn9lu8pyhHlCkWTBQfMudDeAKKmFGeAgAASp4CAAAOOAIAA0yCAgAAOnACAAAMMAIAAAK4AgACHAwCAAI1zwIABqLWAgABJmoCAAAS/AIAANHEAgAFsKoCABhnu0IAAb46AgAAJOoCAAOyigIAR4GkAgAFAmICAAAbXAIAAAL3w Date: Mon, 25 Sep 2017 23:43:55 +0000 Message-ID: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> <022d9f140d9b4306a959e0dacac788e7@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [167.220.0.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0845; 6:8YpbYfNJL+pyXMcRLxgSg8VqAv5nozfPWZ9VfEfFqbO8Z1L6cuxW9i3lqEcBmiX7nowUs8JyFeW7Ya+4mV6HWkygwcd0GuDZ8XKktNUL6Ld0fDn/F/i8KcT+oUhE7lWYKclXvsAMzFf+WXRaSe4pRhyuelSiVLlxgsZSDpXIiHINUkgVEATB/zc7QsYkqzZH0jURxwp+jxu33uXqwGVfWN2BQxu06TYLDPfJzZSa/UmUXif9/+IEJOtQ8QPB4577jHUmm3WKApGqX5MjP4eD9qYMjchw/y01uG8s/kGX8nwpYyXJF5Gl0efo1LrN4AKkbN04kU84gQXmv6z4dUEfug==; 5:FSPL5Bd1BAmUXLv+8YuWMW0W3VyHM5grdb7hl/e6eSGGQ24ckBuG3XuEPtfDC3CAVgLhV5yeWJd17m/EuqZtARcA9pYRK+YctjTwwDuR/ckislx/c59dyJA9HdF2mRc7ho4DVVjv9PXrZ9KeQ3hNQg==; 24:oelkRGR5CgTEc9pHLS3Ub2A2ps02IFImR35pK3DgDZ2RXKDlNa/W3g5UQPIbhUp6ZlLpZE0lMbj5WYk0cktvS4Hpq2UOVaBiKtYTgOk0p9o=; 7:5pSmHAKRwpNEuGiIZZCdBVYbokTnqwrroA5q9Lp884cFh++TpkpXwMwi2nXVE4Vy0jBXhzoU9bW79fXxoZ/PEO86qjF5HDMAGK27Jy9/vev1dqWyW4xhFcHvQ3VExwSAuDoaifWtANAzpHoP4GtYEdL9+OCR8l9KadxJ8BnaE36YYom42kvFlYkGeRpspfjAOxwgKNI/dR/18KTBJIX/mfogWoa5wRvgQRO3X/5OTy0= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 57d59d36-9197-4980-66ab-08d5046f4920 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0845; x-ms-traffictypediagnostic: MWHPR21MB0845: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-exchange-antispam-report-test: UriScan:(67672495146484); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0845; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0845; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(47760400005)(51444003)(377454003)(189002)(199003)(24454002)(13464003)(68736007)(6116002)(33656002)(229853002)(110136005)(77096006)(72206003)(8990500004)(6506006)(86612001)(86362001)(6436002)(97736004)(316002)(102836003)(66066001)(14454004)(3846002)(10090500001)(3280700002)(3660700001)(9686003)(53546010)(2900100001)(2906002)(76176999)(50986999)(54356999)(7736002)(74316002)(53936002)(305945005)(54906003)(55016002)(81166006)(99286003)(81156014)(101416001)(6246003)(105586002)(8676002)(39060400002)(22452003)(106356001)(7696004)(189998001)(5660300001)(4326008)(8936002)(2950100002)(10290500003)(478600001)(25786009)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0845; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 23:43:55.5659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0845 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 23:44:01 -0000 WWVzLCB3ZSBoYXZlIC0tIHdoaWNoIGlzIHdoeSBJIHN1Z2dlc3RlZCB3ZSBnbyBhaGVhZCBhbmQg ZGVmaW5lIG9uZSwgYWxiZWl0IHBlcmhhcHMganVzdCBhIHJlZmVyZW5jZSBBUEkuICBJJ20gbm90 IGNvbnZpbmNlZCBhbiB1cGNhbGwgaXMgbmVjZXNzYXJ5IC0tIHN3YWxsb3dpbmcgdW5zZW50IGRh dGEgYW5kIG5vdGlmeWluZyB0aGUgYXBwIGlmIGl0IGF0dGVtcHRzIHRvIHNlbmQgbW9yZSBpcyBw cm9iYWJseSBzdWZmaWNpZW50LiAgQnV0IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSB0d28g KndvdWxkKiBiZSBhbiBBUEkgZGVzaWduIGRlY2lzaW9uLg0KDQpBbmQgSSB3b3VsZCBhcmd1ZSB0 aGF0IGlmIGEgZ2VuZXJpYyBRVUlDIHN0YWNrIG5lZWRzIHRvIGhhdmUgYSBtZWNoYW5pc20gdG8g dHJhbnNmZXIgbXVsdGktZ2lnYWJ5dGUgbWVzc2FnZXMsIGl0IGFsc28gbmVlZHMgdG8gaGF2ZSBh IHdheSB0byBmb3Jlc3RhbGwgcmVhZGluZyB0aGUgZW50aXJldHkgb2YgdGhvc2UgbWVzc2FnZXMu ICAoQWx0aG91Z2ggd2UgYWxyZWFkeSBkbyBoYXZlIHRoZSBhYmlsaXR5IHRvIGNob2tlIG9mZiBm bG93IGNvbnRyb2wgdW50aWwgdGhlIGFwcGxpY2F0aW9uIHJlYWxpemVzIGl0J3Mgc3VwcG9zZWQg dG8gUlNUX1NUUkVBTSwgSSBzdXBwb3NlLikNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN YXJ0aW4gVGhvbXNvbg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTcgNDozNSBQTQ0K VG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPg0KQ2M6IHF1aWNAaWV0Zi5v cmc7IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBSb2JlcnRvIFBlb24gPGZlbml4QGZi LmNvbT4NClN1YmplY3Q6IFJlOiBTcGxpdCBlcnJvciBjb2RlcyBpbiB0d28NCg0KV2UndmUgZHJp ZnRlZCBkYW5nZXJvdXNseSBjbG9zZSB0byBkZWZpbmluZyBhbiBBUEkuDQoNCllvdSBhcmUgc3Vn Z2VzdGluZyBhbiB1cGNhbGwgdGhhdCBzYXlzICJJJ3ZlIHJlY2VpdmVkIGEgV1JJVEVfQUJPUlQg b24gc3RyZWFtIFguICAob3B0aW9uYWxseTogSSd2ZSBzdG9wcGVkIHNlbmRpbmcgc3RyZWFtIFgu KSAgU2hvdWxkIEkgKGEpIHJlc2V0LCBvciAoYikgY29udGludWU/Ig0KDQpBbHRlcm5hdGl2ZWx5 LCB5b3UgY291bGQgY29uZmlndXJlIHRoZSBhbnN3ZXIgb24gc3RyZWFtcyB3aXRoIGRlZmF1bHRz LCBvciB3aGVuIHlvdSBzdGFydCB3cml0aW5nLg0KDQpUaGF0J3MgYSBwcmV0dHkgd2VsbC1kZWZp bmVkIG5vdGlvbiBpbiB0aGUgYWJzdHJhY3QsIGJ1dCBpZiB3ZSBoYWQgYSB0cmFuc3BvcnQtbGF5 ZXIgbWVzc2FnZSwgZXZlcnkgZ2VuZXJpYyBRVUlDIHN0YWNrIHdvdWxkIG5lZWQgdG8gaGF2ZSBv bmUgb3Igb3RoZXIgbWVjaGFuaXNtLg0KDQpPbiBUdWUsIFNlcCAyNiwgMjAxNyBhdCA5OjEwIEFN LCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4gd3JvdGU6DQo+IEkgYWdyZWUg dGhhdCBpbiBtYW55IGNhc2VzLCAic3RyZWFtcy1hcy1tZXNzYWdlcyIgbW9kZWwgZml0cyB3ZWxs IGluIHRoZSBhcHBsaWNhdGlvbiB1c2UgY2FzZSAobm90IEhUVFAgU3RyZWFtIDEsIHRob3VnaCku ICBJdCBzZWVtcyByZWFzb25hYmxlIHRvIHN1cHBvc2UgdGhhdCBhbiBhcHBsaWNhdGlvbiB3b3Vs ZCBvY2Nhc2lvbmFsbHkgbGlrZSB0byBzZW5kIGEgdmVyeSBsYXJnZSAoMTAwTUI/KSBtZXNzYWdl LCBhbmQgaXQgZ2l2ZXMgaXQgdG8gdGhlIHRyYW5zcG9ydCBpbiBvbmUgc2hvdCAtLSBtYXliZSB1 c2luZyBzb21ldGhpbmcgbGlrZSBMaW51eCBzZW5kZmlsZSgpIEFQSSBjYWxsLg0KPg0KPiBTbyBu b3cgdG8geW91ciBxdWVzdGlvbjoNCj4+ICAgLT4gd2hhdCBpcyB0aGUgdHJhbnNwb3J0IGdvaW5n IHRvICoqZG8qKiB3aXRoIGEgU1RPUF9TRU5ESU5HPw0KPg0KPiBUaGUgYW5zd2VyIHNlZW1zIG9y dGhvZ29uYWwgdG8gYmlkaXJlY3Rpb25hbGl0eS4gIEl0IHdvdWxkIG1ha2Ugc2Vuc2UgZm9yIHRo ZSB0cmFuc3BvcnQgdG8gc3RvcCBzZW5kaW5nIHRoZSBtZXNzYWdlIGFuZCBub3RpZnkgdGhlIGFw cGxpY2F0aW9uIHRoYXQgaXQgZGlkIHNvLiAgVGhlIGFsdGVybmF0aXZlIGlzIHRvIGNvbnRpbnVl IHNlbmRpbmcgdGhlIGxhcmdlIGZpbGUsIHNwZW5kaW5nIHNpZ25pZmljYW50IG5ldHdvcmsgYW5k IENQVSByZXNvdXJjZXMgZG9pbmcgc28sIGFuZCBob3BpbmcgdGhlIGFwcGxpY2F0aW9uIHdvdWxk IGJlIHByb21wdCBhdCByZWNlaXZpbmcgdGhlIG5vdGlmaWNhdGlvbiBhbmQgYXNraW5nIHRoZSB0 cmFuc3BvcnQgdG8gY2FuY2VsIHRoZSB0cmFuc2Zlci4gIEJvdGggYWx0ZXJuYXRpdmVzIGFjaGll dmUgdGhlIHNhbWUgc2VtYW50aWNzOiAiYW4gYXBwIGlzIG5vdGlmaWVkIHRoYXQgdGhhdCB0aGUg cmVjZWl2ZXIgcmVmdXNlZCB0byByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBpdHMgZW50aXJldHki LiAgVGhlIGZvcm1lciBvcHRpb24gYWxsb3dzIHNhdmluZyBuZXR3b3JrIGFuZCBzeXN0ZW1zIHJl c291cmNlcyBvbiB0aGUgcHJvdG9jb2wgbGV2ZWwuDQo+DQo+IEluIHRoZSAicGlwZSIgbW9kZWwg KHVuaWRpcmVjdGlvbmFsIG9yIGJpZGlyZWN0aW9uYWwpLCB0aGlzIGlzIGEgcXVlc3Rpb24gb2Yg d2hldGhlciBvbmx5IHRoZSBzZW5kZXIgaXMgYWxsb3dlZCB0byBjbG9zZSB0aGUgcGlwZSwgb3Ig dGhlIHJlY2VpdmVyIGlzIGFsc28gYWxsb3dlZCB0byBjbG9zZS4NCj4NCj4NCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI1LCAyMDE3IDEy OjAzIEFNDQo+IFRvOiBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4NCj4gQ2M6IHF1aWNAaWV0 Zi5vcmc7IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KPiBTdWJqZWN0 OiBSZTogU3BsaXQgZXJyb3IgY29kZXMgaW4gdHdvDQo+DQo+IE9uIFRodSwgU2VwIDE0LCAyMDE3 IGF0IDEyOjQwIEFNLCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4gd3JvdGU6 DQo+PiBUaGlua2luZyBhYm91dCB0aGlzIGEgYml0IG1vcmUsIGl0IHNlZW1zIHRoYXQgdGhlIGtl eSBkaWZmZXJlbmNlIA0KPj4gYmV0d2VlbiDigJx0Y3Agc29ja2V04oCdIGFuZCDigJx0d28gcGlw ZSBwYWlyc+KAnSBtb2RlbHMgaXMgaW5kZXBlbmRlbmNlIG9mIA0KPj4gdGhlIHNlbmQgYW5kIHJl Y2VpdmUgZGlyZWN0aW9ucy4NCj4NCj4gSSBwcmVmZXIgQ2hyaXN0aWFuJ3MgYW5hbG9neSBvZiBz dHJlYW1zIGFzIG1lc3NhZ2VzLiAgVGhhdCdzIHdoYXQgbW90aXZhdGVkIHRoZSBkZXNpZ24gdGhh dCBJIHByb3Bvc2VkLiAgVGhlbiB5b3UgZG9uJ3QgZ2V0ICJwaXBlIHBhaXJzIg0KPiB5b3UgZ2V0 ICJtZXNzYWdlcyBhbmQgKG9wdGlvbmFsbHkpIHJlc3BvbnNlIG1lc3NhZ2VzIi4NCj4NCj4gT24g VGh1LCBTZXAgMTQsIDIwMTcgYXQgNTowMyBBTSwgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+ IHdyb3RlOg0KPj4gU28gbWFueSBSUEMgbW9kZWxzIGhhdmUgZmFpbGVkIHV0dGVybHkgYmVjYXVz ZSB0aGV5IGNvdWxkbuKAmXQgaGFuZGxlIA0KPj4gcmVjZWl2aW5nIHRoZSBkYXRhIGluIGEgc3Ry ZWFtaW5nIGZhc2hpb24uDQo+DQo+IFRoYXQgZG9lc24ndCBpbnZhbGlkYXRlIHRoZSBzdHJlYW1z LWFyZS1tZXNzYWdlcyBtb2RlbCwgaXQganVzdCByZWNvZ25pemVzIHRoYXQgdGhlIG1lc3NhZ2Vz IGNhbm5vdCBiZSBzZW50IGFuZCByZWNlaXZlZCBhcyBhIHNpbmdsZSB1bml0ICh1bmxlc3MgdGhl eSBhcmUgMCBsZW5ndGgsIEkgZ3Vlc3MpLiAgRmxvdyBjb250cm9sLCBtdWx0aXBsZXhpbmcsIGV0 YywgZXRjLi4uDQo+DQo+IH4NCj4NCj4gSSB3YW50IHRvIGNvbWUgYmFjayB0byB0aGUgb3JpZ2lu YWwgcXVlc3Rpb24gaW4gbGlnaHQgb2Ygd2hhdCB3ZSBsZWFybmVkOg0KPg0KPiAgLT4gd2hhdCBp cyB0aGUgdHJhbnNwb3J0IGdvaW5nIHRvICoqZG8qKiB3aXRoIGEgU1RPUF9TRU5ESU5HPw0KPg0K PiBJIGNhbid0IHRoaW5rIG9mIGFueXRoaW5nIG90aGVyIHRoYW4gdG8gdGVsbCB0aGUgYXBwbGlj YXRpb24uICBUaGF0IG1ha2VzIHRoZSBhbnN3ZXIgcHJldHR5IGNsZWFyIHRvIG1lLg0KPg0KPiBJ IGRvbid0IHRoaW5rIHRoYXQgdGhpcyBkaXNjdXNzaW9uIC0gdmFsdWFibGUgYXMgaXQgaXMgYmVl biAtIGhhcyBjaGFuZ2VkIG15IHBvc2l0aW9uIG9uIHRoaXMgbXVjaC4gIElkZWFsbHkgSSB3b3Vs ZCBsaWtlIHRvIGVuYWJsZSBhbGwgdGhlIHZhcmlvdXMgdmlld3BvaW50cyBvbiB0aGUgcXVlc3Rp b24gdG8gYmUgZXF1YWxseSB2YWxpZC4gIEJ1aWxkaW5nIGEgcHJvdG9jb2wgdGhhdCBjYW4gcHJv dmlkZSBzb21ldGhpbmcgdGhhdCBsb29rcyBsaWtlIGEgVENQIHNvY2tldCBpcyBjaGFsbGVuZ2lu ZyB0aG91Z2gsIGJlY2F1c2UgdGhlIGNvbXBsZXRlIGNsb3NlIG9mIGEgY291cGxlZCBwYWlyIGNh bm5vdCBiZSBkb25lIGdlbmVyaWNhbGx5IC0gSSB0aGluayB0aGF0IHdlIGFsbCBhZ3JlZSB0aGF0 IHRoaXMgaXMgaW1wb3NzaWJsZSBpbiB0aGUgZ2VuZXJhbCBjYXNlLg0KPg0KPiBJIGNhbiBhcHBy ZWNpYXRlIHRoZSBkZXNpcmUgdG8gYnVpbGQgc29tZSBvZiB0aGUgcGllY2VzIHRoYXQgbWlnaHQg YmUgbmVlZGVkIHRvIGJ1aWxkIGEgYmlkaXJlY3Rpb25hbCBjbG9zZSwgYnV0IEkgdGhpbmsgdGhh dCBpcyBtb3JlIGRhbmdlcm91cyB0aGFuIHVzZWZ1bCBhbmQgd291bGQgcHJlZmVyIHRvIGxlYXZl IHRoaXMgdG8gYXBwbGljYXRpb24gcHJvdG9jb2xzLg0KPg0KDQo= From nobody Mon Sep 25 16:53:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC710134607 for ; Mon, 25 Sep 2017 16:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZMeFRjUhF-BG for ; Mon, 25 Sep 2017 16:53:51 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8380E1323B4 for ; Mon, 25 Sep 2017 16:53:51 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id x85so9509386oix.12 for ; Mon, 25 Sep 2017 16:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=houyMgeGkpYvKlrgHpYRGvY1Dbo1eQW5kUdn2j5zIac=; b=fvbpxVEUTubrg4xT4Zi7Wv0yW7MvN8AjXs/k9fObMLbobz2+DBQConezT+PFB04csf T3A7R1c9Ls2rii4WzT5uP5xJCGurdyZZJ1TN+0qmjTKYIqLuUKopyMwH3KORnahZoqgj rJwkFKM2GtvLzVL5IUd0zF+j7Ve5ECPZZnTuiIK+Qz6DgVllUHWq21i8hiWCXaz/tydY XQH6utAtpzkX7FskAo+cKv2QIcAu0+c+UOphIUp5B5huoBzUuZfq02+R0Ni3qKBPWZAB LkbMS5xkfFcswNxIyJ3Pv/GgAypjVvjbLoJ9rZTU+aNcuKojnGZzOC/pEm6xFlx22TNM 6qPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=houyMgeGkpYvKlrgHpYRGvY1Dbo1eQW5kUdn2j5zIac=; b=FFmI1UUWUCAqOQ5KbDgow8kzobAE+VdjniiKanufb0/sEtnkFFHIBzXVUJLx+hihxj ILmk12ewOp+8OYJOfMG9RA4u7tUg7H1aAWlJFEIHPQjUuTZUtd1jTBFvRwV74aFSCcPy AfV7WWsNI+KPOvMZ5BhAlIIzfJVmSK05kGYPoOxgH60Bnlm3wW5Gc3yjkV6QHaM/PS0/ DJ8uZXvFq9fQRs3KP34Ih+mS8fwS8koPchtr30bL4aDY0yrpYZrzQLwL3Gujsii7NuLt GeYqBegIbyhNp+XUhomComLRcx9Yb0hBZA4nr14x34AVs/hsj4cOC6sCwg5BQ/X1EHKs 7CCQ== X-Gm-Message-State: AHPjjUjG66kEJZIBb0zYBxyLlAaqE1dgCAA9BEeR/TMqBEr4kAeoZtXB vnCCksiZ5Ho49k73hPxzWW7HBXnmOkGAi6tLQlhRgQ== X-Google-Smtp-Source: AOwi7QDsD+rtXHr3wiLRreTpZ0bgrAvwuG/QG3s8JcyhDIzCxbdtotXDXVdZlHnlw1KQ/aPTxKneydnbYlVKD1CiNms= X-Received: by 10.202.79.68 with SMTP id d65mr11481946oib.246.1506383630873; Mon, 25 Sep 2017 16:53:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Mon, 25 Sep 2017 16:53:50 -0700 (PDT) In-Reply-To: References: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de> <022d9f140d9b4306a959e0dacac788e7@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Tue, 26 Sep 2017 09:53:50 +1000 Message-ID: Subject: Re: Split error codes in two To: Mike Bishop Cc: "Lubashev, Igor" , "quic@ietf.org" , huitema , Roberto Peon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 23:53:53 -0000 I think that you just managed to change my mind... On Tue, Sep 26, 2017 at 9:43 AM, Mike Bishop wrote: > Yes, we have -- which is why I suggested we go ahead and define one, albe= it perhaps just a reference API. I'm not convinced an upcall is necessary = -- swallowing unsent data and notifying the app if it attempts to send more= is probably sufficient. But the distinction between the two *would* be an= API design decision. Actually, that would be a protocol decision. STOP_SENDING could cause a state transition and cause the stream to become reset, but it creates some nasty side effects. > And I would argue that if a generic QUIC stack needs to have a mechanism = to transfer multi-gigabyte messages, it also needs to have a way to foresta= ll reading the entirety of those messages. (Although we already do have th= e ability to choke off flow control until the application realizes it's sup= posed to RST_STREAM, I suppose.) This is the point that I think is convincing. Ignoring what we might ask an application layer to do (or not), operating purely at the transport layer, if the reader closes, then it won't send flow control credits. That is, it could (and direct the pipe to /dev/null), but I don't think that we've provided the right incentives. Redirecting to /dev/null is costly for both sides, so I see little reason for them to do that. The result is therefore most likely a deadlock. That's the clincher for me. If the transport at the reader doesn't read, then the writer can't write and we end up with streams that are deadlocked until the application resolves it. I don't mind if the application wants to insert itself (the upcall suggestion), but I think that a transport-layer function forces the transport to recognize this problem and deal with it. From nobody Mon Sep 25 17:32:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F3213461A for ; Mon, 25 Sep 2017 17:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZGcmFgEY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OaRy8vSX 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 QAmD6O2E_FSC for ; Mon, 25 Sep 2017 17:32:23 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8650F1321DC for ; Mon, 25 Sep 2017 17:32:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9EB5522131; Mon, 25 Sep 2017 20:32:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 25 Sep 2017 20:32:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=4ZyuaVGlyqX37IVkg/F1iIFIdF+FVz0BYaW9KlVfw bQ=; b=ZGcmFgEYVbWf92YiP8iyw584TNtUP6wZnKRTuFAinbRcZrN+Sm/zBfGIb 5T4q1Kxew2CQjcJn2pGJdkvvymYLB0izI3Q9Q8z0PlAgMOnoDlBxTE7d+ItFzXZ0 gyh95/4VSZuS4hFjFVjKh7maZZNP1KceKahXxZ5q18A8zBErc3ReJsuPANLJfbS1 jnSSsFXc0ulRdMrbGOjBcpPwjfpry3uz9t299kzsr2emoiyAv3Kh91YOD5eR+17Q m3I6vlbFf4LVYGRPDcbCG2OhOVIxmVonB06Z3LCfI6X0d4Z+muWb9fwArULqfun6 zZSU6NxqbeuSrC99b3EocDaRe+1Sg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=4ZyuaVGlyqX37IVkg/ F1iIFIdF+FVz0BYaW9KlVfwbQ=; b=OaRy8vSXaS34CG6A5RpLX0voA5HquROP5A CGTRoFXehqVMt9TCoUb9/4S3y/xx7f0KiELnMC4Wlmg2SNjospDBYzTmWzmC7TYn 2NSUs/63VxmpVLvIAR/EQs9GZ7QpaViH5RL5HGhUCUznyyHfmFog8kLdbPeNYMIi WaEO84xo365T9TsEAsDqi6yD+HEtdYamqj6cOGHLeLJYTST96VwhPKsOtYWTVQjD Hn9ciIYU+DdrJL5rqgVeN+rqFv+eLaCR6mTpCX74O43F95VXisJWTyhYpLP8lpFF jmR4xuN0dtlb6XEAPvJH9v6U1XxFbP95UGv2I+viCrfnymflWCdQ== X-ME-Sender: X-Sasl-enc: vehIfGP48APUbbjXDn9jQtoV25NQwyk5PX8b9CSw8UBG 1506385942 Received: from [192.168.1.25] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 9C2C57E446; Mon, 25 Sep 2017 20:32:21 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Consensus Call on issues closed by the -06 drafts Message-Id: <1023AAAC-5195-4A26-A909-D01041A0C9B5@mnot.net> Date: Tue, 26 Sep 2017 10:32:21 +1000 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 00:32:29 -0000 Everyone, The -06 drafts incorporate the proposed resolutions to another group of = issues, as listed below. Please have a look through them. If there are any resolutions that you = feel need more discussion, please bring it up, either here on the = mailing list or by commenting on the issue itself. In either case, = please explicitly ask for the issue to be re-opened if you want it to be = reconsidered. If folks do this before the Seattle interim, we can hopefully have any = necessary discussions before or during the meeting. See = for a reminder about the process we're using here. Even when = we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms). This list is also available at = . * #748: Introduce draining period for connection termination = (transport) * #733: Acknowledging *_CLOSE (transport) * #729: Keep alive advice (transport http) * #709: Make Push ID sequential (http) * #702: Concurrent server pushes for the same resource (http) * #700: Can a DATA frame be empty? (http) * #696: Move GOAWAY to HTTP draft (transport http) * #690: Do we need endofearlydata? (tls) * #684: Simplify Client Initial size (transport) * #637: Suggest linking CCID to SCID (transport) * #635: Ack frame has two framings that specify a single range = (transport) * #628: Move stream close forward (transport) * #622: Proxy context (transport) * #620: Move stream IDs to the front of frames (transport) * #606: Transport: Client IP change reason (transport) * #601: Transmitting ACK frames (recovery) * #599: Public Resets should be triggered by only QUIC packets = (transport) * #596: Guard initial packet against amplification attack via = compression (transport) * #588: Server chosen connection ID design (transport) * #572: Should we transition to Open state when recv even = MAX_STREAM_DATA or RST on idle (transport) * #564: loosen MUST requirement around close-on-ack-of-unsent = (transport) * #563: ACK prohibitions (transport) * #557: PUSH_PROMISE ordering guarantee (http) * #554: Reconsider the use of FNV-1a for "cleartext" integrity = (transport) * #547: Version fields in transport parameters for NewSessionTicket = (transport) * #546: What to do if a skipped packet is acknowledged (transport = recovery) * #545: Add congestion control (recovery) * #544: Incorporate F-RTO (recovery) * #509: Proof of receipt of packets in ACK (transport) * #508: Stream ID encoding (transport) * #489: Propose SLOT Frame (transport) * #477: Use positive phrasing instead of double negative (http) * #436: Move SETTINGS into TLS Handshake (http) * #433: Propose compressed zero stream frames or TRIM frames (and = partially reliable streams) (transport) * #426: QUIC header format/demultiplexing (transport) * #383: Maximum packet size (transport) * #353: Replace CONNECTION_CLOSE with Public Reset (transport) * #330: CONNECTION_CLOSE semantics (transport) * #328: TIME_WAIT (transport) * #281: Promising more than the client concurrency limit (transport = http) * #245: Single stream for headers and body (http) * #215: Public reset (transport) * #177: CONNECTION_CLOSE reliability (transport recovery) * #165: Resetting Streams (transport http) * #126: Separate transport parameters for 0-RTT (transport) * #121: Version downgrade vulnerability (transport tls) * #68: Explicit Congestion Notification (ECN) (transport recovery) * #51: QUIC version number scheme (transport) -- Mark Nottingham https://www.mnot.net/ From nobody Tue Sep 26 00:24:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9BE132D41 for ; Tue, 26 Sep 2017 00:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ATDyGqd1slvA for ; Tue, 26 Sep 2017 00:24:05 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1201132620 for ; Tue, 26 Sep 2017 00:24:05 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 4so1830618itv.4 for ; Tue, 26 Sep 2017 00:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=XMvugXTLk37jun7a1dNzQKyCdFk6vCUDRj7BmfyMmgg=; b=CO3kjsykO+N0B5boZxmVHeDP3OUr7PP10AcJW78FoUlyq7Ztzr4/gwFdp59OuULwGH AiRNeDfCqZhPKYEENYssSnGwoaaiKeoyRfr0541j7zVQLoPS/WYlweqIldWjEZC8GVTo bkRIiMrRp1oFvrAMSoppghiGpjabqzdPi6VSNNG6/yEoncS4zS2oQnapvFmAAgVq5cgB qHbMN+B70DyXmzp+A+XkL+bFcUWk7I8XqGMprKUXzc6R/RWhpobbXqpBWf8xBeS4H4qo KQoXNQdaUzHPnMZAR3PyCQ/sflorG5Lhl+tg99pxhGMvq7A4QtC9gCzviSKP68J9EoV3 cNuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=XMvugXTLk37jun7a1dNzQKyCdFk6vCUDRj7BmfyMmgg=; b=lvhS0rpKHbWezIJ3i5HDttmETJvyY1zoYwbn/8JEVN+T4Hl/DoQOYBX7uiZ+n6oEVd XTRZJC9tlcKvWlEoTw7+D2c5ewDuKpUsuX1hCpxS+X4xM51+FdZsgINNKJt4hFcvep7k Gbmu4Cnf/5hH4Pn3po2ue74JjzUmoxMWchaEuKHt7sMl1BccR6tnA52l0XpFDFVxiWN1 1JiBbSgnirUf8H+GGrovFbkWsMcCWsnJNW9s7/R5KKuDUh9wPx02vEFD0JwOVf8zbNcF sdA4dj8lrjcAiVRoo1GaMcAjMIA52bD88/t9+XgtEcoqew5Gk2E0zzln5/DZvpwX450D lvIQ== X-Gm-Message-State: AHPjjUhfGDuakAfa/Cx/HPRlgxEmI4lrKQ3+Km2+uy2t0542XF9SIdcw fqTxictoaF3Zt34AhP8hHYlsqBA8Ay21okck0IgwpA== X-Google-Smtp-Source: AOwi7QD4oMAl4y7Oe3Tmr43ZboyWq1LNLKH8BFkC+7U62k78/33v6flWyEWEiLoG9g3Fnd2OkD5fF5xkF0pyaM2qCEs= X-Received: by 10.36.92.133 with SMTP id q127mr4256791itb.31.1506410644844; Tue, 26 Sep 2017 00:24:04 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 26 Sep 2017 00:24:03 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1023AAAC-5195-4A26-A909-D01041A0C9B5@mnot.net> References: <1023AAAC-5195-4A26-A909-D01041A0C9B5@mnot.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 26 Sep 2017 00:24:03 -0700 Message-ID: Subject: Re: Consensus Call on issues closed by the -06 drafts To: QUIC WG , Mark Nottingham Cc: Lars Eggert Content-Type: multipart/alternative; boundary="001a114456125f35f9055a128fcf" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:24:08 -0000 --001a114456125f35f9055a128fcf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t agree with closing #637 https://github.com/quicwg/base-drafts/issues/637, but a new issue https://github.com/quicwg/base-drafts/issues/714 has been raised which largely covers the same issue, and it appears there are discussing on keeping client ID in error message responses, though I don=E2=80=99t have an overview on that. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 26 September 2017 at 02.32.33, Mark Nottingham (mnot@mnot.net) wrote: 637 --001a114456125f35f9055a128fcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I don=E2=80=99t agree with closing #637=C2=A0https://github.com= /quicwg/base-drafts/issues/637, but a new issue=C2=A0
has = been raised which largely covers the same issue, and it appears there are d= iscussing on keeping client ID in error message responses, though I don=E2= =80=99t have an overview on that.



Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 26 September 2017 at 02.32.33, Mark Nottingham (mnot@mnot.net) wrote:

637
--001a114456125f35f9055a128fcf-- From nobody Tue Sep 26 08:45:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330EC134285 for ; Tue, 26 Sep 2017 08:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 k4FmTFD0sozY for ; Tue, 26 Sep 2017 08:45:49 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0131.outbound.protection.outlook.com [104.47.38.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2EC128D0D for ; Tue, 26 Sep 2017 08:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cbXNFlvnJnPPfZ8CCxVwsqlLdNbZMjp7JVEqcM5s0/s=; b=VJMx7ZnBFNFqZap9gzfVjwJqI4rvC1URYN7uEJdJ1Fy5VkapO/p2CJ+b82Gv9cBfC3NqPcjg1IjolgJqFxuAf87NLIH6ksIpQT9+M6QooS3zbC2ZN6N9vNZtHT8WmlaoynuiLftVQ1U8dRNDFWE/9CZKZ7sE4gLk7/0nZoexafY= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0781.namprd21.prod.outlook.com (10.173.51.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.98.0; Tue, 26 Sep 2017 15:45:46 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0098.003; Tue, 26 Sep 2017 15:45:47 +0000 From: Mike Bishop To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , QUIC WG , Mark Nottingham CC: Lars Eggert Subject: RE: Consensus Call on issues closed by the -06 drafts Thread-Topic: Consensus Call on issues closed by the -06 drafts Thread-Index: AQHTNl79poIBpCEotE+rQzVQVVWDg6LGxB2AgACLnOA= Date: Tue, 26 Sep 2017 15:45:46 +0000 Message-ID: References: <1023AAAC-5195-4A26-A909-D01041A0C9B5@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::114] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0781; 6:FynRVkTS88bknkbbyvfICKocGYKH/jUy1xB8C3phSKTkD8XzUEf5+mWF3W7WWuaG9nnpDtOrZttZaQH5lAwpDiu5NovlhyT8n+bJG3yOXtrrgilNEndYJrRfIpST1ttfTbekZ/luiD94/LmVUJbX8vWBBnXSf8N4TWVDGo9QGfwuAmcNZvH0qmxZVGGmfxjVC0Ek43TfIlS76smgjQnu4jF2s8EBBcUZF6D1cYIv8aBfxeXUgvi+vV9xRCrgYLHB8ipYyVt0WatuyRyiwieeF1T29yBj/6wkf4DSRnO4SUDKqCJYp/Ii0viDxu2h7Mx6BDcK9Vcqez68BYaqpHLw6A==; 5:UZPLeB7M0OWlvj/E3kTpwwQOpNOWfR2jyXrkzef6pbsz+sQmPrQ3Y/tPz8u8bKehtsg8C+CmFgp0K5lH2H2B0y0WNtL/d0wd11b2xxdl6TfTJMlW7vElTiZbZUWAX18vIFBMEj81U2bmpcD9BAOu2w==; 24:qnaGM2Hg+yi2p75Gmzw6qTqSdYLsBUN3hOzD0RyEsFPI7UBp/UkGg6JsVlaPckGv0iGiO+21FFaYzVAs+tghI41oN3UaZVxLpT/nDcYmSfw=; 7:2AxYIA+bit0+Y11EcbpD53c4n/g0gGHZfJxguYrPZe4E6yUig0ZMqeGZTf/dnKXeFSSgBs9rVi5jKBaY29YMjB8MvfJAeTcRadvNV8mMs8d0YzSPHrGUetco1MXT6eb+6zdJ+2Wz1AGFx17qnNJQUR4qTYsXBQ3bIVDhC59IzqXwfT2eOpqAvr+0nP7nL5WzjyqZEU8j/PLjRsZ40bQeHMbk9nguXnjnJfXiGk0kZY4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: df62b5b6-0166-4da0-c33e-08d504f5a7b6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0781; x-ms-traffictypediagnostic: MWHPR21MB0781: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(166708455590820)(189930954265078)(100405760836317)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0781; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0781; x-forefront-prvs: 0442E569BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(47760400005)(24454002)(31014005)(199003)(189002)(377454003)(9686003)(81166006)(5660300001)(86612001)(8676002)(55016002)(25786009)(4326008)(6306002)(53936002)(6246003)(10090500001)(54896002)(97736004)(229853002)(86362001)(39060400002)(8936002)(101416001)(33656002)(72206003)(105586002)(7736002)(966005)(2950100002)(54356999)(76176999)(99286003)(10290500003)(77096006)(236005)(81156014)(6506006)(478600001)(74316002)(50986999)(53546010)(106356001)(6436002)(7696004)(2900100001)(2906002)(189998001)(606006)(102836003)(68736007)(790700001)(6116002)(3280700002)(8990500004)(3660700001)(22452003)(110136005)(14454004)(316002)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0781; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01414A7DF3C98F42DE3236C8877B0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2017 15:45:46.8033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0781 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 15:45:52 -0000 --_000_MWHPR21MB01414A7DF3C98F42DE3236C8877B0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzYzNyB3YXMgY2xvc2VkLCBub3QgYmVjYXVzZSBpdCB3YXMgcmVzb2x2ZWQgaW4tZHJhZnQsIGJ1 dCBiZWNhdXNlIGl0IGFkdm9jYXRlZCBhIHBhcnRpY3VsYXIgc29sdXRpb24gdG8gYSBwcm9ibGVt IHJhdGhlciB0aGFuIHJlZmxlY3RpbmcgYSBwcm9ibGVtIGJ5IGl0c2VsZi4gIFBlcmhhcHMgd2Ug c2hvdWxkIG1hcmsgaXQgd2l0aCBhIGRpZmZlcmVudCB0YWcgdGhhbiBoYXMtY29uc2Vuc3VzLCBi dXQgSSBiZWxpZXZlIGl0cyBKdW5lIGNsb3N1cmUgaXMgc3RpbGwgY29ycmVjdC4NCg0KRnJvbTog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2tlbCBG YWhuw7hlIErDuHJnZW5zZW4NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxNyAxMjoy NCBBTQ0KVG86IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RA bW5vdC5uZXQ+DQpDYzogTGFycyBFZ2dlcnQgPGxhcnNAbmV0YXBwLmNvbT4NClN1YmplY3Q6IFJl OiBDb25zZW5zdXMgQ2FsbCBvbiBpc3N1ZXMgY2xvc2VkIGJ5IHRoZSAtMDYgZHJhZnRzDQoNCkkg ZG9u4oCZdCBhZ3JlZSB3aXRoIGNsb3NpbmcgIzYzNyBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dn L2Jhc2UtZHJhZnRzL2lzc3Vlcy82Mzc8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGcXVpY3dnJTJGYmFz ZS1kcmFmdHMlMkZpc3N1ZXMlMkY2MzcmZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBt aWNyb3NvZnQuY29tJTdDOTczNGRiNzMzMjhhNDkwMDJjYWUwOGQ1MDRhZjk2NTIlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDIwMDc0NTUwMDk1OTA0JnNk YXRhPWJqcDQ0MEZjVzdMaFdaR29aVjY4T0tGa0FGUHl4Y2U4QW1INDJSbjFoVTQlM0QmcmVzZXJ2 ZWQ9MD4sIGJ1dCBhIG5ldyBpc3N1ZQ0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRy YWZ0cy9pc3N1ZXMvNzE0PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRz JTJGaXNzdWVzJTJGNzE0JmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0 LmNvbSU3Qzk3MzRkYjczMzI4YTQ5MDAyY2FlMDhkNTA0YWY5NjUyJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQyMDA3NDU1MDA5NTkwNCZzZGF0YT1iYnUl MkJYSmU0UFJEVGVobEFBR2lWJTJCUXVwNjdpJTJGQXluRTJiRjFQMlJ1bVprJTNEJnJlc2VydmVk PTA+DQpoYXMgYmVlbiByYWlzZWQgd2hpY2ggbGFyZ2VseSBjb3ZlcnMgdGhlIHNhbWUgaXNzdWUs IGFuZCBpdCBhcHBlYXJzIHRoZXJlIGFyZSBkaXNjdXNzaW5nIG9uIGtlZXBpbmcgY2xpZW50IElE IGluIGVycm9yIG1lc3NhZ2UgcmVzcG9uc2VzLCB0aG91Z2ggSSBkb27igJl0IGhhdmUgYW4gb3Zl cnZpZXcgb24gdGhhdC4NCg0KDQoNCktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJn ZW5zZW4NCg0KDQpPbiAyNiBTZXB0ZW1iZXIgMjAxNyBhdCAwMi4zMi4zMywgTWFyayBOb3R0aW5n aGFtIChtbm90QG1ub3QubmV0PG1haWx0bzptbm90QG1ub3QubmV0Pikgd3JvdGU6DQo2MzcNCg== --_000_MWHPR21MB01414A7DF3C98F42DE3236C8877B0MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFp bG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFp bF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiM2Mzcg d2FzIGNsb3NlZCwgbm90IGJlY2F1c2UgaXQgd2FzIHJlc29sdmVkIGluLWRyYWZ0LCBidXQgYmVj YXVzZSBpdCBhZHZvY2F0ZWQgYSBwYXJ0aWN1bGFyIHNvbHV0aW9uIHRvIGEgcHJvYmxlbSByYXRo ZXIgdGhhbiByZWZsZWN0aW5nIGEgcHJvYmxlbSBieSBpdHNlbGYuJm5ic3A7IFBlcmhhcHMgd2Ug c2hvdWxkIG1hcmsgaXQgd2l0aCBhIGRpZmZlcmVudCB0YWcgdGhhbiBoYXMtY29uc2Vuc3VzLCBi dXQgSSBiZWxpZXZlDQogaXRzIEp1bmUgY2xvc3VyZSBpcyBzdGlsbCBjb3JyZWN0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBP Zg0KPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgU2VwdGVtYmVyIDI2LCAyMDE3IDEyOjI0IEFNPGJyPg0KPGI+VG86PC9iPiBRVUlDIFdHICZs dDtxdWljQGlldGYub3JnJmd0OzsgTWFyayBOb3R0aW5naGFtICZsdDttbm90QG1ub3QubmV0Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gTGFycyBFZ2dlcnQgJmx0O2xhcnNAbmV0YXBwLmNvbSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IENvbnNlbnN1cyBDYWxsIG9uIGlzc3VlcyBjbG9zZWQgYnkg dGhlIC0wNiBkcmFmdHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZv bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBh Z3JlZSB3aXRoIGNsb3NpbmcgIzYzNyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUy RnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGaXNzdWVzJTJGNjM3JmFtcDtkYXRhPTAyJTdDMDElN0Nt aWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M5NzM0ZGI3MzMyOGE0OTAwMmNhZTA4ZDUw NGFmOTY1MiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY0 MjAwNzQ1NTAwOTU5MDQmYW1wO3NkYXRhPWJqcDQ0MEZjVzdMaFdaR29aVjY4T0tGa0FGUHl4Y2U4 QW1INDJSbjFoVTQlM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cv YmFzZS1kcmFmdHMvaXNzdWVzLzYzNzwvYT4sDQogYnV0IGEgbmV3IGlzc3VlJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdp dGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRmlzc3VlcyUyRjcxNCZhbXA7ZGF0YT0w MiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDOTczNGRiNzMzMjhhNDkw MDJjYWUwOGQ1MDRhZjk2NTIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM2NDIwMDc0NTUwMDk1OTA0JmFtcDtzZGF0YT1iYnUlMkJYSmU0UFJEVGVobEFBR2lW JTJCUXVwNjdpJTJGQXluRTJiRjFQMlJ1bVprJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy83MTQ8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5oYXMgYmVlbiByYWlzZWQgd2hpY2ggbGFyZ2Vs eSBjb3ZlcnMgdGhlIHNhbWUgaXNzdWUsIGFuZCBpdCBhcHBlYXJzIHRoZXJlIGFyZSBkaXNjdXNz aW5nIG9uIGtlZXBpbmcgY2xpZW50IElEIGluIGVycm9yIG1lc3NhZ2UgcmVzcG9uc2VzLCB0aG91 Z2ggSSBkb27igJl0IGhhdmUgYW4gb3ZlcnZpZXcNCiBvbiB0aGF0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1MDY0MTA1MjY0MzExNzQ5MTIiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlr a2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImFpcm1haWxvbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pk9uIDI2IFNlcHRlbWJlciAyMDE3IGF0IDAyLjMyLjMzLCBNYXJrIE5vdHRpbmdoYW0gKDxhIGhy ZWY9Im1haWx0bzptbm90QG1ub3QubmV0Ij5tbm90QG1ub3QubmV0PC9hPikgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+NjM3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB01414A7DF3C98F42DE3236C8877B0MWHPR21MB0141namp_-- From nobody Tue Sep 26 18:36:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A021344D3 for ; Tue, 26 Sep 2017 18:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=OaJn6GRB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oawnVwtQ 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 Q72gUMmvpgfr for ; Tue, 26 Sep 2017 18:36:53 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77E51342DC for ; Tue, 26 Sep 2017 18:36:52 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 42C692122D; Tue, 26 Sep 2017 21:36:51 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 26 Sep 2017 21:36:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=0/EE6vilHTPsbJjNBR tztjMyy7mMBVFS9WVT/7/hGTA=; b=OaJn6GRB91Nhmpb69qGfmer7OpssVdH8dC egiLbMub4PwKvTntwpm2xcyMNidbzOxdg/AXDj+2JokW1IIjA2Vej8l9EL6Y9jNm w79vHwtsG4dGsNKsTWO0rHyBJQhIU5bsUY8RkfIS1O0sJt7IfmFvZTmexiukBAMb yvG+qoXmIFaaGCq+r34LsJIrxZrvora+fvkZV75AKCingsOG5dWF7f+GM0M65Bwz DCS5K483kSBr65haIcmxyA6rfKsM2i0U5y6waCcxelEBfKDTY+9lhWLCxPu+5i2s 7uCeOJ5z/VEFLj5dq+ZUBL57iIvIWpLhQwKMv6DNMpZeVXBuS29g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=0/EE6vilHTPsbJjNBRtztjMyy7mMBVFS9WVT/7/hGTA=; b=oawnVwtQ iMReyns8zXUNP64e4FRYTLYDUkzMzSl117BjhdYgcFZrd9Uz0oHO3rH4F6D0q5Y+ yzpmqB/zRlQo5UBdY9n8WSu6tXsxhaBlyNZSpherXlFGcPUl98clNySQsBpMmqxh YufRG0+2ztNsoVt/Ya7mPHH4k0xsX3w1feSY0ArlIWTOQigTgVGm354aU/0ZZ5FC Y2fSIM9q5ZVsO7kIAuZJMdrBYz4pzVHToQb+992YcI3e43JXz4013ZGwC+pI+0Id wLmj+OwZ1COPVmjunvGFSyij7V4mibH4geDDE0gm+Txk+FSJeZXFOaYet7BgKPZk LSJhRnC0UFZTog== X-ME-Sender: X-Sasl-enc: 9kh/+oQ778KnjZdAfs9uMxYBH/vypCI/j3uEcFHnI4gP 1506476210 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id CD4897FA73; Tue, 26 Sep 2017 21:36:49 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Consensus Call on issues closed by the -06 drafts From: Mark Nottingham In-Reply-To: Date: Wed, 27 Sep 2017 11:36:45 +1000 Cc: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <238E43A0-A318-4BF8-9F28-999A1238D2A0@mnot.net> References: <1023AAAC-5195-4A26-A909-D01041A0C9B5@mnot.net> To: Mike Bishop X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 01:36:56 -0000 Marked as 'invalid' which covers both 'not well formed' and 'duplicate'. Let's try to keep the issues as just that -- issues. If you have a = proposal, there are many ways to convey that: * As a message on the mailing list * As a pull request * As a comment on an issue (that describes the issue it's trying to = address). Cheers, > On 27 Sep 2017, at 1:45 am, Mike Bishop = wrote: >=20 > #637 was closed, not because it was resolved in-draft, but because it = advocated a particular solution to a problem rather than reflecting a = problem by itself. Perhaps we should mark it with a different tag than = has-consensus, but I believe its June closure is still correct. > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3=B8= e J=C3=B8rgensen > Sent: Tuesday, September 26, 2017 12:24 AM > To: QUIC WG ; Mark Nottingham > Cc: Lars Eggert > Subject: Re: Consensus Call on issues closed by the -06 drafts > =20 > I don=E2=80=99t agree with closing #637 = https://github.com/quicwg/base-drafts/issues/637, but a new issue=20 > https://github.com/quicwg/base-drafts/issues/714 > has been raised which largely covers the same issue, and it appears = there are discussing on keeping client ID in error message responses, = though I don=E2=80=99t have an overview on that. > =20 > =20 > =20 > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen >=20 > =20 > On 26 September 2017 at 02.32.33, Mark Nottingham (mnot@mnot.net) = wrote: >=20 > 637 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Sep 27 02:38:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EECD1348E3 for ; Wed, 27 Sep 2017 02:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.78 X-Spam-Level: X-Spam-Status: No, score=0.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 Fgpe7ePKdgd7 for ; Wed, 27 Sep 2017 02:38:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881F01348E1 for ; Wed, 27 Sep 2017 02:38:42 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-07-59cb71a0c4cc Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.4A.21299.0A17BC95; Wed, 27 Sep 2017 11:38:40 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 27 Sep 2017 11:38:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GA3BNeWPVRYDpWFUtUBkobnAVLUVYiLYBO9aV7YEIuY=; b=cPhuLtpfjqMj+u/WIiNY2oDN9zZcB9YemAVLMI6vf/a9wR2jay6zWcECvVdpMXMuPwllzLfwL0nxc7jOO6WLPlLV5chZJ0RPTvaHZr+Ty44Ek4mIpjWqjcYjE43mW+uPEHEp6IAH03vgAyex0XZJXMUgxuWqYnNf6zVwH9XpDPI= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 27 Sep 2017 09:38:37 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.016; Wed, 27 Sep 2017 09:38:37 +0000 From: Ingemar Johansson S To: "gorry@erg.abdn.ac.uk" , =?iso-8859-1?Q?Mirja_K=FChlewind?= CC: Christian Huitema , "quic@ietf.org" , Ingemar Johansson S Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdMWaIZN+ofkuQeuQOGGa2om9/ikzaLIbk0g Date: Wed, 27 Sep 2017 09:38:36 +0000 Message-ID: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> <88460A72-DFEF-4CD8-8A41-C8684EC65C09@tik.ee.ethz.ch> <59C8E900.20409@erg.abdn.ac.uk> In-Reply-To: <59C8E900.20409@erg.abdn.ac.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 6:e/v7LeRaeG8Mp9JuPnbz62AByku1WJf5YtYJ4YDWruuyetADn0zg+djM0d97m1mPukLlhZZhARJz4q1bRvXW+gNP9RMJ/c5e5pIkocXlin6KQUTfnbYQkp/6BKcF/5zR2NoDOVlvmhqvK+ogCLWPGpshQBSLJYQ5NDqKylaFE25YdJID2alNaf9/owUXaFwjL69BBDnNEYcR0ExEK8uXWmrTNbB6s5oMxuCwy295i/X7Ec9zmX22gJzSsiT4o+IaVRO3D5Axgmt7hqyhLUVqNxdihXCU8UfrrNxlCmsZztU25r4Y/hrYt7LoPZq7fiG6iESJJjAjAAP94qWQ//awQQ==; 5:eGEmR+jZTwg85fXGEyD8JsLkqqLAnhJi+th8iZOC0kxs83Nh5XrBJJ/7ArtOPZDUc3yAZx3tljcRgdnZPMOlykZby3a1rqRUDTSGLi/LyxruX7T3qcAJluAOdEUxlNTBimr2KY/5zJClo4EFagxP+g==; 24:8tnuClSezbnh7Hz8IiQMMq+nw051N4eR4wmP4GlPxiHb4tLX0tMdQ+lHq4n4/90LYYvuK+pnsR+KrYXOOriBLElwijLBaoN2nZayRO+h0jg=; 7:qwjqKjOxZ+aEuP51oRJ5PFjTz1rkV08vSuslNRNzcV/6VCtXbzMvOAxj6gsoNeGZsrarqUX7RbBOBuch3PiMn2Xvk0H151ftthzXW8hu3yUbKzB0ccsg4YKitJHBfRUir6gQVoTXezEvimdUkCDMRG2+wzMb5tEC8eJy3hcpByIfg0rFxbU5ET/wJGrHynE5v3L+RWCNncfusjvZHuXxLVx+gu36NWI0JuQFvdB7Log= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(24454002)(199003)(377454003)(13464003)(189002)(102836003)(6116002)(2950100002)(6436002)(106356001)(6506006)(97736004)(3846002)(33656002)(4326008)(5250100002)(2906002)(6246003)(3480700004)(14454004)(2501003)(55016002)(105586002)(3660700001)(6306002)(99286003)(25786009)(2900100001)(53936002)(68736007)(107886003)(9686003)(66066001)(966005)(189998001)(551984002)(229853002)(93886005)(3280700002)(316002)(478600001)(8936002)(7736002)(74316002)(305945005)(54906003)(110136005)(81166006)(81156014)(7116003)(76176999)(8676002)(7696004)(101416001)(86362001)(50986999)(5660300001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 3858fc80-5242-428f-7007-08d5058b8742 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB345; x-ms-traffictypediagnostic: DB4PR07MB345: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(12181511122)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB345; x-forefront-prvs: 04433051BF received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3482CFE0ACA8D52124918D6C2780DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2017 09:38:36.9414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUURSAue/dN/OcGrhNikdDqiGJXEsLBjFRhFDE0ILcKJ30oaKO9p6J 1h/7ocQ0hqXihjiKWLmEmJWpaQ45k9kiGmKKCy6lKGEujUtIjm8C/33nfOfcc+7lsrSil3Fk kzWZHK9RpyolMlwe+TrcXX9rIOps+ZpStZRfiVRF9yqlqpbGYqzS6Q/54yDd2gIVNFb2EQfV 1W1RQcaVDUkYjpb5JnCpyVkc7+kXJ0uqyivEGVWa7PmfTXQuaryuRTYskPNQsdFAaZGMVZD3 CKqnO7AYfEBQU9NCWwJMCmioNA9aTQkF7yZ+0GIwhcCkLcWWwyTEF54ZzMjCtiQH2uo2GUsR TfIRLOwa94uOEgC98TElFjnAr/U8LLIXbG3/kVgYE2f4O7fIWFhOouHp0ph1wz4Gvnwa2m+2 IW6wXtVBWxgRJ5gyT+4fRBN7GJurpsTrEajr+kqLbAeLs7uMyCdg/IkJi+wEQ9UPkGUAkDwp fK6tlorCG7SFXYwo2iQws9NnFaHwaqSZEkUVgqGefKs4AzOFm9aV4mH1e4F1nA/cf2SycjLo Xy7TYvMIA6u527gQuVUcWF3kdOjs1uOK/Tc4Av3lc1jMe8BoSbFEZFeor1miRXaHsl0DPpjX I2kDshM44WZaope3B8cnxwtCusZDw2W2or2P1du249yOhpcDDIiwSHlYjiIGohSMOkvISTMg YGmlrfxi2l5KnqDOucPx6bH87VROMKBjLFbaywO6ByMVJFGdyaVwXAbH/7cUa+OYi2SbF76F BE8UlU6/nSg21T4nzuOxDgmB5tK7YUJIysn6COlkKz/q30jHmbV8c22ObkVmjHnoEs5y/ub+ lhi/G67xgfYeTR3lSt02tX11viP28nH12Kker4jZcMozRRHFDV6qnL+yNih1D9aFd7YPv8h9 Y/Ri4LRP6O9rhuxsJRaS1OdcaF5Q/wMtmIZRVAMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:38:45 -0000 --_000_DB4PR07MB3482CFE0ACA8D52124918D6C2780DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi General question. Is this Ok to discuss on this list or should we have the = discussion on the tracker ? To summarize.. I can make the following observations : 1) ECN in ACK frame or dedicated ECN frame : Proponents of a dedicated ECN = frame argue that adding extra ECN info in the ACK frame can increase the co= mplexity of the ACK frame encoding and parsing. Ian Swett however as a very= strong point in his remark that ECN in a separate frame can give addition= al issues in the congestion control functionality, in other words, what we = save (in complexity) in one part of the chain can cause extra cost and in t= he worst case incomprehensible code in another part of the chain. My takeaw= ay is that it is best to have ECN in the ACK frame. 2) Detailed ECN marking info (2 bits/packet) or ECN marked bytes : I see so= me preference to implement something like what is suggested for RMCAT, I am= not convinced that one need to impose the limitations of AccEcn as the lat= ter is given by the limitations by TCP. Fig 2 and 3 in https://tools.ietf.= org/id/draft-johansson-quic-ecn-01.txt suggests two formats, my preference = is the version presented in figure 3 (alt 2), it is padded at the end of th= e ACK frame. I copy the necessary parts below, it is not intended as a take= it or leave it. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First Ack Block Length (8/16/32/48) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Gap 1 (8)] | [Ack Block 1 Length (8/16/32/48)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Gap 2 (8)] | [Ack Block 2 Length (8/16/32/48)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Gap N (8)] | [Ack Block N Length (8/16/32/48)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ECE|ECE|... variable length, padded to full octets ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ECE field requires two bits encoding per frame. The additional overhead amounts to ceil(N*2/8) octets where the N is the sum of the ACK block lengths. /Ingemar > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: den 25 september 2017 13:31 > To: Mirja K=FChlewind > Cc: Christian Huitema ; quic@ietf.org > Subject: Re: ECN in QUIC > > +1 > > DCTP is not IETF standard - it's documenting a solution that is deployed = in > data centres - as it says - my hope is QUIC receives wider deployment. > > I suggest you start from AccECN, or examine the feedback discussed in > RMCAT - which I think strove for equivalence to this. > > Gorry > > On 25/09/2017, 12:26, Mirja K=FChlewind wrote: > > There is Accurate ECN (draft-ietf-tcpm-accurate-ecn) in tcpm that chang= es > the feedback defined in RFC3168 because we believe more accurate > information in needed in future. > > > > Mirja > > > > > >> Am 20.09.2017 um 21:02 schrieb Christian > Huitema>: > >> > >> > >> > >> On 9/20/2017 9:51 AM, Ingemar Johansson S wrote: > >>> Detailed info about which packets are ECN marked can be useful but ar= e > not stricktly necessary. One alternative, that is presented in the ECN-QU= IC > draft is to count number of marked bytes. > >>> That said, some like the detailed packet-level information type bette= r. I > have not yet been convinced that that this level of detail is necessary t= hough. > >> The problem is whether you can define a one size fit all ECN > >> processing, that if possible should be compatible with ACK > >> compression. There are at least two: > >> > >> * RFC 3168 says, echo ECN=3D1 if at least one of the acked packets had > >> ECN set. > >> > >> * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction > >> of packet acked with ECN in 1RTT is the same as the fraction of > >> packets with ECN set. > >> > >> So, which one? > >> > >> --Christian Huitema > >> > --_000_DB4PR07MB3482CFE0ACA8D52124918D6C2780DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
General question. Is this Ok to discuss on this list or should we have= the discussion on the tracker ?
 
To summarize.. I can make the following observations :
 
1) ECN in ACK frame or dedicated ECN frame : Proponents of a dedicated= ECN frame argue that adding extra ECN info in the ACK frame can increase t= he complexity of the ACK frame encoding and parsing. Ian Swett however as a= very strong point in  his remark that ECN in a separate frame can give additional issues in the congestion c= ontrol functionality, in other words, what we save (in complexity) in one p= art of the chain can cause extra cost and in the worst case incomprehensibl= e code in another part of the chain. My takeaway is that it is best to have ECN in the ACK frame.
 
2) Detailed ECN marking info (2 bits/packet) or ECN marked bytes : I s= ee some preference to implement something like what is suggested for RMCAT,= I am not convinced that one need to impose the limitations of AccEcn as th= e latter is given by the limitations by TCP. Fig 2 and 3 in  https://tools.ietf.org/id/d= raft-johansson-quic-ecn-01.txt suggests two formats, my pref= erence is the version presented in figure 3 (alt 2), it is padded at the end of the ACK frame. I copy the necessary p= arts below, it is not intended as a take it or leave it.
 
      0  = ;            &n= bsp;    1        &nb= sp;          2  &nbs= p;            &= nbsp;   3
      0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
     |   = ;           First Ack Blo= ck Length (8/16/32/48)         = ;   ...
     +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
     |  [Gap 1 (8)= ]  |       [Ack Block 1 Length (8/16/32/= 48)]     ...
     +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
     |  [Gap 2 (8)= ]  |       [Ack Block 2 Length (8/16/32/= 48)]     ...
     +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
       &= nbsp;           &nbs= p;            &= nbsp; ...
     +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
     |  [Gap N (8)= ]  |       [Ack Block N Length (8/16/32/= 48)]     ...
     +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
     |ECE|ECE|... varia= ble length, padded to full octets       =     ...
     +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
 
   The ECE field requires two bits encoding per
      frame.  The additional overhead am= ounts to ceil(N*2/8) octets
      where the N is the sum of the ACK block= lengths.
 
/Ingemar
 
 
> -----Original Message-----
> From: Gorry Fairhurst [ma= ilto:gorry@erg.abdn.ac.uk]
> Sent: den 25 september 2017 13:31
> To: Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>
> Cc: Christian Huitema <huitema@huitema.net>; quic@ietf.org<= /div>
> Subject: Re: ECN in QUIC
>
> +1
>
> DCTP is not IETF standard - it's documenting a solution that is d= eployed in
> data centres - as it says - my hope is QUIC receives wider deploy= ment.
>
> I suggest you start from AccECN, or examine the feedback discusse= d in
> RMCAT - which I think strove for equivalence to this.
>
> Gorry
>
> On 25/09/2017, 12:26, Mirja K=FChlewind wrote:
> > There is Accurate ECN (draft-ietf-tcpm-accurate-ecn) in tcpm= that changes
> the feedback defined in RFC3168 because we believe more accurate<= /div>
> information in needed in future.
> >
> > Mirja
> >
> >
> >> Am 20.09.2017 um 21:02 schrieb Christian
> >>
> >>
> >>
> >> On 9/20/2017 9:51 AM, Ingemar Johansson S wrote:
> >>> Detailed info about which packets are ECN marked can= be useful but are
> not stricktly necessary. One alternative, that is presented in th= e ECN-QUIC
> draft is to count number of marked bytes.
> >>> That said, some like the detailed packet-level infor= mation type better. I
> have not yet been convinced that that this level of detail is nec= essary though.
> >> The problem is whether you can define a one size fit all= ECN
> >> processing, that if possible should be compatible with A= CK
> >> compression. There are at least two:
> >>
> >> * RFC 3168 says, echo ECN=3D1 if at least one of the ack= ed packets had
> >> ECN set.
> >>
> >> * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that = the fraction
> >> of packet acked with ECN in 1RTT is the same as the frac= tion of
> >> packets with ECN set.
> >>
> >> So, which one?
> >>
> >> --Christian Huitema
> >>
>
 
 
 --_000_DB4PR07MB3482CFE0ACA8D52124918D6C2780DB4PR07MB348eurprd_-- From nobody Wed Sep 27 12:18:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C57F134F19 for ; Wed, 27 Sep 2017 12:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 d569CHyxgwri for ; Wed, 27 Sep 2017 12:18:20 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56549134F1C for ; Wed, 27 Sep 2017 12:18:20 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id q80so10017545ywg.2 for ; Wed, 27 Sep 2017 12:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lSEzQmjHqXfM/faLKID1Uv8mt7cheg3Il42mYlTT5dA=; b=wEKG+akM7lDXF5HEY6AJj0qwl6QuA7bg4ZMlPq236PwRu5XFT40TV5ppqCIf0ynMWX 6KoMniic9I08UF3Q+/nU7kyMS9eSErB5iI1Et/U662fY7HYxKXIaMvbozMLDIjOkvBDC nRsQTSbJxF53QiR5i4GxhndsHnm4MS7a532nIxaNAtSfPf2IYDsgeIL5mHbmnD0qjswF eR8p/mzvhkFG3zXoM6voxyo8UDNm1kzJwbhbOnyZAcKfkfaaH+qNyeH1bcVgp39m5zXA 5j1W0EzyP22QHXZ852hSIy8d4yN93kOoE/gCMv6K4dDzD3NM43Tldkvs10B1lNLhST4E L9OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lSEzQmjHqXfM/faLKID1Uv8mt7cheg3Il42mYlTT5dA=; b=HEUdI9/OTyQytTT/qssdf8iy1olgiVihH0oscioh+7DY9LzPu/tj5imDl8IA56uL8h WzrIhF4ijvc/Ppf77VOpN4FUPaVX/o/zAah0GcNoMxMiQcTi3srZSJr4BCa376m3QqiI WTKe5m7Q/o8G9vHFK8eg9ZHGg4aSiZglU5c5hFTL2vy1Kobl7H9d2ofoACs9LESCfMoA ljvxVi0T+jmGtN7/nZepg0XL55hEahgaMlT7dKrsfGLDBVVGgI+kZaJgHGX5unWXk5Xy 53tCcXHA9OqobpsgBhCwKQs/tHakox43FHzUN/UzPRMqP8XjVdzI7ZQHbWKcOa+Alc1D qqDg== X-Gm-Message-State: AHPjjUideGkbZT01YwTy8g9OCZgjtH3+ryT1gTgH8S1jxe2WWxK1htL/ QIGNT0SQ+LEbPzb9HHFO1HiPjxAP5KmjCsGs2Q63kg== X-Google-Smtp-Source: AOwi7QAiXNu6tvWz5EEzmtG6B5O6YVFPuD2HPLi/Wbn4vZdJY2CZG6ufgB4LVopkEkPqozerPI++SuOKMmiriCVZZaE= X-Received: by 10.129.145.214 with SMTP id i205mr1746894ywg.73.1506539899205; Wed, 27 Sep 2017 12:18:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.118.133 with HTTP; Wed, 27 Sep 2017 12:18:18 -0700 (PDT) In-Reply-To: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> <88460A72-DFEF-4CD8-8A41-C8684EC65C09@tik.ee.ethz.ch> <59C8E900.20409@erg.abdn.ac.uk> From: Jana Iyengar Date: Wed, 27 Sep 2017 12:18:18 -0700 Message-ID: Subject: Re: ECN in QUIC To: Ingemar Johansson S Cc: "gorry@erg.abdn.ac.uk" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "quic@ietf.org" , Christian Huitema Content-Type: multipart/alternative; boundary="94eb2c0941c288f8bc055a30a7ea" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 19:18:22 -0000 --94eb2c0941c288f8bc055a30a7ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > General question. Is this Ok to discuss on this list or should we have th= e > discussion on the tracker ? > We should have something on the tracker. Would you open an issue? > To summarize.. I can make the following observations : > > 1) ECN in ACK frame or dedicated ECN frame : Proponents of a dedicated EC= N > frame argue that adding extra ECN info in the ACK frame can increase the > complexity of the ACK frame encoding and parsing. Ian Swett however as a > very strong point in his remark that ECN in a separate frame can give > additional issues in the congestion control functionality, in other words= , > what we save (in complexity) in one part of the chain can cause extra cos= t > and in the worst case incomprehensible code in another part of the chain. > My takeaway is that it is best to have ECN in the ACK frame. > I agree with Ian's argument -- having ECN in a separate frame would make things harder for congestion control. 2) Detailed ECN marking info (2 bits/packet) or ECN marked bytes : I see > some preference to implement something like what is suggested for RMCAT, = I > am not convinced that one need to impose the limitations of AccEcn as the > latter is given by the limitations by TCP. Fig 2 and 3 in > *https://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt* > suggests two > formats, my preference is the version presented in figure 3 (alt 2), it i= s > padded at the end of the ACK frame. I copy the necessary parts below, it = is > not intended as a take it or leave it. > I think we'll need to think carefully about framing, but let's do that on the issue. - jana > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | First Ack Block Length (8/16/32/48) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Gap 1 (8)] | [Ack Block 1 Length (8/16/32/48)] ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Gap 2 (8)] | [Ack Block 2 Length (8/16/32/48)] ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Gap N (8)] | [Ack Block N Length (8/16/32/48)] ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |ECE|ECE|... variable length, padded to full octets ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The ECE field requires two bits encoding per > frame. The additional overhead amounts to ceil(N*2/8) octets > where the N is the sum of the ACK block lengths. > > /Ingemar > > > > -----Original Message----- > > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk > ] > > Sent: den 25 september 2017 13:31 > > To: Mirja K=C3=BChlewind > > Cc: Christian Huitema ; quic@ietf.org > > Subject: Re: ECN in QUIC > > > > +1 > > > > DCTP is not IETF standard - it's documenting a solution that is deploye= d > in > > data centres - as it says - my hope is QUIC receives wider deployment. > > > > I suggest you start from AccECN, or examine the feedback discussed in > > RMCAT - which I think strove for equivalence to this. > > > > Gorry > > > > On 25/09/2017, 12:26, Mirja K=C3=BChlewind wrote: > > > There is Accurate ECN (draft-ietf-tcpm-accurate-ecn) in tcpm that > changes > > the feedback defined in RFC3168 because we believe more accurate > > information in needed in future. > > > > > > Mirja > > > > > > > > >> Am 20.09.2017 um 21:02 schrieb Christian > > Huitema: > > >> > > >> > > >> > > >> On 9/20/2017 9:51 AM, Ingemar Johansson S wrote: > > >>> Detailed info about which packets are ECN marked can be useful but > are > > not stricktly necessary. One alternative, that is presented in the > ECN-QUIC > > draft is to count number of marked bytes. > > >>> That said, some like the detailed packet-level information type > better. I > > have not yet been convinced that that this level of detail is necessary > though. > > >> The problem is whether you can define a one size fit all ECN > > >> processing, that if possible should be compatible with ACK > > >> compression. There are at least two: > > >> > > >> * RFC 3168 says, echo ECN=3D1 if at least one of the acked packets h= ad > > >> ECN set. > > >> > > >> * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction > > >> of packet acked with ECN in 1RTT is the same as the fraction of > > >> packets with ECN set. > > >> > > >> So, which one? > > >> > > >> --Christian Huitema > > >> > > > > > --94eb2c0941c288f8bc055a30a7ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
General question. Is this Ok = to discuss on this list or should we have the discussion on the tracker ?

We should have som= ething on the tracker. Would you open an issue?
=C2=A0
To summarize.. I can make the following observations :
=C2=A0
1) ECN in ACK frame or dedicated ECN frame : Proponents of a dedicated= ECN frame argue that adding extra ECN info in the ACK frame can increase t= he complexity of the ACK frame encoding and parsing. Ian Swett however as a= very strong point in=C2=A0 his remark that ECN in a separate frame can give additional issues in the congestion c= ontrol functionality, in other words, what we save (in complexity) in one p= art of the chain can cause extra cost and in the worst case incomprehensibl= e code in another part of the chain. My takeaway is that it is best to have ECN in the ACK frame.

I agree with Ian's argument= -- having ECN in a separate frame would make things harder for congestion = control.

2) Detailed ECN marking info (2 bits/packet) or ECN marked bytes : I s= ee some preference to implement something like what is suggested for RMCAT,= I am not convinced that one need to impose the limitations of AccEcn as th= e latter is given by the limitations by TCP. Fig 2 and 3 in=C2=A0 https://t= ools.ietf.org/id/draft-johansson-quic-ecn-01.txt s= uggests two formats, my preference is the version presented in figure 3 (alt 2), it is padded at the end of the ACK frame. I copy the necessary p= arts below, it is not intended as a take it or leave it.

=C2=A0I think we'll need to thi= nk carefully about framing, but let's do that on the issue.

- jana

=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=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 1=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 2=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 3
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=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 First Ack B= lock Length (8/16/32/48)=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 [Gap 1 (8)= ]=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Ack Block 1 Length (8/16/32/= 48)]=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 [Gap 2 (8)= ]=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Ack Block 2 Length (8/16/32/= 48)]=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=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 [Gap N (8)= ]=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Ack Block N Length (8/16/32/= 48)]=C2=A0=C2=A0=C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0 |ECE|ECE|... varia= ble length, padded to full octets=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 The ECE field requires two bits encoding per
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 frame.=C2=A0 The additional overhead am= ounts to ceil(N*2/8) octets
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 where the N is the sum of the ACK block= lengths.
=C2=A0
/Ingemar
=C2=A0
=C2=A0
> -----Original Message-----
> From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> Sent: den 25 september 2017 13:31
> To: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch&g= t;
> Cc: Christian Huitema <huitema@huitema.net>; quic@ietf.org
> Subject: Re: ECN in QUIC
>
> +1
>
> DCTP is not IETF standard - it's documenting a solution that = is deployed in
> data centres - as it says - my hope is QUIC receives wider deploy= ment.
>
> I suggest you start from AccECN, or examine the feedback discusse= d in
> RMCAT - which I think strove for equivalence to this.
>
> Gorry
>
> On 25/09/2017, 12:26, Mirja K=C3=BChlewind wrote:
> > There is Accurate ECN (draft-ietf-tcpm-accurate-ecn) in tcpm= that changes
> the feedback defined in RFC3168 because we believe more accurate<= /div>
> information in needed in future.
> >
> > Mirja
> >
> >
> >> Am 20.09.2017 um 21:02 schrieb Christian
> >>
> >>
> >>
> >> On 9/20/2017 9:51 AM, Ingemar Johansson S wrote:
> >>> Detailed info about which packets are ECN marked can= be useful but are
> not stricktly necessary. One alternative, that is presented in th= e ECN-QUIC
> draft is to count number of marked bytes.
> >>> That said, some like the detailed packet-level infor= mation type better. I
> have not yet been convinced that that this level of detail is nec= essary though.
> >> The problem is whether you can define a one size fit all= ECN
> >> processing, that if possible should be compatible with A= CK
> >> compression. There are at least two:
> >>
> >> * RFC 3168 says, echo ECN=3D1 if at least one of the ack= ed packets had
> >> ECN set.
> >>
> >> * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that = the fraction
> >> of packet acked with ECN in 1RTT is the same as the frac= tion of
> >> packets with ECN set.
> >>
> >> So, which one?
> >>
> >> --Christian Huitema
> >>
>
=C2=A0
=C2=A0

--94eb2c0941c288f8bc055a30a7ea-- From nobody Thu Sep 28 05:37:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DAA134706 for ; Thu, 28 Sep 2017 05:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.781 X-Spam-Level: X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 BK6I3GQEVjDB for ; Thu, 28 Sep 2017 05:37:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9AA134684 for ; Thu, 28 Sep 2017 05:37:15 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-2d-59ccecf94285 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EA.56.20899.9FCECC95; Thu, 28 Sep 2017 14:37:13 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 28 Sep 2017 14:36:52 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qkTCo6ftM7WelPWAK9zK+JZcefRGbeoyMES5TS2whLQ=; b=Zgx9NyzwFbzuTv23tBUp8KqRmC3fAXOpl67nosjWdta31Av85BC8oeB3E8EIFwcH5cAfYdtjn6EKukWllDIelVZfpcuzuVjwk4PRJYhRY2s3XkoAu4wyQGzVcgQTbL6ANDY1uLC7QXl0q0LKiRlzSiZcNo8xBhH1poTYNJEDyVk= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 28 Sep 2017 12:36:51 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.016; Thu, 28 Sep 2017 12:36:51 +0000 From: Ingemar Johansson S To: Jana Iyengar CC: "gorry@erg.abdn.ac.uk" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "quic@ietf.org" , Christian Huitema Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdMWaIZN+ofkuQeuQOGGa2om9/ikzaLIbk0g3XpLZgD//t4mIA== Date: Thu, 28 Sep 2017 12:36:50 +0000 Message-ID: References: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <59C27B81.2020609@erg.abdn.ac.uk> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> <88460A72-DFEF-4CD8-8A41-C8684EC65C09@tik.ee.ethz.ch> <59C8E900.20409@erg.abdn.ac.uk> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:3H+zVVnmJ1RX9SZtfSoB9Du1j7Bz/vfUlDwr98Um9H4Q4yiY25jvc7l/f1N4Gveqb2o14Unabkp6JfEZj/CJjbSQmPMH4CdNINNgu17ypCbRII7oqQqsuZ1OYgmQXjeFjjOoKywuY00CcS3r5BW5TjddUa7H+5UbFTNm3e+i9JPT6+dt0OvQ/2cm9MzZTgCQzT4eftxkeAifEcSFnxS1/rF8QvE/akF+C5NbVFyEM+fi9VT46shlmIXPjuY0AJKXP7gtk7Qcmj36c8iEuFJr9vwuZ85Q4Kw3aVmbAs8ppbuM2bQcVj3Uwpde24B8QzfmyFTBwfkuAX0hMciUlBwg9Q==; 5:ERffbx+gBycFOI3kg/RaGVRXYV8quRD/G9V5MFtXAf/dXE3SA8HnItW0Wl8aT6ZKJKzlS0+djp7RmrGfiWyyFyL9XrVq50ePHSMA1wcsJTVPUNZmUczO7DSDTtfBfFkP4ykpIcibVuOKpiBRmH8KAQ==; 24:6v5lmIa8aowUlUHVnq271aw76PoYTHIYiDey0nQnPCfrcg3bYO1DgqgZ/vLVrejXyn15ohV98EPEgQIETkRIfNnAJqkuF8GLNTsC0V10YjY=; 7:Ixk6kca5OxH9jkYr6uVnbmlq9NAc23LHLMvJXwu6wen8StMYhBCQWYbqDnKRu5thHtybtS6JD3gOoGlv0udnNRLCg6kTeoOG//LVjMNFbSLWUPzWUQMRrdRJ2XQh1gU3O8JuteeBohvEwAwPn9HQDFKjwxa37YdJkNiucYujS1Kvo6g9ucWGP8a/esjmbtlp1jQY3Sbg9QNvTRFddIK/wwT0WHxW0Pma2F0f5DqtWmE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5889c22c-0c48-49f9-a4f3-08d5066d97cc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB348; x-ms-traffictypediagnostic: DB4PR07MB348: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(211936372134217)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(920507026)(6041248)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB348; x-forefront-prvs: 0444EB1997 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(199003)(189002)(13464003)(377454003)(24454002)(9686003)(2900100001)(81166006)(14454004)(6306002)(19609705001)(8676002)(86362001)(966005)(4326008)(316002)(7696004)(478600001)(34040400001)(2906002)(5250100002)(97736004)(6246003)(2950100002)(6916009)(102836003)(99286003)(54906003)(55016002)(53936002)(93886005)(3660700001)(68736007)(6116002)(106356001)(66066001)(236005)(3280700002)(3846002)(105586002)(25786009)(551984002)(76176999)(54356999)(53546010)(50986999)(81156014)(189998001)(8936002)(54896002)(790700001)(74316002)(101416001)(606006)(3480700004)(5660300001)(7116003)(6436002)(7736002)(33656002)(6506006)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB34831F4312F8880628C9C47C2790DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2017 12:36:50.9360 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHObv3btfV4rQUn3yBHAQuyrf6MErEimhEUfohVAQbetHRnLKr oiVhlFrqRE3Nl5xGg0zNxLeyluYqdWoqUiw139hCMxuiiaggud0Ffvs9/+d//s85D4cmxCbK g1aqUxiNWqGS8IVkZcRrzxOby8ORATadn+x3TjWSPbpbLZCVfH5KyloaS0lZQd2+UEpesLbI k9e1psonKwZJuV6/yZP3razzr1FRwuA4RqVMYzT+ITeECcXL22TyzApKt5hHiSzUvoTykAsN +BSsNa2SeUhIi/EnBMWNixRXDCAoazA7ChJrCRgZK+JxnTIetNlGnLZZBDPWPMoexsfB8MK4 4Qh2xT7wc3NdYDcRuB/BwtKyw3QIA9T1lfA402Gw/c0mOT4H1oIKh07io7CZu0DYWYSjQDs1 zeemTfPhuylXYG+44DAwFs45TAh7w+zGjCOIwO4waa3lcc/DoDeMEhy7wS/LDsX5Y2F1Qktx +hGYet5PcuwN47X5yD4McLYADNlm52E/6Cj+49zZFWgev+/kGgS6HjHHUuiq3XAGqWDrnVbA sRLKzVaSC/1KgaF52mnygqzxarIIHa/ac3GOk2C0J4eocmzgIJgqrWQVond1Kbx6689ZfKA0 f17AsS9kP6kR7NXrkKABubEMyybGBwX5MRplLMsmqf3UTEor2v1gve3bp9+g3oWzRoRpJNkv 6rYMR4opRRqbkWhEQBMSV5FqaVcSxSkybjGapBhNqophjciTJiXuotDusQgxjlekMDcZJpnR /O/yaBePLKRXxEkD+U3h0TlDmRmBGR3P1FjaVs2kD0w0SXe0V8MCXOora7SXTakBQriQarhY vnXpm/eBCJ/4Cq/RBF2Lqd4S3WVK89LN/7g9SOsi5zofq2zXG1Zj9Oc/hgx+Se8s/GB4eScz 0iI98/5h5lp31JCvdJg1Mw/Wwk/Gjxeb7klINkEReIzQsIp/MIqVg1wDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 12:37:18 -0000 --_000_DB4PR07MB34831F4312F8880628C9C47C2790DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHR3byBkaXNjdXNzaW9uIHBvaW50cyBhcmUgbm93IHBvc3RlZCBhcyBpc3N1ZSAoaHR0cHM6 Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvODA0ICkgYW5kIChodHRwczov L2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy84MDUgKQ0KDQovSW5nZW1hcg0K DQpGcm9tOiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbV0NClNlbnQ6IGRlbiAy NyBzZXB0ZW1iZXIgMjAxNyAyMToxOA0KVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIu cy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0KQ2M6IGdvcnJ5QGVyZy5hYmRuLmFjLnVrOyBNaXJq YSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgcXVpY0BpZXRm Lm9yZzsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpTdWJqZWN0OiBS ZTogRUNOIGluIFFVSUMNCg0KR2VuZXJhbCBxdWVzdGlvbi4gSXMgdGhpcyBPayB0byBkaXNjdXNz IG9uIHRoaXMgbGlzdCBvciBzaG91bGQgd2UgaGF2ZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgdHJh Y2tlciA/DQoNCldlIHNob3VsZCBoYXZlIHNvbWV0aGluZyBvbiB0aGUgdHJhY2tlci4gV291bGQg eW91IG9wZW4gYW4gaXNzdWU/DQoNClRvIHN1bW1hcml6ZS4uIEkgY2FuIG1ha2UgdGhlIGZvbGxv d2luZyBvYnNlcnZhdGlvbnMgOg0KDQoxKSBFQ04gaW4gQUNLIGZyYW1lIG9yIGRlZGljYXRlZCBF Q04gZnJhbWUgOiBQcm9wb25lbnRzIG9mIGEgZGVkaWNhdGVkIEVDTiBmcmFtZSBhcmd1ZSB0aGF0 IGFkZGluZyBleHRyYSBFQ04gaW5mbyBpbiB0aGUgQUNLIGZyYW1lIGNhbiBpbmNyZWFzZSB0aGUg Y29tcGxleGl0eSBvZiB0aGUgQUNLIGZyYW1lIGVuY29kaW5nIGFuZCBwYXJzaW5nLiBJYW4gU3dl dHQgaG93ZXZlciBhcyBhIHZlcnkgc3Ryb25nIHBvaW50IGluICBoaXMgcmVtYXJrIHRoYXQgRUNO IGluIGEgc2VwYXJhdGUgZnJhbWUgY2FuIGdpdmUgYWRkaXRpb25hbCBpc3N1ZXMgaW4gdGhlIGNv bmdlc3Rpb24gY29udHJvbCBmdW5jdGlvbmFsaXR5LCBpbiBvdGhlciB3b3Jkcywgd2hhdCB3ZSBz YXZlIChpbiBjb21wbGV4aXR5KSBpbiBvbmUgcGFydCBvZiB0aGUgY2hhaW4gY2FuIGNhdXNlIGV4 dHJhIGNvc3QgYW5kIGluIHRoZSB3b3JzdCBjYXNlIGluY29tcHJlaGVuc2libGUgY29kZSBpbiBh bm90aGVyIHBhcnQgb2YgdGhlIGNoYWluLiBNeSB0YWtlYXdheSBpcyB0aGF0IGl0IGlzIGJlc3Qg dG8gaGF2ZSBFQ04gaW4gdGhlIEFDSyBmcmFtZS4NCg0KSSBhZ3JlZSB3aXRoIElhbidzIGFyZ3Vt ZW50IC0tIGhhdmluZyBFQ04gaW4gYSBzZXBhcmF0ZSBmcmFtZSB3b3VsZCBtYWtlIHRoaW5ncyBo YXJkZXIgZm9yIGNvbmdlc3Rpb24gY29udHJvbC4NCg0KMikgRGV0YWlsZWQgRUNOIG1hcmtpbmcg aW5mbyAoMiBiaXRzL3BhY2tldCkgb3IgRUNOIG1hcmtlZCBieXRlcyA6IEkgc2VlIHNvbWUgcHJl ZmVyZW5jZSB0byBpbXBsZW1lbnQgc29tZXRoaW5nIGxpa2Ugd2hhdCBpcyBzdWdnZXN0ZWQgZm9y IFJNQ0FULCBJIGFtIG5vdCBjb252aW5jZWQgdGhhdCBvbmUgbmVlZCB0byBpbXBvc2UgdGhlIGxp bWl0YXRpb25zIG9mIEFjY0VjbiBhcyB0aGUgbGF0dGVyIGlzIGdpdmVuIGJ5IHRoZSBsaW1pdGF0 aW9ucyBieSBUQ1AuIEZpZyAyIGFuZCAzIGluICBodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQgc3VnZ2VzdHMgdHdvIGZvcm1hdHMsIG15IHBy ZWZlcmVuY2UgaXMgdGhlIHZlcnNpb24gcHJlc2VudGVkIGluIGZpZ3VyZSAzIChhbHQgMiksIGl0 IGlzIHBhZGRlZCBhdCB0aGUgZW5kIG9mIHRoZSBBQ0sgZnJhbWUuIEkgY29weSB0aGUgbmVjZXNz YXJ5IHBhcnRzIGJlbG93LCBpdCBpcyBub3QgaW50ZW5kZWQgYXMgYSB0YWtlIGl0IG9yIGxlYXZl IGl0Lg0KDQogSSB0aGluayB3ZSdsbCBuZWVkIHRvIHRoaW5rIGNhcmVmdWxseSBhYm91dCBmcmFt aW5nLCBidXQgbGV0J3MgZG8gdGhhdCBvbiB0aGUgaXNzdWUuDQoNCi0gamFuYQ0KDQoNCiAgICAg IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAg ICAgIDMNCiAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICBG aXJzdCBBY2sgQmxvY2sgTGVuZ3RoICg4LzE2LzMyLzQ4KSAgICAgICAgICAgIC4uLg0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICBbR2FwIDEgKDgpXSAgfCAgICAgICBbQWNrIEJsb2NrIDEgTGVuZ3Ro ICg4LzE2LzMyLzQ4KV0gICAgIC4uLg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICBbR2FwIDIgKDgp XSAgfCAgICAgICBbQWNrIEJsb2NrIDIgTGVuZ3RoICg4LzE2LzMyLzQ4KV0gICAgIC4uLg0KICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLg0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICBbR2FwIE4gKDgpXSAgfCAgICAgICBbQWNrIEJsb2NrIE4gTGVuZ3Ro ICg4LzE2LzMyLzQ4KV0gICAgIC4uLg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8RUNFfEVDRXwuLi4g dmFyaWFibGUgbGVuZ3RoLCBwYWRkZWQgdG8gZnVsbCBvY3RldHMgICAgICAgICAgIC4uLg0KICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KDQogICBUaGUgRUNFIGZpZWxkIHJlcXVpcmVzIHR3byBiaXRzIGVuY29kaW5n IHBlcg0KICAgICAgZnJhbWUuICBUaGUgYWRkaXRpb25hbCBvdmVyaGVhZCBhbW91bnRzIHRvIGNl aWwoTioyLzgpIG9jdGV0cw0KICAgICAgd2hlcmUgdGhlIE4gaXMgdGhlIHN1bSBvZiB0aGUgQUNL IGJsb2NrIGxlbmd0aHMuDQoNCi9JbmdlbWFyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBHb3JyeSBGYWlyaHVyc3QgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 a10NCj4gU2VudDogZGVuIDI1IHNlcHRlbWJlciAyMDE3IDEzOjMxDQo+IFRvOiBNaXJqYSBLw7xo bGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1haWx0bzptaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoPj4NCj4gQ2M6IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1h QGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IHF1aWNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQw0KPg0KPiAr MQ0KPg0KPiBEQ1RQIGlzIG5vdCBJRVRGIHN0YW5kYXJkIC0gaXQncyBkb2N1bWVudGluZyBhIHNv bHV0aW9uIHRoYXQgaXMgZGVwbG95ZWQgaW4NCj4gZGF0YSBjZW50cmVzIC0gYXMgaXQgc2F5cyAt IG15IGhvcGUgaXMgUVVJQyByZWNlaXZlcyB3aWRlciBkZXBsb3ltZW50Lg0KPg0KPiBJIHN1Z2dl c3QgeW91IHN0YXJ0IGZyb20gQWNjRUNOLCBvciBleGFtaW5lIHRoZSBmZWVkYmFjayBkaXNjdXNz ZWQgaW4NCj4gUk1DQVQgLSB3aGljaCBJIHRoaW5rIHN0cm92ZSBmb3IgZXF1aXZhbGVuY2UgdG8g dGhpcy4NCj4NCj4gR29ycnkNCj4NCj4gT24gMjUvMDkvMjAxNywgMTI6MjYsIE1pcmphIEvDvGhs ZXdpbmQgd3JvdGU6DQo+ID4gVGhlcmUgaXMgQWNjdXJhdGUgRUNOIChkcmFmdC1pZXRmLXRjcG0t YWNjdXJhdGUtZWNuKSBpbiB0Y3BtIHRoYXQgY2hhbmdlcw0KPiB0aGUgZmVlZGJhY2sgZGVmaW5l ZCBpbiBSRkMzMTY4IGJlY2F1c2Ugd2UgYmVsaWV2ZSBtb3JlIGFjY3VyYXRlDQo+IGluZm9ybWF0 aW9uIGluIG5lZWRlZCBpbiBmdXR1cmUuDQo+ID4NCj4gPiBNaXJqYQ0KPiA+DQo+ID4NCj4gPj4g QW0gMjAuMDkuMjAxNyB1bSAyMTowMiBzY2hyaWViIENocmlzdGlhbg0KPiBIdWl0ZW1hPGh1aXRl bWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PjoNCj4gPj4NCj4gPj4N Cj4gPj4NCj4gPj4gT24gOS8yMC8yMDE3IDk6NTEgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMgd3Jv dGU6DQo+ID4+PiBEZXRhaWxlZCBpbmZvIGFib3V0IHdoaWNoIHBhY2tldHMgYXJlIEVDTiBtYXJr ZWQgY2FuIGJlIHVzZWZ1bCBidXQgYXJlDQo+IG5vdCBzdHJpY2t0bHkgbmVjZXNzYXJ5LiBPbmUg YWx0ZXJuYXRpdmUsIHRoYXQgaXMgcHJlc2VudGVkIGluIHRoZSBFQ04tUVVJQw0KPiBkcmFmdCBp cyB0byBjb3VudCBudW1iZXIgb2YgbWFya2VkIGJ5dGVzLg0KPiA+Pj4gVGhhdCBzYWlkLCBzb21l IGxpa2UgdGhlIGRldGFpbGVkIHBhY2tldC1sZXZlbCBpbmZvcm1hdGlvbiB0eXBlIGJldHRlci4g SQ0KPiBoYXZlIG5vdCB5ZXQgYmVlbiBjb252aW5jZWQgdGhhdCB0aGF0IHRoaXMgbGV2ZWwgb2Yg ZGV0YWlsIGlzIG5lY2Vzc2FyeSB0aG91Z2guDQo+ID4+IFRoZSBwcm9ibGVtIGlzIHdoZXRoZXIg eW91IGNhbiBkZWZpbmUgYSBvbmUgc2l6ZSBmaXQgYWxsIEVDTg0KPiA+PiBwcm9jZXNzaW5nLCB0 aGF0IGlmIHBvc3NpYmxlIHNob3VsZCBiZSBjb21wYXRpYmxlIHdpdGggQUNLDQo+ID4+IGNvbXBy ZXNzaW9uLiBUaGVyZSBhcmUgYXQgbGVhc3QgdHdvOg0KPiA+Pg0KPiA+PiAqIFJGQyAzMTY4IHNh eXMsIGVjaG8gRUNOPTEgaWYgYXQgbGVhc3Qgb25lIG9mIHRoZSBhY2tlZCBwYWNrZXRzIGhhZA0K PiA+PiBFQ04gc2V0Lg0KPiA+Pg0KPiA+PiAqIGRyYWZ0LWlldGYtdGNwbS1kY3RjcC0xMCBzdWdn ZXN0cyBzZXR0aW5nIEVDTiBzbyB0aGF0IHRoZSBmcmFjdGlvbg0KPiA+PiBvZiBwYWNrZXQgYWNr ZWQgd2l0aCBFQ04gaW4gMVJUVCBpcyB0aGUgc2FtZSBhcyB0aGUgZnJhY3Rpb24gb2YNCj4gPj4g cGFja2V0cyB3aXRoIEVDTiBzZXQuDQo+ID4+DQo+ID4+IFNvLCB3aGljaCBvbmU/DQo+ID4+DQo+ ID4+IC0tQ2hyaXN0aWFuIEh1aXRlbWENCj4gPj4NCj4NCg0KDQoNCg== --_000_DB4PR07MB34831F4312F8880628C9C47C2790DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHls ZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdHdv IGRpc2N1c3Npb24gcG9pbnRzIGFyZSBub3cgcG9zdGVkIGFzIGlzc3VlICg8YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy84MDQiPmh0dHBzOi8vZ2l0 aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzgwNDwvYT4gKSBhbmQgKDxhIGhyZWY9 Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzgwNSI+aHR0cHM6 Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvODA1PC9hPg0KICk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+L0luZ2VtYXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dIDxicj4NCjxiPlNl bnQ6PC9iPiBkZW4gMjcgc2VwdGVtYmVyIDIwMTcgMjE6MTg8YnI+DQo8Yj5Ubzo8L2I+IEluZ2Vt YXIgSm9oYW5zc29uIFMgJmx0O2luZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gZ29ycnlAZXJnLmFiZG4uYWMudWs7IE1pcmphIEvDvGhsZXdpbmQgJmx0 O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7OyBxdWljQGlldGYub3JnOyBDaHJp c3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IEVDTiBpbiBRVUlDPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HZW5l cmFsIHF1ZXN0aW9uLiBJcyB0aGlzIE9rIHRvIGRpc2N1c3Mgb24gdGhpcyBsaXN0IG9yIHNob3Vs ZCB3ZSBoYXZlIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSB0cmFja2VyID88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XZSBzaG91bGQgaGF2ZSBzb21ldGhpbmcgb24gdGhlIHRyYWNrZXIuIFdvdWxkIHlvdSBv cGVuIGFuIGlzc3VlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHN1bW1hcml6ZS4uIEkgY2FuIG1ha2Ug dGhlIGZvbGxvd2luZyBvYnNlcnZhdGlvbnMgOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBFQ04gaW4gQUNLIGZyYW1lIG9yIGRlZGljYXRl ZCBFQ04gZnJhbWUgOiBQcm9wb25lbnRzIG9mIGEgZGVkaWNhdGVkIEVDTiBmcmFtZSBhcmd1ZSB0 aGF0IGFkZGluZyBleHRyYSBFQ04gaW5mbyBpbiB0aGUgQUNLIGZyYW1lIGNhbiBpbmNyZWFzZSB0 aGUgY29tcGxleGl0eSBvZiB0aGUgQUNLIGZyYW1lIGVuY29kaW5nIGFuZCBwYXJzaW5nLiBJYW4g U3dldHQgaG93ZXZlciBhcyBhIHZlcnkgc3Ryb25nIHBvaW50DQogaW4mbmJzcDsgaGlzIHJlbWFy ayB0aGF0IEVDTiBpbiBhIHNlcGFyYXRlIGZyYW1lIGNhbiBnaXZlIGFkZGl0aW9uYWwgaXNzdWVz IGluIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZnVuY3Rpb25hbGl0eSwgaW4gb3RoZXIgd29yZHMs IHdoYXQgd2Ugc2F2ZSAoaW4gY29tcGxleGl0eSkgaW4gb25lIHBhcnQgb2YgdGhlIGNoYWluIGNh biBjYXVzZSBleHRyYSBjb3N0IGFuZCBpbiB0aGUgd29yc3QgY2FzZSBpbmNvbXByZWhlbnNpYmxl IGNvZGUgaW4gYW5vdGhlcg0KIHBhcnQgb2YgdGhlIGNoYWluLiBNeSB0YWtlYXdheSBpcyB0aGF0 IGl0IGlzIGJlc3QgdG8gaGF2ZSBFQ04gaW4gdGhlIEFDSyBmcmFtZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGFncmVlIHdpdGggSWFuJ3MgYXJndW1lbnQgLS0gaGF2aW5nIEVDTiBpbiBhIHNlcGFy YXRlIGZyYW1lIHdvdWxkIG1ha2UgdGhpbmdzIGhhcmRlciBmb3IgY29uZ2VzdGlvbiBjb250cm9s LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjIpIERldGFpbGVkIEVDTiBtYXJraW5nIGluZm8gKDIgYml0cy9w YWNrZXQpIG9yIEVDTiBtYXJrZWQgYnl0ZXMgOiBJIHNlZSBzb21lIHByZWZlcmVuY2UgdG8gaW1w bGVtZW50IHNvbWV0aGluZyBsaWtlIHdoYXQgaXMgc3VnZ2VzdGVkIGZvciBSTUNBVCwgSSBhbSBu b3QgY29udmluY2VkIHRoYXQgb25lIG5lZWQgdG8gaW1wb3NlIHRoZSBsaW1pdGF0aW9ucyBvZiBB Y2NFY24gYXMgdGhlIGxhdHRlciBpcyBnaXZlbg0KIGJ5IHRoZSBsaW1pdGF0aW9ucyBieSBUQ1Au IEZpZyAyIGFuZCAzIGluJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDEudHh0PC9hPiBz dWdnZXN0cyB0d28gZm9ybWF0cywgbXkgcHJlZmVyZW5jZSBpcyB0aGUgdmVyc2lvbiBwcmVzZW50 ZWQgaW4gZmlndXJlIDMgKGFsdCAyKSwgaXQgaXMgcGFkZGVkIGF0IHRoZSBlbmQgb2YgdGhlIEFD SyBmcmFtZS4gSSBjb3B5IHRoZSBuZWNlc3NhcnkgcGFydHMgYmVsb3csIGl0IGlzIG5vdCBpbnRl bmRlZCBhcyBhIHRha2UgaXQgb3IgbGVhdmUNCiBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDtJIHRoaW5rIHdlJ2xsIG5lZWQgdG8gdGhpbmsgY2FyZWZ1bGx5IGFib3V0IGZyYW1pbmcsIGJ1 dCBsZXQncyBkbyB0aGF0IG9uIHRoZSBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBqYW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpcnN0IEFjayBCbG9jayBMZW5ndGggKDgvMTYvMzIvNDgpJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBbR2FwIDEgKDgpXSZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtBY2sgQmxvY2sgMSBMZW5ndGggKDgvMTYvMzIv NDgpXSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgW0dhcCAy ICg4KV0mbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbQWNrIEJs b2NrIDIgTGVuZ3RoICg4LzE2LzMyLzQ4KV0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAuLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgW0dhcCBOICg4KV0mbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbQWNrIEJsb2NrIE4gTGVuZ3RoICg4LzE2 LzMyLzQ4KV0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8RUNFfEVDRXwu Li4gdmFyaWFibGUgbGVuZ3RoLCBwYWRkZWQgdG8gZnVsbCBvY3RldHMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBU aGUgRUNFIGZpZWxkIHJlcXVpcmVzIHR3byBiaXRzIGVuY29kaW5nIHBlcjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGZyYW1lLiZuYnNwOyBUaGUgYWRkaXRpb25hbCBvdmVyaGVhZCBhbW91bnRz IHRvIGNlaWwoTioyLzgpIG9jdGV0czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXJlIHRo ZSBOIGlzIHRoZSBzdW0gb2YgdGhlIEFDSyBibG9jayBsZW5ndGhzLiA8bzpwPg0KPC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgRnJvbTogR29ycnkgRmFpcmh1cnN0IFs8YSBocmVmPSJt YWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86Z29ycnlA ZXJnLmFiZG4uYWMudWs8L2E+XTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyBTZW50OiBkZW4gMjUgc2VwdGVtYmVyIDIwMTcgMTM6MzE8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgVG86 IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRp ay5lZS5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFuayI+bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRo ei5jaDwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IENjOiBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1 aXRlbWFAaHVpdGVtYS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9h PiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1 aWNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7IFN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAm IzQzOzE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7IERDVFAgaXMgbm90IElFVEYgc3RhbmRhcmQgLSBpdCdzIGRvY3VtZW50aW5nIGEgc29s dXRpb24gdGhhdCBpcyBkZXBsb3llZCBpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBkYXRhIGNlbnRyZXMgLSBhcyBpdCBzYXlzIC0gbXkg aG9wZSBpcyBRVUlDIHJlY2VpdmVzIHdpZGVyIGRlcGxveW1lbnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIHN1Z2dlc3QgeW91IHN0 YXJ0IGZyb20gQWNjRUNOLCBvciBleGFtaW5lIHRoZSBmZWVkYmFjayBkaXNjdXNzZWQgaW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgUk1D QVQgLSB3aGljaCBJIHRoaW5rIHN0cm92ZSBmb3IgZXF1aXZhbGVuY2UgdG8gdGhpcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEdvcnJ5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyBPbiAyNS8wOS8yMDE3LCAxMjoyNiwgTWlyamEgS8O8aGxld2luZCB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyBUaGVy ZSBpcyBBY2N1cmF0ZSBFQ04gKGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24pIGluIHRjcG0g dGhhdCBjaGFuZ2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IHRoZSBmZWVkYmFjayBkZWZpbmVkIGluIFJGQzMxNjggYmVjYXVzZSB3ZSBi ZWxpZXZlIG1vcmUgYWNjdXJhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgaW5mb3JtYXRpb24gaW4gbmVlZGVkIGluIGZ1dHVyZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyAmZ3Q7IE1pcmphPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7Jmd0OyBBbSAyMC4wOS4yMDE3IHVtIDIxOjAyIHNj aHJpZWIgQ2hyaXN0aWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7IEh1aXRlbWEmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVt YS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDs6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZndDsm Z3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZndDsmZ3Q7IE9uIDkvMjAvMjAxNyA5OjUxIEFNLCBJbmdl bWFyIEpvaGFuc3NvbiBTIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgRGV0YWlsZWQgaW5mbyBhYm91dCB3 aGljaCBwYWNrZXRzIGFyZSBFQ04gbWFya2VkIGNhbiBiZSB1c2VmdWwgYnV0IGFyZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBub3Qgc3Ry aWNrdGx5IG5lY2Vzc2FyeS4gT25lIGFsdGVybmF0aXZlLCB0aGF0IGlzIHByZXNlbnRlZCBpbiB0 aGUgRUNOLVFVSUM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgZHJhZnQgaXMgdG8gY291bnQgbnVtYmVyIG9mIG1hcmtlZCBieXRlcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0 OyZndDsmZ3Q7IFRoYXQgc2FpZCwgc29tZSBsaWtlIHRoZSBkZXRhaWxlZCBwYWNrZXQtbGV2ZWwg aW5mb3JtYXRpb24gdHlwZSBiZXR0ZXIuIEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgaGF2ZSBub3QgeWV0IGJlZW4gY29udmluY2VkIHRo YXQgdGhhdCB0aGlzIGxldmVsIG9mIGRldGFpbCBpcyBuZWNlc3NhcnkgdGhvdWdoLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7Jmd0 OyBUaGUgcHJvYmxlbSBpcyB3aGV0aGVyIHlvdSBjYW4gZGVmaW5lIGEgb25lIHNpemUgZml0IGFs bCBFQ048bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgJmd0OyZndDsgcHJvY2Vzc2luZywgdGhhdCBpZiBwb3NzaWJsZSBzaG91bGQgYmUgY29t cGF0aWJsZSB3aXRoIEFDSzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7Jmd0OyBjb21wcmVzc2lvbi4gVGhlcmUgYXJlIGF0IGxlYXN0 IHR3bzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDsgJmd0OyZndDsgKiBSRkMgMzE2OCBzYXlzLCBlY2hvIEVDTj0xIGlmIGF0 IGxlYXN0IG9uZSBvZiB0aGUgYWNrZWQgcGFja2V0cyBoYWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyZndDsgRUNOIHNldC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0 OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgJmd0OyZndDsgKiBkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMTAgc3VnZ2VzdHMgc2V0dGlu ZyBFQ04gc28gdGhhdCB0aGUgZnJhY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyZndDsgb2YgcGFja2V0IGFja2VkIHdpdGgg RUNOIGluIDFSVFQgaXMgdGhlIHNhbWUgYXMgdGhlIGZyYWN0aW9uIG9mPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZndDsmZ3Q7IHBhY2tl dHMgd2l0aCBFQ04gc2V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7Jmd0OyBTbywgd2hpY2ggb25lPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7Jmd0 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyAmZ3Q7Jmd0OyAtLUNocmlzdGlhbiBIdWl0ZW1hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB4PR07MB34831F4312F8880628C9C47C2790DB4PR07MB348eurprd_-- From nobody Thu Sep 28 22:55:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C023F134924 for ; Thu, 28 Sep 2017 22:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=VDOr3I04; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F7OgKF1x 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 Zl7e1sTkzQY0 for ; Thu, 28 Sep 2017 22:55:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688B1133078 for ; Thu, 28 Sep 2017 22:55:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A80C921A40; Fri, 29 Sep 2017 01:55:24 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 29 Sep 2017 01:55:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=n6fcJLtQ9yxEvWcVMImWnYLC9WeIONA7mMrRyipay kA=; b=VDOr3I04/xma3+TzviS6IAmCOH+McEBeJ/D7wPTyuCofF8MTCFisBJKmF N3SdGiqTpF5S0BoPzfM9maX4dsOsUs2DMykr/G7FwooQT78vLbnUYw9F+rgGKTUD Cvo6htjb+GimubtKfo6rsqIvqjS34+TQJME05rB55QAyV0n2T1IGSLE2ekIETl99 MtX9DRaquLYeG3BcLnsPjrcHOaC+AD7+HRzK4GBHgKNcuU9fmwVDdf5xKbLnSyGO 69LNiM158fwOIsVJvC31aQ2R42Id2GmqnRPULqC+0FZkDs6pzS7ACSR9uQAan6SL YwpIoBNnpKdfw5s6FJouYSYAvrZ8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=n6fcJLtQ9yxEvWcVMI mWnYLC9WeIONA7mMrRyipaykA=; b=F7OgKF1xiziGwNyxZfBUQLND6ZSlhb8vNq XZmmu4YMRxmQMY4/x6vIDtmcFukEedB9S/3vTnJMaTpCwBYQn9LjTWjFZWZqsurc X1+16coUTNWTy5EtBbQHPXODTMcntjdRF2ndPebGA0L9QO18Mw8QjiNEKz6n6y/R Kf72lZQHGpiuR+QuaDcvJjKgTfi4hIAI+NrQV3Q7tI0GhaANkftJ7EjBoco/r5yR sCpQ3k6j6h0lO8N/Apviwndsf6nRyweiQU9VWupJPDI6ar7JZuBCFqp2dA8K/MNu aK0AOkI06nwDZFSFoBMj9aHVzsFCIrjsh0RtdQzXWbQ8UqiGuRag== X-ME-Sender: X-Sasl-enc: Mln0RXWhxEXfR+dO86rScp9mDW79trEyyCuTCkiM55+F 1506664524 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id BABC6245A8; Fri, 29 Sep 2017 01:55:23 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Subject: Seattle Interim meeting - next week Message-Id: Date: Fri, 29 Sep 2017 15:55:18 +1000 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.1.6) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 05:55:28 -0000 We're looking forward to seeing many of you at the interim meeting next = week.=20 As stated before, Tuesday is an interop day, whereas Wednesday and = Thursday are the Working Group meeting. Meeting arrangements are available here: = https://github.com/quicwg/wg-materials/blob/master/interim-17-10/arrangeme= nts.md The agenda (subject to bashing) is here: = https://datatracker.ietf.org/meeting/interim-2017-quic-04/materials/agenda= -interim-2017-quic-04-sessa/ We'll upload the presentations that introduce the architectural issues = shortly. Please note that the room is at capacity; only those who have registered = may attend. If you registered for remote participation, you should have received = details from WebEx already; if not, please ping Lars and I privately. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Sep 29 04:26:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8E41344F1 for ; Fri, 29 Sep 2017 04:26:20 -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 autolearn_force=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 xH5DHAQhCMJm for ; Fri, 29 Sep 2017 04:26:16 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 2781F1344E8 for ; Fri, 29 Sep 2017 04:26:16 -0700 (PDT) Received: from [10.236.169.111] (unknown [148.252.129.147]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0377B1B00056 for ; Fri, 29 Sep 2017 12:26:15 +0100 (BST) From: "Gorry (erg)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Fri, 29 Sep 2017 12:23:58 +0100 Subject: Re: New Version Notification for draft-fairhurst-tsvwg-transport-encrypt-04.txt Message-Id: References: <150668328447.14229.13098365888682582505.idtracker@ietfa.amsl.com> In-Reply-To: <150668328447.14229.13098365888682582505.idtracker@ietfa.amsl.com> To: quic@ietf.org X-Mailer: iPhone Mail (14G60) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 11:26:20 -0000 I enclose a link to the new transport header encryption ID. We hope this pro= vides a useful input to the Quic-dt looking at tradeoffs. Many thanks to all who provided feedback on the last rev. I am particularly p= leased Colin Perkins has now joined me as a co-author. The restructuring and= updates should make this more accessible to readers -- all comments are wel= come via QUIC or TSVWG (on general transport issues) Best wishes Colin and Gorry > On 29 Sep 2017, at 12:08, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-fairhurst-tsvwg-transport-encrypt-04.txt > has been successfully submitted by Godred Fairhurst and posted to the > IETF repository. >=20 > Name: draft-fairhurst-tsvwg-transport-encrypt > Revision: 04 > Title: The Impact of Transport Header Encryption on Operation and E= volution of the Internet > Document date: 2017-09-27 > Group: Individual Submission > Pages: 27 > URL: https://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg= -transport-encrypt-04.txt > Status: https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-tra= nsport-encrypt/ > Htmlized: https://tools.ietf.org/html/draft-fairhurst-tsvwg-transpor= t-encrypt-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-fairhurst-tsvw= g-transport-encrypt-04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-fairhurst-tsvwg-= transport-encrypt-04 >=20 > Abstract: > This document describes implications of applying end-to-end > encryption at the transport layer. It identifies some in-network > uses of transport layer header information that can be used with a > transport header integrity check. It reviews the implication of > developing encrypted end-to-end transport protocols and examines the > implication of developing and deploying encrypted end-to-end > transport protocols. Since transport measurement and analysis of the > impact of network characteristics have been important to the design > of current transport protocols, it also considers some anticipated > implications on transport and application evolution. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat