" but we're not doing HTTP for the first implementation draft. We want to get into the habit of using ALPN, so I think we should define one. Perhaps "implementation-1"? -Ekr --001a114dd266213ec305535cf503 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The TLS draft implies (though I suppose one could argue) t= hat QUIC should

always negotiate ALPN. The HTTP draft specifies "h= q-<version>" but we're not

doing HTTP for the firs= t implementation draft.

We want to get into the ha= bit of using ALPN, so I think we should define one.

Perhaps "= ;implementation-1"?

-Ekr

--001a114dd266213ec305535cf503-- From nobody Mon Jul 3 02:33:44 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 0199E131550; Mon, 3 Jul 2017 02:33:43 -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-applicability-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149907442287.4885.414625010159334254@ietfa.amsl.com> Date: Mon, 03 Jul 2017 02:33:42 -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: Mon, 03 Jul 2017 09:33:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Applicability of the QUIC Transport Protocol Authors : Mirja Kuehlewind Brian Trammell Filename : draft-ietf-quic-applicability-00.txt Pages : 9 Date : 2017-07-03 Abstract: This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC, and implementors of these application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-applicability-00 https://datatracker.ietf.org/doc/html/draft-ietf-quic-applicability-00 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 Mon Jul 3 02:33:59 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 6A88713155C; Mon, 3 Jul 2017 02:33:54 -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-manageability-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149907443442.5002.14751279536269389577@ietfa.amsl.com> Date: Mon, 03 Jul 2017 02:33:54 -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: Mon, 03 Jul 2017 09:33:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Manageability of the QUIC Transport Protocol Authors : Mirja Kuehlewind Brian Trammell Dan Druta Filename : draft-ietf-quic-manageability-00.txt Pages : 12 Date : 2017-07-03 Abstract: This document discusses manageability of the QUIC transport protocol, focusing on caveats impacting network operations involving QUIC traffic. Its intended audience is network operators, as well as content providers that rely on the use of QUIC-aware middleboxes, e.g. for load balancing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-manageability-00 https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-00 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 Mon Jul 3 02:37: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 D84B7131555 for ; Mon, 3 Jul 2017 02:37:27 -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, 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 5msVSvFWbuhO for ; Mon, 3 Jul 2017 02:37:25 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A72131550 for ; Mon, 3 Jul 2017 02:37:24 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 653AD34081B for ; Mon, 3 Jul 2017 11:37:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.6813); Mon, 3 Jul 2017 11:37:23 +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 for ; Mon, 3 Jul 2017 11:37:23 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 22587773 for quic@ietf.org; Mon, 03 Jul 2017 11:37:23 +0200 From: Brian Trammell (IETF) X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_76F090A5-B3D3-4EA2-9E83-ADCEBA07D0DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Fwd: I-D Action: draft-ietf-quic-applicability-00.txt Date: Mon, 3 Jul 2017 11:37:22 +0200 References: <149907442287.4885.414625010159334254@ietfa.amsl.com> To: QUIC WG Message-Id: <921A4A11-1BD4-443C-991C-3055BA0F3EAF@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 9.3 $3124$) X-Mailer: Apple Mail (2.3124) 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, 03 Jul 2017 09:37:28 -0000 --Apple-Mail=_76F090A5-B3D3-4EA2-9E83-ADCEBA07D0DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've posted an initial WG version of the applicability draft. This = draft still has a couple of open issues and a few changes to track in = the -04 revisions of the base drafts, but we wanted to get a version out = to discuss before Prague. The manageability and applicability drafts have their own GitHub = repository, https://github.com/quicwg/ops-drafts. Issues on these drafts = can be filed at https://github.com/quicwg/ops-drafts/issues and/or = discussed on the quic@ietf.org mailing list. Thanks, cheers, Brian (for the editors of the ops drafts) > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-quic-applicability-00.txt > Date: 3 July 2017 at 11:33:42 GMT+2 > To: > Cc: quic@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the QUIC of the IETF. >=20 > Title : Applicability of the QUIC Transport Protocol > Authors : Mirja Kuehlewind > Brian Trammell > Filename : draft-ietf-quic-applicability-00.txt > Pages : 9 > Date : 2017-07-03 >=20 > Abstract: > This document discusses the applicability of the QUIC transport > protocol, focusing on caveats impacting application protocol > development and deployment over QUIC. Its intended audience is > designers of application protocol mappings to QUIC, and implementors > of these application protocols. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-quic-applicability-00 > https://datatracker.ietf.org/doc/html/draft-ietf-quic-applicability-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --Apple-Mail=_76F090A5-B3D3-4EA2-9E83-ADCEBA07D0DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZWhBSAAoJEIoSt78L6kajy/UP/RjeeZPA7uSrR9xvgVWrE660 E9Q7txHrhArUfM+j/OXpJD9tRfBQr/iuUlffkGjWFrmHeT+/oioOJ/osVbVl1zOk qPGOvc3Kw+VnjQyuKG7+kKe6iNA3YwcOwxW41uPj2oAdaUsOZY1MirxpNyXQnfPV JhAiyqjSRx5V8XywrniXP2UutPTpHJ/3C6Gl2HQtp8ICsTWhfnZmOIqPtfwMP1JI C/2kQNaCseXAQ33Td7maAjWg/uy082FkO5anbaeMyhdeW+F3hL6SxJP7lGkZ/ku+ YxCaDzgOfG6+9+4BTQFR5xEDALi5Lp8pNT7h+T/xu2Ioa6+5Es9Q1alNtjko+faj VF44cmMZvYifzD+dIDbSK5RUFpRp6WdiLW38HJFcabmUXYTMYAK6QeFL1hnUrC/+ 0tQVRXIUjVjj65epDDKeYxHSoKEOdioNOlXBl7RnMN2UZnLMAeBkpi1F3ZpBDf9i Nr4K4C5ZMfblqSnJl9GruEAkXsJVxPlgNd4sKfEXJiIMCsSH8RWOZtUwtfmmectx mhaK3VuoZnVbymwMl4l4YqNUKqQjjCSBRBkjZVQzZ+PINQEkEKpQdaYJ1IOpOkz/ fmsruoc7WgbzhTOggy6Gjoc7/Gv715ihfoikOu/dfa2j2nRWe9z7yx22EXI4szOL jI6cJCFM0qM7AToKnC6/ =RwEx -----END PGP SIGNATURE----- --Apple-Mail=_76F090A5-B3D3-4EA2-9E83-ADCEBA07D0DB-- From nobody Mon Jul 3 02:37: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 B4BDC131555 for ; Mon, 3 Jul 2017 02:37:57 -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, 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 J4acq-pdEzHb for ; Mon, 3 Jul 2017 02:37:55 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBE4131550 for ; Mon, 3 Jul 2017 02:37:55 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3BB62340D7C for ; Mon, 3 Jul 2017 11:37:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.6813); Mon, 3 Jul 2017 11:37:54 +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 for ; Mon, 3 Jul 2017 11:37:54 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 22587853 for quic@ietf.org; Mon, 03 Jul 2017 11:37:54 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_D8C1D25B-D9A2-4A9D-9E60-58AB3142B5D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Fwd: I-D Action: draft-ietf-quic-manageability-00.txt Date: Mon, 3 Jul 2017 11:37:53 +0200 References: <149907443442.5002.14751279536269389577@ietfa.amsl.com> To: QUIC WG Message-Id: <0ACDDC69-6549-4CF7-A018-BC52B8DD0859@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 9.3 $3124$) X-Mailer: Apple Mail (2.3124) 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, 03 Jul 2017 09:37:58 -0000 --Apple-Mail=_D8C1D25B-D9A2-4A9D-9E60-58AB3142B5D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Likewise, we've posted an initial WG version of the manageability draft. = As with applicability, this draft still has a couple of open issues and = a few changes to track in the -04 revisions of the base drafts, but we = wanted to get a version out to discuss before Prague. The manageability and applicability drafts have their own GitHub = repository, https://github.com/quicwg/ops-drafts. Issues on these drafts = can be filed at https://github.com/quicwg/ops-drafts/issues and/or = discussed on the quic@ietf.org mailing list. Thanks, cheers, Brian (for the editors of the ops drafts) > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-quic-manageability-00.txt > Date: 3 July 2017 at 11:33:54 GMT+2 > To: > Cc: quic@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the QUIC of the IETF. >=20 > Title : Manageability of the QUIC Transport Protocol > Authors : Mirja Kuehlewind > Brian Trammell > Dan Druta > Filename : draft-ietf-quic-manageability-00.txt > Pages : 12 > Date : 2017-07-03 >=20 > Abstract: > This document discusses manageability of the QUIC transport = protocol, > focusing on caveats impacting network operations involving QUIC > traffic. Its intended audience is network operators, as well as > content providers that rely on the use of QUIC-aware middleboxes, > e.g. for load balancing. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-quic-manageability-00 > https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --Apple-Mail=_D8C1D25B-D9A2-4A9D-9E60-58AB3142B5D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZWhByAAoJEIoSt78L6kajMjUQAJrsAoaYDtB6uUyEGQjEwfCG EzNsHJ92Y9QfChuOrYoCsE9gOCAiuotx21FGrVt3G+VhmyYCOkght3+0/CI+WhRM YMOEsIPpHaK1chBxqOFiGgPMwOOXgTN5Rkt7pWTlHQPFrK1xTKZN0URvQ5MVO3Ke Db2eDPrFPUNFUx3gLVdJ8mlqKj8UrdSnWWrQsdyruzjWFjsMRdu8a8g2SDzucBlF Z1uE4TtIqKL0k7Phd7T8sxdeZBKAlK+VGWCQU31dkuikb5LekoFj1Oln3eQyaFKS oj3dX0WfnhRrclGV+xKgo2XouERrQ3GbEG0dFuXoG+d9QJUfj7hL0VWIohmpxsjz kFHB5mzEMLGjGijmVJHkBFd/yvXSbrgOHAwILiXEkTJPGUt3j5S8J6F+cS9HfvE7 GpV2PB/dKboV+/NXXzhFpt9KUSMIixBNj669EcWkKaC99XBZRblgG/0y3vzTvrBY oguQzl2QO5v6HX1o+mf+l22o8TfTa8HsywAxxBD++bvzPNbvUgZIU0j2dl9shvwI 37YDVyxVDs9crTdloP6QwA9ytVrLxnjDmzAxoM9qEEuj/rFpvlFvDE+nqWbCerkF 4vGd9H1nnwW9g1Yezjl70rCjwhBsWmkt4vFeM1wA4NWDvO8x159SUACxBPstgrgL nrsfqlUBT1wFfnnuWesz =ycTs -----END PGP SIGNATURE----- --Apple-Mail=_D8C1D25B-D9A2-4A9D-9E60-58AB3142B5D4-- From nobody Mon Jul 3 06:07: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 5EBEE124D37; Mon, 3 Jul 2017 06:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8_7gZ9Ax4t8i; Mon, 3 Jul 2017 06:07:23 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA16129BA4; Mon, 3 Jul 2017 06:07:00 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id B0B08602DE; Mon, 3 Jul 2017 15:06:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 92D8616005E; Mon, 3 Jul 2017 15:06:59 +0200 (CEST) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0352.000; Mon, 3 Jul 2017 15:06:59 +0200 From: To: "quic@ietf.org" CC: "IETF IPPM WG (ippm@ietf.org)" Subject: TR: I-D Action: draft-stephan-quic-interdomain-troubleshooting-00.txt Thread-Topic: I-D Action: draft-stephan-quic-interdomain-troubleshooting-00.txt Thread-Index: AQHS8+Gnfganiwqd80yN+D/vXwRoVaJCDrpg Date: Mon, 3 Jul 2017 13:06:57 +0000 Message-ID: <29477_1499087219_595A4173_29477_477_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB919AC4538@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <149907533000.4990.3917157363711000733@ietfa.amsl.com> In-Reply-To: <149907533000.4990.3917157363711000733@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Mon, 03 Jul 2017 13:07:25 -0000 Hi, We posted a draft which discusses constraints that QUIC is pushing on netwo= rks performance measurements (troubleshooting, fallback, goodput, fairness.= ..).=20 Feedbacks are welcome. Abstract: On-path network performance measurements methods currently deployed contribute to the ossification of the Internet because they are expensive to deploy and to maintain. This draft motivates the exposure of QUIC header fields for on-path network measurements and their specification in the QUIC core protocol as a solution to avoid on-path network performance measurements to ossify the IP stack in the future. https://tools.ietf.org/html/draft-stephan-quic-interdomain-troubleshooting-= 00. Best Regards Emile -----Message d'origine----- De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de in= ternet-drafts@ietf.org Envoy=E9=A0: lundi 3 juillet 2017 11:49 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-stephan-quic-interdomain-troubleshooting-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : QUIC Interdomain Troubleshooting Authors : Emile Stephan Mathilde Cayla Arnaud Braud Fred Fieau Filename : draft-stephan-quic-interdomain-troubleshooting-00.txt Pages : 9 Date : 2017-07-03 Abstract: On-path network performance measurements methods currently deployed contribute to the ossification of the Internet because they are expensive to deploy and to maintain. This draft motivates the exposure of QUIC header fields for on-path network measurements and their specification in the QUIC core protocol as a solution to avoid on-path network performance measurements to ossify the IP stack in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-stephan-quic-interdomain-troubleshoo= ting/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-stephan-quic-interdomain-troubleshooting-= 00=20 https://datatracker.ietf.org/doc/html/draft-stephan-quic-interdomain-troubl= eshooting-00 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jul 4 06:13: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 B5A5C129B64 for ; Tue, 4 Jul 2017 06:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 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, T_KAM_HTML_FONT_INVALID=0.01] 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 Fzq89F9PpNrT for ; Tue, 4 Jul 2017 06:13:51 -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 248FB129B29 for ; Tue, 4 Jul 2017 06:13:50 -0700 (PDT) X-AuditID: c1b4fb30-703ff70000001664-a9-595b948d6faf Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 60.83.05732.D849B595; Tue, 4 Jul 2017 15:13:49 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 4 Jul 2017 15:13:48 +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=U5hu4J1gf/pmN7YYSAjACGNygN5WEe09YHCqHz9cS4w=; b=I7E77BLrNTWhMUJmQtHQbv7qd12QA4de5uCAfNv7gFSVLRgjmEFezpPkUIR2RLthK3FAIt8BIv67FzHMXu2YexV2Nv6xU5Df4oR7zo2useBd8Lk2dAcyqmn/FX0hs/JvoVizjy8BVZjKk2BOa2w/j83P9dz78/+1nZj1FUiGpRU= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB0639.eurprd07.prod.outlook.com (10.141.43.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 13:13:47 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ce9:7bec:5be9:91b5]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ce9:7bec:5be9:91b5%18]) with mapi id 15.01.1240.010; Tue, 4 Jul 2017 13:13:47 +0000 From: Ingemar Johansson S To: Bob Briscoe CC: QUIC IETF mailing list , Ingemar Johansson S Subject: RE: Quick review of ECN for QUIC: draft-johansson-quic-ecn-03 Thread-Topic: Quick review of ECN for QUIC: draft-johansson-quic-ecn-03 Thread-Index: AQHS7gsvdP/sazXU60Kiru14WhrlQ6JDZ3mw Date: Tue, 4 Jul 2017 13:13:46 +0000 Message-ID: References: <0062c1c4-254c-651f-c091-7f85fc1a28fa@bobbriscoe.net> In-Reply-To: <0062c1c4-254c-651f-c091-7f85fc1a28fa@bobbriscoe.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB0639; 7:ROCIv313LLYukoJeta5Tm4eyWhRQbUvqfDiw7XRkpmDr+aRt2M9Cluxj1SebntkVmrzHoevdVpjfxKz+QvfMnGGkR00NazUIC4mCsTMpNfRaiNInc6017jDmth4xCG9S4u+aFUsSkwv9WmbdeDuYeMa4z45hk/qRvkEikSQYU2UqzCQFYJe+VFZg44+xaqVmcvP9TNh3tpb0HdvF6cO6tsz62e+AkOl0gdqYGdSYCcuJbx4ivTghqel7DJPl+Oiia/c59bqrXUIVtowkVQ+yfC2cNBg7kKL2Afejy4kxedmeHUTsv4W1MM+HYB6Da5MYbIWq2yXl0MsBupjTUng8LY8o+c9EMHuGm51zu2xOSeeUDgsZEa819IMNGEnHBE6rZDamgnJhN65ZnRirOFgYRcFbD2Y/NKecAhFPYSOK5KbOeGE/lnV94zVfvfnUHoOG65Jp/PjwWvimi3iWQSJylKM44d08fUMzSVcUeLPwhKHNXk5du/eR5u2OkadABA971lcyBIOMZaGEpa5UDIEAraoYI2CtVyMwWddc5r9JR5PiZF1XGhfJ140YW3qHvcSCD3LQT46Y/r7xd3oaQktdM6KFGHaom2JkMelPX1TILsi3s52d05TKt4cU3sw+KhS3vFJrq2wveTlIEcdmTN9INe55bZfyWlqBrAQPxzZy+5QAM7Nc99Soz3KlXibJtRn4kC3YzjhfZVOP5UyOYaLtG2vOlN+6MjpFPZ6s5Y7SXBCfl8vI+q2zDtX3L0lC5zVT18KFPuXXiY13GunnP502eyoWwuH/DomH8AB4GycvXRc= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39400400002)(39410400002)(39860400002)(39850400002)(39840400002)(39450400003)(51914003)(24454002)(76176999)(50986999)(54356999)(9326002)(3280700002)(6506006)(53546010)(5660300001)(6436002)(2900100001)(2906002)(6916009)(2950100002)(7696004)(4326008)(230783001)(5250100002)(86362001)(66066001)(229853002)(74316002)(966005)(81166006)(8936002)(6116002)(8676002)(790700001)(102836003)(14454004)(6246003)(3846002)(107886003)(53376002)(606006)(33656002)(110136004)(38730400002)(478600001)(99286003)(55016002)(25786009)(54906002)(3660700001)(7736002)(6306002)(54896002)(53936002)(189998001)(236005)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0639; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 04ab5468-3208-4c29-0125-08d4c2de8119 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB0639; x-ms-traffictypediagnostic: DB4PR07MB0639: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(37575265505322)(133145235818549)(26388249023172)(236129657087228)(48057245064654)(148574349560750)(21748063052155)(167848164394848)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB0639; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB0639; x-forefront-prvs: 0358535363 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348EFBE3B5A9F023AAAD12BC2D70DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 13:13:46.8322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0639 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURTAud9jfluNrnPmwZR0KJjga/iH1CiVLCECwQidf+TMz0fqlM1E i0gRS3yAxoJciUONmFDaMhJLpaHZzBcTMQSbtpGaCb5tvmjbt8D/fuec3733nMNlSJGe9mVy lcWsSqnIl/AEVFPKh0th9Zq01Mh1i2/M0IKOjqnTnYglEn9bJunE9nY7kUTIBbJMNj+3hFVF XEwX5IyWP6OLxg9RqXXhOVWO/u6gGsRnAEdDxccuBwsYER5E0PdI7w6GEVSv2VwWhetJKK+h uMJTAvr2DO5gHsHU0abL4mEZ6I27DmYYMQ4G/eMgJ5I4EzTL952GF74CY0MbLluMr0LlrI3m WArVfS89uLeCwD6zRDhZiOVgGP9KOlmE42Cz285zXsnH8TDQXORMI+wPlt0flJNJ7AOzthaC GwxD+6cJkmNvWLYe0c6OEW5yDDnwxtUl4ACon5Jzjj+YW2pdswOe58FE3wbNBXU82LGvUZx1 HQbmtARX+EnAYM8+jyuEws7rLreUB8vTw25pEkHbl2b3vUYaDHtW9wk/GH3fSDagUO2x3jku hKGJCqR1rcATTE02Suva5Dno7I3glEDQ1C54cBwCVS+aPY7ndcijA3mrWXVGQbZUGs6qcm+r 1YXKcCVbbECOD/S5ez+yBy0vxhkRZpDkpPDbw7RUEa0oUZcVGBEwpEQsbK51pISZirJ7rKrw lupuPqs2ojMMJfERxvVPpohwtqKYzWPZIlb1v0owfN9yJI38LhuoClFMF1tvZowEHs69C/BK 77dcjuLdCbaYk8bObg2KYjW9B69kWTULgVvtKyOm2KyoaHnCfIO4NestX3yzNaHR09SZLC39 NSvXeKWuXtMfLLUYeNuL609SH/jLVzu2deFt5zvJ02ZF5UpyWH/8BZvJ/OfUHhvgd2NmRUKp cxRRoaRKrfgHss7tGTwDAAA= 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, 04 Jul 2017 13:13:55 -0000 --_000_DB4PR07MB348EFBE3B5A9F023AAAD12BC2D70DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNClRoYW5rcyBmb3IgdGhlIHJldmlldyAsIGNvbW1lbnRzIGlubGluZQ0KDQovSW5nZW1hcg0K DQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBk ZW4gMjYganVuaSAyMDE3IDAxOjMxDQpUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5z LmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQpDYzogUVVJQyBJRVRGIG1haWxpbmcgbGlzdCA8cXVp Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFF1aWNrIHJldmlldyBvZiBFQ04gZm9yIFFVSUM6IGRyYWZ0 LWpvaGFuc3Nvbi1xdWljLWVjbi0wMw0KDQpJbmdlbWFyLA0KDQpBcyBqdXN0IHByb21pc2VkIChv biB0Y3BtIC0gcGFzdGVkIGJlbG93KSBoZXJlJ3MgYSBydXNoZWQgd3JpdGUtdXAgb2YgdGhlIGhp Z2ggb3JkZXIgYml0cyBvZiBteSByZXZpZXcgb2YgeW91ciBkcmFmdC1qb2hhbnNzb24tcXVpYy1l Y24tMDMuDQpUaGlzIGlzIHB1cmVseSBhIGxpc3Qgb2YgbXkgaW1tZWRpYXRlIHJlYWN0aW9ucyB0 byBzZW50ZW5jZXMgaW4gdGhlIGRyYWZ0LiBJIHdpbGwgbmVlZCBsb25nZXIgdG8gdGhpbmsgYWJv dXQgdGhlIHByb3RvY29sIGFzIGEgd2hvbGUsIHdoZXRoZXIgdGhpcyBpcyB0aGUgYmVzdCBhcHBy b2FjaCwgd2hldGhlciB0aGVyZSBtaWdodCBiZSBhIGJldHRlciBhcHByb2FjaCwgYW5kIHRoZSBv cGVuIGlzc3VlcyB5b3UgbGlzdC4NCg0KMi4xDQpJdCB3b3VsZCBiZSB1c2VmdWwgdG8gZmlyc3Qg ZGVzY3JpYmUgaG93IHRoZSBwcm90b2NvbCB3b3VsZCB3b3JrIGFjcm9zcyBhIG5ldHdvcmsgd2l0 aG91dCBCeXphbnRpbmUgbWlkZGxlYm94IGJlaGF2aW91ciBhbmQgd2l0aG91dCBob2JibGVkIG9w ZXJhdGluZyBzeXN0ZW1zIHRoYXQgY2Fubm90IGFjY2VzcyB0aGUgRUNOIGZpZWxkIG9mIElQIHBh Y2tldHMuIFRoZW4gc2VwYXJhdGVseSBkZXNjcmliZSBmYWxsLWJhY2sgaW4gdGhlIGZhY2Ugb2Yg dmFyaW91cyBFQ04gZmFpbHVyZXMgc2VwYXJhdGVseS4NCltJSl0gT0sNCg0KDQpQcmVmZXJhYmx5 LCBsZXQncyB0cnkgdG8gdGhpbmsgb2YgYSB3YXkgdG8gc3VwcG9ydCBFQ04gb24gdGhlIHZlcnkg Zmlyc3QgUVVJQyBjb25uZWN0aW9uIHNldHVwIGRhdGFncmFtcyAoc2VlIGNvbW1lbnRzIHBhc3Rl ZCBiZWxvdyBhYm91dCBjb3B5aW5nIHRoZSB0ZWNobmlxdWVzIGluIGRyYWZ0LWJhZ251bG8tdGNw bS1nZW5lcmFsaXplZC1lY24sIHdoaWNoIGRlcGVuZHMgb24gZHJhZnQtaWV0Zi10Y3BtLWFjY3Vy YXRlLWVjbiBmb3IgdGhpcyBjYXBhYmlsaXR5KS4NCltJSl0gWWVzLCB0aGF0IGNhbiBiZSBhIGdv b2QgaWRlYS4gVGhlIG9yaWdpbmFsIGludGVudGlvbiB3YXMgdG8gYmUgY29uc2VydmF0aXZlIGFu ZCBhdm9pZCB0aGF0IEVDTiBuZWdvdGlhdGlvbiBpbiBRVUlDIOKAnGJsYWNrLWhvbGVz4oCdIHRo ZSBjb25uZWN0aW9uIHNldHVwLiBCdXQgZ2l2ZW4gdGhlIGRpc2N1c3Npb24gYXJvdW5kIGRyYWZ0 LWJhZ251bG8tdGNwbS1nZW5lcmFsaXplZC1lY24gaXQgaXMgcXVpdGUgcG9zc2libGUgdGhhdCBv bmUgY2FuIGRvIEVDTiBuZWdvdGlhdGlvbiBhbHJlYWR5IGF0IHNldHVwLg0KDQoNCkluIGEgc2lt aWxhciB2ZWluLCB5b3UgbWlnaHQgd2FudCB0byBsb29rIGF0IChhbmQgZXZlbiBjaXRlKSBSRkM3 ODYwIGZvciByZXF1aXJlbWVudHMgYWJvdXQgRUNOIGZlZWRiYWNrIChpdCB3YXMgc3BlY2lmaWNh bGx5IGFib3V0IFRDUCwgYnV0IHRoZXJlIGlzIHN0dWZmIHRoZXJlIHJlbGV2YW50IHRvIFFVSUMg dG9vKS4NCltJSl0gSG1tLCBkbyB5b3UgbWVhbiBzb21lIG90aGVyIFJGQyA/DQoNCg0KMi4xLjEN ClRoZSBhcmd1bWVudCBmb3Igc2VuZGluZyBhbiBFQ04gbmVnb3RpYXRpb24gZnJhbWUgaW4gYSBw YWNrZXQgb24gaXRzIG93biBvbmx5IG9ubHkgbWFrZXMgc2Vuc2UgaWYgbG9zcyBpcyBtb3JlIGxp a2VseSBmb3IgcGFja2V0cyB3aXRoIGEgbm9uLXplcm8gSVAtRUNOIGZpZWxkLiBUaGVyZWZvcmUs IHRoaXMgc2hvdWxkIG5vdCBuZWNlc3NhcmlseSBiZSBhIGxvbmctdGVybSByZXF1aXJlbWVudCBv biB0aGUgcHJvdG9jb2wuDQpbSUpdIEFncmVlLCB3cm90ZSB1cCBwcmVzZW50YXRpb24gc2xpZGVz IGZvciB0aGUgUVVJQyBpbnRlcmltIChkaWQgbm90IGdldCBhaXIgdGltZSB0aGVuIHRvIHByZXNl bnQgaXQpLiBPbmUgcXVlc3Rpb24gd2FzIGFjdHVhbGx5IGlmIG9uZSBzaG91bGQgbW92ZSBFQ04g bmVnb3RpYXRpb24gdG8gdGhlIFFVSUMgY29ubmVjdGlvbiBzZXR1cC4NCg0KV2h5IGFsd2F5cyB1 c2UgQ0UgdG8gdGVzdCB0cmF2ZXJzYWwgb2YgdGhlIElQLUVDTiBmaWVsZD8gU2V0dGluZyB0aGUg RUNUIGNvZGVwb2ludCB0aGF0IHdpbGwgYmUgdXNlZCB0aHJvdWdob3V0IHRoZSBjb25uZWN0aW9u IGFsc28gdGVzdHMgZm9yIHplcm9pbmcgdGhlIEVDTiBmaWVsZCwgd2l0aG91dCByaXNraW5nIGxv c2luZyB2aXNpYmlsaXR5IG9mIGEgQ0UgbWFya2luZyBpbnRyb2R1Y2VkIGluIHRoZSBuZXR3b3Jr Lg0KW0lKXSBBZG1pdCwgdGhhdCBJIHNlbGVjdGVkIENFIGZvciBsYWNrIG9mIGJldHRlciBrbm93 bGVkZ2UsIEVDVCgwKSBvciBFQ1QoMSkgKGRlcGVuZGluZyBvbiBFQ04gZXhwZXJpbWVudGFsIHVz ZSkgbWF5IGJlIGJldHRlci4NCg0KDQpEZWZpbmUgImEgZmFpbGVkIGNoYWxsZW5nZS9yZXNwb25z ZSBwaGFzZSIuIENhbid0IGl0IGZhaWwgZm9yIGEgaGFsZi1jb25uZWN0aW9uLCBub3QgbmVjZXNz YXJpbHkgZm9yIHRoZSB3aG9sZSBjb25uZWN0aW9uPw0KW0lKXSBJbiBzb21lIGNhc2VzIGEgY2hh bGxlbmdlIHJlcG9uc2UgY2FuIGZhaWwgZm9yIG9uZSBoYWxmLWNvbm5lY3Rpb24sIHN0aWxsIGl0 IHNob3VsZCBiZSBwb3NzaWJsZSB0byAgdXNlIEVDTiBpbiBvbmUgZGF0YSBkaXJlY3Rpb24uIFRo aXMgbmVlZHMgc29tZSBleHRyYSBjb25zaWRlcmF0aW9uIGFuZCBjbGFyaWZpY2F0aW9uLg0KDQoN CjIuMS4yDQpUaGUgbW9kZSBtZWNoYW5pc20gb2YgUkZDNjY3OSBuZWVkcyB0byBiZSBkZXNjcmli ZWQsIG5vdCBqdXN0IHJlZmVyZW5jZWQuIE5vdGUgdGhhdCBkcmFmdC1pZXRmLXRzdndnLWVjbi1l eHBlcmltZW50YXRpb24gaW50ZW5kcyB0byB1cGRhdGUgUkZDNjY3OSBpbiB0aGlzIHJlc3BlY3Qg KHJlbW92aW5nIHRoZSB1c2Ugb2YgdGhlIEVDTiBub25jZSkuDQpbSUpdIFllcywgYWRkZWQgdGhp cyB3aXRob3V0IHRoaW5raW5nLCBtb3JlIHdvcmsgaXMgbmVlZGVkLg0KDQoNCjIuMw0KTml0OiBZ b3UgYXNzaWduIHRoZSBuYW1lcyBFMSBhbmQgRTIgZm9yIHRoZSBmaWVsZHMgZm9yIHRoZSBsZW5n dGggb2YgZWFjaCBlbmNvZGluZyBvZiBFQ1QoMCkgYW5kIEVDVCgxKS4gSXQgd291bGQgYmUgbGVz cyBpbGxvZ2ljYWwgaWYgdGhleSB3ZXJlIGNhbGxlZCBFMCBhbmQgRTEuDQpbSUpdIFllcywgeW91 IGFyZSByaWdodCA6LSksIHdpbGwgY29ycmVjdCB0aGlzLg0KDQpUaGUgZmVlZGJhY2sgZ2l2ZXMg dGhlIG51bWJlciBvZiBtYXJrZWQgYnl0ZXMuIEl0IG5lZWRzIHRvIHNwZWNpZnkgd2hpY2ggaGVh ZGVycyBhcmUgKG5vdCkgaW5jbHVkZWQgaW4gdGhlIGJ5dGUgY291bnQuIEFuZCBpZiBhIGRhdGFn cmFtIHdpdGggemVybyBieXRlcyBpcyBFQ04tbWFya2VkLCBob3cgZG8geW91IHByb3Bvc2UgdG8g ZmVlZCB0aGF0IGJhY2sgKGluIEFjY0VDTiBpdCBmZWVkcyBiYWNrIG1hcmtlZCBwYWNrZXRzIGFu ZCBtYXJrZWQgYnl0ZXMpPw0KW0lKXSBZZXMsIHRoaXMgaXMgbm90IGNsZWFyLCB0aGUgc2FtZSBh bWJpZ3VpdHkgaXMgYWxzbyBpbiBkcmFmdC1pZXRmLXF1aWMtcmVjb3ZlcnktMDQgYXMgc2VudF9i eXRlcyBpcyBub3QgZXhwbGFpbmVkLg0KDQoNCg0KSXQgc2F5cyAxIG9jdGV0IG92ZXJoZWFkIGlm IEVDTiBpcyBub3Qgc3VwcG9ydGVkLiBDYW4ndCB0aGUgZW5kcyBzZW5kIG5vIEVDTiBmZWVkYmFj ayBhdCBhbGwgaWYgdGhleSBoYXZlIGRpc2FibGVkIEVDTiBkdXJpbmcgdGhlIGNoYWxsZW5nZSBy ZXNwb25zZT8NCltJSl0gWWVzIGl0IGlzIGEgcG9zc2liaWxpdHkgdG8gaW5jbHVkZSB0aGUgRUNO IGJ5dGUgY291bnQgZXZlbiBpZiBFQ04gaXMgbm90IHN1cHBvcnRlZCBhcyB0aGUgZm9ybWF0IGlz IHNlbGYtY29udGFpbmVkLCB0aGlzIHNob3VsZCBiZSBjbGFyaWZpZWQuDQoNCg0KMi40DQpJdCBz dWdnZXN0cyB1c2luZyBhIGdpdmVuIHBhdHRlcm4gdG8gZGV0ZWN0IHRoZSBuZWVkIGZvciBmYWxs LWJhY2suIFRoYXQncyBhIGdvb2QgaWRlYS4gSSB0aGluayBhbnkgcGFydGljdWxhciBjb25uZWN0 aW9uIHNob3VsZCBvbmx5IG5lZWQgdG8gaW5jbHVkZSB0d28gSVAtRUNOIGNvZGVwb2ludHMgaW4g dGhlIHBhdHRlcm46IHRoZSByZWxldmFudCBFQ1QgY29kZXBvaW50IGFuZCBDRS4NCg0KWW91IG1p Z2h0IGFsc28gd2FudCB0byBsb29rIGF0IHRoaXMgZXhwaXJlZCBJLUQ6IGRyYWZ0LW1vbmNhc3Rl ci10Y3BtLXJjdi1jaGVhdCB3aGljaCB1c2VzIENFIHJhbmRvbWx5IHRvIHZlcmlmeSB0aGF0IHRo ZSByZWNlaXZlciBmZWVkYmFjayBpcyBub3QgY2hlYXRpbmcuIFlvdSBtaWdodCBiZSBhYmxlIHRv IGludGVncmF0ZSB0aGF0IGludG8gdGhlIHBhdGggdHJhdmVyc2FsIHRlc3RpbmcsIGFsdGhvdWdo IEkgYWNjZXB0IHRoYXQgYSBkZXRlcm1pbmlzdGljIHBhdHRlcm4gYWxsb3dzIHRoZSByZW1vdGUg cGVlciB0byBkZXRlY3QgcHJvYmxlbXMsIHdoZXJlYXMgYSByYW5kb20gb25lIGRvZXNuJ3QuDQoN Ckl0IHN1Z2dlc3RzIGEgZ2VuZXJpYyBFQ04gZmFsbC1iYWNrIGRyYWZ0LiBJdCBpcyBoYXJkIHRv IGRlc2NyaWJlIGZhbGwtYmFjayBpbmRlcGVuZGVudCBvZiBhbnkgc3BlY2lmaWMgcHJvdG9jb2wu DQpbSUpdIFRoYW5rcywgdGhpcyBzZWN0aW9uIG5lZWRzIG1vcmUgd29yay4NCg0KDQoyLjYNCk5p dDogcy9yZW1hcmsvcmUtbWFyay8gYmVjYXVzZSByZW1hcmsgbWVhbnMgc29tZXRoaW5nIGRpZmZl cmVudC4NCltJSl0gT0sNCg0KDQoNCkEgY291cGxlIG9mIG1vbnRocyBhZ28sIHdlIHdlcmUgZGlz Y3Vzc2luZyB1c2luZyB0aW1lc3RhbXBzIG9uIGZlZWRiYWNrLCBzbyB0aGF0IGZld2VyIEFDS3Mg Y291bGQgYmUgc2VudCB3aXRob3V0IGxvc2luZyB0aW1pbmcgaW5mby4gQXJlIHlvdSBwbGFubmlu ZyB0byBpbmNsdWRlIHRoYXQgaWRlYSBpbiB0aGlzIGRyYWZ0Pw0KW0lKXSBTdXBwb3J0IGZvciBk ZXRhaWxlZCB0aW1zdGFtcHMgaXMgYWxyZWFkeSBhdmFpbGFibGUgaW4gdGhlIFFVSUMgcHJvdG9j b2wgQUNLcw0KDQoNClRoYXQncyBpdCBmb3Igbm93Lg0KDQoNCg0KQm9iDQoNCg0KLS0tLS0tLS0g Rm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNClJlOiBSZSA6IFdvcmtpbmcg Z3JvdXAgYWNjZXB0YW5jZSBjYWxsIGRyYWZ0LWJhZ251bG8tdGNwbS1nZW5lcmFsaXplZC1lY24t MDQNCg0KRGF0ZToNCg0KU3VuLCAyNSBKdW4gMjAxNyAyMzoxNzo0MiArMDEwMA0KDQpGcm9tOg0K DQpCb2IgQnJpc2NvZSA8aWV0ZkBib2JicmlzY29lLm5ldD48bWFpbHRvOmlldGZAYm9iYnJpc2Nv ZS5uZXQ+DQoNClRvOg0KDQpJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29u QGVyaWNzc29uLmNvbT48bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPiwg dGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4gPHRjcG1AaWV0Zi5vcmc+PG1haWx0 bzp0Y3BtQGlldGYub3JnPg0KDQpDQzoNCg0KdGNwbS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRj cG0tY2hhaXJzQGlldGYub3JnPiA8dGNwbS1jaGFpcnNAaWV0Zi5vcmc+PG1haWx0bzp0Y3BtLWNo YWlyc0BpZXRmLm9yZz4sIG1hcmNlbG8gYmFnbnVsbyBicmF1biA8bWFyY2Vsb0BpdC51YzNtLmVz PjxtYWlsdG86bWFyY2Vsb0BpdC51YzNtLmVzPg0KDQoNCg0KSW5nZW1hciwNCg0KDQoNClRoZSBk cmFmdCBhbHJlYWR5IHNheXMgdGhpcyB3b3JrIHNob3VsIGJlIHRyYW5zZmVyYWJsZSB0byBTQ1RQ LiBJIG1pZ2h0DQoNCmFsc28gYWRkIGEgbm90ZSB0aGF0IGl0IGNvdWxkIGFsc28gYmVuZWZpdCBR VUlDLCBhbHRobyBJJ2QgbGlrZSB0byBzZWUNCg0Kc29tZSBkZXRhaWwgYmVmb3JlIHByZXN1bWlu ZyB0aGlzIHdpbGwgd29yay4NCg0KDQoNCkNvaW5jaWRlbnRhbGx5LCBJIGp1c3QgcmVhZCB5b3Vy IEVDTiBpbiBRVUlDIGRyYWZ0IHllc3RlcmRheS4gQW5kLCBhbHNvDQoNCmNvaW5jaWRlbnRhbGx5 LCBvbmUgb2YgbXkgbWFpbiBjb21tZW50cyB3YXMgZ29pbmcgdG8gYmUgdGhhdCBpdCBzZWVtcw0K DQpkaXNhcHBvaW50aW5nIHRoYXQgaXQgb25seSAic2VuZHMgYW4gRUNOIG5lZ290aWF0aW9uIGZy YW1lIHdoZW4NCg0KY29ubmVjdGlvbiBzZXR1cCBpcyBjb21wbGV0ZWQuIiBSZXRyYW5zbWlzc2lv biB0aW1lb3V0cyBoYXZlIHRvIGJlDQoNCmNvbnNlcnZhdGl2ZSBkdXJpbmcgY29ubmVjdGlvbiBz ZXQtdXAgd2hhdGV2ZXIgdGhlIHByb3RvY29sLiBTbyB0aGUNCg0KYmFja2dyb3VuZCBsZXZlbCBv ZiBjb25nZXN0aW9uIGxvc3Mgd2lsbCB0aGVuIGxlYWQgdG8gdW5uZWNlc3NhcmlseQ0KDQpwcm90 cmFjdGVkIGludGVybWl0dGVudCBkZWxheXMsIHdoaWNoIHdpbGwgcGFydGljdWxhcmx5IGhpdCBz aG9ydCBRVUlDDQoNCmZsb3dzLiBTbyBJIHdhcyBnb2luZyB0byBzdWdnZXN0IHRoYXQgeW91IG1p Z2h0IGJlIGFibGUgdG8gcHJvdGVjdCBRVUlDDQoNCmNvbm5lY3Rpb24gc2V0dXAgZnJvbSByYW5k b20gY29uZ2VzdGlvbiBsb3NzIGJ5IGFuIGFwcHJvYWNoIHNpbWlsYXIgdG8NCg0KRUNOKysuDQoN Cg0KDQoNCg0KSSBjYW5ub3QgZ3VhcmFudGVlIHRoYXQgSSB3aWxsIGhhdmUgdGltZSB0byB3cml0 ZSB1cCB0aGUgb3RoZXIgY29tbWVudHMNCg0KZnJvbSBteSByZXZpZXcgaW4gdGltZSBmb3IgeW91 IHRvIHVzZSBpdCBiZWZvcmUgdGhlIElFVEYgZGVhZGxpbmUgKEkgYW0NCg0KYWJvdXQgdG8gdGFr ZSBhIHdlZWsgb2ZmLCByZXR1cm5pbmcgb24gMyBKdWwpLiBCdXQgSSB3aWxsIHRyeSB0byBkbyBh DQoNCnF1aWNrIHN1bW1hcnkgZm9yIHRoZSBRVUlDIGxpc3Qgbm93Lg0KDQoNCg0KDQoNCg0KDQpC b2INCg0KDQoNCk9uIDI1LzA2LzE3IDE5OjAzLCBJbmdlbWFyIEpvaGFuc3NvbiBTIHdyb3RlOg0K DQo+IEhpDQoNCj4NCg0KPiBJIHN1cHBvcnQgdGhpcyB3b3JrLg0KDQo+IEluIGFkZGl0aW9uLCBw YXJ0cyBvZiB0aGUgZmluZGluZ3MgYW5kIHJlY29tbWVuZGF0aW9ucyBpbiB0aGlzIFRDUCBnZW5l cmFsaXplZCBFQ04gd29yayBtYXkgYWxzbyBiZSB1c2VmdWwgZm9yIHRoZSBzcGVjaWZpY2F0aW9u IG9mIHRoZSBFQ04gc3VwcG9ydCBpbiBRVUlDLCBjdXJyZW50bHkgb3V0bGluZWQgaW4gKGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAzLnR4dCApLg0K DQo+DQoNCj4gUmVnYXJkcw0KDQo+IEluZ2VtYXIgSm9oYW5zc29uDQoNCj4NCg0KDQoNCi0tDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0 cDovL2JvYmJyaXNjb2UubmV0Lw0K --_000_DB4PR07MB348EFBE3B5A9F023AAAD12BC2D70DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+VGhhbmtz IGZvciB0aGUgcmV2aWV3ICwgY29tbWVudHMgaW5saW5lPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij4vSW5nZW1hcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQo8YnI+ DQo8Yj5TZW50OjwvYj4gZGVuIDI2IGp1bmkgMjAxNyAwMTozMTxicj4NCjxiPlRvOjwvYj4gSW5n ZW1hciBKb2hhbnNzb24gUyAmbHQ7aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBRVUlDIElFVEYgbWFpbGluZyBsaXN0ICZsdDtxdWljQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBRdWljayByZXZpZXcgb2YgRUNOIGZvciBRVUlDOiBk cmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbmdlbWFyLDxicj4NCjxicj4NCkFzIGp1c3QgcHJvbWlzZWQgKG9u IHRjcG0gLSBwYXN0ZWQgYmVsb3cpIGhlcmUncyBhIHJ1c2hlZCB3cml0ZS11cCBvZiB0aGUgaGln aCBvcmRlciBiaXRzIG9mIG15IHJldmlldyBvZiB5b3VyIGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVj bi0wMy48YnI+DQpUaGlzIGlzIHB1cmVseSBhIGxpc3Qgb2YgbXkgaW1tZWRpYXRlIHJlYWN0aW9u cyB0byBzZW50ZW5jZXMgaW4gdGhlIGRyYWZ0LiBJIHdpbGwgbmVlZCBsb25nZXIgdG8gdGhpbmsg YWJvdXQgdGhlIHByb3RvY29sIGFzIGEgd2hvbGUsIHdoZXRoZXIgdGhpcyBpcyB0aGUgYmVzdCBh cHByb2FjaCwgd2hldGhlciB0aGVyZSBtaWdodCBiZSBhIGJldHRlciBhcHByb2FjaCwgYW5kIHRo ZSBvcGVuIGlzc3VlcyB5b3UgbGlzdC48YnI+DQo8YnI+DQoyLjE8YnI+DQpJdCB3b3VsZCBiZSB1 c2VmdWwgdG8gZmlyc3QgZGVzY3JpYmUgaG93IHRoZSBwcm90b2NvbCB3b3VsZCB3b3JrIGFjcm9z cyBhIG5ldHdvcmsgd2l0aG91dCBCeXphbnRpbmUgbWlkZGxlYm94IGJlaGF2aW91ciBhbmQgd2l0 aG91dCBob2JibGVkIG9wZXJhdGluZyBzeXN0ZW1zIHRoYXQgY2Fubm90IGFjY2VzcyB0aGUgRUNO IGZpZWxkIG9mIElQIHBhY2tldHMuIFRoZW4gc2VwYXJhdGVseSBkZXNjcmliZSBmYWxsLWJhY2sg aW4gdGhlIGZhY2Ugb2YgdmFyaW91cw0KIEVDTiBmYWlsdXJlcyBzZXBhcmF0ZWx5LjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+W0lKXSBPSzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NClByZWZlcmFi bHksIGxldCdzIHRyeSB0byB0aGluayBvZiBhIHdheSB0byBzdXBwb3J0IEVDTiBvbiB0aGUgdmVy eSBmaXJzdCBRVUlDIGNvbm5lY3Rpb24gc2V0dXAgZGF0YWdyYW1zIChzZWUgY29tbWVudHMgcGFz dGVkIGJlbG93IGFib3V0IGNvcHlpbmcgdGhlIHRlY2huaXF1ZXMgaW4gZHJhZnQtYmFnbnVsby10 Y3BtLWdlbmVyYWxpemVkLWVjbiwgd2hpY2ggZGVwZW5kcyBvbiBkcmFmdC1pZXRmLXRjcG0tYWNj dXJhdGUtZWNuIGZvciB0aGlzIGNhcGFiaWxpdHkpLjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+W0lKXSBZZXMsIHRoYXQgY2FuIGJlIGEgZ29vZCBpZGVh LiBUaGUgb3JpZ2luYWwgaW50ZW50aW9uIHdhcyB0byBiZSBjb25zZXJ2YXRpdmUgYW5kIGF2b2lk IHRoYXQgRUNOIG5lZ290aWF0aW9uIGluIFFVSUMg4oCcYmxhY2staG9sZXPigJ0gdGhlIGNvbm5l Y3Rpb24gc2V0dXAuIEJ1dCBnaXZlbiB0aGUgZGlzY3Vzc2lvbiBhcm91bmQNCjwvc3Bhbj5kcmFm dC1iYWdudWxvLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuIGl0IGlzIHF1aXRlIHBvc3NpYmxlIHRoYXQg b25lIGNhbiBkbyBFQ04gbmVnb3RpYXRpb24gYWxyZWFkeSBhdCBzZXR1cC48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KSW4gYSBzaW1pbGFyIHZlaW4sIHlvdSBtaWdodCB3YW50IHRvIGxv b2sgYXQgKGFuZCBldmVuIGNpdGUpIFJGQzc4NjAgZm9yIHJlcXVpcmVtZW50cyBhYm91dCBFQ04g ZmVlZGJhY2sgKGl0IHdhcyBzcGVjaWZpY2FsbHkgYWJvdXQgVENQLCBidXQgdGhlcmUgaXMgc3R1 ZmYgdGhlcmUgcmVsZXZhbnQgdG8gUVVJQyB0b28pLjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+W0lKXSBIbW0sIGRvIHlvdSBtZWFuIHNvbWUgb3RoZXIg UkZDID8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjIuMS4xPGJyPg0KVGhlIGFyZ3VtZW50IGZvciBzZW5kaW5nIGFuIEVDTiBuZWdvdGlh dGlvbiBmcmFtZSBpbiBhIHBhY2tldCBvbiBpdHMgb3duIG9ubHkgb25seSBtYWtlcyBzZW5zZSBp ZiBsb3NzIGlzIG1vcmUgbGlrZWx5IGZvciBwYWNrZXRzIHdpdGggYSBub24temVybyBJUC1FQ04g ZmllbGQuIFRoZXJlZm9yZSwgdGhpcyBzaG91bGQgbm90IG5lY2Vzc2FyaWx5IGJlIGEgbG9uZy10 ZXJtIHJlcXVpcmVtZW50IG9uIHRoZSBwcm90b2NvbC48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPltJSl0gQWdyZWUsIHdyb3RlIHVwIHByZXNlbnRhdGlv biBzbGlkZXMgZm9yIHRoZSBRVUlDIGludGVyaW0gKGRpZCBub3QgZ2V0IGFpciB0aW1lIHRoZW4g dG8gcHJlc2VudCBpdCkuIE9uZSBxdWVzdGlvbiB3YXMgYWN0dWFsbHkgaWYgb25lIHNob3VsZCBt b3ZlIEVDTiBuZWdvdGlhdGlvbiB0byB0aGUgUVVJQyBjb25uZWN0aW9uIHNldHVwLjwvc3Bhbj48 YnI+DQo8YnI+DQpXaHkgYWx3YXlzIHVzZSBDRSB0byB0ZXN0IHRyYXZlcnNhbCBvZiB0aGUgSVAt RUNOIGZpZWxkPyBTZXR0aW5nIHRoZSBFQ1QgY29kZXBvaW50IHRoYXQgd2lsbCBiZSB1c2VkIHRo cm91Z2hvdXQgdGhlIGNvbm5lY3Rpb24gYWxzbyB0ZXN0cyBmb3IgemVyb2luZyB0aGUgRUNOIGZp ZWxkLCB3aXRob3V0IHJpc2tpbmcgbG9zaW5nIHZpc2liaWxpdHkgb2YgYSBDRSBtYXJraW5nIGlu dHJvZHVjZWQgaW4gdGhlIG5ldHdvcmsuPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij5bSUpdIEFkbWl0LCB0aGF0IEkgc2VsZWN0ZWQgQ0UgZm9yIGxhY2sg b2YgYmV0dGVyIGtub3dsZWRnZSwgRUNUKDApIG9yIEVDVCgxKSAoZGVwZW5kaW5nIG9uIEVDTiBl eHBlcmltZW50YWwgdXNlKSBtYXkgYmUgYmV0dGVyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KRGVmaW5lICZxdW90O2EgZmFpbGVkIGNo YWxsZW5nZS9yZXNwb25zZSBwaGFzZSZxdW90Oy4gQ2FuJ3QgaXQgZmFpbCBmb3IgYSBoYWxmLWNv bm5lY3Rpb24sIG5vdCBuZWNlc3NhcmlseSBmb3IgdGhlIHdob2xlIGNvbm5lY3Rpb24/PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bSUpdIEluIHNvbWUg Y2FzZXMgYSBjaGFsbGVuZ2UgcmVwb25zZSBjYW4gZmFpbCBmb3Igb25lIGhhbGYtY29ubmVjdGlv biwgc3RpbGwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvICZuYnNwO3VzZSBFQ04gaW4gb25lIGRh dGEgZGlyZWN0aW9uLiBUaGlzIG5lZWRzIHNvbWUgZXh0cmEgY29uc2lkZXJhdGlvbiBhbmQgY2xh cmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQoyLjEuMjxicj4NClRoZSBtb2RlIG1lY2hhbmlzbSBvZiBSRkM2Njc5IG5lZWRz IHRvIGJlIGRlc2NyaWJlZCwgbm90IGp1c3QgcmVmZXJlbmNlZC4gTm90ZSB0aGF0IGRyYWZ0LWll dGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbiBpbnRlbmRzIHRvIHVwZGF0ZSBSRkM2Njc5IGlu IHRoaXMgcmVzcGVjdCAocmVtb3ZpbmcgdGhlIHVzZSBvZiB0aGUgRUNOIG5vbmNlKS48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPltJSl0gWWVzLCBhZGRl ZCB0aGlzIHdpdGhvdXQgdGhpbmtpbmcsIG1vcmUgd29yayBpcyBuZWVkZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KMi4zPGJyPg0KTml0 OiBZb3UgYXNzaWduIHRoZSBuYW1lcyBFMSBhbmQgRTIgZm9yIHRoZSBmaWVsZHMgZm9yIHRoZSBs ZW5ndGggb2YgZWFjaCBlbmNvZGluZyBvZiBFQ1QoMCkgYW5kIEVDVCgxKS4gSXQgd291bGQgYmUg bGVzcyBpbGxvZ2ljYWwgaWYgdGhleSB3ZXJlIGNhbGxlZCBFMCBhbmQgRTEuPHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bSUpdIFllcywgeW91IGFyZSBy aWdodCA6LSksIHdpbGwgY29ycmVjdCB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBmZWVkYmFjayBnaXZlcyB0aGUgbnVtYmVyIG9mIG1h cmtlZCBieXRlcy4gSXQgbmVlZHMgdG8gc3BlY2lmeSB3aGljaCBoZWFkZXJzIGFyZSAobm90KSBp bmNsdWRlZCBpbiB0aGUgYnl0ZSBjb3VudC4gQW5kIGlmIGEgZGF0YWdyYW0gd2l0aCB6ZXJvIGJ5 dGVzIGlzIEVDTi1tYXJrZWQsIGhvdyBkbyB5b3UgcHJvcG9zZSB0byBmZWVkIHRoYXQgYmFjayAo aW4gQWNjRUNOIGl0IGZlZWRzIGJhY2sgbWFya2VkIHBhY2tldHMgYW5kIG1hcmtlZCBieXRlcyk/ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bSUpdIFll cywgdGhpcyBpcyBub3QgY2xlYXIsIHRoZSBzYW1lIGFtYmlndWl0eSBpcyBhbHNvIGluPC9zcGFu Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPmRyYWZ0LWlldGYtcXVpYy1yZWNvdmVy eS0wNCBhcyBzZW50X2J5dGVzIGlzIG5vdCBleHBsYWluZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCkl0IHNheXMgMSBvY3RldCBvdmVyaGVhZCBpZiBFQ04gaXMgbm90IHN1cHBvcnRlZC4gQ2Fu J3QgdGhlIGVuZHMgc2VuZCBubyBFQ04gZmVlZGJhY2sgYXQgYWxsIGlmIHRoZXkgaGF2ZSBkaXNh YmxlZCBFQ04gZHVyaW5nIHRoZSBjaGFsbGVuZ2UgcmVzcG9uc2U/PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bSUpdIFllcyBpdCBpcyBhIHBvc3NpYmls aXR5IHRvIGluY2x1ZGUgdGhlIEVDTiBieXRlIGNvdW50IGV2ZW4gaWYgRUNOIGlzIG5vdCBzdXBw b3J0ZWQgYXMgdGhlIGZvcm1hdCBpcyBzZWxmLWNvbnRhaW5lZCwgdGhpcyBzaG91bGQgYmUgY2xh cmlmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjIuNCA8YnI+DQpJdCBzdWdnZXN0cyB1c2luZyBhIGdpdmVuIHBhdHRlcm4gdG8gZGV0 ZWN0IHRoZSBuZWVkIGZvciBmYWxsLWJhY2suIFRoYXQncyBhIGdvb2QgaWRlYS4gSSB0aGluayBh bnkgcGFydGljdWxhciBjb25uZWN0aW9uIHNob3VsZCBvbmx5IG5lZWQgdG8gaW5jbHVkZSB0d28g SVAtRUNOIGNvZGVwb2ludHMgaW4gdGhlIHBhdHRlcm46IHRoZSByZWxldmFudCBFQ1QgY29kZXBv aW50IGFuZCBDRS48YnI+DQo8YnI+DQpZb3UgbWlnaHQgYWxzbyB3YW50IHRvIGxvb2sgYXQgdGhp cyBleHBpcmVkIEktRDogZHJhZnQtbW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0IHdoaWNoIHVzZXMg Q0UgcmFuZG9tbHkgdG8gdmVyaWZ5IHRoYXQgdGhlIHJlY2VpdmVyIGZlZWRiYWNrIGlzIG5vdCBj aGVhdGluZy4gWW91IG1pZ2h0IGJlIGFibGUgdG8gaW50ZWdyYXRlIHRoYXQgaW50byB0aGUgcGF0 aCB0cmF2ZXJzYWwgdGVzdGluZywgYWx0aG91Z2ggSSBhY2NlcHQgdGhhdCBhIGRldGVybWluaXN0 aWMNCiBwYXR0ZXJuIGFsbG93cyB0aGUgcmVtb3RlIHBlZXIgdG8gZGV0ZWN0IHByb2JsZW1zLCB3 aGVyZWFzIGEgcmFuZG9tIG9uZSBkb2Vzbid0Ljxicj4NCjxicj4NCkl0IHN1Z2dlc3RzIGEgZ2Vu ZXJpYyBFQ04gZmFsbC1iYWNrIGRyYWZ0LiBJdCBpcyBoYXJkIHRvIGRlc2NyaWJlIGZhbGwtYmFj ayBpbmRlcGVuZGVudCBvZiBhbnkgc3BlY2lmaWMgcHJvdG9jb2wuPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bSUpdIFRoYW5rcywgdGhpcyBzZWN0aW9u IG5lZWRzIG1vcmUgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQoyLjY8YnI+DQpOaXQ6IHMvcmVtYXJrL3JlLW1hcmsvIGJlY2F1c2Ug cmVtYXJrIG1lYW5zIHNvbWV0aGluZyBkaWZmZXJlbnQuPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bSUpdIE9LPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KQSBjb3VwbGUgb2YgbW9udGhz IGFnbywgd2Ugd2VyZSBkaXNjdXNzaW5nIHVzaW5nIHRpbWVzdGFtcHMgb24gZmVlZGJhY2ssIHNv IHRoYXQgZmV3ZXIgQUNLcyBjb3VsZCBiZSBzZW50IHdpdGhvdXQgbG9zaW5nIHRpbWluZyBpbmZv LiBBcmUgeW91IHBsYW5uaW5nIHRvIGluY2x1ZGUgdGhhdCBpZGVhIGluIHRoaXMgZHJhZnQ/PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bSUpdIFN1cHBv cnQgZm9yIGRldGFpbGVkIHRpbXN0YW1wcyBpcyBhbHJlYWR5IGF2YWlsYWJsZSBpbiB0aGUgUVVJ QyBwcm90b2NvbCBBQ0tzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KVGhhdCdzIGl0IGZvciBub3cuIDxicj4NCjxicj4NCjxicj4NCjxicj4N CkJvYjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0t IDxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBj ZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9w IiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+U3ViamVjdDogPG86cD48 L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmU6IFJlIDogV29ya2luZyBncm91cCBhY2NlcHRhbmNl IGNhbGwgZHJhZnQtYmFnbnVsby10Y3BtLWdlbmVyYWxpemVkLWVjbi0wNDxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0i cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp Z2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RGF0ZTogPG86cD48L286cD48L2I+PC9w Pg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U3VuLCAyNSBKdW4gMjAxNyAyMzoxNzo0MiAmIzQzOzAxMDA8bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkZyb206IDxvOnA+PC9vOnA+PC9i PjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJvYiBCcmlzY29lIDxhIGhyZWY9Im1haWx0bzppZXRmQGJvYmJyaXNj b2UubmV0Ij4mbHQ7aWV0ZkBib2JicmlzY29lLm5ldCZndDs8L2E+PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9wPg0KPC90 ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SW5nZW1hciBKb2hhbnNzb24gUyA8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFu c3NvbkBlcmljc3Nvbi5jb20iPg0KJmx0O2luZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29t Jmd0OzwvYT4sIDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9h Pg0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPiZsdDt0Y3BtQGlldGYub3JnJmd0Ozwv YT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxp Z249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkNDOiA8bzpw PjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86dGNwbS1jaGFpcnNAaWV0 Zi5vcmciPnRjcG0tY2hhaXJzQGlldGYub3JnPC9hPg0KPGEgaHJlZj0ibWFpbHRvOnRjcG0tY2hh aXJzQGlldGYub3JnIj4mbHQ7dGNwbS1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PC9hPiwgbWFyY2VsbyBi YWdudWxvIGJyYXVuDQo8YSBocmVmPSJtYWlsdG86bWFyY2Vsb0BpdC51YzNtLmVzIj4mbHQ7bWFy Y2Vsb0BpdC51YzNtLmVzJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT5JbmdlbWFyLDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBkcmFmdCBhbHJl YWR5IHNheXMgdGhpcyB3b3JrIHNob3VsIGJlIHRyYW5zZmVyYWJsZSB0byBTQ1RQLiBJIG1pZ2h0 IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFsc28gYWRkIGEgbm90ZSB0aGF0IGl0IGNvdWxkIGFs c28gYmVuZWZpdCBRVUlDLCBhbHRobyBJJ2QgbGlrZSB0byBzZWUgPG86cD48L286cD48L3ByZT4N CjxwcmU+c29tZSBkZXRhaWwgYmVmb3JlIHByZXN1bWluZyB0aGlzIHdpbGwgd29yay48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Db2luY2lkZW50 YWxseSwgSSBqdXN0IHJlYWQgeW91ciBFQ04gaW4gUVVJQyBkcmFmdCB5ZXN0ZXJkYXkuIEFuZCwg YWxzbyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb2luY2lkZW50YWxseSwgb25lIG9mIG15IG1h aW4gY29tbWVudHMgd2FzIGdvaW5nIHRvIGJlIHRoYXQgaXQgc2VlbXMgPG86cD48L286cD48L3By ZT4NCjxwcmU+ZGlzYXBwb2ludGluZyB0aGF0IGl0IG9ubHkgJnF1b3Q7c2VuZHMgYW4gRUNOIG5l Z290aWF0aW9uIGZyYW1lIHdoZW4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Y29ubmVjdGlvbiBz ZXR1cCBpcyBjb21wbGV0ZWQuJnF1b3Q7IFJldHJhbnNtaXNzaW9uIHRpbWVvdXRzIGhhdmUgdG8g YmUgPG86cD48L286cD48L3ByZT4NCjxwcmU+Y29uc2VydmF0aXZlIGR1cmluZyBjb25uZWN0aW9u IHNldC11cCB3aGF0ZXZlciB0aGUgcHJvdG9jb2wuIFNvIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5iYWNrZ3JvdW5kIGxldmVsIG9mIGNvbmdlc3Rpb24gbG9zcyB3aWxsIHRoZW4gbGVhZCB0 byB1bm5lY2Vzc2FyaWx5IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnByb3RyYWN0ZWQgaW50ZXJt aXR0ZW50IGRlbGF5cywgd2hpY2ggd2lsbCBwYXJ0aWN1bGFybHkgaGl0IHNob3J0IFFVSUMgPG86 cD48L286cD48L3ByZT4NCjxwcmU+Zmxvd3MuIFNvIEkgd2FzIGdvaW5nIHRvIHN1Z2dlc3QgdGhh dCB5b3UgbWlnaHQgYmUgYWJsZSB0byBwcm90ZWN0IFFVSUMgPG86cD48L286cD48L3ByZT4NCjxw cmU+Y29ubmVjdGlvbiBzZXR1cCBmcm9tIHJhbmRvbSBjb25nZXN0aW9uIGxvc3MgYnkgYW4gYXBw cm9hY2ggc2ltaWxhciB0byA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5FQ04mIzQzOyYjNDM7Ljxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgY2Fubm90IGd1YXJhbnRlZSB0aGF0IEkgd2lsbCBo YXZlIHRpbWUgdG8gd3JpdGUgdXAgdGhlIG90aGVyIGNvbW1lbnRzIDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPmZyb20gbXkgcmV2aWV3IGluIHRpbWUgZm9yIHlvdSB0byB1c2UgaXQgYmVmb3JlIHRo ZSBJRVRGIGRlYWRsaW5lIChJIGFtIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFib3V0IHRvIHRh a2UgYSB3ZWVrIG9mZiwgcmV0dXJuaW5nIG9uIDMgSnVsKS4gQnV0IEkgd2lsbCB0cnkgdG8gZG8g YSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5xdWljayBzdW1tYXJ5IGZvciB0aGUgUVVJQyBsaXN0 IG5vdy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT5Cb2I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT5PbiAyNS8wNi8xNyAxOTowMywgSW5nZW1hciBKb2hhbnNzb24gUyB3cm90ZTo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mZ3Q7IEhpPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgSSBzdXBwb3J0IHRoaXMgd29yay48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mZ3Q7IEluIGFkZGl0aW9uLCBwYXJ0cyBvZiB0aGUgZmluZGluZ3Mg YW5kIHJlY29tbWVuZGF0aW9ucyBpbiB0aGlzIFRDUCBnZW5lcmFsaXplZCBFQ04gd29yayBtYXkg YWxzbyBiZSB1c2VmdWwgZm9yIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBFQ04gc3VwcG9ydCBp biBRVUlDLCBjdXJyZW50bHkgb3V0bGluZWQgaW4gKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAzLnR4dCI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9pZC9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDMudHh0PC9hPiApLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IFJl Z2FyZHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IEluZ2VtYXIgSm9oYW5zc29uPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286 cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29l Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2Jicmlz Y29lLm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_DB4PR07MB348EFBE3B5A9F023AAAD12BC2D70DB4PR07MB348eurprd_-- From nobody Tue Jul 4 08:57:00 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 B872E13167C for ; Tue, 4 Jul 2017 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 rrQEPopzpw-o for ; Tue, 4 Jul 2017 08:56:57 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 4545F12EC30 for ; Tue, 4 Jul 2017 08:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ndcemajoi+mm22jC4QX6Iff91JjKs1wv9RbJL57eiTY=; b=KIodPfwUh3e+S7rymi2qFdacj /VuAnWF0fnzwrXYGAnNOu3qp8nRLCa8U79XH9DGS4uEWF+30xVPIpXPT2pfk78QmRNa0+kfL2sE2H n3bf5PdYKVZxqH6A/jdJA8mvGr/V+9TNhBjoEKQTo3cdXf4HCLcn6zRPr9vXVtxKry46iET2j9e+J FTy/mgdKqZDCRTL1Zz+5ouiQiGzVuujrjDAy9dcDPkjHEx7QK85oS3N1fYMIYCAhvaHoHR3cUZ4Zs XblK2Jk40y26kGzHCo58zFNWAeFtIuPFBwKSX+UHlvzwAVHZd3+vDTAzKyHR6i7yiLXBzzMwip+Za hmwdvAz9g==; Received: from [31.185.128.124] (port=48882 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dSQC7-00030l-Pe; Tue, 04 Jul 2017 16:56:55 +0100 Subject: Re: Quick review of ECN for QUIC: draft-johansson-quic-ecn-03 To: Ingemar Johansson S Cc: QUIC IETF mailing list References: <0062c1c4-254c-651f-c091-7f85fc1a28fa@bobbriscoe.net> From: Bob Briscoe Message-ID: <077640e4-8313-d8fb-ae42-df96f7fdd155@bobbriscoe.net> Date: Tue, 4 Jul 2017 16:56:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------51533A40BA55D34EA44EB33F" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net 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, 04 Jul 2017 15:56:59 -0000 This is a multi-part message in MIME format. --------------51533A40BA55D34EA44EB33F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ingemar, On 04/07/17 14:13, Ingemar Johansson S wrote: > > In a similar vein, you might want to look at (and even cite) RFC7860 > for requirements about ECN feedback (it was specifically about TCP, > but there is stuff there relevant to QUIC too). > > [IJ] Hmm, do you mean some other RFC ? > [BB] Sry RFC7560. I blame either blurred eye-sight or blurred memory!? Thx for responses on all the other points. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------51533A40BA55D34EA44EB33F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Ingemar,

On 04/07/17 14:13, Ingemar Johansson S wrote:

In a similar vein, you might want to look at (and even cite) RFC7860 for requirements about ECN feedback (it was specifically about TCP, but there is stuff there relevant to QUIC too).

[IJ] Hmm, do you mean some other RFC ?

[BB] Sry RFC7560.
I blame either blurred eye-sight or blurred memory!?

Thx for responses on all the other points.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

--------------51533A40BA55D34EA44EB33F-- From nobody Tue Jul 4 22:41: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 1E97D12773A for ; Tue, 4 Jul 2017 22:41:32 -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, 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=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 80SZ2d28K-3P for ; Tue, 4 Jul 2017 22:41:28 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 5311C126C23 for ; Tue, 4 Jul 2017 22:41:28 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id u62so118738445pgb.3 for ; Tue, 04 Jul 2017 22:41:28 -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=FGDHt2JnfcpM1rucQzAi+BVdYBc9/hVsqnEwIbNHOa4=; b=nojt6MHY2LgmGH7dxcayS5YqJQb42BSrwyq5IMI2fQ5oSGeS7ziILti66e5OtU4uuW kNmNJNieECXiQ+Sb6O63dgAdGccLd6Y/9GDDcs43fhLSavxEBZMD/YIo80j+yF3wgg2J bAjsHkWOr4kC2Pr/INTPh3H7V/Wfah89FUPS0wMHSrf55YytliAU9RP3INRroJtG8LPN j6DwR5rfWM8oycsDjs1gSXYCzGrTQypJ+KWpLgTTgeI0L0dqiH96WymPl8sc6a5WpmTK zwa8UritVPyd0AXd1EUbLHh2gJcokuODejzHzUm77DctfN33gnzpdb+xFQlvCOHYxql9 spZw== 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=FGDHt2JnfcpM1rucQzAi+BVdYBc9/hVsqnEwIbNHOa4=; b=bxRaCBbTFj5Vx7rQyi+lV5SCztRXR1MoRrRNwgiqD1cH/oksKxsLSUs3uLIqA+Fjge +hWtrq9Bwbt0EMsJM4qCR8PjGJxuNfpxtOlYX3lTHWpF9h/hTD1K3OejpSnS+UOvBcNe rc7wHcRBBzVHJJ88l31jJyi+gkR/UZFPwTAcLyJLooEe2bTbY4Syon8ISqB9dK/e4tp2 J7am4SbrztfijNeJVI+8h1V+igXyaRNnh/M1VqdzmEcN+WqDKl7ilYIHYUImzYbpUEka bn1kfWTEtEJgNklxJYXGouad6hzjWczpCIqZTSF9oQQ4Ju9Lj+wQHkUX359IW3a1kMes 0eOA== X-Gm-Message-State: AIVw113JCyzAiajM5OS0QZlxAvQeMLDp/VH2o/QZsZu5yoQ9Jnx8fOQi 6Nm/M5VMuhDWaxRUR+nKLGSTfx7/XA== X-Received: by 10.84.211.103 with SMTP id b94mr20767883pli.230.1499233287793; Tue, 04 Jul 2017 22:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Tue, 4 Jul 2017 22:41:26 -0700 (PDT) In-Reply-To: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri>

<2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> From: Kazuho Oku Date: Wed, 5 Jul 2017 14:41:26 +0900 Message-ID: Subject: Re: Unidirectional streams PR To: Ian Swett Cc: "Lubashev, Igor" , Mike Bishop , Dmitri Tikhonov , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Jo Kulik , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Martin Thomson 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, 05 Jul 2017 05:41:32 -0000 2017-06-29 10:23 GMT+09:00 Ian Swett : > I updated my PR(#656) today, sorry for the delay. I attempted to address > the issues identified with text. Some may prefer more tweaks to the stat= e > diagram, which are also possible, so I'm open to suggestions. After all, I think that the approach proposed here is the most well-balanced one. As much as I think that having first-class support for unidirectional streams is preferable, I also think that we should keep the overall architecture (i.e. sum of the complexity in the transport layer and the application layer) as simple as possible. IMO having support for bidirectional streams (along with support for unidirectional streams) aligns with such intention. Most of the application protocols that will be deployed over the QUIC transport will be in request-response style, at least to some extent. Hence it is preferable for the transport layer to provide a framework that fits such style. Bidirectional streams provide the necessary features. FIN provides a way to indicate the end of the message. RST provides a way to cancel the exchange of the message in both directions. IMO the biggest issue with the unidirectional-only approach is that you cannot have the two features together. If a client needs a way to reset the server's response before observing the first frame, it cannot use FIN as an indicator of the end of the request. It is true that the issue can be evaded by doing one's own framing in the application layer. #643 does that by introducing a CANCEL_REQUEST frame. But I do not think that we should require every application protocol built above QUIC to do its own framing. In addition to that, need to keep two uni-directional streams open would consume more resources than being able to close one direction of a bi-directional stream at an earlier moment. > In the meantime, I've been considering other alternatives, including > variations on Mike's direction and a variation of the "Do Nothing" option > which involved the application signaling to the transport that streams of= a > certain sort(ie: server to client for server push) were unidirectional, a= s > GQUIC does today. Overall, I think the approach I've outlined does a goo= d > job of iterating on existing deployment experience and adding explicit > signaling for unidirectional streams instead of implicit signaling at the > application layer. There are pros and cons to both explicit and implicit > signaling, but I think explicit signaling is more complete and less prone= to > application error. > > Thanks, Ian > > > On Wed, Jun 28, 2017 at 8:14 PM, Lubashev, Igor wro= te: >> >> > unless what the transport provides is a perfect fit for application >> > semantics, you end up building those semantics into the application an= yway. >> >> I agree with this. We should avoid adding complexity into transport for >> rare use cases, since it goes against KISS principle. >> >> On the other hand, adding support for a by far the most common use case >> makes a lot of sense. This helps apps avoid screwing up implementing th= at >> common case and lets us optimize that common case in the lower layer. Bi= Di >> streams are such common cases. Uni streams are likely to be the >> second-most-common cases (hence you offered this PR to optimize them). >> >> >> The Associated Streams proposal offers extra semantic flexibility at a >> cost of some semantic complexity (someone would need to verify that the >> associated stream numbers make sense -- api? apps?) and a few extra byte= s. >> >> I'd like to wait to see Ian's revised proposal. The initial proposal >> offered to do only one thing -- offer a choice of uni/bi-directional str= eams >> -- but it did it in a very simple way, which is nice. >> >> - Igor >> >> >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Wednesday, June 28, 2017 7:28 PM >> To: Mike Bishop >> Cc: Swindells, Thomas (Nokia - GB/Cambridge, UK) >> ; QUIC WG ; Mikkel Fahn=C3=B8= e >> J=C3=B8rgensen ; Dmitri Tikhonov >> ; Jo Kulik >> Subject: Re: Unidirectional streams PR >> >> There is probably a simpler approach here, take a bit (as Ian did) and s= ay >> that if that bit is set, then the stream is in response to another and t= he >> stream ID of the stream to which this is responding follows immediately >> after the stream ID of the stream itself. You could then include that o= nly >> at the start of the stream, or in multiple frames (or as we decide). >> >> The problem with this, as with several of the other issues we're >> discussing, is that unless what the transport provides is a perfect fit = for >> application semantics, you end up building those semantics into the >> application anyway. HTTP certainly can't survive without its own >> association semantics for pushes. That suggests to me that having >> bidirectional semantics in the transport creates more duplication than >> otherwise. Hence my proposal. >> >> On 28 June 2017 at 15:26, Mike Bishop >> wrote: >> > As promised, a PR for adding =E2=80=9Cassociated streams=E2=80=9D is a= t >> > https://github.com/quicwg/base-drafts/pull/672. This very >> > deliberately builds on top of MT=E2=80=99s PR =E2=80=93 it=E2=80=99s a= dding a primitive which >> > can be used to construct various abstractions atop unidirectional >> > streams, but the lifecycle is still fundamentally unidirectional. >> > >> > >> > >> > Copying my notes here for list discussion purposes. >> > >> > Major changes >> > >> > Leveraging @igorlord's insight that OO=3D00 only occurs on the first >> > STREAM frame of a stream, I used that as the trigger for a Stream >> > Properties byte. >> > Two bits of that byte describe the directionality of the stream: >> > >> > Unidirectional (no response expected) >> > Initial bidirectional (one response expected) Initial multi-response >> > (one or more responses expected; needs a better name) Response >> > >> > If the type is Response, there's an Associated Stream ID field, length >> > given by two more bits following the same pattern as the SS bits in >> > the STREAM frame ID. >> > >> > Personal Opinion >> > >> > On the plus side, these stream types seem to cover the abstractions I >> > can envision for most applications. You can unilaterally send >> > something (unidirectional), do request/response (bidirectional), or >> > pub/sub (single subscription stream, series of update streams). >> > >> > I don't care for the fact that I still need the stream type header in >> > HTTP after putting this in the transport. That will be ameliorated if >> > we go back to one stream per request, since all unidirectional streams >> > will be push streams. (As a side-note, I considered using the >> > multiple-response option in the HTTP mapping, but then I need a stream >> > header again to indicate which is the response and which the pushes.) >> > >> > I particularly don't like that you now have to look at the frame type >> > header to find out whether a field exists which tells you the length >> > of something else in the header. I'd like to simplify that. I went >> > with this model over a CREATE_STREAM frame because of @mikkelfj's >> > use-case of very small messages >> > -- this adds only one byte to the first frame on a stream in one >> > direction and 2-5 bytes to the first frame of response streams. A >> > separate frame type would be somewhat larger, but could be cleaner in >> > that respect. >> > >> > >> > >> > >> > >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Swindells, >> > Thomas (Nokia - GB/Cambridge, UK) >> > Sent: Wednesday, June 28, 2017 7:56 AM >> > To: Jo Kulik ; Mikkel Fahn=C3=B8e J=C3=B8rgensen >> > >> > Cc: QUIC WG ; Dmitri Tikhonov >> > >> > Subject: RE: Unidirectional streams PR >> > >> > >> > >> > I agree that looking at the layers of abstraction is useful. In >> > principle having the wire protocol just have constructs for >> > unidirectional streams does not in itself limit creating >> > bi-directional communication flows, supported at either the library or >> > application layer. >> > >> > >> > >> > However, there need to be a standard way of doing bi-directional >> > communication for migrating applications implemented using a socket >> > style api. It needs to be easy to move an existing application from TC= P >> > to QUIC. >> > This move may be attractive in many situations as QUIC gives improved >> > security and may allow greater throughput due to the more modern (and >> > customizable) congestion control algorithms compared to the OS TCP >> > stack. >> > >> > >> > >> > For migrating standard socket api applications I don=E2=80=99t think i= t would >> > be appropriate to leave the work to the application to do correlation, >> > at least the library should be providing this service using the wire >> > protocol as appropriate. Clearly we want a client written with one >> > library to be able to communicate successfully with a server written >> > using a different library. >> > This needs some form of standardization of the signalling. This could >> > either be a building block overlay on top of QUIC, or implemented at >> > the wire protocol level. >> > >> > >> > >> > In terms of patterns I think the following may be some of the most >> > common patterns (with potential to be provided at the library and or >> > wire protocol level). >> > >> > I/O pattern : Example >> > >> > 1/0 : An input only flow, perhaps a data logger like syslog with no >> > confirmation/feedback >> > >> > 0/1 : an output only flow, perhaps a topic message bus service with >> > no confirmation/feedback >> > >> > 1/1 : standard TCP applications with a single flow per connection >> > >> > 1/* : single input, many output, modelling STDIN/STDOUT+STDERR >> > >> > (1/1)* : multiplexed pairs of flows =E2=80=93 supporting multiple sock= ets >> > muxed onto a single QUIC connection >> > >> > >> > >> > Obviously, an application would always have the option to combine any >> > single direction flows with application level correlators to construct >> > more complex flows if desired. >> > >> > >> > >> > At the moment my gut says the 1/1 use-case is common enough that the >> > wire protocol should provide a standard mechanism to support it as a >> > standard overlay would probably end up being treated as part of the >> > wire format anyway. >> > >> > >> > >> > Perhaps streams should be explicitly created with a CREATE_STREAM >> > frame which would be capable of defining multiple related streams? >> > >> > There is the option of whether only (1/1) pairs can be created this >> > way, or >> > (1/n) combinations could be supported (with an application defined way >> > to identify the use of each of the output streams). A step further may >> > be that there is a transport parameter that defines whether the server >> > is allowed to create additional streams, or if stream creation is >> > purely client driven (like TCP). I don=E2=80=99t know if either of the= se would >> > simplify how to handle stream accounting, and in particular only >> > creating a flow when all parties have sufficient allowances left. >> > >> > >> > >> > Thomas >> > >> > >> > >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jo Kulik >> > Sent: 28 June 2017 15:09 >> > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen >> > Cc: QUIC WG ; Dmitri Tikhonov >> > >> > Subject: Re: Unidirectional streams PR >> > >> > >> > >> > I'd like to pop back up to a comment Igor made last week, because I >> > find it helpful in thinking about the design space: >> > >> > >> > >> > I think of three layers of abstraction: >> > >> > 1. QUIC Wire Protocol (the thing described by the QUIC Transport >> > RFC) >> > 2. QUIC Library API (a library exposing some useful abstractions >> > -- >> > such as blocking/non-blocking unidirectional streams and bidirectional >> > =E2=80=9Csockets=E2=80=9D -- and implementing them using QUIC Wire Pro= tocol) >> > 3. Application (something that uses QUIC Library APIs) >> > >> > I think there is some argument to be made that Martin's original >> > proposal did not take into account how we would achieve (2) for >> > bi-directional streams. (I don't think it strictly said "thou shalt >> > not do (2)" either, but that is up to interpretation.) >> > >> > >> > >> > Several people have argued that we do not want every application to >> > have to re-implement bi-directional streams (3) for every application, >> > and this is not how g-quic (our largest deployment) works right now. >> > These arguments make sense to me, but YMMV. >> > >> > >> > >> > Just because the particular *mechanism* that is being proposed has >> > some issues, however, doesn't scream out to me, at least, that we >> > should abandon this particular *design goal*. The goal being a >> > transport protocol that can elegantly fit with a uni/bi stream model. >> > Now, if we conclude that there can never be an elegant model that >> > achieves this goal, then so be it. But I also feel like we haven't >> > reached that point in the discussion yet. (At the very least, this >> > discussion has been fruitful to me in terms of mapping the design spac= e >> > and elucidating requirements). >> > >> > >> > >> > One of the reasons I still think this design goal is under >> > consideration is that Ian and Igor/Mike have been talking about >> > alternate solutions which have a similar flavor. During the recent >> > "quiet"ness on the thread, personally, I've been waiting to hear more >> > from them. >> > >> > >> > >> > On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen >> > wrote: >> > >> > In reply to Ranjeeth >> > >> > >> > >> > It is not only a matter of simplicity for the sake of simplicity: >> > >> > >> > >> > - A complex transport layer might end up being poorly implemented >> > leading to reduced interoperability and ultimately adoption. This >> > complexity is not only in implementation but also in understanding the >> > exact semantics of stream lifetime. Even if the spec is sufficiently >> > clear, it will still be open to misinterpretations. >> > >> > >> > >> > - Bi-directional state may have to be maintained longer and with more >> > overhead than with uni-directional streams, especially under loss, >> > potentially leading to poor performance and poor resource utilisation >> > because the transport layer has insufficient information. >> > >> > >> > >> > - The extra complexity at the application layer may be overstated - it >> > is significantly simpler to manage a map that associates to two >> > streams than it is to maintain bi-directional state at the transport >> > layer. It is even possible to implicitly link streams with same >> > identifiers, e.g. in a RPC scenario. That said, I do see a potential >> > benefit of a wrapper that implements the common bi-directional case. >> > >> > >> > >> > - Complexity at the application layer may be duplicated, but >> > implementation errors are also isolated to that application. >> > Specifically for HTTP I would assume that QUIC transport and QUIC HTTP >> > implementers would be large the same for a long time to come, so I >> > would not expect the tradeoff here to be particularly concerning. >> > >> > >> > >> > - Unix pipes are traditionally constructed as a pair of >> > uni-directional file descriptors and that is a reasonably proven >> > model. C=E2=80=99s standard library stdin, stdout and stderr is an exa= mple of >> > an asymmetric model with implicit linkage between uni-directional file >> > descriptors. >> > >> > >> > >> > - There are lots of use cases for non-HTTP like connectivity - Kafka >> > high volume message queuing for example. The industry trend appears to >> > move towards asynchronous processing and messaging. It depends on >> > whether you look at QUIC as a TCP + TLS replacement, or as a HTTPS / >> > REST RPC replacement. >> > >> > >> > >> > - Uni-directional streams may currently be unproven in the wild, but a >> > proposal is needed before an implementation can be made and testet. I >> > agree that it is easy to design into wrong assumptions without real >> > world testing. >> > >> > >> > >> > - There will hopefully not be a large number of successors to QUIC - >> > perhaps some purpose specific variants, e.g. for embedded use. >> > Widespread adaptation and compatibility is very necessary so it makes >> > sense to have QUIC being sufficiently simple and expressive to achieve >> > this goal. A polymorf QUIC will not achieve that goal. On the other >> > hand, a solid QUIC foundation can be used for a large number of >> > application protocols. >> > >> > >> > >> > - Finally, it may turn out that uni-directional streams just is a bad >> > idea - I doubt it, but I do believe real world tests are needed. >> > >> > >> > >> > Kind Regards, >> > >> > Mikkel Fahn=C3=B8e J=C3=B8rgensen >> > >> > >> > >> > On 28 June 2017 at 14.42.36, Dmitri Tikhonov >> > (dtikhonov@litespeedtech.com) >> > wrote: >> > >> > On Tue, Jun 27, 2017 at 02:31:38PM -0700, Ranjeeth Kumar Dasineni wrot= e: >> >> 2. We are overplaying the simplicity of design. Even if we deem >> >> deployment experience not a concern, if every application layer >> >> protocol that needs support for bidirectional streams has to >> >> implement some correlators and such above, that's a net negative in >> >> terms of complexity. >> > >> > This is an important point: we want QUIC adoption to be made easy. >> > A program that speaks HTTP today should be able to use an existing >> > QUIC library without having to emulate bidirectional streams in order >> > to fit it into HTTP usage pattern. Forcing every one of these programs >> > to do this is certainly a hurdle. >> > >> > - Dmitri. >> > >> > >> > --=20 Kazuho Oku From nobody Wed Jul 5 20:50: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 C42B512FEE2 for ; Wed, 5 Jul 2017 20:50:15 -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=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 A9OnPPNGySmh for ; Wed, 5 Jul 2017 20:50:12 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 8DA9912EE8D for ; Wed, 5 Jul 2017 20:50:12 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v663kVd8030994; Thu, 6 Jul 2017 04:50:09 +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=jGxyuMx3ZKqeJSL7qs3w5N6fnNnXYOpvKomn0gX0UHY=; b=jzWtncURp83C8IIHLrpw8Qt+sxh9MrRlnkD2CBQ5akqtVxL2MsHDtS7r/SYSBcsKVlXf VQ4FR85mzQN5Ycn9VNEHtfFG2gnb7zbQ7GtsFyCgOPgRfJkfZX/SPCmnmICy8N9CTc35 VhTCbCRj+RGZ4rMQGCcvb5ccTVPh0NtOmonFdXAL7XBpdYsSfm2aWY5UDjKwF4j5aacu SQlRoW/yuhwRa7kwYz0YfH1lGzyZHDpMuex6VYfmwqr92h49gfqdCgTRz6hgkyhYZJKR Zui7Re+izHRg2E0PhrHtnItnrCUKMKSqOVJKqlyiRJikwkhUShFyMRwNxHACacxqNePm Cg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bgsdjdcrx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jul 2017 04:50:09 +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 v663kJ70023193; Wed, 5 Jul 2017 23:50:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ubj8g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2017 23:50:07 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Jul 2017 23:50:06 -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; Wed, 5 Jul 2017 23:50:06 -0400 From: "Lubashev, Igor" To: Kazuho Oku , Ian Swett CC: Mike Bishop , Dmitri Tikhonov , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Jo Kulik , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "QUIC WG" , Martin Thomson Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qFJcNmOfPnkGlJjRXQ/9soKI0ttCAgATMZACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSAD//8GgUIAAXnCAgAm2IgCAAS8I8A== Date: Thu, 6 Jul 2017 03:50:05 +0000 Message-ID: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri>

<2240c2a68910453e97fc50d42e8a1d4f@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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.110] 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-07-06_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-1703280000 definitions=main-1707060061 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_01:, , 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-1703280000 definitions=main-1707060062 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, 06 Jul 2017 03:50:16 -0000 PiBJZiBhIGNsaWVudCBuZWVkcyBhIHdheSB0byByZXNldCB0aGUgc2VydmVyJ3MgcmVzcG9uc2Ug YmVmb3JlIG9ic2VydmluZyB0aGUgZmlyc3QgZnJhbWUsIGl0IGNhbm5vdCB1c2UgRklOIGFzIGFu IGluZGljYXRvciBvZiB0aGUgZW5kIG9mIHRoZSByZXF1ZXN0Lg0KDQpUaGVyZSBpcyBhIERJU0lO VEVSRVNUIGZyYW1lIHByb3Bvc2FsIChQUiAjMTcxOiBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dn L2Jhc2UtZHJhZnRzL3B1bGwvMTcxKS4gIFRoYXQncyBzb21ldGhpbmcgdGhhdCBJIGJlbGlldmUg aXMgdmFsdWFibGUgaW5kZXBlbmRlbnQgb2YgdGhpcyBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBS Lg0KDQotIElnb3INCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2F6dWhv IE9rdSBbbWFpbHRvOmthenVob29rdUBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5 IDA1LCAyMDE3IDE6NDEgQU0NClRvOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+DQpD YzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBNaWtlIEJpc2hvcCA8TWlj aGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT47IERtaXRyaSBUaWtob25vdiA8ZHRpa2hvbm92QGxp dGVzcGVlZHRlY2guY29tPjsgU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdl LCBVSykgPHRob21hcy5zd2luZGVsbHNAbm9raWEuY29tPjsgSm8gS3VsaWsgPGpva3VsaWtAZ29v Z2xlLmNvbT47IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47 IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25A Z21haWwuY29tPg0KU3ViamVjdDogUmU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgUFINCg0KMjAx Ny0wNi0yOSAxMDoyMyBHTVQrMDk6MDAgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjoN Cj4gSSB1cGRhdGVkIG15IFBSKCM2NTYpIHRvZGF5LCBzb3JyeSBmb3IgdGhlIGRlbGF5LiAgSSBh dHRlbXB0ZWQgdG8gDQo+IGFkZHJlc3MgdGhlIGlzc3VlcyBpZGVudGlmaWVkIHdpdGggdGV4dC4g IFNvbWUgbWF5IHByZWZlciBtb3JlIHR3ZWFrcyANCj4gdG8gdGhlIHN0YXRlIGRpYWdyYW0sIHdo aWNoIGFyZSBhbHNvIHBvc3NpYmxlLCBzbyBJJ20gb3BlbiB0byBzdWdnZXN0aW9ucy4NCg0KQWZ0 ZXIgYWxsLCBJIHRoaW5rIHRoYXQgdGhlIGFwcHJvYWNoIHByb3Bvc2VkIGhlcmUgaXMgdGhlIG1v c3Qgd2VsbC1iYWxhbmNlZCBvbmUuDQoNCkFzIG11Y2ggYXMgSSB0aGluayB0aGF0IGhhdmluZyBm aXJzdC1jbGFzcyBzdXBwb3J0IGZvciB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGlzIHByZWZlcmFi bGUsIEkgYWxzbyB0aGluayB0aGF0IHdlIHNob3VsZCBrZWVwIHRoZSBvdmVyYWxsIGFyY2hpdGVj dHVyZSAoaS5lLiBzdW0gb2YgdGhlIGNvbXBsZXhpdHkgaW4gdGhlIHRyYW5zcG9ydCBsYXllciBh bmQgdGhlIGFwcGxpY2F0aW9uIGxheWVyKSBhcyBzaW1wbGUgYXMgcG9zc2libGUuDQoNCklNTyBo YXZpbmcgc3VwcG9ydCBmb3IgYmlkaXJlY3Rpb25hbCBzdHJlYW1zIChhbG9uZyB3aXRoIHN1cHBv cnQgZm9yIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMpIGFsaWducyB3aXRoIHN1Y2ggaW50ZW50aW9u Lg0KDQpNb3N0IG9mIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbHMgdGhhdCB3aWxsIGJlIGRlcGxv eWVkIG92ZXIgdGhlIFFVSUMgdHJhbnNwb3J0IHdpbGwgYmUgaW4gcmVxdWVzdC1yZXNwb25zZSBz dHlsZSwgYXQgbGVhc3QgdG8gc29tZSBleHRlbnQuDQpIZW5jZSBpdCBpcyBwcmVmZXJhYmxlIGZv ciB0aGUgdHJhbnNwb3J0IGxheWVyIHRvIHByb3ZpZGUgYSBmcmFtZXdvcmsgdGhhdCBmaXRzIHN1 Y2ggc3R5bGUuDQoNCkJpZGlyZWN0aW9uYWwgc3RyZWFtcyBwcm92aWRlIHRoZSBuZWNlc3Nhcnkg ZmVhdHVyZXMuIEZJTiBwcm92aWRlcyBhIHdheSB0byBpbmRpY2F0ZSB0aGUgZW5kIG9mIHRoZSBt ZXNzYWdlLiBSU1QgcHJvdmlkZXMgYSB3YXkgdG8gY2FuY2VsIHRoZSBleGNoYW5nZSBvZiB0aGUg bWVzc2FnZSBpbiBib3RoIGRpcmVjdGlvbnMuDQoNCklNTyB0aGUgYmlnZ2VzdCBpc3N1ZSB3aXRo IHRoZSB1bmlkaXJlY3Rpb25hbC1vbmx5IGFwcHJvYWNoIGlzIHRoYXQgeW91IGNhbm5vdCBoYXZl IHRoZSB0d28gZmVhdHVyZXMgdG9nZXRoZXIuIElmIGEgY2xpZW50IG5lZWRzIGEgd2F5IHRvIHJl c2V0IHRoZSBzZXJ2ZXIncyByZXNwb25zZSBiZWZvcmUgb2JzZXJ2aW5nIHRoZSBmaXJzdCBmcmFt ZSwgaXQgY2Fubm90IHVzZSBGSU4gYXMgYW4gaW5kaWNhdG9yIG9mIHRoZSBlbmQgb2YgdGhlIHJl cXVlc3QuDQoNCkl0IGlzIHRydWUgdGhhdCB0aGUgaXNzdWUgY2FuIGJlIGV2YWRlZCBieSBkb2lu ZyBvbmUncyBvd24gZnJhbWluZyBpbiB0aGUgYXBwbGljYXRpb24gbGF5ZXIuICM2NDMgZG9lcyB0 aGF0IGJ5IGludHJvZHVjaW5nIGEgQ0FOQ0VMX1JFUVVFU1QgZnJhbWUuDQoNCkJ1dCBJIGRvIG5v dCB0aGluayB0aGF0IHdlIHNob3VsZCByZXF1aXJlIGV2ZXJ5IGFwcGxpY2F0aW9uIHByb3RvY29s IGJ1aWx0IGFib3ZlIFFVSUMgdG8gZG8gaXRzIG93biBmcmFtaW5nLiBJbiBhZGRpdGlvbiB0byB0 aGF0LCBuZWVkIHRvIGtlZXAgdHdvIHVuaS1kaXJlY3Rpb25hbCBzdHJlYW1zIG9wZW4gd291bGQg Y29uc3VtZSBtb3JlIHJlc291cmNlcyB0aGFuIGJlaW5nIGFibGUgdG8gY2xvc2Ugb25lIGRpcmVj dGlvbiBvZiBhIGJpLWRpcmVjdGlvbmFsIHN0cmVhbSBhdCBhbiBlYXJsaWVyIG1vbWVudC4NCg0K PiBJbiB0aGUgbWVhbnRpbWUsIEkndmUgYmVlbiBjb25zaWRlcmluZyBvdGhlciBhbHRlcm5hdGl2 ZXMsIGluY2x1ZGluZyANCj4gdmFyaWF0aW9ucyBvbiBNaWtlJ3MgZGlyZWN0aW9uIGFuZCBhIHZh cmlhdGlvbiBvZiB0aGUgIkRvIE5vdGhpbmciIA0KPiBvcHRpb24gd2hpY2ggaW52b2x2ZWQgdGhl IGFwcGxpY2F0aW9uIHNpZ25hbGluZyB0byB0aGUgdHJhbnNwb3J0IHRoYXQgDQo+IHN0cmVhbXMg b2YgYSBjZXJ0YWluIHNvcnQoaWU6IHNlcnZlciB0byBjbGllbnQgZm9yIHNlcnZlciBwdXNoKSB3 ZXJlIA0KPiB1bmlkaXJlY3Rpb25hbCwgYXMgR1FVSUMgZG9lcyB0b2RheS4gIE92ZXJhbGwsIEkg dGhpbmsgdGhlIGFwcHJvYWNoIA0KPiBJJ3ZlIG91dGxpbmVkIGRvZXMgYSBnb29kIGpvYiBvZiBp dGVyYXRpbmcgb24gZXhpc3RpbmcgZGVwbG95bWVudCANCj4gZXhwZXJpZW5jZSBhbmQgYWRkaW5n IGV4cGxpY2l0IHNpZ25hbGluZyBmb3IgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyANCj4gaW5zdGVh ZCBvZiBpbXBsaWNpdCBzaWduYWxpbmcgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiAgVGhlcmUg YXJlIA0KPiBwcm9zIGFuZCBjb25zIHRvIGJvdGggZXhwbGljaXQgYW5kIGltcGxpY2l0IHNpZ25h bGluZywgYnV0IEkgdGhpbmsgDQo+IGV4cGxpY2l0IHNpZ25hbGluZyBpcyBtb3JlIGNvbXBsZXRl IGFuZCBsZXNzIHByb25lIHRvIGFwcGxpY2F0aW9uIGVycm9yLg0KPg0KPiBUaGFua3MsIElhbg0K Pg0KPg0KPiBPbiBXZWQsIEp1biAyOCwgMjAxNyBhdCA4OjE0IFBNLCBMdWJhc2hldiwgSWdvciA8 aWx1YmFzaGVAYWthbWFpLmNvbT4gd3JvdGU6DQo+Pg0KPj4gPiB1bmxlc3Mgd2hhdCB0aGUgdHJh bnNwb3J0IHByb3ZpZGVzIGlzIGEgcGVyZmVjdCBmaXQgZm9yIGFwcGxpY2F0aW9uIA0KPj4gPiBz ZW1hbnRpY3MsIHlvdSBlbmQgdXAgYnVpbGRpbmcgdGhvc2Ugc2VtYW50aWNzIGludG8gdGhlIGFw cGxpY2F0aW9uIGFueXdheS4NCj4+DQo+PiBJIGFncmVlIHdpdGggdGhpcy4gV2Ugc2hvdWxkIGF2 b2lkIGFkZGluZyBjb21wbGV4aXR5IGludG8gdHJhbnNwb3J0IA0KPj4gZm9yIHJhcmUgdXNlIGNh c2VzLCBzaW5jZSBpdCBnb2VzIGFnYWluc3QgS0lTUyBwcmluY2lwbGUuDQo+Pg0KPj4gT24gdGhl IG90aGVyIGhhbmQsIGFkZGluZyBzdXBwb3J0IGZvciBhIGJ5IGZhciB0aGUgbW9zdCBjb21tb24g dXNlIA0KPj4gY2FzZSBtYWtlcyBhIGxvdCBvZiBzZW5zZS4gIFRoaXMgaGVscHMgYXBwcyBhdm9p ZCBzY3Jld2luZyB1cCANCj4+IGltcGxlbWVudGluZyB0aGF0IGNvbW1vbiBjYXNlIGFuZCBsZXRz IHVzIG9wdGltaXplIHRoYXQgY29tbW9uIGNhc2UgDQo+PiBpbiB0aGUgbG93ZXIgbGF5ZXIuIEJp RGkgc3RyZWFtcyBhcmUgc3VjaCBjb21tb24gY2FzZXMuIFVuaSBzdHJlYW1zIA0KPj4gYXJlIGxp a2VseSB0byBiZSB0aGUgc2Vjb25kLW1vc3QtY29tbW9uIGNhc2VzIChoZW5jZSB5b3Ugb2ZmZXJl ZCB0aGlzIFBSIHRvIG9wdGltaXplIHRoZW0pLg0KPj4NCj4+DQo+PiBUaGUgQXNzb2NpYXRlZCBT dHJlYW1zIHByb3Bvc2FsIG9mZmVycyBleHRyYSBzZW1hbnRpYyBmbGV4aWJpbGl0eSBhdCANCj4+ IGEgY29zdCBvZiBzb21lIHNlbWFudGljIGNvbXBsZXhpdHkgKHNvbWVvbmUgd291bGQgbmVlZCB0 byB2ZXJpZnkgdGhhdCANCj4+IHRoZSBhc3NvY2lhdGVkIHN0cmVhbSBudW1iZXJzIG1ha2Ugc2Vu c2UgLS0gYXBpPyBhcHBzPykgYW5kIGEgZmV3IGV4dHJhIGJ5dGVzLg0KPj4NCj4+IEknZCBsaWtl IHRvIHdhaXQgdG8gc2VlIElhbidzIHJldmlzZWQgcHJvcG9zYWwuICBUaGUgaW5pdGlhbCBwcm9w b3NhbCANCj4+IG9mZmVyZWQgdG8gZG8gb25seSBvbmUgdGhpbmcgLS0gb2ZmZXIgYSBjaG9pY2Ug b2YgdW5pL2JpLWRpcmVjdGlvbmFsIA0KPj4gc3RyZWFtcw0KPj4gLS0gYnV0IGl0IGRpZCBpdCBp biBhIHZlcnkgc2ltcGxlIHdheSwgd2hpY2ggaXMgbmljZS4NCj4+DQo+PiAtIElnb3INCj4+DQo+ Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IE1hcnRpbiBUaG9tc29u IFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXQ0KPj4gU2VudDogV2VkbmVzZGF5LCBK dW5lIDI4LCAyMDE3IDc6MjggUE0NCj4+IFRvOiBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BA bWljcm9zb2Z0LmNvbT4NCj4+IENjOiBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1i cmlkZ2UsIFVLKSANCj4+IDx0aG9tYXMuc3dpbmRlbGxzQG5va2lhLmNvbT47IFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc+OyBNaWtrZWwgRmFobsO4ZSANCj4+IErDuHJnZW5zZW4gPG1pa2tlbGZqQGdt YWlsLmNvbT47IERtaXRyaSBUaWtob25vdiANCj4+IDxkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5j b20+OyBKbyBLdWxpayA8am9rdWxpa0Bnb29nbGUuY29tPg0KPj4gU3ViamVjdDogUmU6IFVuaWRp cmVjdGlvbmFsIHN0cmVhbXMgUFINCj4+DQo+PiBUaGVyZSBpcyBwcm9iYWJseSBhIHNpbXBsZXIg YXBwcm9hY2ggaGVyZSwgdGFrZSBhIGJpdCAoYXMgSWFuIGRpZCkgDQo+PiBhbmQgc2F5IHRoYXQg aWYgdGhhdCBiaXQgaXMgc2V0LCB0aGVuIHRoZSBzdHJlYW0gaXMgaW4gcmVzcG9uc2UgdG8gDQo+ PiBhbm90aGVyIGFuZCB0aGUgc3RyZWFtIElEIG9mIHRoZSBzdHJlYW0gdG8gd2hpY2ggdGhpcyBp cyByZXNwb25kaW5nIA0KPj4gZm9sbG93cyBpbW1lZGlhdGVseSBhZnRlciB0aGUgc3RyZWFtIElE IG9mIHRoZSBzdHJlYW0gaXRzZWxmLiAgWW91IA0KPj4gY291bGQgdGhlbiBpbmNsdWRlIHRoYXQg b25seSBhdCB0aGUgc3RhcnQgb2YgdGhlIHN0cmVhbSwgb3IgaW4gbXVsdGlwbGUgZnJhbWVzIChv ciBhcyB3ZSBkZWNpZGUpLg0KPj4NCj4+IFRoZSBwcm9ibGVtIHdpdGggdGhpcywgYXMgd2l0aCBz ZXZlcmFsIG9mIHRoZSBvdGhlciBpc3N1ZXMgd2UncmUgDQo+PiBkaXNjdXNzaW5nLCBpcyB0aGF0 IHVubGVzcyB3aGF0IHRoZSB0cmFuc3BvcnQgcHJvdmlkZXMgaXMgYSBwZXJmZWN0IA0KPj4gZml0 IGZvciBhcHBsaWNhdGlvbiBzZW1hbnRpY3MsIHlvdSBlbmQgdXAgYnVpbGRpbmcgdGhvc2Ugc2Vt YW50aWNzIA0KPj4gaW50byB0aGUgYXBwbGljYXRpb24gYW55d2F5LiAgSFRUUCBjZXJ0YWlubHkg Y2FuJ3Qgc3Vydml2ZSB3aXRob3V0IA0KPj4gaXRzIG93biBhc3NvY2lhdGlvbiBzZW1hbnRpY3Mg Zm9yIHB1c2hlcy4gIFRoYXQgc3VnZ2VzdHMgdG8gbWUgdGhhdCANCj4+IGhhdmluZyBiaWRpcmVj dGlvbmFsIHNlbWFudGljcyBpbiB0aGUgdHJhbnNwb3J0IGNyZWF0ZXMgbW9yZSANCj4+IGR1cGxp Y2F0aW9uIHRoYW4gb3RoZXJ3aXNlLiAgSGVuY2UgbXkgcHJvcG9zYWwuDQo+Pg0KPj4gT24gMjgg SnVuZSAyMDE3IGF0IDE1OjI2LCBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0 LmNvbT4NCj4+IHdyb3RlOg0KPj4gPiBBcyBwcm9taXNlZCwgYSBQUiBmb3IgYWRkaW5nIOKAnGFz c29jaWF0ZWQgc3RyZWFtc+KAnSBpcyBhdCANCj4+ID4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3 Zy9iYXNlLWRyYWZ0cy9wdWxsLzY3Mi4gIFRoaXMgdmVyeSANCj4+ID4gZGVsaWJlcmF0ZWx5IGJ1 aWxkcyBvbiB0b3Agb2YgTVTigJlzIFBSIOKAkyBpdOKAmXMgYWRkaW5nIGEgcHJpbWl0aXZlIA0K Pj4gPiB3aGljaCBjYW4gYmUgdXNlZCB0byBjb25zdHJ1Y3QgdmFyaW91cyBhYnN0cmFjdGlvbnMg YXRvcCANCj4+ID4gdW5pZGlyZWN0aW9uYWwgc3RyZWFtcywgYnV0IHRoZSBsaWZlY3ljbGUgaXMg c3RpbGwgZnVuZGFtZW50YWxseSB1bmlkaXJlY3Rpb25hbC4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ ID4gQ29weWluZyBteSBub3RlcyBoZXJlIGZvciBsaXN0IGRpc2N1c3Npb24gcHVycG9zZXMuDQo+ PiA+DQo+PiA+IE1ham9yIGNoYW5nZXMNCj4+ID4NCj4+ID4gTGV2ZXJhZ2luZyBAaWdvcmxvcmQn cyBpbnNpZ2h0IHRoYXQgT089MDAgb25seSBvY2N1cnMgb24gdGhlIGZpcnN0IA0KPj4gPiBTVFJF QU0gZnJhbWUgb2YgYSBzdHJlYW0sIEkgdXNlZCB0aGF0IGFzIHRoZSB0cmlnZ2VyIGZvciBhIFN0 cmVhbSANCj4+ID4gUHJvcGVydGllcyBieXRlLg0KPj4gPiBUd28gYml0cyBvZiB0aGF0IGJ5dGUg ZGVzY3JpYmUgdGhlIGRpcmVjdGlvbmFsaXR5IG9mIHRoZSBzdHJlYW06DQo+PiA+DQo+PiA+IFVu aWRpcmVjdGlvbmFsIChubyByZXNwb25zZSBleHBlY3RlZCkgSW5pdGlhbCBiaWRpcmVjdGlvbmFs IChvbmUgDQo+PiA+IHJlc3BvbnNlIGV4cGVjdGVkKSBJbml0aWFsIG11bHRpLXJlc3BvbnNlIChv bmUgb3IgbW9yZSByZXNwb25zZXMgDQo+PiA+IGV4cGVjdGVkOyBuZWVkcyBhIGJldHRlciBuYW1l KSBSZXNwb25zZQ0KPj4gPg0KPj4gPiBJZiB0aGUgdHlwZSBpcyBSZXNwb25zZSwgdGhlcmUncyBh biBBc3NvY2lhdGVkIFN0cmVhbSBJRCBmaWVsZCwgDQo+PiA+IGxlbmd0aCBnaXZlbiBieSB0d28g bW9yZSBiaXRzIGZvbGxvd2luZyB0aGUgc2FtZSBwYXR0ZXJuIGFzIHRoZSBTUyANCj4+ID4gYml0 cyBpbiB0aGUgU1RSRUFNIGZyYW1lIElELg0KPj4gPg0KPj4gPiBQZXJzb25hbCBPcGluaW9uDQo+ PiA+DQo+PiA+IE9uIHRoZSBwbHVzIHNpZGUsIHRoZXNlIHN0cmVhbSB0eXBlcyBzZWVtIHRvIGNv dmVyIHRoZSBhYnN0cmFjdGlvbnMgDQo+PiA+IEkgY2FuIGVudmlzaW9uIGZvciBtb3N0IGFwcGxp Y2F0aW9ucy4gWW91IGNhbiB1bmlsYXRlcmFsbHkgc2VuZCANCj4+ID4gc29tZXRoaW5nICh1bmlk aXJlY3Rpb25hbCksIGRvIHJlcXVlc3QvcmVzcG9uc2UgKGJpZGlyZWN0aW9uYWwpLCBvciANCj4+ ID4gcHViL3N1YiAoc2luZ2xlIHN1YnNjcmlwdGlvbiBzdHJlYW0sIHNlcmllcyBvZiB1cGRhdGUg c3RyZWFtcykuDQo+PiA+DQo+PiA+IEkgZG9uJ3QgY2FyZSBmb3IgdGhlIGZhY3QgdGhhdCBJIHN0 aWxsIG5lZWQgdGhlIHN0cmVhbSB0eXBlIGhlYWRlciANCj4+ID4gaW4gSFRUUCBhZnRlciBwdXR0 aW5nIHRoaXMgaW4gdGhlIHRyYW5zcG9ydC4gVGhhdCB3aWxsIGJlIA0KPj4gPiBhbWVsaW9yYXRl ZCBpZiB3ZSBnbyBiYWNrIHRvIG9uZSBzdHJlYW0gcGVyIHJlcXVlc3QsIHNpbmNlIGFsbCANCj4+ ID4gdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyB3aWxsIGJlIHB1c2ggc3RyZWFtcy4gKEFzIGEgc2lk ZS1ub3RlLCBJIA0KPj4gPiBjb25zaWRlcmVkIHVzaW5nIHRoZSBtdWx0aXBsZS1yZXNwb25zZSBv cHRpb24gaW4gdGhlIEhUVFAgbWFwcGluZywgDQo+PiA+IGJ1dCB0aGVuIEkgbmVlZCBhIHN0cmVh bSBoZWFkZXIgYWdhaW4gdG8gaW5kaWNhdGUgd2hpY2ggaXMgdGhlIA0KPj4gPiByZXNwb25zZSBh bmQgd2hpY2ggdGhlIHB1c2hlcy4pDQo+PiA+DQo+PiA+IEkgcGFydGljdWxhcmx5IGRvbid0IGxp a2UgdGhhdCB5b3Ugbm93IGhhdmUgdG8gbG9vayBhdCB0aGUgZnJhbWUgDQo+PiA+IHR5cGUgaGVh ZGVyIHRvIGZpbmQgb3V0IHdoZXRoZXIgYSBmaWVsZCBleGlzdHMgd2hpY2ggdGVsbHMgeW91IHRo ZSANCj4+ID4gbGVuZ3RoIG9mIHNvbWV0aGluZyBlbHNlIGluIHRoZSBoZWFkZXIuIEknZCBsaWtl IHRvIHNpbXBsaWZ5IHRoYXQuIA0KPj4gPiBJIHdlbnQgd2l0aCB0aGlzIG1vZGVsIG92ZXIgYSBD UkVBVEVfU1RSRUFNIGZyYW1lIGJlY2F1c2Ugb2YgDQo+PiA+IEBtaWtrZWxmaidzIHVzZS1jYXNl IG9mIHZlcnkgc21hbGwgbWVzc2FnZXMNCj4+ID4gLS0gdGhpcyBhZGRzIG9ubHkgb25lIGJ5dGUg dG8gdGhlIGZpcnN0IGZyYW1lIG9uIGEgc3RyZWFtIGluIG9uZSANCj4+ID4gZGlyZWN0aW9uIGFu ZCAyLTUgYnl0ZXMgdG8gdGhlIGZpcnN0IGZyYW1lIG9mIHJlc3BvbnNlIHN0cmVhbXMuIEEgDQo+ PiA+IHNlcGFyYXRlIGZyYW1lIHR5cGUgd291bGQgYmUgc29tZXdoYXQgbGFyZ2VyLCBidXQgY291 bGQgYmUgY2xlYW5lciANCj4+ID4gaW4gdGhhdCByZXNwZWN0Lg0KPj4gPg0KPj4gPg0KPj4gPg0K Pj4gPg0KPj4gPg0KPj4gPiBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgU3dpbmRlbGxzLCANCj4+ID4gVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJy aWRnZSwgVUspDQo+PiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyOCwgMjAxNyA3OjU2IEFNDQo+ PiA+IFRvOiBKbyBLdWxpayA8am9rdWxpa0Bnb29nbGUuY29tPjsgTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiANCj4+ID4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCj4+ID4gQ2M6IFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc+OyBEbWl0cmkgVGlraG9ub3YgDQo+PiA+IDxkdGlraG9ub3ZAbGl0ZXNwZWVk dGVjaC5jb20+DQo+PiA+IFN1YmplY3Q6IFJFOiBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBSDQo+ PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEkgYWdyZWUgdGhhdCBsb29raW5nIGF0IHRoZSBsYXllcnMg b2YgYWJzdHJhY3Rpb24gaXMgdXNlZnVsLiBJbiANCj4+ID4gcHJpbmNpcGxlIGhhdmluZyB0aGUg d2lyZSBwcm90b2NvbCBqdXN0IGhhdmUgY29uc3RydWN0cyBmb3IgDQo+PiA+IHVuaWRpcmVjdGlv bmFsIHN0cmVhbXMgZG9lcyBub3QgaW4gaXRzZWxmIGxpbWl0IGNyZWF0aW5nIA0KPj4gPiBiaS1k aXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uIGZsb3dzLCBzdXBwb3J0ZWQgYXQgZWl0aGVyIHRoZSBs aWJyYXJ5IA0KPj4gPiBvciBhcHBsaWNhdGlvbiBsYXllci4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ ID4gSG93ZXZlciwgdGhlcmUgbmVlZCB0byBiZSBhIHN0YW5kYXJkIHdheSBvZiBkb2luZyBiaS1k aXJlY3Rpb25hbCANCj4+ID4gY29tbXVuaWNhdGlvbiBmb3IgbWlncmF0aW5nIGFwcGxpY2F0aW9u cyBpbXBsZW1lbnRlZCB1c2luZyBhIHNvY2tldCANCj4+ID4gc3R5bGUgYXBpLiBJdCBuZWVkcyB0 byBiZSBlYXN5IHRvIG1vdmUgYW4gZXhpc3RpbmcgYXBwbGljYXRpb24gZnJvbSANCj4+ID4gVENQ IHRvIFFVSUMuDQo+PiA+IFRoaXMgbW92ZSBtYXkgYmUgYXR0cmFjdGl2ZSBpbiBtYW55IHNpdHVh dGlvbnMgYXMgUVVJQyBnaXZlcyANCj4+ID4gaW1wcm92ZWQgc2VjdXJpdHkgYW5kIG1heSBhbGxv dyBncmVhdGVyIHRocm91Z2hwdXQgZHVlIHRvIHRoZSBtb3JlIA0KPj4gPiBtb2Rlcm4gKGFuZA0K Pj4gPiBjdXN0b21pemFibGUpIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zIGNvbXBhcmVk IHRvIHRoZSBPUyBUQ1AgDQo+PiA+IHN0YWNrLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBGb3Ig bWlncmF0aW5nIHN0YW5kYXJkIHNvY2tldCBhcGkgYXBwbGljYXRpb25zIEkgZG9u4oCZdCB0aGlu ayBpdCANCj4+ID4gd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gbGVhdmUgdGhlIHdvcmsgdG8gdGhl IGFwcGxpY2F0aW9uIHRvIGRvIA0KPj4gPiBjb3JyZWxhdGlvbiwgYXQgbGVhc3QgdGhlIGxpYnJh cnkgc2hvdWxkIGJlIHByb3ZpZGluZyB0aGlzIHNlcnZpY2UgDQo+PiA+IHVzaW5nIHRoZSB3aXJl IHByb3RvY29sIGFzIGFwcHJvcHJpYXRlLiBDbGVhcmx5IHdlIHdhbnQgYSBjbGllbnQgDQo+PiA+ IHdyaXR0ZW4gd2l0aCBvbmUgbGlicmFyeSB0byBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHN1Y2Nl c3NmdWxseSANCj4+ID4gd2l0aCBhIHNlcnZlciB3cml0dGVuIHVzaW5nIGEgZGlmZmVyZW50IGxp YnJhcnkuDQo+PiA+IFRoaXMgbmVlZHMgc29tZSBmb3JtIG9mIHN0YW5kYXJkaXphdGlvbiBvZiB0 aGUgc2lnbmFsbGluZy4gVGhpcyANCj4+ID4gY291bGQgZWl0aGVyIGJlIGEgYnVpbGRpbmcgYmxv Y2sgb3ZlcmxheSBvbiB0b3Agb2YgUVVJQywgb3IgDQo+PiA+IGltcGxlbWVudGVkIGF0IHRoZSB3 aXJlIHByb3RvY29sIGxldmVsLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBJbiB0ZXJtcyBvZiBw YXR0ZXJucyBJIHRoaW5rIHRoZSBmb2xsb3dpbmcgbWF5IGJlIHNvbWUgb2YgdGhlIG1vc3QgDQo+ PiA+IGNvbW1vbiBwYXR0ZXJucyAod2l0aCBwb3RlbnRpYWwgdG8gYmUgcHJvdmlkZWQgYXQgdGhl IGxpYnJhcnkgYW5kIA0KPj4gPiBvciB3aXJlIHByb3RvY29sIGxldmVsKS4NCj4+ID4NCj4+ID4g SS9PIHBhdHRlcm4gIDogRXhhbXBsZQ0KPj4gPg0KPj4gPiAxLzAgICA6IEFuIGlucHV0IG9ubHkg ZmxvdywgcGVyaGFwcyBhIGRhdGEgbG9nZ2VyIGxpa2Ugc3lzbG9nIHdpdGggbm8NCj4+ID4gY29u ZmlybWF0aW9uL2ZlZWRiYWNrDQo+PiA+DQo+PiA+IDAvMSAgOiBhbiBvdXRwdXQgb25seSBmbG93 LCBwZXJoYXBzIGEgdG9waWMgbWVzc2FnZSBidXMgc2VydmljZSANCj4+ID4gd2l0aCBubyBjb25m aXJtYXRpb24vZmVlZGJhY2sNCj4+ID4NCj4+ID4gMS8xIDogc3RhbmRhcmQgVENQIGFwcGxpY2F0 aW9ucyB3aXRoIGEgc2luZ2xlIGZsb3cgcGVyIGNvbm5lY3Rpb24NCj4+ID4NCj4+ID4gMS8qIDog c2luZ2xlIGlucHV0LCBtYW55IG91dHB1dCwgbW9kZWxsaW5nIFNURElOL1NURE9VVCtTVERFUlIN Cj4+ID4NCj4+ID4gKDEvMSkqIDogbXVsdGlwbGV4ZWQgcGFpcnMgb2YgZmxvd3Mg4oCTIHN1cHBv cnRpbmcgbXVsdGlwbGUgc29ja2V0cyANCj4+ID4gbXV4ZWQgb250byBhIHNpbmdsZSBRVUlDIGNv bm5lY3Rpb24NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gT2J2aW91c2x5LCBhbiBhcHBsaWNhdGlv biB3b3VsZCBhbHdheXMgaGF2ZSB0aGUgb3B0aW9uIHRvIGNvbWJpbmUgDQo+PiA+IGFueSBzaW5n bGUgZGlyZWN0aW9uIGZsb3dzIHdpdGggYXBwbGljYXRpb24gbGV2ZWwgY29ycmVsYXRvcnMgdG8g DQo+PiA+IGNvbnN0cnVjdCBtb3JlIGNvbXBsZXggZmxvd3MgaWYgZGVzaXJlZC4NCj4+ID4NCj4+ ID4NCj4+ID4NCj4+ID4gQXQgdGhlIG1vbWVudCBteSBndXQgc2F5cyB0aGUgMS8xIHVzZS1jYXNl IGlzIGNvbW1vbiBlbm91Z2ggdGhhdCANCj4+ID4gdGhlIHdpcmUgcHJvdG9jb2wgc2hvdWxkIHBy b3ZpZGUgYSBzdGFuZGFyZCBtZWNoYW5pc20gdG8gc3VwcG9ydCBpdCANCj4+ID4gYXMgYSBzdGFu ZGFyZCBvdmVybGF5IHdvdWxkIHByb2JhYmx5IGVuZCB1cCBiZWluZyB0cmVhdGVkIGFzIHBhcnQg DQo+PiA+IG9mIHRoZSB3aXJlIGZvcm1hdCBhbnl3YXkuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+ IFBlcmhhcHMgc3RyZWFtcyBzaG91bGQgYmUgZXhwbGljaXRseSBjcmVhdGVkIHdpdGggYSBDUkVB VEVfU1RSRUFNIA0KPj4gPiBmcmFtZSB3aGljaCB3b3VsZCBiZSBjYXBhYmxlIG9mIGRlZmluaW5n IG11bHRpcGxlIHJlbGF0ZWQgc3RyZWFtcz8NCj4+ID4NCj4+ID4gVGhlcmUgaXMgdGhlIG9wdGlv biBvZiB3aGV0aGVyIG9ubHkgKDEvMSkgcGFpcnMgY2FuIGJlIGNyZWF0ZWQgdGhpcyANCj4+ID4g d2F5LCBvcg0KPj4gPiAoMS9uKSBjb21iaW5hdGlvbnMgY291bGQgYmUgc3VwcG9ydGVkICh3aXRo IGFuIGFwcGxpY2F0aW9uIGRlZmluZWQgDQo+PiA+IHdheSB0byBpZGVudGlmeSB0aGUgdXNlIG9m IGVhY2ggb2YgdGhlIG91dHB1dCBzdHJlYW1zKS4gQSBzdGVwIA0KPj4gPiBmdXJ0aGVyIG1heSBi ZSB0aGF0IHRoZXJlIGlzIGEgdHJhbnNwb3J0IHBhcmFtZXRlciB0aGF0IGRlZmluZXMgDQo+PiA+ IHdoZXRoZXIgdGhlIHNlcnZlciBpcyBhbGxvd2VkIHRvIGNyZWF0ZSBhZGRpdGlvbmFsIHN0cmVh bXMsIG9yIGlmIA0KPj4gPiBzdHJlYW0gY3JlYXRpb24gaXMgcHVyZWx5IGNsaWVudCBkcml2ZW4g KGxpa2UgVENQKS4gSSBkb27igJl0IGtub3cgaWYgDQo+PiA+IGVpdGhlciBvZiB0aGVzZSB3b3Vs ZCBzaW1wbGlmeSBob3cgdG8gaGFuZGxlIHN0cmVhbSBhY2NvdW50aW5nLCBhbmQgDQo+PiA+IGlu IHBhcnRpY3VsYXIgb25seSBjcmVhdGluZyBhIGZsb3cgd2hlbiBhbGwgcGFydGllcyBoYXZlIHN1 ZmZpY2llbnQgYWxsb3dhbmNlcyBsZWZ0Lg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBUaG9tYXMN Cj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvIEt1bGlrDQo+PiA+IFNlbnQ6IDI4IEp1bmUgMjAxNyAx NTowOQ0KPj4gPiBUbzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwu Y29tPg0KPj4gPiBDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IERtaXRyaSBUaWtob25vdiAN Cj4+ID4gPGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbT4NCj4+ID4gU3ViamVjdDogUmU6IFVu aWRpcmVjdGlvbmFsIHN0cmVhbXMgUFINCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gSSdkIGxpa2Ug dG8gcG9wIGJhY2sgdXAgdG8gYSBjb21tZW50IElnb3IgbWFkZSBsYXN0IHdlZWssIGJlY2F1c2Ug SSANCj4+ID4gZmluZCBpdCBoZWxwZnVsIGluIHRoaW5raW5nIGFib3V0IHRoZSBkZXNpZ24gc3Bh Y2U6DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEkgdGhpbmsgb2YgdGhyZWUgbGF5ZXJzIG9mIGFi c3RyYWN0aW9uOg0KPj4gPg0KPj4gPiAxLiAgICAgICBRVUlDIFdpcmUgUHJvdG9jb2wgKHRoZSB0 aGluZyBkZXNjcmliZWQgYnkgdGhlIFFVSUMgVHJhbnNwb3J0DQo+PiA+IFJGQykNCj4+ID4gMi4g ICAgICAgUVVJQyBMaWJyYXJ5IEFQSSAoYSBsaWJyYXJ5IGV4cG9zaW5nIHNvbWUgdXNlZnVsIGFi c3RyYWN0aW9ucw0KPj4gPiAtLQ0KPj4gPiBzdWNoIGFzIGJsb2NraW5nL25vbi1ibG9ja2luZyB1 bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFuZCANCj4+ID4gYmlkaXJlY3Rpb25hbCDigJxzb2NrZXRz 4oCdIC0tIGFuZCBpbXBsZW1lbnRpbmcgdGhlbSB1c2luZyBRVUlDIFdpcmUgUHJvdG9jb2wpDQo+ PiA+IDMuICAgICAgIEFwcGxpY2F0aW9uIChzb21ldGhpbmcgdGhhdCB1c2VzIFFVSUMgTGlicmFy eSBBUElzKQ0KPj4gPg0KPj4gPiBJIHRoaW5rIHRoZXJlIGlzIHNvbWUgYXJndW1lbnQgdG8gYmUg bWFkZSB0aGF0IE1hcnRpbidzIG9yaWdpbmFsIA0KPj4gPiBwcm9wb3NhbCBkaWQgbm90IHRha2Ug aW50byBhY2NvdW50IGhvdyB3ZSB3b3VsZCBhY2hpZXZlICgyKSBmb3IgDQo+PiA+IGJpLWRpcmVj dGlvbmFsIHN0cmVhbXMuICAoSSBkb24ndCB0aGluayBpdCBzdHJpY3RseSBzYWlkICJ0aG91IA0K Pj4gPiBzaGFsdCBub3QgZG8gKDIpIiBlaXRoZXIsIGJ1dCB0aGF0IGlzIHVwIHRvIGludGVycHJl dGF0aW9uLikNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gU2V2ZXJhbCBwZW9wbGUgaGF2ZSBhcmd1 ZWQgdGhhdCB3ZSBkbyBub3Qgd2FudCBldmVyeSBhcHBsaWNhdGlvbiB0byANCj4+ID4gaGF2ZSB0 byByZS1pbXBsZW1lbnQgYmktZGlyZWN0aW9uYWwgc3RyZWFtcyAoMykgZm9yIGV2ZXJ5IA0KPj4g PiBhcHBsaWNhdGlvbiwgYW5kIHRoaXMgaXMgbm90IGhvdyBnLXF1aWMgKG91ciBsYXJnZXN0IGRl cGxveW1lbnQpIHdvcmtzIHJpZ2h0IG5vdy4NCj4+ID4gVGhlc2UgYXJndW1lbnRzIG1ha2Ugc2Vu c2UgdG8gbWUsIGJ1dCBZTU1WLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBKdXN0IGJlY2F1c2Ug dGhlIHBhcnRpY3VsYXIgKm1lY2hhbmlzbSogdGhhdCBpcyBiZWluZyBwcm9wb3NlZCBoYXMgDQo+ PiA+IHNvbWUgaXNzdWVzLCBob3dldmVyLCBkb2Vzbid0IHNjcmVhbSBvdXQgdG8gbWUsIGF0IGxl YXN0LCB0aGF0IHdlIA0KPj4gPiBzaG91bGQgYWJhbmRvbiB0aGlzIHBhcnRpY3VsYXIgKmRlc2ln biBnb2FsKi4gIFRoZSBnb2FsIGJlaW5nIGEgDQo+PiA+IHRyYW5zcG9ydCBwcm90b2NvbCB0aGF0 IGNhbiBlbGVnYW50bHkgZml0IHdpdGggYSB1bmkvYmkgc3RyZWFtIG1vZGVsLg0KPj4gPiBOb3cs IGlmIHdlIGNvbmNsdWRlIHRoYXQgdGhlcmUgY2FuIG5ldmVyIGJlIGFuIGVsZWdhbnQgbW9kZWwg dGhhdCANCj4+ID4gYWNoaWV2ZXMgdGhpcyBnb2FsLCB0aGVuIHNvIGJlIGl0LiAgQnV0IEkgYWxz byBmZWVsIGxpa2Ugd2UgaGF2ZW4ndCANCj4+ID4gcmVhY2hlZCB0aGF0IHBvaW50IGluIHRoZSBk aXNjdXNzaW9uIHlldC4gIChBdCB0aGUgdmVyeSBsZWFzdCwgdGhpcyANCj4+ID4gZGlzY3Vzc2lv biBoYXMgYmVlbiBmcnVpdGZ1bCB0byBtZSBpbiB0ZXJtcyBvZiBtYXBwaW5nIHRoZSBkZXNpZ24g DQo+PiA+IHNwYWNlIGFuZCBlbHVjaWRhdGluZyByZXF1aXJlbWVudHMpLg0KPj4gPg0KPj4gPg0K Pj4gPg0KPj4gPiBPbmUgb2YgdGhlIHJlYXNvbnMgSSBzdGlsbCB0aGluayB0aGlzIGRlc2lnbiBn b2FsIGlzIHVuZGVyIA0KPj4gPiBjb25zaWRlcmF0aW9uIGlzIHRoYXQgSWFuIGFuZCBJZ29yL01p a2UgaGF2ZSBiZWVuIHRhbGtpbmcgYWJvdXQgDQo+PiA+IGFsdGVybmF0ZSBzb2x1dGlvbnMgd2hp Y2ggaGF2ZSBhIHNpbWlsYXIgZmxhdm9yLiAgRHVyaW5nIHRoZSByZWNlbnQgDQo+PiA+ICJxdWll dCJuZXNzIG9uIHRoZSB0aHJlYWQsIHBlcnNvbmFsbHksIEkndmUgYmVlbiB3YWl0aW5nIHRvIGhl YXIgDQo+PiA+IG1vcmUgZnJvbSB0aGVtLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBPbiBXZWQs IEp1biAyOCwgMjAxNyBhdCA5OjQxIEFNLCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIA0KPj4g PiA8bWlra2VsZmpAZ21haWwuY29tPiB3cm90ZToNCj4+ID4NCj4+ID4gSW4gcmVwbHkgdG8gUmFu amVldGgNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gSXQgaXMgbm90IG9ubHkgYSBtYXR0ZXIgb2Yg c2ltcGxpY2l0eSBmb3IgdGhlIHNha2Ugb2Ygc2ltcGxpY2l0eToNCj4+ID4NCj4+ID4NCj4+ID4N Cj4+ID4gLSBBIGNvbXBsZXggdHJhbnNwb3J0IGxheWVyIG1pZ2h0IGVuZCB1cCBiZWluZyBwb29y bHkgaW1wbGVtZW50ZWQgDQo+PiA+IGxlYWRpbmcgdG8gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5 IGFuZCB1bHRpbWF0ZWx5IGFkb3B0aW9uLiBUaGlzIA0KPj4gPiBjb21wbGV4aXR5IGlzIG5vdCBv bmx5IGluIGltcGxlbWVudGF0aW9uIGJ1dCBhbHNvIGluIHVuZGVyc3RhbmRpbmcgDQo+PiA+IHRo ZSBleGFjdCBzZW1hbnRpY3Mgb2Ygc3RyZWFtIGxpZmV0aW1lLiBFdmVuIGlmIHRoZSBzcGVjIGlz IA0KPj4gPiBzdWZmaWNpZW50bHkgY2xlYXIsIGl0IHdpbGwgc3RpbGwgYmUgb3BlbiB0byBtaXNp bnRlcnByZXRhdGlvbnMuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IC0gQmktZGlyZWN0aW9uYWwg c3RhdGUgbWF5IGhhdmUgdG8gYmUgbWFpbnRhaW5lZCBsb25nZXIgYW5kIHdpdGggDQo+PiA+IG1v cmUgb3ZlcmhlYWQgdGhhbiB3aXRoIHVuaS1kaXJlY3Rpb25hbCBzdHJlYW1zLCBlc3BlY2lhbGx5 IHVuZGVyIA0KPj4gPiBsb3NzLCBwb3RlbnRpYWxseSBsZWFkaW5nIHRvIHBvb3IgcGVyZm9ybWFu Y2UgYW5kIHBvb3IgcmVzb3VyY2UgDQo+PiA+IHV0aWxpc2F0aW9uIGJlY2F1c2UgdGhlIHRyYW5z cG9ydCBsYXllciBoYXMgaW5zdWZmaWNpZW50IGluZm9ybWF0aW9uLg0KPj4gPg0KPj4gPg0KPj4g Pg0KPj4gPiAtIFRoZSBleHRyYSBjb21wbGV4aXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBt YXkgYmUgb3ZlcnN0YXRlZCAtIA0KPj4gPiBpdCBpcyBzaWduaWZpY2FudGx5IHNpbXBsZXIgdG8g bWFuYWdlIGEgbWFwIHRoYXQgYXNzb2NpYXRlcyB0byB0d28gDQo+PiA+IHN0cmVhbXMgdGhhbiBp dCBpcyB0byBtYWludGFpbiBiaS1kaXJlY3Rpb25hbCBzdGF0ZSBhdCB0aGUgDQo+PiA+IHRyYW5z cG9ydCBsYXllci4gSXQgaXMgZXZlbiBwb3NzaWJsZSB0byBpbXBsaWNpdGx5IGxpbmsgc3RyZWFt cyANCj4+ID4gd2l0aCBzYW1lIGlkZW50aWZpZXJzLCBlLmcuIGluIGEgUlBDIHNjZW5hcmlvLiBU aGF0IHNhaWQsIEkgZG8gc2VlIA0KPj4gPiBhIHBvdGVudGlhbCBiZW5lZml0IG9mIGEgd3JhcHBl ciB0aGF0IGltcGxlbWVudHMgdGhlIGNvbW1vbiBiaS1kaXJlY3Rpb25hbCBjYXNlLg0KPj4gPg0K Pj4gPg0KPj4gPg0KPj4gPiAtIENvbXBsZXhpdHkgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIG1h eSBiZSBkdXBsaWNhdGVkLCBidXQgDQo+PiA+IGltcGxlbWVudGF0aW9uIGVycm9ycyBhcmUgYWxz byBpc29sYXRlZCB0byB0aGF0IGFwcGxpY2F0aW9uLg0KPj4gPiBTcGVjaWZpY2FsbHkgZm9yIEhU VFAgSSB3b3VsZCBhc3N1bWUgdGhhdCBRVUlDIHRyYW5zcG9ydCBhbmQgUVVJQyANCj4+ID4gSFRU UCBpbXBsZW1lbnRlcnMgd291bGQgYmUgbGFyZ2UgdGhlIHNhbWUgZm9yIGEgbG9uZyB0aW1lIHRv IGNvbWUsIA0KPj4gPiBzbyBJIHdvdWxkIG5vdCBleHBlY3QgdGhlIHRyYWRlb2ZmIGhlcmUgdG8g YmUgcGFydGljdWxhcmx5IGNvbmNlcm5pbmcuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IC0gVW5p eCBwaXBlcyBhcmUgdHJhZGl0aW9uYWxseSBjb25zdHJ1Y3RlZCBhcyBhIHBhaXIgb2YgDQo+PiA+ IHVuaS1kaXJlY3Rpb25hbCBmaWxlIGRlc2NyaXB0b3JzIGFuZCB0aGF0IGlzIGEgcmVhc29uYWJs eSBwcm92ZW4gDQo+PiA+IG1vZGVsLiBD4oCZcyBzdGFuZGFyZCBsaWJyYXJ5IHN0ZGluLCBzdGRv dXQgYW5kIHN0ZGVyciBpcyBhbiBleGFtcGxlIA0KPj4gPiBvZiBhbiBhc3ltbWV0cmljIG1vZGVs IHdpdGggaW1wbGljaXQgbGlua2FnZSBiZXR3ZWVuIA0KPj4gPiB1bmktZGlyZWN0aW9uYWwgZmls ZSBkZXNjcmlwdG9ycy4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gLSBUaGVyZSBhcmUgbG90cyBv ZiB1c2UgY2FzZXMgZm9yIG5vbi1IVFRQIGxpa2UgY29ubmVjdGl2aXR5IC0gDQo+PiA+IEthZmth IGhpZ2ggdm9sdW1lIG1lc3NhZ2UgcXVldWluZyBmb3IgZXhhbXBsZS4gVGhlIGluZHVzdHJ5IHRy ZW5kIA0KPj4gPiBhcHBlYXJzIHRvIG1vdmUgdG93YXJkcyBhc3luY2hyb25vdXMgcHJvY2Vzc2lu ZyBhbmQgbWVzc2FnaW5nLiBJdCANCj4+ID4gZGVwZW5kcyBvbiB3aGV0aGVyIHlvdSBsb29rIGF0 IFFVSUMgYXMgYSBUQ1AgKyBUTFMgcmVwbGFjZW1lbnQsIG9yIA0KPj4gPiBhcyBhIEhUVFBTIC8g UkVTVCBSUEMgcmVwbGFjZW1lbnQuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IC0gVW5pLWRpcmVj dGlvbmFsIHN0cmVhbXMgbWF5IGN1cnJlbnRseSBiZSB1bnByb3ZlbiBpbiB0aGUgd2lsZCwgDQo+ PiA+IGJ1dCBhIHByb3Bvc2FsIGlzIG5lZWRlZCBiZWZvcmUgYW4gaW1wbGVtZW50YXRpb24gY2Fu IGJlIG1hZGUgYW5kIA0KPj4gPiB0ZXN0ZXQuIEkgYWdyZWUgdGhhdCBpdCBpcyBlYXN5IHRvIGRl c2lnbiBpbnRvIHdyb25nIGFzc3VtcHRpb25zIA0KPj4gPiB3aXRob3V0IHJlYWwgd29ybGQgdGVz dGluZy4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gLSBUaGVyZSB3aWxsIGhvcGVmdWxseSBub3Qg YmUgYSBsYXJnZSBudW1iZXIgb2Ygc3VjY2Vzc29ycyB0byBRVUlDIA0KPj4gPiAtIHBlcmhhcHMg c29tZSBwdXJwb3NlIHNwZWNpZmljIHZhcmlhbnRzLCBlLmcuIGZvciBlbWJlZGRlZCB1c2UuDQo+ PiA+IFdpZGVzcHJlYWQgYWRhcHRhdGlvbiBhbmQgY29tcGF0aWJpbGl0eSBpcyB2ZXJ5IG5lY2Vz c2FyeSBzbyBpdCANCj4+ID4gbWFrZXMgc2Vuc2UgdG8gaGF2ZSBRVUlDIGJlaW5nIHN1ZmZpY2ll bnRseSBzaW1wbGUgYW5kIGV4cHJlc3NpdmUgDQo+PiA+IHRvIGFjaGlldmUgdGhpcyBnb2FsLiBB IHBvbHltb3JmIFFVSUMgd2lsbCBub3QgYWNoaWV2ZSB0aGF0IGdvYWwuIA0KPj4gPiBPbiB0aGUg b3RoZXIgaGFuZCwgYSBzb2xpZCBRVUlDIGZvdW5kYXRpb24gY2FuIGJlIHVzZWQgZm9yIGEgbGFy Z2UgDQo+PiA+IG51bWJlciBvZiBhcHBsaWNhdGlvbiBwcm90b2NvbHMuDQo+PiA+DQo+PiA+DQo+ PiA+DQo+PiA+IC0gRmluYWxseSwgaXQgbWF5IHR1cm4gb3V0IHRoYXQgdW5pLWRpcmVjdGlvbmFs IHN0cmVhbXMganVzdCBpcyBhIA0KPj4gPiBiYWQgaWRlYSAtIEkgZG91YnQgaXQsIGJ1dCBJIGRv IGJlbGlldmUgcmVhbCB3b3JsZCB0ZXN0cyBhcmUgbmVlZGVkLg0KPj4gPg0KPj4gPg0KPj4gPg0K Pj4gPiBLaW5kIFJlZ2FyZHMsDQo+PiA+DQo+PiA+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4N Cj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gT24gMjggSnVuZSAyMDE3IGF0IDE0LjQyLjM2LCBEbWl0 cmkgVGlraG9ub3YNCj4+ID4gKGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbSkNCj4+ID4gd3Jv dGU6DQo+PiA+DQo+PiA+IE9uIFR1ZSwgSnVuIDI3LCAyMDE3IGF0IDAyOjMxOjM4UE0gLTA3MDAs IFJhbmplZXRoIEt1bWFyIERhc2luZW5pIHdyb3RlOg0KPj4gPj4gMi4gV2UgYXJlIG92ZXJwbGF5 aW5nIHRoZSBzaW1wbGljaXR5IG9mIGRlc2lnbi4gRXZlbiBpZiB3ZSBkZWVtIA0KPj4gPj4gZGVw bG95bWVudCBleHBlcmllbmNlIG5vdCBhIGNvbmNlcm4sIGlmIGV2ZXJ5IGFwcGxpY2F0aW9uIGxh eWVyIA0KPj4gPj4gcHJvdG9jb2wgdGhhdCBuZWVkcyBzdXBwb3J0IGZvciBiaWRpcmVjdGlvbmFs IHN0cmVhbXMgaGFzIHRvIA0KPj4gPj4gaW1wbGVtZW50IHNvbWUgY29ycmVsYXRvcnMgYW5kIHN1 Y2ggYWJvdmUsIHRoYXQncyBhIG5ldCBuZWdhdGl2ZSANCj4+ID4+IGluIHRlcm1zIG9mIGNvbXBs ZXhpdHkuDQo+PiA+DQo+PiA+IFRoaXMgaXMgYW4gaW1wb3J0YW50IHBvaW50OiB3ZSB3YW50IFFV SUMgYWRvcHRpb24gdG8gYmUgbWFkZSBlYXN5Lg0KPj4gPiBBIHByb2dyYW0gdGhhdCBzcGVha3Mg SFRUUCB0b2RheSBzaG91bGQgYmUgYWJsZSB0byB1c2UgYW4gZXhpc3RpbmcgDQo+PiA+IFFVSUMg bGlicmFyeSB3aXRob3V0IGhhdmluZyB0byBlbXVsYXRlIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBp biANCj4+ID4gb3JkZXIgdG8gZml0IGl0IGludG8gSFRUUCB1c2FnZSBwYXR0ZXJuLiBGb3JjaW5n IGV2ZXJ5IG9uZSBvZiB0aGVzZSANCj4+ID4gcHJvZ3JhbXMgdG8gZG8gdGhpcyBpcyBjZXJ0YWlu bHkgYSBodXJkbGUuDQo+PiA+DQo+PiA+IC0gRG1pdHJpLg0KPj4gPg0KPj4gPg0KPj4NCj4NCg0K DQoNCi0tDQpLYXp1aG8gT2t1DQo= From nobody Wed Jul 5 22:17: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 E8763126BF7 for ; Wed, 5 Jul 2017 22:17: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_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=fb.com header.b=HKyKlY0y; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iSTVSdiQ 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 1XSOFESqMeJk for ; Wed, 5 Jul 2017 22:17:10 -0700 (PDT) Received: from mx0b-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 5BBA61200CF for ; Wed, 5 Jul 2017 22:17:10 -0700 (PDT) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v665Ddw3011124; Wed, 5 Jul 2017 22:17:01 -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=nzpq1GPQVWxfRhD8q3A8ouMqouwUnjpro7Ddh9QgxpI=; b=HKyKlY0y2Ui0g1BXvwyDjL3hGvtcjfKZZhFga1GXyL1THswI6P8TPaSWsOYmnuhppfh8 vBVPryy+U4Y2nZ6V+u6hKv8YvEwP8KR17Jn1wqf6O6d1kXKAiEDovYqD9Mc8oVOo/9YB NLk3gbs2z0ldhiG+U6KntxXuazifgjuSQ54= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2bhbg68jmb-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 05 Jul 2017 22:17:01 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.18) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 5 Jul 2017 22:16:59 -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=nzpq1GPQVWxfRhD8q3A8ouMqouwUnjpro7Ddh9QgxpI=; b=iSTVSdiQgnYpH082WGUOiyZS5xd7D6qkQIvM3zpGBmSG+QyYFCpnxP4JVTpS+bIrGowlaU7GlsRxHUSz2X1aJoaHXQ49vPcwA5Zz/vtYkLKkGghwmQH/7WnA8amxgBA/dv7chxhUUC6P4SvAR8zQOK0m6HTY7rR0tZHPUbgd5vM= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Thu, 6 Jul 2017 05:16:57 +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.01.1220.018; Thu, 6 Jul 2017 05:16:56 +0000 From: Subodh Iyengar To: "Lubashev, Igor" , Kazuho Oku , Ian Swett CC: Mike Bishop , Dmitri Tikhonov , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Jo Kulik , =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , QUIC WG , Martin Thomson Subject: Re: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qYA+OJNlgCk66zUVoUQGXHqI0Yv6AgATdKACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSACAAAzfAIAAEzGAgAm2IgCAAXM4gIAAEPcY Date: Thu, 6 Jul 2017 05:16:56 +0000 Message-ID: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri>

<2240c2a68910453e97fc50d42e8a1d4f@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: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [2601:602:9801:6840:19e0:3a44:6a42:e831] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 20:7lmh/IOgghMe0qBnU6E0ILkuXwf5R9DGWFXVt7NxdeuA4ivfSfFr+OkkOF9Sl4Sw5GGVcRv8sL8eg/dw1zc/0bi9T8E3AzOrBk8jrzKH3ORk4mrjXXnNPbyUdPldPwOhPSwbWup6XCd+m0xTlgalD3cUOlMgaPorD/ninK3ibK0= x-ms-office365-filtering-correlation-id: eaacea26-0fcc-4150-fa33-08d4c42e38ed x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1455; x-ms-traffictypediagnostic: MWHPR15MB1455: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(133145235818549)(278428928389397)(166708455590820)(26388249023172)(236129657087228)(192374486261705)(82608151540597)(48057245064654)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910042)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1455; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39400400002)(39840400002)(39450400003)(55674003)(377454003)(24454002)(51444003)(377424004)(13464003)(478600001)(7736002)(3660700001)(606006)(6436002)(966005)(68736007)(14454004)(53936002)(3280700002)(45080400002)(8676002)(25786009)(6246003)(54356999)(50986999)(53546010)(81166006)(39060400002)(102836003)(6116002)(38730400002)(76176999)(77096006)(54906002)(55016002)(9686003)(2906002)(229853002)(561944003)(99286003)(2950100002)(6306002)(54896002)(3480700004)(7416002)(189998001)(86362001)(5660300001)(236005)(33656002)(7116003)(7696004)(6506006)(4326008)(8666007)(74316002)(93886004)(53946003)(8936002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14552E4F7BB6BE5FB43A58FDB6D50MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2017 05:16:56.6867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 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-07-06_02:, , 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, 06 Jul 2017 05:17:15 -0000 --_000_MWHPR15MB14552E4F7BB6BE5FB43A58FDB6D50MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Without such a signal, a generic proxy that is not aware of your applicat= ion internals is not able to know when to send the FIN I see, this use case does make somewhat sense, however I'm curious if someo= ne has a concrete use case for a generic QUIC proxy which is not aware of t= he application protocol at all. In TCP this was more common for middleboxes= to do because there was no end to end encryption of the transport, however= QUIC is encrypted. Even with cases when we tunneling protocols at our end,= we usually have some knowledge of the app that we are running because we n= eed to route them differently to different backends. I was mostly thinking = that proxies would at least have some knowledge about HTTP/2 or app protoco= ls. Maybe it is possible to make #656 more palatable, at least to me. I had 2 t= hings against it initially, which were: 1. We might need to add another state to the machine to the sender state= , i.e. normally when sending a FIN, it is ok to keep receiving stream frame= s after, however in a uni directional stream it is illegal to get a stream = frame. 2. In its current form it also has an implicit requirement to not open l= ower streams. I think opening lower streams have some desirable properties = which I've commented on in https://github.com/quicwg/base-drafts/issues/662= . An implementation could probably implement 1. with not too much trouble by = doing a special case in the stream state machine when it receives a stream = frame in the half closed local state. For 2. thinking about it a bit more I think the underlying question here is= who enforces directionality, i.e. did I receive data I should not have. If= it is the transport, then we need to answer that question with issue #662,= however if it can be the application or a higher layer API between the app= lication and transport that enforces directionality then we don't need to k= now whether a lower stream is bi-directional or not. I'm leaning towards an= API between the transport and application enforcing directionality. The re= ason for that is that an application that needs to use unidirectionality ne= eds to use a different API anyway. Given that we could leave lower streams = to be opened as it is now, but leaving the exact semantics of enforcing bi-= directionality or uni-directionality to a higher layer. That should suffice= for even a generic proxy right? I still prefer do nothing with app directed close though. > But I do not think that we should require every application protocol buil= t above QUIC to do its own framing. Second Kazuho on this one. Subodh ________________________________ From: QUIC on behalf of Lubashev, Igor Sent: Wednesday, July 5, 2017 8:50:05 PM To: Kazuho Oku; Ian Swett Cc: Mike Bishop; Dmitri Tikhonov; Swindells, Thomas (Nokia - GB/Cambridge, = UK); Jo Kulik; Mikkel Fahn=F8e J=F8rgensen; QUIC WG; Martin Thomson Subject: RE: Unidirectional streams PR > If a client needs a way to reset the server's response before observing t= he first frame, it cannot use FIN as an indicator of the end of the request= . There is a DISINTEREST frame proposal (PR #171: https://github.com/quicwg/b= ase-drafts/pull/171). That's something that I believe is valuable independ= ent of this Unidirectional streams PR. - Igor -----Original Message----- From: Kazuho Oku [mailto:kazuhooku@gmail.com] Sent: Wednesday, July 05, 2017 1:41 AM To: Ian Swett Cc: Lubashev, Igor ; Mike Bishop ; Dmitri Tikhonov ; Swindells, Thomas= (Nokia - GB/Cambridge, UK) ; Jo Kulik ; Mikkel Fahn=F8e J=F8rgensen ; QUIC WG ; Martin Thomson Subject: Re: Unidirectional streams PR 2017-06-29 10:23 GMT+09:00 Ian Swett : > I updated my PR(#656) today, sorry for the delay. I attempted to > address the issues identified with text. Some may prefer more tweaks > to the state diagram, which are also possible, so I'm open to suggestions= . After all, I think that the approach proposed here is the most well-balance= d one. As much as I think that having first-class support for unidirectional strea= ms is preferable, I also think that we should keep the overall architecture= (i.e. sum of the complexity in the transport layer and the application lay= er) as simple as possible. IMO having support for bidirectional streams (along with support for unidir= ectional streams) aligns with such intention. Most of the application protocols that will be deployed over the QUIC trans= port will be in request-response style, at least to some extent. Hence it is preferable for the transport layer to provide a framework that = fits such style. Bidirectional streams provide the necessary features. FIN provides a way to= indicate the end of the message. RST provides a way to cancel the exchange= of the message in both directions. IMO the biggest issue with the unidirectional-only approach is that you can= not have the two features together. If a client needs a way to reset the se= rver's response before observing the first frame, it cannot use FIN as an i= ndicator of the end of the request. It is true that the issue can be evaded by doing one's own framing in the a= pplication layer. #643 does that by introducing a CANCEL_REQUEST frame. But I do not think that we should require every application protocol built = above QUIC to do its own framing. In addition to that, need to keep two uni= -directional streams open would consume more resources than being able to c= lose one direction of a bi-directional stream at an earlier moment. > In the meantime, I've been considering other alternatives, including > variations on Mike's direction and a variation of the "Do Nothing" > option which involved the application signaling to the transport that > streams of a certain sort(ie: server to client for server push) were > unidirectional, as GQUIC does today. Overall, I think the approach > I've outlined does a good job of iterating on existing deployment > experience and adding explicit signaling for unidirectional streams > instead of implicit signaling at the application layer. There are > pros and cons to both explicit and implicit signaling, but I think > explicit signaling is more complete and less prone to application error. > > Thanks, Ian > > > On Wed, Jun 28, 2017 at 8:14 PM, Lubashev, Igor wro= te: >> >> > unless what the transport provides is a perfect fit for application >> > semantics, you end up building those semantics into the application an= yway. >> >> I agree with this. We should avoid adding complexity into transport >> for rare use cases, since it goes against KISS principle. >> >> On the other hand, adding support for a by far the most common use >> case makes a lot of sense. This helps apps avoid screwing up >> implementing that common case and lets us optimize that common case >> in the lower layer. BiDi streams are such common cases. Uni streams >> are likely to be the second-most-common cases (hence you offered this PR= to optimize them). >> >> >> The Associated Streams proposal offers extra semantic flexibility at >> a cost of some semantic complexity (someone would need to verify that >> the associated stream numbers make sense -- api? apps?) and a few extra = bytes. >> >> I'd like to wait to see Ian's revised proposal. The initial proposal >> offered to do only one thing -- offer a choice of uni/bi-directional >> streams >> -- but it did it in a very simple way, which is nice. >> >> - Igor >> >> >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Wednesday, June 28, 2017 7:28 PM >> To: Mike Bishop >> Cc: Swindells, Thomas (Nokia - GB/Cambridge, UK) >> ; QUIC WG ; Mikkel Fahn=F8e >> J=F8rgensen ; Dmitri Tikhonov >> ; Jo Kulik >> Subject: Re: Unidirectional streams PR >> >> There is probably a simpler approach here, take a bit (as Ian did) >> and say that if that bit is set, then the stream is in response to >> another and the stream ID of the stream to which this is responding >> follows immediately after the stream ID of the stream itself. You >> could then include that only at the start of the stream, or in multiple = frames (or as we decide). >> >> The problem with this, as with several of the other issues we're >> discussing, is that unless what the transport provides is a perfect >> fit for application semantics, you end up building those semantics >> into the application anyway. HTTP certainly can't survive without >> its own association semantics for pushes. That suggests to me that >> having bidirectional semantics in the transport creates more >> duplication than otherwise. Hence my proposal. >> >> On 28 June 2017 at 15:26, Mike Bishop >> wrote: >> > As promised, a PR for adding =93associated streams=94 is at >> > https://github.com/quicwg/base-drafts/pull/672. This very >> > deliberately builds on top of MT=92s PR =96 it=92s adding a primitive >> > which can be used to construct various abstractions atop >> > unidirectional streams, but the lifecycle is still fundamentally unidi= rectional. >> > >> > >> > >> > Copying my notes here for list discussion purposes. >> > >> > Major changes >> > >> > Leveraging @igorlord's insight that OO=3D00 only occurs on the first >> > STREAM frame of a stream, I used that as the trigger for a Stream >> > Properties byte. >> > Two bits of that byte describe the directionality of the stream: >> > >> > Unidirectional (no response expected) Initial bidirectional (one >> > response expected) Initial multi-response (one or more responses >> > expected; needs a better name) Response >> > >> > If the type is Response, there's an Associated Stream ID field, >> > length given by two more bits following the same pattern as the SS >> > bits in the STREAM frame ID. >> > >> > Personal Opinion >> > >> > On the plus side, these stream types seem to cover the abstractions >> > I can envision for most applications. You can unilaterally send >> > something (unidirectional), do request/response (bidirectional), or >> > pub/sub (single subscription stream, series of update streams). >> > >> > I don't care for the fact that I still need the stream type header >> > in HTTP after putting this in the transport. That will be >> > ameliorated if we go back to one stream per request, since all >> > unidirectional streams will be push streams. (As a side-note, I >> > considered using the multiple-response option in the HTTP mapping, >> > but then I need a stream header again to indicate which is the >> > response and which the pushes.) >> > >> > I particularly don't like that you now have to look at the frame >> > type header to find out whether a field exists which tells you the >> > length of something else in the header. I'd like to simplify that. >> > I went with this model over a CREATE_STREAM frame because of >> > @mikkelfj's use-case of very small messages >> > -- this adds only one byte to the first frame on a stream in one >> > direction and 2-5 bytes to the first frame of response streams. A >> > separate frame type would be somewhat larger, but could be cleaner >> > in that respect. >> > >> > >> > >> > >> > >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Swindells, >> > Thomas (Nokia - GB/Cambridge, UK) >> > Sent: Wednesday, June 28, 2017 7:56 AM >> > To: Jo Kulik ; Mikkel Fahn=F8e J=F8rgensen >> > >> > Cc: QUIC WG ; Dmitri Tikhonov >> > >> > Subject: RE: Unidirectional streams PR >> > >> > >> > >> > I agree that looking at the layers of abstraction is useful. In >> > principle having the wire protocol just have constructs for >> > unidirectional streams does not in itself limit creating >> > bi-directional communication flows, supported at either the library >> > or application layer. >> > >> > >> > >> > However, there need to be a standard way of doing bi-directional >> > communication for migrating applications implemented using a socket >> > style api. It needs to be easy to move an existing application from >> > TCP to QUIC. >> > This move may be attractive in many situations as QUIC gives >> > improved security and may allow greater throughput due to the more >> > modern (and >> > customizable) congestion control algorithms compared to the OS TCP >> > stack. >> > >> > >> > >> > For migrating standard socket api applications I don=92t think it >> > would be appropriate to leave the work to the application to do >> > correlation, at least the library should be providing this service >> > using the wire protocol as appropriate. Clearly we want a client >> > written with one library to be able to communicate successfully >> > with a server written using a different library. >> > This needs some form of standardization of the signalling. This >> > could either be a building block overlay on top of QUIC, or >> > implemented at the wire protocol level. >> > >> > >> > >> > In terms of patterns I think the following may be some of the most >> > common patterns (with potential to be provided at the library and >> > or wire protocol level). >> > >> > I/O pattern : Example >> > >> > 1/0 : An input only flow, perhaps a data logger like syslog with no >> > confirmation/feedback >> > >> > 0/1 : an output only flow, perhaps a topic message bus service >> > with no confirmation/feedback >> > >> > 1/1 : standard TCP applications with a single flow per connection >> > >> > 1/* : single input, many output, modelling STDIN/STDOUT+STDERR >> > >> > (1/1)* : multiplexed pairs of flows =96 supporting multiple sockets >> > muxed onto a single QUIC connection >> > >> > >> > >> > Obviously, an application would always have the option to combine >> > any single direction flows with application level correlators to >> > construct more complex flows if desired. >> > >> > >> > >> > At the moment my gut says the 1/1 use-case is common enough that >> > the wire protocol should provide a standard mechanism to support it >> > as a standard overlay would probably end up being treated as part >> > of the wire format anyway. >> > >> > >> > >> > Perhaps streams should be explicitly created with a CREATE_STREAM >> > frame which would be capable of defining multiple related streams? >> > >> > There is the option of whether only (1/1) pairs can be created this >> > way, or >> > (1/n) combinations could be supported (with an application defined >> > way to identify the use of each of the output streams). A step >> > further may be that there is a transport parameter that defines >> > whether the server is allowed to create additional streams, or if >> > stream creation is purely client driven (like TCP). I don=92t know if >> > either of these would simplify how to handle stream accounting, and >> > in particular only creating a flow when all parties have sufficient al= lowances left. >> > >> > >> > >> > Thomas >> > >> > >> > >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jo Kulik >> > Sent: 28 June 2017 15:09 >> > To: Mikkel Fahn=F8e J=F8rgensen >> > Cc: QUIC WG ; Dmitri Tikhonov >> > >> > Subject: Re: Unidirectional streams PR >> > >> > >> > >> > I'd like to pop back up to a comment Igor made last week, because I >> > find it helpful in thinking about the design space: >> > >> > >> > >> > I think of three layers of abstraction: >> > >> > 1. QUIC Wire Protocol (the thing described by the QUIC Transport >> > RFC) >> > 2. QUIC Library API (a library exposing some useful abstractions >> > -- >> > such as blocking/non-blocking unidirectional streams and >> > bidirectional =93sockets=94 -- and implementing them using QUIC Wire P= rotocol) >> > 3. Application (something that uses QUIC Library APIs) >> > >> > I think there is some argument to be made that Martin's original >> > proposal did not take into account how we would achieve (2) for >> > bi-directional streams. (I don't think it strictly said "thou >> > shalt not do (2)" either, but that is up to interpretation.) >> > >> > >> > >> > Several people have argued that we do not want every application to >> > have to re-implement bi-directional streams (3) for every >> > application, and this is not how g-quic (our largest deployment) works= right now. >> > These arguments make sense to me, but YMMV. >> > >> > >> > >> > Just because the particular *mechanism* that is being proposed has >> > some issues, however, doesn't scream out to me, at least, that we >> > should abandon this particular *design goal*. The goal being a >> > transport protocol that can elegantly fit with a uni/bi stream model. >> > Now, if we conclude that there can never be an elegant model that >> > achieves this goal, then so be it. But I also feel like we haven't >> > reached that point in the discussion yet. (At the very least, this >> > discussion has been fruitful to me in terms of mapping the design >> > space and elucidating requirements). >> > >> > >> > >> > One of the reasons I still think this design goal is under >> > consideration is that Ian and Igor/Mike have been talking about >> > alternate solutions which have a similar flavor. During the recent >> > "quiet"ness on the thread, personally, I've been waiting to hear >> > more from them. >> > >> > >> > >> > On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahn=F8e J=F8rgensen >> > wrote: >> > >> > In reply to Ranjeeth >> > >> > >> > >> > It is not only a matter of simplicity for the sake of simplicity: >> > >> > >> > >> > - A complex transport layer might end up being poorly implemented >> > leading to reduced interoperability and ultimately adoption. This >> > complexity is not only in implementation but also in understanding >> > the exact semantics of stream lifetime. Even if the spec is >> > sufficiently clear, it will still be open to misinterpretations. >> > >> > >> > >> > - Bi-directional state may have to be maintained longer and with >> > more overhead than with uni-directional streams, especially under >> > loss, potentially leading to poor performance and poor resource >> > utilisation because the transport layer has insufficient information. >> > >> > >> > >> > - The extra complexity at the application layer may be overstated - >> > it is significantly simpler to manage a map that associates to two >> > streams than it is to maintain bi-directional state at the >> > transport layer. It is even possible to implicitly link streams >> > with same identifiers, e.g. in a RPC scenario. That said, I do see >> > a potential benefit of a wrapper that implements the common bi-directi= onal case. >> > >> > >> > >> > - Complexity at the application layer may be duplicated, but >> > implementation errors are also isolated to that application. >> > Specifically for HTTP I would assume that QUIC transport and QUIC >> > HTTP implementers would be large the same for a long time to come, >> > so I would not expect the tradeoff here to be particularly concerning. >> > >> > >> > >> > - Unix pipes are traditionally constructed as a pair of >> > uni-directional file descriptors and that is a reasonably proven >> > model. C=92s standard library stdin, stdout and stderr is an example >> > of an asymmetric model with implicit linkage between >> > uni-directional file descriptors. >> > >> > >> > >> > - There are lots of use cases for non-HTTP like connectivity - >> > Kafka high volume message queuing for example. The industry trend >> > appears to move towards asynchronous processing and messaging. It >> > depends on whether you look at QUIC as a TCP + TLS replacement, or >> > as a HTTPS / REST RPC replacement. >> > >> > >> > >> > - Uni-directional streams may currently be unproven in the wild, >> > but a proposal is needed before an implementation can be made and >> > testet. I agree that it is easy to design into wrong assumptions >> > without real world testing. >> > >> > >> > >> > - There will hopefully not be a large number of successors to QUIC >> > - perhaps some purpose specific variants, e.g. for embedded use. >> > Widespread adaptation and compatibility is very necessary so it >> > makes sense to have QUIC being sufficiently simple and expressive >> > to achieve this goal. A polymorf QUIC will not achieve that goal. >> > On the other hand, a solid QUIC foundation can be used for a large >> > number of application protocols. >> > >> > >> > >> > - Finally, it may turn out that uni-directional streams just is a >> > bad idea - I doubt it, but I do believe real world tests are needed. >> > >> > >> > >> > Kind Regards, >> > >> > Mikkel Fahn=F8e J=F8rgensen >> > >> > >> > >> > On 28 June 2017 at 14.42.36, Dmitri Tikhonov >> > (dtikhonov@litespeedtech.com) >> > wrote: >> > >> > On Tue, Jun 27, 2017 at 02:31:38PM -0700, Ranjeeth Kumar Dasineni wrot= e: >> >> 2. We are overplaying the simplicity of design. Even if we deem >> >> deployment experience not a concern, if every application layer >> >> protocol that needs support for bidirectional streams has to >> >> implement some correlators and such above, that's a net negative >> >> in terms of complexity. >> > >> > This is an important point: we want QUIC adoption to be made easy. >> > A program that speaks HTTP today should be able to use an existing >> > QUIC library without having to emulate bidirectional streams in >> > order to fit it into HTTP usage pattern. Forcing every one of these >> > programs to do this is certainly a hurdle. >> > >> > - Dmitri. >> > >> > >> > -- Kazuho Oku --_000_MWHPR15MB14552E4F7BB6BE5FB43A58FDB6D50MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> Without such a signal, a gene= ric proxy that is not aware of your application internals is not able to kn= ow when to send the FIN

I see, this use case does make somewhat= sense, however I'm curious if someone has a concrete use ca= se for a generic QUIC proxy which is not aware of the application protocol at all. In TCP this was more common for middleboxes t= o do because there was no end to end encryption of the transport, however Q= UIC is encrypted. Even with cases when we tunneling protocols at our e= nd, we usually have some knowledge of the app that we are running because we need to route them differently to d= ifferent backends. I was mostly thinking that proxies would at le= ast have some knowledge about HTTP/2 or app protocols.

Maybe it is possible to make #656 more palatable, at least to me. I ha= d 2 things against it initially, which were:

We might need to add another state to the machine to the sender state, = i.e. normally when sending a FIN, it is ok to keep receiving stream frames = after, however in a uni directional stream it is illegal to get a stream fr= ame.
In its current form it also has an implicit requirement to not= open lower streams. I think opening lower streams have some desirable prop= erties which I've commented on in https:/= /github.com/quicwg/base-drafts/issues/662.

An implementation could probably implement 1. with not too much troubl= e by doing a special case in the stream state machine when it receives a st= ream frame in the half closed local state.

For 2. thinking about it a bit more I think the underlying question here is= who enforces directionality, i.e. did I receive data I should not hav= e. If it is the transport, then we need to answer that question with issue = #662, however if it can be the application or a higher layer API between the application and transport that enforces = directionality then we don't need to know whether a lower stream is bi-dire= ctional or not. I'm leaning towards an API between the transport and applic= ation enforcing directionality. The reason for that is that an application that needs to use unidirectiona= lity needs to use a different API anyway. Given that we could lea= ve lower streams to be opened as it is now, but leaving the exact semantics= of enforcing bi-directionality or uni-directionality to a higher layer. That should suffice for even a generic proxy right?&nbs= p;

I still prefer do nothing with app directed close though.

> But I do not think that we should require every application protocol built abo= ve QUIC to do its own framing.

Second Kazuho on this one.

Subodh

From: QUIC <quic-bounc= es@ietf.org> on behalf of Lubashev, Igor <ilubashe@akamai.com>
Sent: Wednesday, July 5, 2017 8:50:05 PM
To: Kazuho Oku; Ian Swett
Cc: Mike Bishop; Dmitri Tikhonov; Swindells, Thomas (Nokia - GB/Camb= ridge, UK); Jo Kulik; Mikkel Fahn=F8e J=F8rgensen; QUIC WG; Martin Thomson<= br> Subject: RE: Unidirectional streams PR

> If a client needs a way to reset the server's= response before observing the first frame, it cannot use FIN as an indicat= or of the end of the request.

There is a DISINTEREST frame proposal (PR #171: https://github.com/quicwg/base-drafts/pull/171). That's something= that I believe is valuable independent of this Unidirectional streams PR.<= br>
- Igor

-----Original Message-----
From: Kazuho Oku [mailto:kazuhooku@g= mail.com]
Sent: Wednesday, July 05, 2017 1:41 AM
To: Ian Swett <ianswett@google.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Mike Bishop <Michael.Bis= hop@microsoft.com>; Dmitri Tikhonov <dtikhonov@litespeedtech.com>;= Swindells, Thomas (Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.co= m>; Jo Kulik <jokulik@google.com>; Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org>; Martin Thomson = <martin.thomson@gmail.com>
Subject: Re: Unidirectional streams PR

2017-06-29 10:23 GMT+09:00 Ian Swett <ianswett@google.com>:
> I updated my PR(#656) today, sorry for the delay. I attempted to=
> address the issues identified with text. Some may prefer more tw= eaks
> to the state diagram, which are also possible, so I'm open to suggesti= ons.

After all, I think that the approach proposed here is the most well-balance= d one.

As much as I think that having first-class support for unidirectional strea= ms is preferable, I also think that we should keep the overall architecture= (i.e. sum of the complexity in the transport layer and the application lay= er) as simple as possible.

IMO having support for bidirectional streams (along with support for unidir= ectional streams) aligns with such intention.

Most of the application protocols that will be deployed over the QUIC trans= port will be in request-response style, at least to some extent.
Hence it is preferable for the transport layer to provide a framework that = fits such style.

Bidirectional streams provide the necessary features. FIN provides a way to= indicate the end of the message. RST provides a way to cancel the exchange= of the message in both directions.

IMO the biggest issue with the unidirectional-only approach is that you can= not have the two features together. If a client needs a way to reset the se= rver's response before observing the first frame, it cannot use FIN as an i= ndicator of the end of the request.

It is true that the issue can be evaded by doing one's own framing in the a= pplication layer. #643 does that by introducing a CANCEL_REQUEST frame.

But I do not think that we should require every application protocol built = above QUIC to do its own framing. In addition to that, need to keep two uni= -directional streams open would consume more resources than being able to c= lose one direction of a bi-directional stream at an earlier moment.

> In the meantime, I've been considering other alternatives, including <= br> > variations on Mike's direction and a variation of the "Do Nothing= "
> option which involved the application signaling to the transport that =
> streams of a certain sort(ie: server to client for server push) were <= br> > unidirectional, as GQUIC does today. Overall, I think the approa= ch
> I've outlined does a good job of iterating on existing deployment
> experience and adding explicit signaling for unidirectional streams > instead of implicit signaling at the application layer. There ar= e
> pros and cons to both explicit and implicit signaling, but I think > explicit signaling is more complete and less prone to application erro= r.
>
> Thanks, Ian
>
>
> On Wed, Jun 28, 2017 at 8:14 PM, Lubashev, Igor <ilubashe@akamai.co= m> wrote:
>>
>> > unless what the transport provides is a perfect fit for appli= cation
>> > semantics, you end up building those semantics into the appli= cation anyway.
>>
>> I agree with this. We should avoid adding complexity into transpor= t
>> for rare use cases, since it goes against KISS principle.
>>
>> On the other hand, adding support for a by far the most common use=
>> case makes a lot of sense. This helps apps avoid screwing up=
>> implementing that common case and lets us optimize that common cas= e
>> in the lower layer. BiDi streams are such common cases. Uni stream= s
>> are likely to be the second-most-common cases (hence you offered t= his PR to optimize them).
>>
>>
>> The Associated Streams proposal offers extra semantic flexibility = at
>> a cost of some semantic complexity (someone would need to verify t= hat
>> the associated stream numbers make sense -- api? apps?) and a few = extra bytes.
>>
>> I'd like to wait to see Ian's revised proposal. The initial = proposal
>> offered to do only one thing -- offer a choice of uni/bi-direction= al
>> streams
>> -- but it did it in a very simple way, which is nice.
>>
>> - Igor
>>
>>
>> -----Original Message-----
>> From: Martin Thomson [= mailto:martin.thomson@gmail.com]
>> Sent: Wednesday, June 28, 2017 7:28 PM
>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>> Cc: Swindells, Thomas (Nokia - GB/Cambridge, UK)
>> <thomas.swindells@nokia.com>; QUIC WG <quic@ietf.org>;= Mikkel Fahn=F8e
>> J=F8rgensen <mikkelfj@gmail.com>; Dmitri Tikhonov
>> <dtikhonov@litespeedtech.com>; Jo Kulik <jokulik@google.c= om>
>> Subject: Re: Unidirectional streams PR
>>
>> There is probably a simpler approach here, take a bit (as Ian did)=
>> and say that if that bit is set, then the stream is in response to=
>> another and the stream ID of the stream to which this is respondin= g
>> follows immediately after the stream ID of the stream itself. = ; You
>> could then include that only at the start of the stream, or in mul= tiple frames (or as we decide).
>>
>> The problem with this, as with several of the other issues we're <= br> >> discussing, is that unless what the transport provides is a perfec= t
>> fit for application semantics, you end up building those semantics=
>> into the application anyway. HTTP certainly can't survive wi= thout
>> its own association semantics for pushes. That suggests to m= e that
>> having bidirectional semantics in the transport creates more
>> duplication than otherwise. Hence my proposal.
>>
>> On 28 June 2017 at 15:26, Mike Bishop <Michael.Bishop@microsoft= .com>
>> wrote:
>> > As promised, a PR for adding =93associated streams=94 is at <= br> >> > ht= tps://github.com/quicwg/base-drafts/pull/672. This very
>> > deliberately builds on top of MT=92s PR =96 it=92s adding a p= rimitive
>> > which can be used to construct various abstractions atop
>> > unidirectional streams, but the lifecycle is still fundamenta= lly unidirectional.
>> >
>> >
>> >
>> > Copying my notes here for list discussion purposes.
>> >
>> > Major changes
>> >
>> > Leveraging @igorlord's insight that OO=3D00 only occurs on th= e first
>> > STREAM frame of a stream, I used that as the trigger for a St= ream
>> > Properties byte.
>> > Two bits of that byte describe the directionality of the stre= am:
>> >
>> > Unidirectional (no response expected) Initial bidirectional (= one
>> > response expected) Initial multi-response (one or more respon= ses
>> > expected; needs a better name) Response
>> >
>> > If the type is Response, there's an Associated Stream ID fiel= d,
>> > length given by two more bits following the same pattern as t= he SS
>> > bits in the STREAM frame ID.
>> >
>> > Personal Opinion
>> >
>> > On the plus side, these stream types seem to cover the abstra= ctions
>> > I can envision for most applications. You can unilaterally se= nd
>> > something (unidirectional), do request/response (bidirectiona= l), or
>> > pub/sub (single subscription stream, series of update streams= ).
>> >
>> > I don't care for the fact that I still need the stream type h= eader
>> > in HTTP after putting this in the transport. That will be >> > ameliorated if we go back to one stream per request, since al= l
>> > unidirectional streams will be push streams. (As a side-note,= I
>> > considered using the multiple-response option in the HTTP map= ping,
>> > but then I need a stream header again to indicate which is th= e
>> > response and which the pushes.)
>> >
>> > I particularly don't like that you now have to look at the fr= ame
>> > type header to find out whether a field exists which tells yo= u the
>> > length of something else in the header. I'd like to simplify = that.
>> > I went with this model over a CREATE_STREAM frame because of =
>> > @mikkelfj's use-case of very small messages
>> > -- this adds only one byte to the first frame on a stream in = one
>> > direction and 2-5 bytes to the first frame of response stream= s. A
>> > separate frame type would be somewhat larger, but could be cl= eaner
>> > in that respect.
>> >
>> >
>> >
>> >
>> >
>> > From: QUIC [mailto:q= uic-bounces@ietf.org] On Behalf Of Swindells,
>> > Thomas (Nokia - GB/Cambridge, UK)
>> > Sent: Wednesday, June 28, 2017 7:56 AM
>> > To: Jo Kulik <jokulik@google.com>; Mikkel Fahn=F8e J=F8= rgensen
>> > <mikkelfj@gmail.com>
>> > Cc: QUIC WG <quic@ietf.org>; Dmitri Tikhonov
>> > <dtikhonov@litespeedtech.com>
>> > Subject: RE: Unidirectional streams PR
>> >
>> >
>> >
>> > I agree that looking at the layers of abstraction is useful. = In
>> > principle having the wire protocol just have constructs for <= br> >> > unidirectional streams does not in itself limit creating
>> > bi-directional communication flows, supported at either the l= ibrary
>> > or application layer.
>> >
>> >
>> >
>> > However, there need to be a standard way of doing bi-directio= nal
>> > communication for migrating applications implemented using a = socket
>> > style api. It needs to be easy to move an existing applicatio= n from
>> > TCP to QUIC.
>> > This move may be attractive in many situations as QUIC gives =
>> > improved security and may allow greater throughput due to the= more
>> > modern (and
>> > customizable) congestion control algorithms compared to the O= S TCP
>> > stack.
>> >
>> >
>> >
>> > For migrating standard socket api applications I don=92t thin= k it
>> > would be appropriate to leave the work to the application to = do
>> > correlation, at least the library should be providing this se= rvice
>> > using the wire protocol as appropriate. Clearly we want a cli= ent
>> > written with one library to be able to communicate successful= ly
>> > with a server written using a different library.
>> > This needs some form of standardization of the signalling. Th= is
>> > could either be a building block overlay on top of QUIC, or <= br> >> > implemented at the wire protocol level.
>> >
>> >
>> >
>> > In terms of patterns I think the following may be some of the= most
>> > common patterns (with potential to be provided at the library= and
>> > or wire protocol level).
>> >
>> > I/O pattern : Example
>> >
>> > 1/0   : An input only flow, perhaps a data logger l= ike syslog with no
>> > confirmation/feedback
>> >
>> > 0/1 : an output only flow, perhaps a topic message bus = service
>> > with no confirmation/feedback
>> >
>> > 1/1 : standard TCP applications with a single flow per connec= tion
>> >
>> > 1/* : single input, many output, modelling STDIN/STDOUT+S= TDERR
>> >
>> > (1/1)* : multiplexed pairs of flows =96 supporting multiple s= ockets
>> > muxed onto a single QUIC connection
>> >
>> >
>> >
>> > Obviously, an application would always have the option to com= bine
>> > any single direction flows with application level correlators= to
>> > construct more complex flows if desired.
>> >
>> >
>> >
>> > At the moment my gut says the 1/1 use-case is common enough t= hat
>> > the wire protocol should provide a standard mechanism to supp= ort it
>> > as a standard overlay would probably end up being treated as = part
>> > of the wire format anyway.
>> >
>> >
>> >
>> > Perhaps streams should be explicitly created with a CREATE_ST= REAM
>> > frame which would be capable of defining multiple related str= eams?
>> >
>> > There is the option of whether only (1/1) pairs can be create= d this
>> > way, or
>> > (1/n) combinations could be supported (with an application de= fined
>> > way to identify the use of each of the output streams). A ste= p
>> > further may be that there is a transport parameter that defin= es
>> > whether the server is allowed to create additional streams, o= r if
>> > stream creation is purely client driven (like TCP). I don=92t= know if
>> > either of these would simplify how to handle stream accountin= g, and
>> > in particular only creating a flow when all parties have suff= icient allowances left.
>> >
>> >
>> >
>> > Thomas
>> >
>> >
>> >
>> > From: QUIC [mailto:q= uic-bounces@ietf.org] On Behalf Of Jo Kulik
>> > Sent: 28 June 2017 15:09
>> > To: Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.com> >> > Cc: QUIC WG <quic@ietf.org>; Dmitri Tikhonov
>> > <dtikhonov@litespeedtech.com>
>> > Subject: Re: Unidirectional streams PR
>> >
>> >
>> >
>> > I'd like to pop back up to a comment Igor made last week, bec= ause I
>> > find it helpful in thinking about the design space:
>> >
>> >
>> >
>> > I think of three layers of abstraction:
>> >
>> > 1.       QUIC Wire Protocol (th= e thing described by the QUIC Transport
>> > RFC)
>> > 2.       QUIC Library API (a li= brary exposing some useful abstractions
>> > --
>> > such as blocking/non-blocking unidirectional streams and
>> > bidirectional =93sockets=94 -- and implementing them using QU= IC Wire Protocol)
>> > 3.       Application (something= that uses QUIC Library APIs)
>> >
>> > I think there is some argument to be made that Martin's origi= nal
>> > proposal did not take into account how we would achieve (2) f= or
>> > bi-directional streams. (I don't think it strictly said= "thou
>> > shalt not do (2)" either, but that is up to interpretati= on.)
>> >
>> >
>> >
>> > Several people have argued that we do not want every applicat= ion to
>> > have to re-implement bi-directional streams (3) for every >> > application, and this is not how g-quic (our largest deployme= nt) works right now.
>> > These arguments make sense to me, but YMMV.
>> >
>> >
>> >
>> > Just because the particular *mechanism* that is being propose= d has
>> > some issues, however, doesn't scream out to me, at least, tha= t we
>> > should abandon this particular *design goal*. The goal = being a
>> > transport protocol that can elegantly fit with a uni/bi strea= m model.
>> > Now, if we conclude that there can never be an elegant model = that
>> > achieves this goal, then so be it. But I also feel like= we haven't
>> > reached that point in the discussion yet. (At the very = least, this
>> > discussion has been fruitful to me in terms of mapping the de= sign
>> > space and elucidating requirements).
>> >
>> >
>> >
>> > One of the reasons I still think this design goal is under >> > consideration is that Ian and Igor/Mike have been talking abo= ut
>> > alternate solutions which have a similar flavor. During= the recent
>> > "quiet"ness on the thread, personally, I've been wa= iting to hear
>> > more from them.
>> >
>> >
>> >
>> > On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahn=F8e J=F8rgensen =
>> > <mikkelfj@gmail.com> wrote:
>> >
>> > In reply to Ranjeeth
>> >
>> >
>> >
>> > It is not only a matter of simplicity for the sake of simplic= ity:
>> >
>> >
>> >
>> > - A complex transport layer might end up being poorly impleme= nted
>> > leading to reduced interoperability and ultimately adoption. = This
>> > complexity is not only in implementation but also in understa= nding
>> > the exact semantics of stream lifetime. Even if the spec is <= br> >> > sufficiently clear, it will still be open to misinterpretatio= ns.
>> >
>> >
>> >
>> > - Bi-directional state may have to be maintained longer and w= ith
>> > more overhead than with uni-directional streams, especially u= nder
>> > loss, potentially leading to poor performance and poor resour= ce
>> > utilisation because the transport layer has insufficient info= rmation.
>> >
>> >
>> >
>> > - The extra complexity at the application layer may be overst= ated -
>> > it is significantly simpler to manage a map that associates t= o two
>> > streams than it is to maintain bi-directional state at the >> > transport layer. It is even possible to implicitly link strea= ms
>> > with same identifiers, e.g. in a RPC scenario. That said, I d= o see
>> > a potential benefit of a wrapper that implements the common b= i-directional case.
>> >
>> >
>> >
>> > - Complexity at the application layer may be duplicated, but =
>> > implementation errors are also isolated to that application.<= br> >> > Specifically for HTTP I would assume that QUIC transport and = QUIC
>> > HTTP implementers would be large the same for a long time to = come,
>> > so I would not expect the tradeoff here to be particularly co= ncerning.
>> >
>> >
>> >
>> > - Unix pipes are traditionally constructed as a pair of
>> > uni-directional file descriptors and that is a reasonably pro= ven
>> > model. C=92s standard library stdin, stdout and stderr is an = example
>> > of an asymmetric model with implicit linkage between
>> > uni-directional file descriptors.
>> >
>> >
>> >
>> > - There are lots of use cases for non-HTTP like connectivity = -
>> > Kafka high volume message queuing for example. The industry t= rend
>> > appears to move towards asynchronous processing and messaging= . It
>> > depends on whether you look at QUIC as a TCP + TLS replac= ement, or
>> > as a HTTPS / REST RPC replacement.
>> >
>> >
>> >
>> > - Uni-directional streams may currently be unproven in the wi= ld,
>> > but a proposal is needed before an implementation can be made= and
>> > testet. I agree that it is easy to design into wrong assumpti= ons
>> > without real world testing.
>> >
>> >
>> >
>> > - There will hopefully not be a large number of successors to= QUIC
>> > - perhaps some purpose specific variants, e.g. for embedded u= se.
>> > Widespread adaptation and compatibility is very necessary so = it
>> > makes sense to have QUIC being sufficiently simple and expres= sive
>> > to achieve this goal. A polymorf QUIC will not achieve that g= oal.
>> > On the other hand, a solid QUIC foundation can be used for a = large
>> > number of application protocols.
>> >
>> >
>> >
>> > - Finally, it may turn out that uni-directional streams just = is a
>> > bad idea - I doubt it, but I do believe real world tests are = needed.
>> >
>> >
>> >
>> > Kind Regards,
>> >
>> > Mikkel Fahn=F8e J=F8rgensen
>> >
>> >
>> >
>> > On 28 June 2017 at 14.42.36, Dmitri Tikhonov
>> > (dtikhonov@litespeedtech.com)
>> > wrote:
>> >
>> > On Tue, Jun 27, 2017 at 02:31:38PM -0700, Ranjeeth Kumar Dasi= neni wrote:
>> >> 2. We are overplaying the simplicity of design. Even if w= e deem
>> >> deployment experience not a concern, if every application= layer
>> >> protocol that needs support for bidirectional streams has= to
>> >> implement some correlators and such above, that's a net n= egative
>> >> in terms of complexity.
>> >
>> > This is an important point: we want QUIC adoption to be made = easy.
>> > A program that speaks HTTP today should be able to use an exi= sting
>> > QUIC library without having to emulate bidirectional streams = in
>> > order to fit it into HTTP usage pattern. Forcing every one of= these
>> > programs to do this is certainly a hurdle.
>> >
>> > - Dmitri.
>> >
>> >
>>
>

--
Kazuho Oku

--_000_MWHPR15MB14552E4F7BB6BE5FB43A58FDB6D50MWHPR15MB1455namp_-- From nobody Thu Jul 6 17:57: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 329E5131548 for ; Thu, 6 Jul 2017 17:57:30 -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, 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=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 ZYSLJ7RFmRWW for ; Thu, 6 Jul 2017 17:57:27 -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 A64EF129564 for ; Thu, 6 Jul 2017 17:57:27 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id c73so8856789pfk.2 for ; Thu, 06 Jul 2017 17:57: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=I9shb2EJ/ZcRVjnxGbLl7D8yfeam/Lrdqy0L506Vfpw=; b=tgaVTiulKj2k/G//QS98RTGYJE4aO1F9dhEH4eiCHjLp2m/8UdsUrKPHlrRSXdXyEk 8WH4XInfgsX0E+9FyKUXRV7u9mhcDT0JdLFoJRnu97BUb41d1zkwB3DihaRODqhHwtu0 ezUfVUTxS+SedFB1OTvhKEF2LwRIMKHl4R4Hy2a0dHLttEF07qUdho/WcSB61JpoZl5Q DrMlDePhcy6lV7Wfwo/FTkWsOoAMzkxXK01we93MiKWci/+Pbox1bqLw+yzXHEioU6cC 8zN3AzT9HLyH5TRfw26SZM2hTBWtpwv5kxiT1Iq7q+E5seo/hjNyRvtV7X1eIeslJ/Kt L4fg== 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=I9shb2EJ/ZcRVjnxGbLl7D8yfeam/Lrdqy0L506Vfpw=; b=tju38wV9VEGu7Cpmu4MpayXffVQ2yRygxakDqg8daU4oBnyJe4wLF+jckBHIkZqukB M9Fi9rtPXim4BWkIkE9G3VocOcLpRch9A4UfAyzFHl04t//0/aLURIRLpa3Aq/MJgLaB 1z8sjdXoHVvIlpvkzIs9xMGXucUtjFSjmEkfWThk14WsEgnROUIwuk3bTkkSmU6+FgyP kw/uUJIwitkKfVXg+9JtGJZU+bBptxjGY6VvzI/IToZT6kceDBlZeUjIqYBF1PXfiMM5 rcCYjWHZ7MapCK/hW2S1ZCoMLW5XNjzvwg+cLQ1ID+qkhgyxDg0B+oJSXWFc9LC6ADVu m5nA== X-Gm-Message-State: AIVw113r5xMmHx9J8V47o8l1MchrhkDesDJs7+ojnXNbwFDJYA1zoV0o CSdGyaaxL+XqevjPFdN6dk6oYYHNOA== X-Received: by 10.98.79.130 with SMTP id f2mr28887499pfj.133.1499389047029; Thu, 06 Jul 2017 17:57:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Thu, 6 Jul 2017 17:57:26 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 7 Jul 2017 09:57:26 +0900 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson 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: Fri, 07 Jul 2017 00:57:30 -0000 2017-06-21 16:41 GMT+09:00 Martin Thomson : > I've created a pull request unidirectional streams. > > https://github.com/quicwg/base-drafts/pull/643 Thank you for working on the PR. Going through the PR (and the discussion on this mailing list thread), I have one question. Could somebody clarify what a server is expected to do when there are no more streams than can be used to send a response (i.e. when a server has used all the Stream IDs up to 2^32-2 and then receives a request)? In a protocol that does 1:N mapping between request and response (HTTP with push can be considered as such a protocol), a server will finish using all of its streams before the client does. So there is a possibility that by the time the server observes a new client-initiated stream carrying a request, it might not have any unused stream IDs that can be used for sending a response. I can think of two ways to handle such an issue. One way is to define a server-sent signal in the application binding (e.g., HTTP over QUIC) that indicates the client that the request should be replayed on a different QUIC connection. The other way is on the client side _guess_ the possibility of server reaching stream ID starvation, and if there's such a possibility, open a new connection for sending requests (though making such a guess might not be easy due to packet reordering). Going through the PR, I could not find a change that tries to handle the issue. Hence asking the question. > I won't go into detail about this here, other than to point out that > there is extensive rationale for the choices I made in the PR summary, > a copy of which I will include for your convenience. > > ## Transport Changes > > Streams are unidirectional. Each has three states: idle, open, and > closed. I separated the transitions for sending and receiving because > that turned out to be easier to explain. The reordering thing makes > them different in subtle ways. > > That's all. The changes in transport are relatively small and they > simplify streams a lot. That it also makes the transport more generic > is a nice bonus. > > ## HTTP Changes > > This is where the bulk of the changes are. > > ### Stream Correlation > > Previously request and response were implicitly correlated, as was the > data correlated with the request or response headers. With this > change, that correlation each stream has a header that explicitly > correlates these. > > There are 5 types of stream: connection control, request, response, > data, and push. The first two have a simple header that has a type. > The next two reference another stream in their header, which ties > request to response and data to request or response. Push streams > each reference a PUSH_PROMISE using a newly minted push ID (I decided > that was cleaner than what I proposed at the interim). > > I chose backward references rather than forward references for two > reasons. First, request and response correlation can't use forward > references because that would mean the client would be exerting > (uncoordinated) control over server streams. Second, that gives the > server the most flexibility in terms of how it answers requests (see > #281). The cost of using backward references is that endpoints have > to check that the backward references aren't bad, either referencing > the wrong type of stream, or with multiple references to the same > stream. > > The presence or absence of a message body is signaled after the > initial header block using a HAS_BODY frame. This empty frame > indicates that another stream will include the body of the message - > or a promise for a body. I would like to eliminate this stream split. > See #245 and #557 for more details on that, though we need to fix #176 > first, which brings us back to QPACK/QCRAM again. > > ### Prioritization > > This changes prioritization so that it identifies requests. I only > made the minimal changes here, which means that this doesn't fix #441 > at the same time, I've left that for later (see below). > > ### Cancelling Pushes > > Because server push doesn't create streams with PUSH_PROMISE, I had to > create a way to cancel them between the time that the PUSH_PROMISE is > sent and when the push stream is created. That's called RST_PUSH. > > ## Things That Need Improvement > > I haven't based this on #171. I think that functionality is good, but > the last time I looked at the PR I didn't like some of the changes > Mike made there. (That's a taste thing.) This really assumes that we > accept something very much like #171. > > This really needs QPACK/QCRAM. Right now, it is impossible to cancel > some types of request using RST_STREAM because not all messages will > have a body (#176 again). On balance, given that bodies are what you > really want to kill, it's not disastrous, but it's a problem > nonetheless. I think that we all agree that this is something that we > need to fix, but we haven't reached the point where we agree on the > details of the fix. > > ## Things That Want Improvement > > This also really wants headers and data on the same stream . It > doesn't exactly need that, but merging the streams would make things a > lot easy, both conceptually and structurally. > > I chose the simplest possible encoding for all of the fields that I > touched. That means that stream IDs are all 32 bits in size and the > HAS_BODY frame takes an entire 9 octets. For things that are that > common, there are many ways in which byte efficiency could be > improved. > > The push ID changes might allow us to trivially fix #441. Use of an > as-yet-not-created push ID as a node in the priority tree would allow > for prioritization to use "empty" nodes. We'd need to explicitly > allow that though. > > # Fixes > > Closes #515, #240, #281, #175. > -- Kazuho Oku From nobody Thu Jul 6 18:05: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 38D60131545 for ; Thu, 6 Jul 2017 18:05:46 -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 bOR2_bRM6atz for ; Thu, 6 Jul 2017 18:05:42 -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 890B0131559 for ; Thu, 6 Jul 2017 18:05:42 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id m68so18628473ith.1 for ; Thu, 06 Jul 2017 18:05:42 -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=l2NuHp5HQtmOnLMMr7pWfxyQU/hi6a6VmXCYmZVt7JY=; b=kQXqU9Z9I4u7qszKod353KY333wfZrYs5p3bqYaGraVaalHiCJv3I35lFKYVkhCIet 27sy3nIdHYmob2LOi1ae2gMeKBU0jEedLAoevq+3qY9EcrhJ75Nd9sfDv4XSss4+v67L iYo3pW7gPkS521cXDX2hkLeDmWFO5Dq/mW/nIrz5gNLVWY60Kj1tgdAvPtjTYG2qlEoQ 9JGkjqjiRnx+nFhFlEhtmz1CNAr3uUjFea8FAC4Fe5k2yq8Wl1fJD1DU4+gbEJ+J26AK VYErUB85QZnctDzGIC1v8D9N9alb/Hqwzmt7AY4ZcTEhXHanZODufjFwYnLDxH/2Qcjf sLeg== 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=l2NuHp5HQtmOnLMMr7pWfxyQU/hi6a6VmXCYmZVt7JY=; b=Wuvzf0LEWRk27LzKq+0KIkkCN1V4rbgKJ4D2wV/wwv3XoEHYmjvEsuQotOmGGpDMEA J1dMOQYagPbdIqY3+yOp88x3WG4juToLIYa37hyF1AKlikFud33ieSWOtuu+PYcEdmd9 Eqma00Is5EaQ9GH96TUGP2+v7YV8IkH0Ax3wBwAdlLH03pbej+0qcmC+dKqhFC/hm8Va 1ZnqxcvkQ96ufqcRhA4E/O4yd/HDOonSko8bmt62QlAiPMhDy/Lw7p+N3cspkBi7Pf8B sOzTlwVYeHNfRH7rj62eoo52OSgN1W4y8vUXab8nyyc5lAZN2/ZUeJIAgK2yetsL4rtp uCKA== X-Gm-Message-State: AIVw110f2U3ol+1+qg/H0CVKBDDt5n43r7hrYOGeLT2WqsXPxSmZ/tlc /xgyyB6WWioBK5L4VP1e9TI+wCADig== X-Received: by 10.36.236.4 with SMTP id g4mr744911ith.60.1499389541981; Thu, 06 Jul 2017 18:05:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.162 with HTTP; Thu, 6 Jul 2017 18:05:41 -0700 (PDT) In-Reply-To: References:

From: Martin Thomson Date: Fri, 7 Jul 2017 11:05:41 +1000 Message-ID: Subject: Re: Unidirectional streams PR To: Kazuho Oku 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: Fri, 07 Jul 2017 01:05:46 -0000 On 7 July 2017 at 10:57, Kazuho Oku wrote: > Could somebody clarify what a server is expected to do when there are > no more streams than can be used to send a response (i.e. when a > server has used all the Stream IDs up to 2^32-2 and then receives a > request)? I think that the only sensible approach is to give up on the connection before this point is reached. A client can't know exactly how many streams a server has open, so I think that the only sensible course of action is to initiate graceful shutdown whenever the endpoint might be inclined to MAX_STREAM_ID that is 2^32-1 or greater. (In the PR, the limit is 2^32-1.) From nobody Thu Jul 6 18:43: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 5F19112F3D5 for ; Thu, 6 Jul 2017 18:43:34 -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, FREEMAIL_FROM=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 Np9bYQwBYjOi for ; Thu, 6 Jul 2017 18:43:33 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 06CEE129AFA for ; Thu, 6 Jul 2017 18:43:33 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e7so9344820pfk.0 for ; Thu, 06 Jul 2017 18:43:33 -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=cLdLsk+2vZpTnZZ6mIuzHS6ZNvCruA4jySBy4s2PDUc=; b=kiBDyUWtoZRE1XqPj4RRj4Z1QUE9ulOxIfj8qL/ofeZOJu+gv8r7gq1uab2+V2vcM9 IMeHHNg6tuj2VObhPK9lFBdXXUUtS6aCnY4ATOWQnd0rHyqIa6kf3F83rgxMnkMftz/J bzqW2/IVk/vRdvPomVTIvvWWrSM6VAdqokEXDMtf78OMI9cVp29C1husxUJyBOGXT8vx +e/jzH93OFH5SKSCJe13ccodj1X7QE9CeOzY/9htbr3Ca3LH3IJ8WSMQIpkGYyHIVgg2 LZDNmUaZWJ7ITRtXEE/Ae1jYI1c5ZRB86hsfyLlgY2rtMuqI1bdL7C1dE+SHiF/Mvzm1 4+Uw== 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=cLdLsk+2vZpTnZZ6mIuzHS6ZNvCruA4jySBy4s2PDUc=; b=FO7IQfFsxaEWd7QvAT0a2gCfXjkcvK+gCF6CfH0rcl13kuiMF68RDP1IWvfgV6ozes 7P0x6lZideAweL4+r5PDoTu/mNJ2wkNjNhwuYf5yKXStqkkxgWtoxFtkoX6NXgXaw+vN cV/nHc1l15JFFpma9dRRVHZQdWcDr3fK4DF8Gjsg12rkqK8fid/Zd1Qwoj14G1lFtXen x3fKYv3Xd8hzeePXYQ2VBzGadH7p4e6DfE+aQWOM1rZfbormzXZRfBKrLilEQKi/WU1W AJXNRb2myVZXZVxeVM3EWU+A8Oaed1Mfd9vmAnllWNNtgABQH7ZjT0RrEE6D7PLR1FDV GzJA== X-Gm-Message-State: AIVw113fPM/jiRwd5Eaa5zj5h40qDQE1DbPntVqh5Jo6AfrpiSVi7oxo b4W1vveawszLte7AnRJ02qyqkIb0cw== X-Received: by 10.84.231.197 with SMTP id g5mr144805pln.71.1499391812594; Thu, 06 Jul 2017 18:43:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Thu, 6 Jul 2017 18:43:31 -0700 (PDT) In-Reply-To: References:

From: Kazuho Oku Date: Fri, 7 Jul 2017 10:43:31 +0900 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson 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: Fri, 07 Jul 2017 01:43:34 -0000 2017-07-07 10:05 GMT+09:00 Martin Thomson : > On 7 July 2017 at 10:57, Kazuho Oku wrote: >> Could somebody clarify what a server is expected to do when there are >> no more streams than can be used to send a response (i.e. when a >> server has used all the Stream IDs up to 2^32-2 and then receives a >> request)? > > I think that the only sensible approach is to give up on the > connection before this point is reached. > > A client can't know exactly how many streams a server has open, so I > think that the only sensible course of action is to initiate graceful > shutdown whenever the endpoint might be inclined to MAX_STREAM_ID that > is 2^32-1 or greater. > > (In the PR, the limit is 2^32-1.) Thank you for the clarification. So it would be sensible to stop initiating new requests on an existing connection when the number of unused stream IDs of the peer becomes as low as max-concurrent-streams multiplied by some safety factor (something like 10 would be enough, considering the probability of loss or reordering of packets carrying DATA frames and consecutive MAX_STREAM_ID frames). -- Kazuho Oku From nobody Thu Jul 6 18:49:00 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 D4B02131556 for ; Thu, 6 Jul 2017 18:48:58 -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, RP_MATCHES_RCVD=-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=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 GsViu2Wd1X70 for ; Thu, 6 Jul 2017 18:48:53 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 89618129B38 for ; Thu, 6 Jul 2017 18:48:53 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id j186so9349756pge.2 for ; Thu, 06 Jul 2017 18:48:53 -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=v30F62PGZ9rzXQyZiP/thx61l9YsT78JM7jahszdNFY=; b=bTzkVvkReH3zcanqJATWD/Nk12Q3Wle70dKQx+TxksCI4GsWF1FU2MVUqYYlXGRjwd VKneUD7RVxiyHXCQx4Mo5moM5hvWdMhLB0QrcNwvkpn2eIv8QdGQDkUyHmaSdWikyHnn 4+xqHSlPfEJUC8tu3n93CJKJ2akge9Xs9hWT7EeR1dmjKbz5UBCOjYAyde2mbl+/BdJs cCwgHSqykJ/5h00g5aZqPPvtcwi5t13A9ExS7UE1b26SzmSLolU6adMPlDotoH8jevTE LnZ8nMV5njCLE686DpYwTozfZMCKKaJoJb7pYH2K+f+4UVhxze0AxvbdYOBfLGwa8RwF K8pg== 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=v30F62PGZ9rzXQyZiP/thx61l9YsT78JM7jahszdNFY=; b=E8KpbNjunAL8C38VbzbLZt7q3Px2bl9eZ1EwNccyKV3+eUNsNw366bdkkOcVc1C418 SBFmuban5/8jx4rNsy6pLWbzw3BrnuAcdndMbnnlbgqODv7ez1i9tfarnS6T31Rd0ZxA EuUkLoHUNMliP0QWIA/Nim/nYMyu7Ey5sO2D2T+ULudLOvtxdKRLg2C/m+VtW4fa26PA vNg8NOcYUuTEhlRYZYOfBfZr9ioWaimz8Uj8Bdu1r9uTXziRLNzPCdOgljL9c11Jo0sk UbpgcocKV3taYXvD6aVPSMs2Dmx0Fk0WN8UDJ00oo0TlzYGJ6bK8ZxBM/Krv0UGH2xuz f2nw== X-Gm-Message-State: AIVw111FpKf8vm04B7kGhi8pBzhzju5IaUONNfwEAJUIcin62gSJGvBd hAbpxG0Wbx+Z1kzIY0jx4YwRZCVZh+If X-Received: by 10.98.110.65 with SMTP id j62mr16338847pfc.115.1499392132648; Thu, 06 Jul 2017 18:48:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.153.19 with HTTP; Thu, 6 Jul 2017 18:48:51 -0700 (PDT) In-Reply-To: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri>

<2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com>

From: Jana Iyengar Date: Thu, 6 Jul 2017 18:48:51 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Subodh Iyengar Cc: "Lubashev, Igor" , Kazuho Oku , Ian Swett , Mike Bishop , Dmitri Tikhonov , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Jo Kulik , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="001a1139535872b2120553b06f38" 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, 07 Jul 2017 01:48:59 -0000 --001a1139535872b2120553b06f38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar wrote: > > Without such a signal, a generic proxy that is not aware of your > application internals is not able to know when to send the FIN > > I see, this use case does make somewhat sense, however I'm curious > if someone has a concrete use case for a generic QUIC proxy which is not > aware of the application protocol at all. In TCP this was more common for > middleboxes to do because there was no end to end encryption of the > transport, however QUIC is encrypted. Even with cases when we tunneling > protocols at our end, we usually have some knowledge of the app that we a= re > running because we need to route them differently to different backends. = I > was mostly thinking that proxies would at least have some knowledge about > HTTP/2 or app protocols. > This is my thinking too. I'm not sure I understand what sort of proxy would want to know about stream closures... but if such a proxy exists, it justifies the explicit signal. Maybe it is possible to make #656 more palatable, at least to me. I had 2 > things against it initially, which were: > > > 1. We might need to add another state to the machine to the sender > state, i.e. normally when sending a FIN, it is ok to keep receiving st= ream > frames after, however in a uni directional stream it is illegal to get= a > stream frame. > 2. In its current form it also has an implicit requirement to not open > lower streams. I think opening lower streams have some desirable prope= rties > which I've commented on in https://github.com/quicwg/ > base-drafts/issues/662. > > > An implementation could probably implement 1. with not too much trouble b= y > doing a special case in the stream state machine when it receives a strea= m > frame in the half closed local state. > I think this is covered by the current half-closed state. When an outgoing uni stream is created, it should have a final received offset of 0. If any STREAM frames are received that have data at an offset > the final received offset (which is 0 in this case), then the connection is torn down with QUIC_STREAM_DATA_AFTER_TERMINATION error (see Section 11.3 ). > For 2. thinking about it a bit more I think the underlying question here > is who enforces directionality, i.e. did I receive data I should not have= . > If it is the transport, then we need to answer that question with issue > #662, however if it can be the application or a higher layer API between > the application and transport that enforces directionality then we don't > need to know whether a lower stream is bi-directional or not. I'm leaning > towards an API between the transport and application enforcing > directionality. The reason for that is that an application that needs to > use unidirectionality needs to use a different API anyway. Given that we > could leave lower streams to be opened as it is now, but leaving the exac= t > semantics of enforcing bi-directionality or uni-directionality to a highe= r > layer. That should suffice for even a generic proxy right? > I thought about this, and I'm leaning towards having the transport enforce this. I like your suggestion of moving this logic up to the application. Implicit open is then just "open", and then the stream moves into half-closed state as it receives an application signal or a STREAM frame with the bit set. The tradeoff to consider here is that an implementation will not be able to instantiate an "optimized" uni stream on implicit creation (or will have to swap a bidirectional stream with a uni one). There's value in allowing implementations to implement optimized uni/bi stream objects, which would mean that the transport ought to be able to create one of these two types of objects, therefore allowing (requiring?) enforcement of directionality in the transport. Can you resolve #662 with a separate state? Meaning that implicitly open streams are now considered "reserved" (or some such). This allows you to have a separate state until you know for sure which type of stream you're constructing, which can happen via an application signal or from a received STREAM frame. I still prefer do nothing with app directed close though. > Having an explicit bit in the frame does allow for some more flexibility, which may be useful. > But I do not think that we should require every application protocol > built above QUIC to do its own framing. > > Second Kazuho on this one. > +1. This is the biggest argument for bidirectionality -- most applications need that, and expecting them to all create their own correlators and state machine to manage bidirectionality goes against what I'd consider useful transport API design. Extremely common design patterns, such as bidirectionality, should be part of the transport. - jana Subodh > > ------------------------------ > *From:* QUIC on behalf of Lubashev, Igor < > ilubashe@akamai.com> > *Sent:* Wednesday, July 5, 2017 8:50:05 PM > *To:* Kazuho Oku; Ian Swett > *Cc:* Mike Bishop; Dmitri Tikhonov; Swindells, Thomas (Nokia - > GB/Cambridge, UK); Jo Kulik; Mikkel Fahn=C3=B8e J=C3=B8rgensen; QUIC WG; = Martin > Thomson > > *Subject:* RE: Unidirectional streams PR > > > If a client needs a way to reset the server's response before observing > the first frame, it cannot use FIN as an indicator of the end of the > request. > > There is a DISINTEREST frame proposal (PR #171: https://github.com/quicwg= / > base-drafts/pull/171). That's something that I believe is valuable > independent of this Unidirectional streams PR. > > - Igor > > > -----Original Message----- > From: Kazuho Oku [mailto:kazuhooku@gmail.com ] > Sent: Wednesday, July 05, 2017 1:41 AM > To: Ian Swett > Cc: Lubashev, Igor ; Mike Bishop < > Michael.Bishop@microsoft.com>; Dmitri Tikhonov < > dtikhonov@litespeedtech.com>; Swindells, Thomas (Nokia - GB/Cambridge, > UK) ; Jo Kulik ; Mikkel > Fahn=C3=B8e J=C3=B8rgensen ; QUIC WG ;= Martin > Thomson > Subject: Re: Unidirectional streams PR > > 2017-06-29 10:23 GMT+09:00 Ian Swett : > > I updated my PR(#656) today, sorry for the delay. I attempted to > > address the issues identified with text. Some may prefer more tweaks > > to the state diagram, which are also possible, so I'm open to > suggestions. > > After all, I think that the approach proposed here is the most > well-balanced one. > > As much as I think that having first-class support for unidirectional > streams is preferable, I also think that we should keep the overall > architecture (i.e. sum of the complexity in the transport layer and the > application layer) as simple as possible. > > IMO having support for bidirectional streams (along with support for > unidirectional streams) aligns with such intention. > > Most of the application protocols that will be deployed over the QUIC > transport will be in request-response style, at least to some extent. > Hence it is preferable for the transport layer to provide a framework tha= t > fits such style. > > Bidirectional streams provide the necessary features. FIN provides a way > to indicate the end of the message. RST provides a way to cancel the > exchange of the message in both directions. > > IMO the biggest issue with the unidirectional-only approach is that you > cannot have the two features together. If a client needs a way to reset t= he > server's response before observing the first frame, it cannot use FIN as = an > indicator of the end of the request. > > It is true that the issue can be evaded by doing one's own framing in the > application layer. #643 does that by introducing a CANCEL_REQUEST frame. > > But I do not think that we should require every application protocol buil= t > above QUIC to do its own framing. In addition to that, need to keep two > uni-directional streams open would consume more resources than being able > to close one direction of a bi-directional stream at an earlier moment. > > > In the meantime, I've been considering other alternatives, including > > variations on Mike's direction and a variation of the "Do Nothing" > > option which involved the application signaling to the transport that > > streams of a certain sort(ie: server to client for server push) were > > unidirectional, as GQUIC does today. Overall, I think the approach > > I've outlined does a good job of iterating on existing deployment > > experience and adding explicit signaling for unidirectional streams > > instead of implicit signaling at the application layer. There are > > pros and cons to both explicit and implicit signaling, but I think > > explicit signaling is more complete and less prone to application error= . > > > > Thanks, Ian > > > > > > On Wed, Jun 28, 2017 at 8:14 PM, Lubashev, Igor > wrote: > >> > >> > unless what the transport provides is a perfect fit for application > >> > semantics, you end up building those semantics into the application > anyway. > >> > >> I agree with this. We should avoid adding complexity into transport > >> for rare use cases, since it goes against KISS principle. > >> > >> On the other hand, adding support for a by far the most common use > >> case makes a lot of sense. This helps apps avoid screwing up > >> implementing that common case and lets us optimize that common case > >> in the lower layer. BiDi streams are such common cases. Uni streams > >> are likely to be the second-most-common cases (hence you offered this > PR to optimize them). > >> > >> > >> The Associated Streams proposal offers extra semantic flexibility at > >> a cost of some semantic complexity (someone would need to verify that > >> the associated stream numbers make sense -- api? apps?) and a few extr= a > bytes. > >> > >> I'd like to wait to see Ian's revised proposal. The initial proposal > >> offered to do only one thing -- offer a choice of uni/bi-directional > >> streams > >> -- but it did it in a very simple way, which is nice. > >> > >> - Igor > >> > >> > >> -----Original Message----- > >> From: Martin Thomson [mailto:martin.thomson@gmail.com > ] > >> Sent: Wednesday, June 28, 2017 7:28 PM > >> To: Mike Bishop > >> Cc: Swindells, Thomas (Nokia - GB/Cambridge, UK) > >> ; QUIC WG ; Mikkel Fahn=C3= =B8e > >> J=C3=B8rgensen ; Dmitri Tikhonov > >> ; Jo Kulik > >> Subject: Re: Unidirectional streams PR > >> > >> There is probably a simpler approach here, take a bit (as Ian did) > >> and say that if that bit is set, then the stream is in response to > >> another and the stream ID of the stream to which this is responding > >> follows immediately after the stream ID of the stream itself. You > >> could then include that only at the start of the stream, or in multipl= e > frames (or as we decide). > >> > >> The problem with this, as with several of the other issues we're > >> discussing, is that unless what the transport provides is a perfect > >> fit for application semantics, you end up building those semantics > >> into the application anyway. HTTP certainly can't survive without > >> its own association semantics for pushes. That suggests to me that > >> having bidirectional semantics in the transport creates more > >> duplication than otherwise. Hence my proposal. > >> > >> On 28 June 2017 at 15:26, Mike Bishop > >> wrote: > >> > As promised, a PR for adding =E2=80=9Cassociated streams=E2=80=9D is= at > >> > https://github.com/quicwg/base-drafts/pull/672. This very > >> > deliberately builds on top of MT=E2=80=99s PR =E2=80=93 it=E2=80=99s= adding a primitive > >> > which can be used to construct various abstractions atop > >> > unidirectional streams, but the lifecycle is still fundamentally > unidirectional. > >> > > >> > > >> > > >> > Copying my notes here for list discussion purposes. > >> > > >> > Major changes > >> > > >> > Leveraging @igorlord's insight that OO=3D00 only occurs on the first > >> > STREAM frame of a stream, I used that as the trigger for a Stream > >> > Properties byte. > >> > Two bits of that byte describe the directionality of the stream: > >> > > >> > Unidirectional (no response expected) Initial bidirectional (one > >> > response expected) Initial multi-response (one or more responses > >> > expected; needs a better name) Response > >> > > >> > If the type is Response, there's an Associated Stream ID field, > >> > length given by two more bits following the same pattern as the SS > >> > bits in the STREAM frame ID. > >> > > >> > Personal Opinion > >> > > >> > On the plus side, these stream types seem to cover the abstractions > >> > I can envision for most applications. You can unilaterally send > >> > something (unidirectional), do request/response (bidirectional), or > >> > pub/sub (single subscription stream, series of update streams). > >> > > >> > I don't care for the fact that I still need the stream type header > >> > in HTTP after putting this in the transport. That will be > >> > ameliorated if we go back to one stream per request, since all > >> > unidirectional streams will be push streams. (As a side-note, I > >> > considered using the multiple-response option in the HTTP mapping, > >> > but then I need a stream header again to indicate which is the > >> > response and which the pushes.) > >> > > >> > I particularly don't like that you now have to look at the frame > >> > type header to find out whether a field exists which tells you the > >> > length of something else in the header. I'd like to simplify that. > >> > I went with this model over a CREATE_STREAM frame because of > >> > @mikkelfj's use-case of very small messages > >> > -- this adds only one byte to the first frame on a stream in one > >> > direction and 2-5 bytes to the first frame of response streams. A > >> > separate frame type would be somewhat larger, but could be cleaner > >> > in that respect. > >> > > >> > > >> > > >> > > >> > > >> > From: QUIC [mailto:quic-bounces@ietf.org ] On > Behalf Of Swindells, > >> > Thomas (Nokia - GB/Cambridge, UK) > >> > Sent: Wednesday, June 28, 2017 7:56 AM > >> > To: Jo Kulik ; Mikkel Fahn=C3=B8e J=C3=B8rgensen > >> > > >> > Cc: QUIC WG ; Dmitri Tikhonov > >> > > >> > Subject: RE: Unidirectional streams PR > >> > > >> > > >> > > >> > I agree that looking at the layers of abstraction is useful. In > >> > principle having the wire protocol just have constructs for > >> > unidirectional streams does not in itself limit creating > >> > bi-directional communication flows, supported at either the library > >> > or application layer. > >> > > >> > > >> > > >> > However, there need to be a standard way of doing bi-directional > >> > communication for migrating applications implemented using a socket > >> > style api. It needs to be easy to move an existing application from > >> > TCP to QUIC. > >> > This move may be attractive in many situations as QUIC gives > >> > improved security and may allow greater throughput due to the more > >> > modern (and > >> > customizable) congestion control algorithms compared to the OS TCP > >> > stack. > >> > > >> > > >> > > >> > For migrating standard socket api applications I don=E2=80=99t think= it > >> > would be appropriate to leave the work to the application to do > >> > correlation, at least the library should be providing this service > >> > using the wire protocol as appropriate. Clearly we want a client > >> > written with one library to be able to communicate successfully > >> > with a server written using a different library. > >> > This needs some form of standardization of the signalling. This > >> > could either be a building block overlay on top of QUIC, or > >> > implemented at the wire protocol level. > >> > > >> > > >> > > >> > In terms of patterns I think the following may be some of the most > >> > common patterns (with potential to be provided at the library and > >> > or wire protocol level). > >> > > >> > I/O pattern : Example > >> > > >> > 1/0 : An input only flow, perhaps a data logger like syslog with n= o > >> > confirmation/feedback > >> > > >> > 0/1 : an output only flow, perhaps a topic message bus service > >> > with no confirmation/feedback > >> > > >> > 1/1 : standard TCP applications with a single flow per connection > >> > > >> > 1/* : single input, many output, modelling STDIN/STDOUT+STDERR > >> > > >> > (1/1)* : multiplexed pairs of flows =E2=80=93 supporting multiple so= ckets > >> > muxed onto a single QUIC connection > >> > > >> > > >> > > >> > Obviously, an application would always have the option to combine > >> > any single direction flows with application level correlators to > >> > construct more complex flows if desired. > >> > > >> > > >> > > >> > At the moment my gut says the 1/1 use-case is common enough that > >> > the wire protocol should provide a standard mechanism to support it > >> > as a standard overlay would probably end up being treated as part > >> > of the wire format anyway. > >> > > >> > > >> > > >> > Perhaps streams should be explicitly created with a CREATE_STREAM > >> > frame which would be capable of defining multiple related streams? > >> > > >> > There is the option of whether only (1/1) pairs can be created this > >> > way, or > >> > (1/n) combinations could be supported (with an application defined > >> > way to identify the use of each of the output streams). A step > >> > further may be that there is a transport parameter that defines > >> > whether the server is allowed to create additional streams, or if > >> > stream creation is purely client driven (like TCP). I don=E2=80=99t = know if > >> > either of these would simplify how to handle stream accounting, and > >> > in particular only creating a flow when all parties have sufficient > allowances left. > >> > > >> > > >> > > >> > Thomas > >> > > >> > > >> > > >> > From: QUIC [mailto:quic-bounces@ietf.org ] On > Behalf Of Jo Kulik > >> > Sent: 28 June 2017 15:09 > >> > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > >> > Cc: QUIC WG ; Dmitri Tikhonov > >> > > >> > Subject: Re: Unidirectional streams PR > >> > > >> > > >> > > >> > I'd like to pop back up to a comment Igor made last week, because I > >> > find it helpful in thinking about the design space: > >> > > >> > > >> > > >> > I think of three layers of abstraction: > >> > > >> > 1. QUIC Wire Protocol (the thing described by the QUIC Transpo= rt > >> > RFC) > >> > 2. QUIC Library API (a library exposing some useful abstractio= ns > >> > -- > >> > such as blocking/non-blocking unidirectional streams and > >> > bidirectional =E2=80=9Csockets=E2=80=9D -- and implementing them usi= ng QUIC Wire > Protocol) > >> > 3. Application (something that uses QUIC Library APIs) > >> > > >> > I think there is some argument to be made that Martin's original > >> > proposal did not take into account how we would achieve (2) for > >> > bi-directional streams. (I don't think it strictly said "thou > >> > shalt not do (2)" either, but that is up to interpretation.) > >> > > >> > > >> > > >> > Several people have argued that we do not want every application to > >> > have to re-implement bi-directional streams (3) for every > >> > application, and this is not how g-quic (our largest deployment) > works right now. > >> > These arguments make sense to me, but YMMV. > >> > > >> > > >> > > >> > Just because the particular *mechanism* that is being proposed has > >> > some issues, however, doesn't scream out to me, at least, that we > >> > should abandon this particular *design goal*. The goal being a > >> > transport protocol that can elegantly fit with a uni/bi stream model= . > >> > Now, if we conclude that there can never be an elegant model that > >> > achieves this goal, then so be it. But I also feel like we haven't > >> > reached that point in the discussion yet. (At the very least, this > >> > discussion has been fruitful to me in terms of mapping the design > >> > space and elucidating requirements). > >> > > >> > > >> > > >> > One of the reasons I still think this design goal is under > >> > consideration is that Ian and Igor/Mike have been talking about > >> > alternate solutions which have a similar flavor. During the recent > >> > "quiet"ness on the thread, personally, I've been waiting to hear > >> > more from them. > >> > > >> > > >> > > >> > On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen > >> > wrote: > >> > > >> > In reply to Ranjeeth > >> > > >> > > >> > > >> > It is not only a matter of simplicity for the sake of simplicity: > >> > > >> > > >> > > >> > - A complex transport layer might end up being poorly implemented > >> > leading to reduced interoperability and ultimately adoption. This > >> > complexity is not only in implementation but also in understanding > >> > the exact semantics of stream lifetime. Even if the spec is > >> > sufficiently clear, it will still be open to misinterpretations. > >> > > >> > > >> > > >> > - Bi-directional state may have to be maintained longer and with > >> > more overhead than with uni-directional streams, especially under > >> > loss, potentially leading to poor performance and poor resource > >> > utilisation because the transport layer has insufficient information= . > >> > > >> > > >> > > >> > - The extra complexity at the application layer may be overstated - > >> > it is significantly simpler to manage a map that associates to two > >> > streams than it is to maintain bi-directional state at the > >> > transport layer. It is even possible to implicitly link streams > >> > with same identifiers, e.g. in a RPC scenario. That said, I do see > >> > a potential benefit of a wrapper that implements the common > bi-directional case. > >> > > >> > > >> > > >> > - Complexity at the application layer may be duplicated, but > >> > implementation errors are also isolated to that application. > >> > Specifically for HTTP I would assume that QUIC transport and QUIC > >> > HTTP implementers would be large the same for a long time to come, > >> > so I would not expect the tradeoff here to be particularly concernin= g. > >> > > >> > > >> > > >> > - Unix pipes are traditionally constructed as a pair of > >> > uni-directional file descriptors and that is a reasonably proven > >> > model. C=E2=80=99s standard library stdin, stdout and stderr is an e= xample > >> > of an asymmetric model with implicit linkage between > >> > uni-directional file descriptors. > >> > > >> > > >> > > >> > - There are lots of use cases for non-HTTP like connectivity - > >> > Kafka high volume message queuing for example. The industry trend > >> > appears to move towards asynchronous processing and messaging. It > >> > depends on whether you look at QUIC as a TCP + TLS replacement, or > >> > as a HTTPS / REST RPC replacement. > >> > > >> > > >> > > >> > - Uni-directional streams may currently be unproven in the wild, > >> > but a proposal is needed before an implementation can be made and > >> > testet. I agree that it is easy to design into wrong assumptions > >> > without real world testing. > >> > > >> > > >> > > >> > - There will hopefully not be a large number of successors to QUIC > >> > - perhaps some purpose specific variants, e.g. for embedded use. > >> > Widespread adaptation and compatibility is very necessary so it > >> > makes sense to have QUIC being sufficiently simple and expressive > >> > to achieve this goal. A polymorf QUIC will not achieve that goal. > >> > On the other hand, a solid QUIC foundation can be used for a large > >> > number of application protocols. > >> > > >> > > >> > > >> > - Finally, it may turn out that uni-directional streams just is a > >> > bad idea - I doubt it, but I do believe real world tests are needed. > >> > > >> > > >> > > >> > Kind Regards, > >> > > >> > Mikkel Fahn=C3=B8e J=C3=B8rgensen > >> > > >> > > >> > > >> > On 28 June 2017 at 14.42.36, Dmitri Tikhonov > >> > (dtikhonov@litespeedtech.com) > >> > wrote: > >> > > >> > On Tue, Jun 27, 2017 at 02:31:38PM -0700, Ranjeeth Kumar Dasineni > wrote: > >> >> 2. We are overplaying the simplicity of design. Even if we deem > >> >> deployment experience not a concern, if every application layer > >> >> protocol that needs support for bidirectional streams has to > >> >> implement some correlators and such above, that's a net negative > >> >> in terms of complexity. > >> > > >> > This is an important point: we want QUIC adoption to be made easy. > >> > A program that speaks HTTP today should be able to use an existing > >> > QUIC library without having to emulate bidirectional streams in > >> > order to fit it into HTTP usage pattern. Forcing every one of these > >> > programs to do this is certainly a hurdle. > >> > > >> > - Dmitri. > >> > > >> > > >> > > > > > > -- > Kazuho Oku > --001a1139535872b2120553b06f38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On W= ed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar <> wr= ote:

>=C2=A0Without such a signal, a gene= ric proxy that is not aware of your application internals is not able to kn= ow when to send the FIN

I see, this use case does make somewhat= sense, however I'm curious if=C2=A0someone has=C2=A0a concrete=C2=A0us= e case for a generic QUIC proxy which is not aware of the application protocol at all. In TCP this was more common for middleboxes t= o do because there was no end to end encryption of the transport, however Q= UIC is encrypted. Even with cases when we=C2=A0tunneling protocols at our e= nd, we usually have some knowledge of the app that we are running because we need to route them differently to d= ifferent backends.=C2=A0I was mostly thinking that=C2=A0proxies would at le= ast have some knowledge=C2=A0about HTTP/2 or app protocols.

This= is my thinking too. I'm not sure I understand what sort of proxy would= want to know about stream closures... but if such a proxy exists, it justi= fies the explicit signal.

Maybe it is=C2=A0possible to make #656 more palatable, at least to me. I ha= d 2 things against it initially, which were:

We might need to add another state to the machine to the sender state, = i.e. normally when sending a FIN, it is ok to keep receiving stream frames = after, however in a uni directional stream it is illegal to get a stream fr= ame.
In its current form it also has an implicit requirement to not= open lower streams. I think opening lower streams have some desirable prop= erties which I've commented on in=C2=A0http= s://github.com/quicwg/base-drafts/issues/662.

An implementation could probably implement 1. with not too much troubl= e by doing a special case in the stream state machine when it receives a st= ream frame in the half closed local state.

I think this is covered by = the current half-closed state. When an outgoing uni stream is created, it s= hould have a final received offset of 0. If any STREAM frames are received = that have data at an offset > the final received offset (which is 0 in t= his case), then the connection is torn down with QUIC_STREAM_DATA_AFTER_TER= MINATION error (see ).

=C2=A0

I thought about this, and I'm = leaning towards having the transport enforce this.=C2=A0

I like your suggestion of moving this logic up to the applicati= on. Implicit open is then just "open", and then the stream moves = into half-closed state as it receives an application signal or a STREAM fra= me with the bit set. The tradeoff to consider here is that an implementatio= n will not be able to instantiate an "optimized" uni stream on im= plicit creation (or will have to swap a bidirectional stream with a uni one= ). There's value in allowing implementations to implement optimized uni= /bi stream objects, which would mean that the transport ought to be able to= create one of these two types of objects, therefore allowing (requiring?) = enforcement of directionality in the transport.

<= div>Can you resolve #662 with a separate state? Meaning that implicitly ope= n streams are now considered "reserved" (or some such). This allo= ws you to have a separate state until you know for sure which type of strea= m you're constructing, which can happen via an application signal or fr= om a received STREAM frame.

I still prefer do nothing with app directed close=C2=A0though.
=

Having an e= xplicit bit in the frame does allow for some more flexibility, which may be= useful.

>=C2=A0But I do not think that we should require every application protocol built abo= ve QUIC to do its own framing.

Second Kazuho on this one.

+1. This is the biggest argument for bidirecti= onality -- most applications need that, and expecting them to all create th= eir own correlators and state machine to manage bidirectionality goes again= st what I'd consider useful transport API design. Extremely common desi= gn patterns, such as bidirectionality, should be part of the transport.
=C2=A0
- jana

Subodh

F= rom: QUIC <quic-bounces@ietf.org> on behalf of Lubashev, Igor <ilubashe@akamai.com> Sent: Wednesday, July 5, 2017 8:50:05 PM
To: Kazuho Oku; Ian Swett
Cc: Mike Bishop; Dmitri Tikhonov; Swindells, Thomas (Nokia - GB/Camb= ridge, UK); Jo Kulik; Mikkel Fahn=C3=B8e J=C3=B8rgensen; QUIC WG; Martin Th= omson

Subject: RE: Unidirectional streams PR

=C2=A0

> If a client needs= a way to reset the server's response before observing the first frame,= it cannot use FIN as an indicator of the end of the request.

There is a DISINTEREST frame proposal (PR #171: https://github.com/quicwg/base-drafts/pull/171).=C2=A0 That's = something that I believe is valuable independent of this Unidirectional str= eams PR.

- Igor

-----Original Message-----
From: Kazuho Oku [= mailto:kazuhooku@gmail.com]
Sent: Wednesday, July 05, 2017 1:41 AM
To: Ian Swett <= ianswett@google.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Mike Bishop <Michael.Bishop@microsoft.com&g= t;; Dmitri Tikhonov <dtikhonov@litespeedtech.com>; Swindells, Thomas (= Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.com>; Jo Kulik <jokulik@google.com>= ; Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail= .com>; QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Unidirectional streams PR

2017-06-29 10:23 GMT+09:00 Ian Swett <ianswett@google.com>:
> I updated my PR(#656) today, sorry for the delay.=C2=A0 I attempted to=
> address the issues identified with text.=C2=A0 Some may prefer more tw= eaks
> to the state diagram, which are also possible, so I'm open to sugg= estions.

After all, I think that the approach proposed here is the most well-balance= d one.

As much as I think that having first-class support for unidirectional strea= ms is preferable, I also think that we should keep the overall architecture= (i.e. sum of the complexity in the transport layer and the application lay= er) as simple as possible.

IMO having support for bidirectional streams (along with support for unidir= ectional streams) aligns with such intention.

Most of the application protocols that will be deployed over the QUIC trans= port will be in request-response style, at least to some extent.
Hence it is preferable for the transport layer to provide a framework that = fits such style.

Bidirectional streams provide the necessary features. FIN provides a way to= indicate the end of the message. RST provides a way to cancel the exchange= of the message in both directions.

IMO the biggest issue with the unidirectional-only approach is that you can= not have the two features together. If a client needs a way to reset the se= rver's response before observing the first frame, it cannot use FIN as = an indicator of the end of the request.

It is true that the issue can be evaded by doing one's own framing in t= he application layer. #643 does that by introducing a CANCEL_REQUEST frame.=

But I do not think that we should require every application protocol built = above QUIC to do its own framing. In addition to that, need to keep two uni= -directional streams open would consume more resources than being able to c= lose one direction of a bi-directional stream at an earlier moment.

> In the meantime, I've been considering other alternatives, includi= ng
> variations on Mike's direction and a variation of the "Do Not= hing"
> option which involved the application signaling to the transport that =
> streams of a certain sort(ie: server to client for server push) were <= br> > unidirectional, as GQUIC does today.=C2=A0 Overall, I think the approa= ch
> I've outlined does a good job of iterating on existing deployment =
> experience and adding explicit signaling for unidirectional streams > instead of implicit signaling at the application layer.=C2=A0 There ar= e
> pros and cons to both explicit and implicit signaling, but I think > explicit signaling is more complete and less prone to application erro= r.
>
> Thanks, Ian
>
>
> On Wed, Jun 28, 2017 at 8:14 PM, Lubashev, Igor <ilubashe@akamai.com> wrote: >>
>> > unless what the transport provides is a perfect fit for appli= cation
>> > semantics, you end up building those semantics into the appli= cation anyway.
>>
>> I agree with this. We should avoid adding complexity into transpor= t
>> for rare use cases, since it goes against KISS principle.
>>
>> On the other hand, adding support for a by far the most common use=
>> case makes a lot of sense.=C2=A0 This helps apps avoid screwing up=
>> implementing that common case and lets us optimize that common cas= e
>> in the lower layer. BiDi streams are such common cases. Uni stream= s
>> are likely to be the second-most-common cases (hence you offered t= his PR to optimize them).
>>
>>
>> The Associated Streams proposal offers extra semantic flexibility = at
>> a cost of some semantic complexity (someone would need to verify t= hat
>> the associated stream numbers make sense -- api? apps?) and a few = extra bytes.
>>
>> I'd like to wait to see Ian's revised proposal.=C2=A0 The = initial proposal
>> offered to do only one thing -- offer a choice of uni/bi-direction= al
>> streams
>> -- but it did it in a very simple way, which is nice.
>>
>> - Igor
>>
>>
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: Wednesday, June 28, 2017 7:28 PM
>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>> Cc: Swindells, Thomas (Nokia - GB/Cambridge, UK)
>> <thomas.swindells@nokia.com>; QUIC WG <quic@ietf.org>; Mikkel Fahn=C3=B8e
>> J=C3=B8rgensen <mikkelfj@gmail.com>; Dmitri Tikhonov
>> <dtikhonov@litespeedtech.com>; Jo Kulik <jokulik@google.com>
>> Subject: Re: Unidirectional streams PR
>>
>> There is probably a simpler approach here, take a bit (as Ian did)=
>> and say that if that bit is set, then the stream is in response to=
>> another and the stream ID of the stream to which this is respondin= g
>> follows immediately after the stream ID of the stream itself.=C2= =A0 You
>> could then include that only at the start of the stream, or in mul= tiple frames (or as we decide).
>>
>> The problem with this, as with several of the other issues we'= re
>> discussing, is that unless what the transport provides is a perfec= t
>> fit for application semantics, you end up building those semantics=
>> into the application anyway.=C2=A0 HTTP certainly can't surviv= e without
>> its own association semantics for pushes.=C2=A0 That suggests to m= e that
>> having bidirectional semantics in the transport creates more
>> duplication than otherwise.=C2=A0 Hence my proposal.
>>
>> On 28 June 2017 at 15:26, Mike Bishop <Michael.Bishop@microsoft.com&= gt;
>> wrote:
>> > As promised, a PR for adding =E2=80=9Cassociated streams=E2= =80=9D is at
>> > https://github.com/quicwg/base-drafts/pull/672.=C2= =A0 This very
>> > deliberately builds on top of MT=E2=80=99s PR =E2=80=93 it=E2= =80=99s adding a primitive
>> > which can be used to construct various abstractions atop
>> > unidirectional streams, but the lifecycle is still fundamenta= lly unidirectional.
>> >
>> >
>> >
>> > Copying my notes here for list discussion purposes.
>> >
>> > Major changes
>> >
>> > Leveraging @igorlord's insight that OO=3D00 only occurs o= n the first
>> > STREAM frame of a stream, I used that as the trigger for a St= ream
>> > Properties byte.
>> > Two bits of that byte describe the directionality of the stre= am:
>> >
>> > Unidirectional (no response expected) Initial bidirectional (= one
>> > response expected) Initial multi-response (one or more respon= ses
>> > expected; needs a better name) Response
>> >
>> > If the type is Response, there's an Associated Stream ID = field,
>> > length given by two more bits following the same pattern as t= he SS
>> > bits in the STREAM frame ID.
>> >
>> > Personal Opinion
>> >
>> > On the plus side, these stream types seem to cover the abstra= ctions
>> > I can envision for most applications. You can unilaterally se= nd
>> > something (unidirectional), do request/response (bidirectiona= l), or
>> > pub/sub (single subscription stream, series of update streams= ).
>> >
>> > I don't care for the fact that I still need the stream ty= pe header
>> > in HTTP after putting this in the transport. That will be >> > ameliorated if we go back to one stream per request, since al= l
>> > unidirectional streams will be push streams. (As a side-note,= I
>> > considered using the multiple-response option in the HTTP map= ping,
>> > but then I need a stream header again to indicate which is th= e
>> > response and which the pushes.)
>> >
>> > I particularly don't like that you now have to look at th= e frame
>> > type header to find out whether a field exists which tells yo= u the
>> > length of something else in the header. I'd like to simpl= ify that.
>> > I went with this model over a CREATE_STREAM frame because of =
>> > @mikkelfj's use-case of very small messages
>> > -- this adds only one byte to the first frame on a stream in = one
>> > direction and 2-5 bytes to the first frame of response stream= s. A
>> > separate frame type would be somewhat larger, but could be cl= eaner
>> > in that respect.
>> >
>> >
>> >
>> >
>> >
>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Swindells,
>> > Thomas (Nokia - GB/Cambridge, UK)
>> > Sent: Wednesday, June 28, 2017 7:56 AM
>> > To: Jo Kulik <jokulik@google.com>; Mikkel Fahn=C3=B8e J=C3=B8rgensen <= br> >> > <m= ikkelfj@gmail.com>
>> > Cc: QUIC WG <quic@ietf.org>; Dmitri Tikhonov
>> > <dtikhonov@litespeedtech.com>
>> > Subject: RE: Unidirectional streams PR
>> >
>> >
>> >
>> > I agree that looking at the layers of abstraction is useful. = In
>> > principle having the wire protocol just have constructs for <= br> >> > unidirectional streams does not in itself limit creating
>> > bi-directional communication flows, supported at either the l= ibrary
>> > or application layer.
>> >
>> >
>> >
>> > However, there need to be a standard way of doing bi-directio= nal
>> > communication for migrating applications implemented using a = socket
>> > style api. It needs to be easy to move an existing applicatio= n from
>> > TCP to QUIC.
>> > This move may be attractive in many situations as QUIC gives =
>> > improved security and may allow greater throughput due to the= more
>> > modern (and
>> > customizable) congestion control algorithms compared to the O= S TCP
>> > stack.
>> >
>> >
>> >
>> > For migrating standard socket api applications I don=E2=80=99= t think it
>> > would be appropriate to leave the work to the application to = do
>> > correlation, at least the library should be providing this se= rvice
>> > using the wire protocol as appropriate. Clearly we want a cli= ent
>> > written with one library to be able to communicate successful= ly
>> > with a server written using a different library.
>> > This needs some form of standardization of the signalling. Th= is
>> > could either be a building block overlay on top of QUIC, or <= br> >> > implemented at the wire protocol level.
>> >
>> >
>> >
>> > In terms of patterns I think the following may be some of the= most
>> > common patterns (with potential to be provided at the library= and
>> > or wire protocol level).
>> >
>> > I/O pattern=C2=A0 : Example
>> >
>> > 1/0=C2=A0=C2=A0 : An input only flow, perhaps a data logger l= ike syslog with no
>> > confirmation/feedback
>> >
>> > 0/1=C2=A0 : an output only flow, perhaps a topic message bus = service
>> > with no confirmation/feedback
>> >
>> > 1/1 : standard TCP applications with a single flow per connec= tion
>> >
>> > 1/* : single input, many output, modelling STDIN/STDOUT+STDER= R
>> >
>> > (1/1)* : multiplexed pairs of flows =E2=80=93 supporting mult= iple sockets
>> > muxed onto a single QUIC connection
>> >
>> >
>> >
>> > Obviously, an application would always have the option to com= bine
>> > any single direction flows with application level correlators= to
>> > construct more complex flows if desired.
>> >
>> >
>> >
>> > At the moment my gut says the 1/1 use-case is common enough t= hat
>> > the wire protocol should provide a standard mechanism to supp= ort it
>> > as a standard overlay would probably end up being treated as = part
>> > of the wire format anyway.
>> >
>> >
>> >
>> > Perhaps streams should be explicitly created with a CREATE_ST= REAM
>> > frame which would be capable of defining multiple related str= eams?
>> >
>> > There is the option of whether only (1/1) pairs can be create= d this
>> > way, or
>> > (1/n) combinations could be supported (with an application de= fined
>> > way to identify the use of each of the output streams). A ste= p
>> > further may be that there is a transport parameter that defin= es
>> > whether the server is allowed to create additional streams, o= r if
>> > stream creation is purely client driven (like TCP). I don=E2= =80=99t know if
>> > either of these would simplify how to handle stream accountin= g, and
>> > in particular only creating a flow when all parties have suff= icient allowances left.
>> >
>> >
>> >
>> > Thomas
>> >
>> >
>> >
>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jo Kulik
>> > Sent: 28 June 2017 15:09
>> > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
>> > Cc: QUIC WG <quic@ietf.org>; Dmitri Tikhonov
>> > <dtikhonov@litespeedtech.com>
>> > Subject: Re: Unidirectional streams PR
>> >
>> >
>> >
>> > I'd like to pop back up to a comment Igor made last week,= because I
>> > find it helpful in thinking about the design space:
>> >
>> >
>> >
>> > I think of three layers of abstraction:
>> >
>> > 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 QUIC Wire Protocol (th= e thing described by the QUIC Transport
>> > RFC)
>> > 2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 QUIC Library API (a li= brary exposing some useful abstractions
>> > --
>> > such as blocking/non-blocking unidirectional streams and
>> > bidirectional =E2=80=9Csockets=E2=80=9D -- and implementing t= hem using QUIC Wire Protocol)
>> > 3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Application (something= that uses QUIC Library APIs)
>> >
>> > I think there is some argument to be made that Martin's o= riginal
>> > proposal did not take into account how we would achieve (2) f= or
>> > bi-directional streams.=C2=A0 (I don't think it strictly = said "thou
>> > shalt not do (2)" either, but that is up to interpretati= on.)
>> >
>> >
>> >
>> > Several people have argued that we do not want every applicat= ion to
>> > have to re-implement bi-directional streams (3) for every >> > application, and this is not how g-quic (our largest deployme= nt) works right now.
>> > These arguments make sense to me, but YMMV.
>> >
>> >
>> >
>> > Just because the particular *mechanism* that is being propose= d has
>> > some issues, however, doesn't scream out to me, at least,= that we
>> > should abandon this particular *design goal*.=C2=A0 The goal = being a
>> > transport protocol that can elegantly fit with a uni/bi strea= m model.
>> > Now, if we conclude that there can never be an elegant model = that
>> > achieves this goal, then so be it.=C2=A0 But I also feel like= we haven't
>> > reached that point in the discussion yet.=C2=A0 (At the very = least, this
>> > discussion has been fruitful to me in terms of mapping the de= sign
>> > space and elucidating requirements).
>> >
>> >
>> >
>> > One of the reasons I still think this design goal is under >> > consideration is that Ian and Igor/Mike have been talking abo= ut
>> > alternate solutions which have a similar flavor.=C2=A0 During= the recent
>> > "quiet"ness on the thread, personally, I've bee= n waiting to hear
>> > more from them.
>> >
>> >
>> >
>> > On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahn=C3=B8e J=C3=B8rg= ensen
>> > <m= ikkelfj@gmail.com> wrote:
>> >
>> > In reply to Ranjeeth
>> >
>> >
>> >
>> > It is not only a matter of simplicity for the sake of simplic= ity:
>> >
>> >
>> >
>> > - A complex transport layer might end up being poorly impleme= nted
>> > leading to reduced interoperability and ultimately adoption. = This
>> > complexity is not only in implementation but also in understa= nding
>> > the exact semantics of stream lifetime. Even if the spec is <= br> >> > sufficiently clear, it will still be open to misinterpretatio= ns.
>> >
>> >
>> >
>> > - Bi-directional state may have to be maintained longer and w= ith
>> > more overhead than with uni-directional streams, especially u= nder
>> > loss, potentially leading to poor performance and poor resour= ce
>> > utilisation because the transport layer has insufficient info= rmation.
>> >
>> >
>> >
>> > - The extra complexity at the application layer may be overst= ated -
>> > it is significantly simpler to manage a map that associates t= o two
>> > streams than it is to maintain bi-directional state at the >> > transport layer. It is even possible to implicitly link strea= ms
>> > with same identifiers, e.g. in a RPC scenario. That said, I d= o see
>> > a potential benefit of a wrapper that implements the common b= i-directional case.
>> >
>> >
>> >
>> > - Complexity at the application layer may be duplicated, but =
>> > implementation errors are also isolated to that application.<= br> >> > Specifically for HTTP I would assume that QUIC transport and = QUIC
>> > HTTP implementers would be large the same for a long time to = come,
>> > so I would not expect the tradeoff here to be particularly co= ncerning.
>> >
>> >
>> >
>> > - Unix pipes are traditionally constructed as a pair of
>> > uni-directional file descriptors and that is a reasonably pro= ven
>> > model. C=E2=80=99s standard library stdin, stdout and stderr = is an example
>> > of an asymmetric model with implicit linkage between
>> > uni-directional file descriptors.
>> >
>> >
>> >
>> > - There are lots of use cases for non-HTTP like connectivity = -
>> > Kafka high volume message queuing for example. The industry t= rend
>> > appears to move towards asynchronous processing and messaging= . It
>> > depends on whether you look at QUIC as a TCP + TLS replacemen= t, or
>> > as a HTTPS / REST RPC replacement.
>> >
>> >
>> >
>> > - Uni-directional streams may currently be unproven in the wi= ld,
>> > but a proposal is needed before an implementation can be made= and
>> > testet. I agree that it is easy to design into wrong assumpti= ons
>> > without real world testing.
>> >
>> >
>> >
>> > - There will hopefully not be a large number of successors to= QUIC
>> > - perhaps some purpose specific variants, e.g. for embedded u= se.
>> > Widespread adaptation and compatibility is very necessary so = it
>> > makes sense to have QUIC being sufficiently simple and expres= sive
>> > to achieve this goal. A polymorf QUIC will not achieve that g= oal.
>> > On the other hand, a solid QUIC foundation can be used for a = large
>> > number of application protocols.
>> >
>> >
>> >
>> > - Finally, it may turn out that uni-directional streams just = is a
>> > bad idea - I doubt it, but I do believe real world tests are = needed.
>> >
>> >
>> >
>> > Kind Regards,
>> >
>> > Mikkel Fahn=C3=B8e J=C3=B8rgensen
>> >
>> >
>> >
>> > On 28 June 2017 at 14.42.36, Dmitri Tikhonov
>> > (dtikhonov@litespeedtech.com)
>> > wrote:
>> >
>> > On Tue, Jun 27, 2017 at 02:31:38PM -0700, Ranjeeth Kumar Dasi= neni wrote:
>> >> 2. We are overplaying the simplicity of design. Even if w= e deem
>> >> deployment experience not a concern, if every application= layer
>> >> protocol that needs support for bidirectional streams has= to
>> >> implement some correlators and such above, that's a n= et negative
>> >> in terms of complexity.
>> >
>> > This is an important point: we want QUIC adoption to be made = easy.
>> > A program that speaks HTTP today should be able to use an exi= sting
>> > QUIC library without having to emulate bidirectional streams = in
>> > order to fit it into HTTP usage pattern. Forcing every one of= these
>> > programs to do this is certainly a hurdle.
>> >
>> > - Dmitri.
>> >
>> >
>>
>

--
Kazuho Oku

--001a1139535872b2120553b06f38-- From nobody Thu Jul 6 19:05: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 811EC131537 for ; Thu, 6 Jul 2017 19:05: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, 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 tEcodrBatZ4N for ; Thu, 6 Jul 2017 19:05:01 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 1D706129B17 for ; Thu, 6 Jul 2017 19:05:01 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 188so879263itx.0 for ; Thu, 06 Jul 2017 19:05:01 -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=ee5glioYRs5C6TmqxKQj92c4rh7P4eDVfHMLb0AQCts=; b=nRcdCnTps+67Yxdj1vEVfmc3GqVjZVz1R/MF5KZOHQFSfC4CuAG9wuKCj7dJoJRvUS sTOK9SKJs3rGwJ0jCOzUPiTinGZbkGBcbWy2HVsj217ZrsTmyhv16cHaqtMWPx2hriUe GAmlE74jxYwn5Nsb7mpadHY21FCvY4pg4rQjOYz2vNVfspHSAhlahzIoXNFFxjXBGPjH zFbrWL94PKA6Cdek7JPN1U3xNWkfixZB79gnzQ/nbD0UQvXfrFyHUjlH/j+Md7C/f29j +oq94fwF8zdl7x/j3t4vRJb2MjGwz0lzCNljY3klOKfB19pjIF8kdNW2scl1zQoZOfWD IVeA== 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=ee5glioYRs5C6TmqxKQj92c4rh7P4eDVfHMLb0AQCts=; b=bEuUPA4V2XDMzE72LMUzmB+xXrRjqDnPorsgygDjJoVpilrae4nNVfZoP/V3zhWd09 fqhJqDl0Efqrjx1fyQ0ShfiA5z1JDSNMIQew6OqTUhbgJKtDwL54nMACoPVL57Xe1F64 quXg0/siu5v00LAhX4yE8CIva/wyJIGjx98pRWjH8ww3oqwHiXZIgi85lAPo4d+PYVXO liKBX5IXrmt5JYMgLpLq+nfkHlnm9VdKAPxTZ4Kw5aJJhtOlC9jEwl6pP7SSkX1fNvtO Mg8SO5pK1s5ECZCktluc5ddAPaNtoiuLgxpzUhPyF0Zsv+EJg2mxrL0F4KK8XyH7sxdi hIQA== X-Gm-Message-State: AIVw112plHeUqJQwQQGFluU0zzvuwhCjBi4y+cQDz8PLzkqvzAQ8c4c6 TQghowxbfIdeSTZa2w1BgQDW3a33xHJc X-Received: by 10.36.125.81 with SMTP id b78mr806715itc.26.1499393100525; Thu, 06 Jul 2017 19:05:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.162 with HTTP; Thu, 6 Jul 2017 19:04:59 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 7 Jul 2017 12:04:59 +1000 Message-ID: Subject: Re: Unidirectional streams PR To: Kazuho Oku 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: Fri, 07 Jul 2017 02:05:02 -0000 On 7 July 2017 at 11:43, Kazuho Oku wrote: > So it would be sensible to stop initiating new requests on an existing > connection when the number of unused stream IDs of the peer becomes as > low as max-concurrent-streams multiplied by some safety factor > (something like 10 would be enough, considering the probability of > loss or reordering of packets carrying DATA frames and consecutive > MAX_STREAM_ID frames). Yeah, you have to allow for the possibility of the server wanting to push some number of times in response to each of your requests. I was originally going to say that you hit the wall only once you MAX_STREAM_ID hits the limit, but the server can always promise in excess of this limit. If you want those promises to be resolved, then allowing more space is reasonable. 10 sounds reasonable, but we can't know the distribution of pushes to requests (today it is close to 0 in the aggregate, but this could change). From nobody Thu Jul 6 19:21: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 BA80E1316B7 for ; Thu, 6 Jul 2017 19:21:14 -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, FREEMAIL_FROM=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 S5VMynPwk20J for ; Thu, 6 Jul 2017 19:21:13 -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 75026131684 for ; Thu, 6 Jul 2017 19:21:13 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id t186so9762277pgb.1 for ; Thu, 06 Jul 2017 19:21:13 -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=5OzlgaxG21ScD3tYYOA+lY+RkvRdPUtULwul7m/RMEY=; b=VoLVESNm3zLvVoB/hco699VGLx+h6kVBCjlsTY64lmNsoKM/+pk7ZQt9oZWykrf27G JeYmdsVpd1uL3zRH/VwmO1+QqHx9o8j8e3yfqNz2DkSl6tlePz/B/Lm4EpHyog8CQJGM nMC6W87xY9Trcy2ueXub0fsNfnHWZPJPI4az0v9tae0nKvIdmynhQu8VRQ1//cUQLmer lLnRB2GYX6mK7BzjDKMAuim79oxk8NvUgT8CmqP7BDHnehezhVXpDGOTvbdmUXthkOTd B10RSOuBltsrxkZMTogtzis2/ZLdcdf9Osw4HCoNk4M9V0yI73fp/JYW2Nx6IpRO4sOk qJrg== 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=5OzlgaxG21ScD3tYYOA+lY+RkvRdPUtULwul7m/RMEY=; b=nj1qgzqK409+OLafIQhzZdiWhCevmrtQw0aLDyABMVI1Wow3AojMhHKAKGTv3v30P5 o7AAz5scYm5W5Cd8TGIXoyoilfG3Lp/RoE234apsOsV0iR4Jo12hnBlnqUWg0H5yHACa MxcBsWHqsUomhGbjl5abkN0m2FmrTr/FqoYxrty+b2MHLs7o0knmxzAuFqIofu6PMVfx GSqZfcqlNrZlsuOQwk01cq9RKNr+pAmkFJzK9h5yFmZ71hWqcnJlH41S6JCA2uxyPvEv oWsOSiQ9fV9TTmGnjUmhbTFmoE9KHmBMFcuSNiyb3f2RyuQFRWWM8hDtsIuAJ5F1uH92 hwMA== X-Gm-Message-State: AIVw113DkufFCkL8zqxAKbQbHqBBhB5ieGH77ykj3FDEcgSkQ+tz8rPk iGJfl74mYw0d3zDJN/2ryLgdVHPUdw== X-Received: by 10.84.231.197 with SMTP id g5mr289692pln.71.1499394073075; Thu, 06 Jul 2017 19:21:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Thu, 6 Jul 2017 19:21:11 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 7 Jul 2017 11:21:11 +0900 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson 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: Fri, 07 Jul 2017 02:21:15 -0000 2017-07-07 11:04 GMT+09:00 Martin Thomson : > On 7 July 2017 at 11:43, Kazuho Oku wrote: >> So it would be sensible to stop initiating new requests on an existing >> connection when the number of unused stream IDs of the peer becomes as >> low as max-concurrent-streams multiplied by some safety factor >> (something like 10 would be enough, considering the probability of >> loss or reordering of packets carrying DATA frames and consecutive >> MAX_STREAM_ID frames). > > Yeah, you have to allow for the possibility of the server wanting to > push some number of times in response to each of your requests. I was > originally going to say that you hit the wall only once you > MAX_STREAM_ID hits the limit, but the server can always promise in > excess of this limit. If you want those promises to be resolved, then > allowing more space is reasonable. 10 sounds reasonable, but we can't > know the distribution of pushes to requests (today it is close to 0 in > the aggregate, but this could change). That's a good point. Considering the complexity of guessing when the server runs out of stream IDs, it might be easier if we could use a server-sent CANCEL_REQUEST frame as an indication that the client needs to resend the request on a new connection. -- Kazuho Oku From nobody Thu Jul 6 20:07:39 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 16D2E127698 for ; Thu, 6 Jul 2017 20:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, 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 Wg_OfUPdY-4X for ; Thu, 6 Jul 2017 20:07:32 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 7E2D0126E3A for ; Thu, 6 Jul 2017 20:07:32 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6737R23017678; Fri, 7 Jul 2017 04:07:27 +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=FQw1ZLc35Qvc51o3AQD1SpgfjEAuCg+UIyleoisedWQ=; b=OGQY8O1ZFkg9Nl6i6GmFstmCpaIe9x4UukNMDI4YuQ6Wa1yEe9UmPFTPwcwPDBfxjqkL TRaozNeT+KMVse/4224xf4Z9LccY2jsWFDOGP1KmCbxvHMU8UFFgEi2LxNAZcPD516M8 uMRDlLOFckPXlEfGNBWRWXVqRnwFFLUXbWM5rqoeJKIWSozZYoS6ZfHY2HRDGBIANuAH dZQXNPuirJ+aGqb6KOw9CKOUf12bXmj2oSwtdxpadoYy270Z0oOkp1cZB307xSy9I6a/ Ze4oqKHUTQ0BEaHOpBhHr3+utYxTJlZmokioH/Rf+Xv7hWzMwavJcZAwPgUL/cf6Lbvv Qw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bhry222mf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 04:07:26 +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 v6735b0G029019; Thu, 6 Jul 2017 23:07:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72uem38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Jul 2017 23:07:24 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 6 Jul 2017 23:07:23 -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; Thu, 6 Jul 2017 23:07:24 -0400 From: "Lubashev, Igor" To: "jri@google.com" , "subodh@fb.com" CC: "quic@ietf.org" , "kazuhooku@gmail.com" , "martin.thomson@gmail.com" , "ianswett@google.com" , "dtikhonov@litespeedtech.com" , "mikkelfj@gmail.com" , "thomas.swindells@nokia.com" , "jokulik@google.com" , "Michael.Bishop@microsoft.com" Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qFJcNmOfPnkGlJjRXQ/9soKI0ttCAgATMZACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSAD//8GgUIAAXnCAgAm2IgCAAS8I8IAAXHQAgAFYMoD//9Lj2Q== Date: Fri, 7 Jul 2017 03:07:23 +0000 Message-ID: <070fb70b3674407b817da845f8ed524c@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@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-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_070fb70b3674407b817da845f8ed524cusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_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-1703280000 definitions=main-1707070046 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_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-1703280000 definitions=main-1707070047 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, 07 Jul 2017 03:07:37 -0000 --_000_070fb70b3674407b817da845f8ed524cusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > I'm not sure I understand what sort of proxy would want to know about str= eam closures... Any proxy that keeps per-stream state would want to know about stream closu= res (just like the endpoint transport implementation would). Say you have a fast and reliable network to which devices with very limited= amount of memory are attached (sensors on a Mars station connected to the = station network). But this network is connected to the Internet via a slow = and unreliable link (satellite?). To communicate with far-away endpoints ov= er slow and unreliable links, you need a lot of memory, or your throughput = suffers. The solution could be a proxy on the border of this network. Such = proxy would mediate QUIC connections between the limited-memory devices and= Internet endpoints. The proxy would ACK all packets itself, while maintain= ing big enough buffers to retransmit stream data sent to the Internet and r= eassemble streams from the Internet. (One can think of similar situations c= loser to Earth, of course.) -----Original Message----- From: Jana Iyengar [jri@google.com] Received: Thursday, 06 Jul 2017, 9:48PM To: Subodh Iyengar [subodh@fb.com] CC: Lubashev, Igor [ilubashe@akamai.com]; Kazuho Oku [kazuhooku@gmail.com];= Ian Swett [ianswett@google.com]; Mike Bishop [Michael.Bishop@microsoft.com= ]; Dmitri Tikhonov [dtikhonov@litespeedtech.com]; Swindells, Thomas (Nokia = - GB/Cambridge, UK) [thomas.swindells@nokia.com]; Jo Kulik [jokulik@google.= com]; Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; QUIC WG [quic@ietf.= org]; Martin Thomson [martin.thomson@gmail.com] Subject: Re: Unidirectional streams PR On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar > wrote: > Without such a signal, a generic proxy that is not aware of your applicat= ion internals is not able to know when to send the FIN I see, this use case does make somewhat sense, however I'm curious if someo= ne has a concrete use case for a generic QUIC proxy which is not aware of t= he application protocol at all. In TCP this was more common for middleboxes= to do because there was no end to end encryption of the transport, however= QUIC is encrypted. Even with cases when we tunneling protocols at our end,= we usually have some knowledge of the app that we are running because we n= eed to route them differently to different backends. I was mostly thinking = that proxies would at least have some knowledge about HTTP/2 or app protoco= ls. This is my thinking too. I'm not sure I understand what sort of proxy would= want to know about stream closures... but if such a proxy exists, it justi= fies the explicit signal. Maybe it is possible to make #656 more palatable, at least to me. I had 2 t= hings against it initially, which were: 1. We might need to add another state to the machine to the sender state= , i.e. normally when sending a FIN, it is ok to keep receiving stream frame= s after, however in a uni directional stream it is illegal to get a stream = frame. 2. In its current form it also has an implicit requirement to not open l= ower streams. I think opening lower streams have some desirable properties = which I've commented on in https://github.com/quicwg/base-drafts/issues/662= . An implementation could probably implement 1. with not too much trouble by = doing a special case in the stream state machine when it receives a stream = frame in the half closed local state. I think this is covered by the current half-closed state. When an outgoing = uni stream is created, it should have a final received offset of 0. If any = STREAM frames are received that have data at an offset > the final received= offset (which is 0 in this case), then the connection is torn down with QU= IC_STREAM_DATA_AFTER_TERMINATION error (see Section 11.3). For 2. thinking about it a bit more I think the underlying question here is= who enforces directionality, i.e. did I receive data I should not have. If= it is the transport, then we need to answer that question with issue #662,= however if it can be the application or a higher layer API between the app= lication and transport that enforces directionality then we don't need to k= now whether a lower stream is bi-directional or not. I'm leaning towards an= API between the transport and application enforcing directionality. The re= ason for that is that an application that needs to use unidirectionality ne= eds to use a different API anyway. Given that we could leave lower streams = to be opened as it is now, but leaving the exact semantics of enforcing bi-= directionality or uni-directionality to a higher layer. That should suffice= for even a generic proxy right? I thought about this, and I'm leaning towards having the transport enforce = this. I like your suggestion of moving this logic up to the application. Implicit= open is then just "open", and then the stream moves into half-closed state= as it receives an application signal or a STREAM frame with the bit set. T= he tradeoff to consider here is that an implementation will not be able to = instantiate an "optimized" uni stream on implicit creation (or will have to= swap a bidirectional stream with a uni one). There's value in allowing imp= lementations to implement optimized uni/bi stream objects, which would mean= that the transport ought to be able to create one of these two types of ob= jects, therefore allowing (requiring?) enforcement of directionality in the= transport. Can you resolve #662 with a separate state? Meaning that implicitly open st= reams are now considered "reserved" (or some such). This allows you to have= a separate state until you know for sure which type of stream you're const= ructing, which can happen via an application signal or from a received STRE= AM frame. I still prefer do nothing with app directed close though. Having an explicit bit in the frame does allow for some more flexibility, w= hich may be useful. > But I do not think that we should require every application protocol buil= t above QUIC to do its own framing. Second Kazuho on this one. +1. This is the biggest argument for bidirectionality -- most applications = need that, and expecting them to all create their own correlators and state= machine to manage bidirectionality goes against what I'd consider useful t= ransport API design. Extremely common design patterns, such as bidirectiona= lity, should be part of the transport. - jana Subodh ________________________________ From: QUIC > on behalf = of Lubashev, Igor > Sent: Wednesday, July 5, 2017 8:50:05 PM To: Kazuho Oku; Ian Swett Cc: Mike Bishop; Dmitri Tikhonov; Swindells, Thomas (Nokia - GB/Cambridge, = UK); Jo Kulik; Mikkel Fahn=F8e J=F8rgensen; QUIC WG; Martin Thomson Subject: RE: Unidirectional streams PR > If a client needs a way to reset the server's response before observing t= he first frame, it cannot use FIN as an indicator of the end of the request= . There is a DISINTEREST frame proposal (PR #171: https://github.com/quicwg/b= ase-drafts/pull/171). That's something that I believe is valuable independent of this Uni= directional streams PR. - Igor -----Original Message----- From: Kazuho Oku [mailto:kazuhooku@gmail.com] Sent: Wednesday, July 05, 2017 1:41 AM To: Ian Swett > Cc: Lubashev, Igor >; Mike = Bishop >;= Dmitri Tikhonov >; Swindells, Thomas (Nokia - GB/Cambridge, UK) >; Jo Kulik >; Mikkel Fahn=F8e J=F8rgensen >; QUIC WG >;= Martin Thomson > Subject: Re: Unidirectional streams PR 2017-06-29 10:23 GMT+09:00 Ian Swett >: > I updated my PR(#656) today, sorry for the delay. I attempted to > address the issues identified with text. Some may prefer more tweaks > to the state diagram, which are also possible, so I'm open to suggestions= . After all, I think that the approach proposed here is the most well-balance= d one. As much as I think that having first-class support for unidirectional strea= ms is preferable, I also think that we should keep the overall architecture= (i.e. sum of the complexity in the transport layer and the application lay= er) as simple as possible. IMO having support for bidirectional streams (along with support for unidir= ectional streams) aligns with such intention. Most of the application protocols that will be deployed over the QUIC trans= port will be in request-response style, at least to some extent. Hence it is preferable for the transport layer to provide a framework that = fits such style. Bidirectional streams provide the necessary features. FIN provides a way to= indicate the end of the message. RST provides a way to cancel the exchange= of the message in both directions. IMO the biggest issue with the unidirectional-only approach is that you can= not have the two features together. If a client needs a way to reset the se= rver's response before observing the first frame, it cannot use FIN as an i= ndicator of the end of the request. It is true that the issue can be evaded by doing one's own framing in the a= pplication layer. #643 does that by introducing a CANCEL_REQUEST frame. But I do not think that we should require every application protocol built = above QUIC to do its own framing. In addition to that, need to keep two uni= -directional streams open would consume more resources than being able to c= lose one direction of a bi-directional stream at an earlier moment. > In the meantime, I've been considering other alternatives, including > variations on Mike's direction and a variation of the "Do Nothing" > option which involved the application signaling to the transport that > streams of a certain sort(ie: server to client for server push) were > unidirectional, as GQUIC does today. Overall, I think the approach > I've outlined does a good job of iterating on existing deployment > experience and adding explicit signaling for unidirectional streams > instead of implicit signaling at the application layer. There are > pros and cons to both explicit and implicit signaling, but I think > explicit signaling is more complete and less prone to application error. > > Thanks, Ian > > > On Wed, Jun 28, 2017 at 8:14 PM, Lubashev, Igor > wrote: >> >> > unless what the transport provides is a perfect fit for application >> > semantics, you end up building those semantics into the application an= yway. >> >> I agree with this. We should avoid adding complexity into transport >> for rare use cases, since it goes against KISS principle. >> >> On the other hand, adding support for a by far the most common use >> case makes a lot of sense. This helps apps avoid screwing up >> implementing that common case and lets us optimize that common case >> in the lower layer. BiDi streams are such common cases. Uni streams >> are likely to be the second-most-common cases (hence you offered this PR= to optimize them). >> >> >> The Associated Streams proposal offers extra semantic flexibility at >> a cost of some semantic complexity (someone would need to verify that >> the associated stream numbers make sense -- api? apps?) and a few extra = bytes. >> >> I'd like to wait to see Ian's revised proposal. The initial proposal >> offered to do only one thing -- offer a choice of uni/bi-directional >> streams >> -- but it did it in a very simple way, which is nice. >> >> - Igor >> >> >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Wednesday, June 28, 2017 7:28 PM >> To: Mike Bishop > >> Cc: Swindells, Thomas (Nokia - GB/Cambridge, UK) >> >; QUIC WG= >; Mikkel Fahn=F8e >> J=F8rgensen >; Dmitri Tikh= onov >> >; Jo Ku= lik > >> Subject: Re: Unidirectional streams PR >> >> There is probably a simpler approach here, take a bit (as Ian did) >> and say that if that bit is set, then the stream is in response to >> another and the stream ID of the stream to which this is responding >> follows immediately after the stream ID of the stream itself. You >> could then include that only at the start of the stream, or in multiple = frames (or as we decide). >> >> The problem with this, as with several of the other issues we're >> discussing, is that unless what the transport provides is a perfect >> fit for application semantics, you end up building those semantics >> into the application anyway. HTTP certainly can't survive without >> its own association semantics for pushes. That suggests to me that >> having bidirectional semantics in the transport creates more >> duplication than otherwise. Hence my proposal. >> >> On 28 June 2017 at 15:26, Mike Bishop > >> wrote: >> > As promised, a PR for adding =93associated streams=94 is at >> > https://github.com/quicwg/base-drafts/pull/672. This very >> > deliberately builds on top of MT=92s PR =96 it=92s adding a primitive >> > which can be used to construct various abstractions atop >> > unidirectional streams, but the lifecycle is still fundamentally unidi= rectional. >> > >> > >> > >> > Copying my notes here for list discussion purposes. >> > >> > Major changes >> > >> > Leveraging @igorlord's insight that OO=3D00 only occurs on the first >> > STREAM frame of a stream, I used that as the trigger for a Stream >> > Properties byte. >> > Two bits of that byte describe the directionality of the stream: >> > >> > Unidirectional (no response expected) Initial bidirectional (one >> > response expected) Initial multi-response (one or more responses >> > expected; needs a better name) Response >> > >> > If the type is Response, there's an Associated Stream ID field, >> > length given by two more bits following the same pattern as the SS >> > bits in the STREAM frame ID. >> > >> > Personal Opinion >> > >> > On the plus side, these stream types seem to cover the abstractions >> > I can envision for most applications. You can unilaterally send >> > something (unidirectional), do request/response (bidirectional), or >> > pub/sub (single subscription stream, series of update streams). >> > >> > I don't care for the fact that I still need the stream type header >> > in HTTP after putting this in the transport. That will be >> > ameliorated if we go back to one stream per request, since all >> > unidirectional streams will be push streams. (As a side-note, I >> > considered using the multiple-response option in the HTTP mapping, >> > but then I need a stream header again to indicate which is the >> > response and which the pushes.) >> > >> > I particularly don't like that you now have to look at the frame >> > type header to find out whether a field exists which tells you the >> > length of something else in the header. I'd like to simplify that. >> > I went with this model over a CREATE_STREAM frame because of >> > @mikkelfj's use-case of very small messages >> > -- this adds only one byte to the first frame on a stream in one >> > direction and 2-5 bytes to the first frame of response streams. A >> > separate frame type would be somewhat larger, but could be cleaner >> > in that respect. >> > >> > >> > >> > >> > >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Swindells, >> > Thomas (Nokia - GB/Cambridge, UK) >> > Sent: Wednesday, June 28, 2017 7:56 AM >> > To: Jo Kulik >; Mikkel F= ahn=F8e J=F8rgensen >> > > >> > Cc: QUIC WG >; Dmitri Tikhonov >> > > >> > Subject: RE: Unidirectional streams PR >> > >> > >> > >> > I agree that looking at the layers of abstraction is useful. In >> > principle having the wire protocol just have constructs for >> > unidirectional streams does not in itself limit creating >> > bi-directional communication flows, supported at either the library >> > or application layer. >> > >> > >> > >> > However, there need to be a standard way of doing bi-directional >> > communication for migrating applications implemented using a socket >> > style api. It needs to be easy to move an existing application from >> > TCP to QUIC. >> > This move may be attractive in many situations as QUIC gives >> > improved security and may allow greater throughput due to the more >> > modern (and >> > customizable) congestion control algorithms compared to the OS TCP >> > stack. >> > >> > >> > >> > For migrating standard socket api applications I don=92t think it >> > would be appropriate to leave the work to the application to do >> > correlation, at least the library should be providing this service >> > using the wire protocol as appropriate. Clearly we want a client >> > written with one library to be able to communicate successfully >> > with a server written using a different library. >> > This needs some form of standardization of the signalling. This >> > could either be a building block overlay on top of QUIC, or >> > implemented at the wire protocol level. >> > >> > >> > >> > In terms of patterns I think the following may be some of the most >> > common patterns (with potential to be provided at the library and >> > or wire protocol level). >> > >> > I/O pattern : Example >> > >> > 1/0 : An input only flow, perhaps a data logger like syslog with no >> > confirmation/feedback >> > >> > 0/1 : an output only flow, perhaps a topic message bus service >> > with no confirmation/feedback >> > >> > 1/1 : standard TCP applications with a single flow per connection >> > >> > 1/* : single input, many output, modelling STDIN/STDOUT+STDERR >> > >> > (1/1)* : multiplexed pairs of flows =96 supporting multiple sockets >> > muxed onto a single QUIC connection >> > >> > >> > >> > Obviously, an application would always have the option to combine >> > any single direction flows with application level correlators to >> > construct more complex flows if desired. >> > >> > >> > >> > At the moment my gut says the 1/1 use-case is common enough that >> > the wire protocol should provide a standard mechanism to support it >> > as a standard overlay would probably end up being treated as part >> > of the wire format anyway. >> > >> > >> > >> > Perhaps streams should be explicitly created with a CREATE_STREAM >> > frame which would be capable of defining multiple related streams? >> > >> > There is the option of whether only (1/1) pairs can be created this >> > way, or >> > (1/n) combinations could be supported (with an application defined >> > way to identify the use of each of the output streams). A step >> > further may be that there is a transport parameter that defines >> > whether the server is allowed to create additional streams, or if >> > stream creation is purely client driven (like TCP). I don=92t know if >> > either of these would simplify how to handle stream accounting, and >> > in particular only creating a flow when all parties have sufficient al= lowances left. >> > >> > >> > >> > Thomas >> > >> > >> > >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jo Kulik >> > Sent: 28 June 2017 15:09 >> > To: Mikkel Fahn=F8e J=F8rgensen > >> > Cc: QUIC WG >; Dmitri Tikhonov >> > > >> > Subject: Re: Unidirectional streams PR >> > >> > >> > >> > I'd like to pop back up to a comment Igor made last week, because I >> > find it helpful in thinking about the design space: >> > >> > >> > >> > I think of three layers of abstraction: >> > >> > 1. QUIC Wire Protocol (the thing described by the QUIC Transport >> > RFC) >> > 2. QUIC Library API (a library exposing some useful abstractions >> > -- >> > such as blocking/non-blocking unidirectional streams and >> > bidirectional =93sockets=94 -- and implementing them using QUIC Wire P= rotocol) >> > 3. Application (something that uses QUIC Library APIs) >> > >> > I think there is some argument to be made that Martin's original >> > proposal did not take into account how we would achieve (2) for >> > bi-directional streams. (I don't think it strictly said "thou >> > shalt not do (2)" either, but that is up to interpretation.) >> > >> > >> > >> > Several people have argued that we do not want every application to >> > have to re-implement bi-directional streams (3) for every >> > application, and this is not how g-quic (our largest deployment) works= right now. >> > These arguments make sense to me, but YMMV. >> > >> > >> > >> > Just because the particular *mechanism* that is being proposed has >> > some issues, however, doesn't scream out to me, at least, that we >> > should abandon this particular *design goal*. The goal being a >> > transport protocol that can elegantly fit with a uni/bi stream model. >> > Now, if we conclude that there can never be an elegant model that >> > achieves this goal, then so be it. But I also feel like we haven't >> > reached that point in the discussion yet. (At the very least, this >> > discussion has been fruitful to me in terms of mapping the design >> > space and elucidating requirements). >> > >> > >> > >> > One of the reasons I still think this design goal is under >> > consideration is that Ian and Igor/Mike have been talking about >> > alternate solutions which have a similar flavor. During the recent >> > "quiet"ness on the thread, personally, I've been waiting to hear >> > more from them. >> > >> > >> > >> > On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahn=F8e J=F8rgensen >> > > wrote: >> > >> > In reply to Ranjeeth >> > >> > >> > >> > It is not only a matter of simplicity for the sake of simplicity: >> > >> > >> > >> > - A complex transport layer might end up being poorly implemented >> > leading to reduced interoperability and ultimately adoption. This >> > complexity is not only in implementation but also in understanding >> > the exact semantics of stream lifetime. Even if the spec is >> > sufficiently clear, it will still be open to misinterpretations. >> > >> > >> > >> > - Bi-directional state may have to be maintained longer and with >> > more overhead than with uni-directional streams, especially under >> > loss, potentially leading to poor performance and poor resource >> > utilisation because the transport layer has insufficient information. >> > >> > >> > >> > - The extra complexity at the application layer may be overstated - >> > it is significantly simpler to manage a map that associates to two >> > streams than it is to maintain bi-directional state at the >> > transport layer. It is even possible to implicitly link streams >> > with same identifiers, e.g. in a RPC scenario. That said, I do see >> > a potential benefit of a wrapper that implements the common bi-directi= onal case. >> > >> > >> > >> > - Complexity at the application layer may be duplicated, but >> > implementation errors are also isolated to that application. >> > Specifically for HTTP I would assume that QUIC transport and QUIC >> > HTTP implementers would be large the same for a long time to come, >> > so I would not expect the tradeoff here to be particularly concerning. >> > >> > >> > >> > - Unix pipes are traditionally constructed as a pair of >> > uni-directional file descriptors and that is a reasonably proven >> > model. C=92s standard library stdin, stdout and stderr is an example >> > of an asymmetric model with implicit linkage between >> > uni-directional file descriptors. >> > >> > >> > >> > - There are lots of use cases for non-HTTP like connectivity - >> > Kafka high volume message queuing for example. The industry trend >> > appears to move towards asynchronous processing and messaging. It >> > depends on whether you look at QUIC as a TCP + TLS replacement, or >> > as a HTTPS / REST RPC replacement. >> > >> > >> > >> > - Uni-directional streams may currently be unproven in the wild, >> > but a proposal is needed before an implementation can be made and >> > testet. I agree that it is easy to design into wrong assumptions >> > without real world testing. >> > >> > >> > >> > - There will hopefully not be a large number of successors to QUIC >> > - perhaps some purpose specific variants, e.g. for embedded use. >> > Widespread adaptation and compatibility is very necessary so it >> > makes sense to have QUIC being sufficiently simple and expressive >> > to achieve this goal. A polymorf QUIC will not achieve that goal. >> > On the other hand, a solid QUIC foundation can be used for a large >> > number of application protocols. >> > >> > >> > >> > - Finally, it may turn out that uni-directional streams just is a >> > bad idea - I doubt it, but I do believe real world tests are needed. >> > >> > >> > >> > Kind Regards, >> > >> > Mikkel Fahn=F8e J=F8rgensen >> > >> > >> > >> > On 28 June 2017 at 14.42.36, Dmitri Tikhonov >> > (dtikhonov@litespeedtech.com) >> > wrote: >> > >> > On Tue, Jun 27, 2017 at 02:31:38PM -0700, Ranjeeth Kumar Dasineni wrot= e: >> >> 2. We are overplaying the simplicity of design. Even if we deem >> >> deployment experience not a concern, if every application layer >> >> protocol that needs support for bidirectional streams has to >> >> implement some correlators and such above, that's a net negative >> >> in terms of complexity. >> > >> > This is an important point: we want QUIC adoption to be made easy. >> > A program that speaks HTTP today should be able to use an existing >> > QUIC library without having to emulate bidirectional streams in >> > order to fit it into HTTP usage pattern. Forcing every one of these >> > programs to do this is certainly a hurdle. >> > >> > - Dmitri. >> > >> > >> > -- Kazuho Oku --_000_070fb70b3674407b817da845f8ed524cusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > I'm not sure I understand what sort of proxy would wa= nt to know about stream closures...

Any proxy that keeps per-stream state would want to know about stream closu= res (just like the endpoint transport implementation would).

Say you have a fast and reliable network to which devices with very limited= amount of memory are attached (sensors on a Mars station connected to the = station network). But this network is connected to the Internet via a slow = and unreliable link (satellite?). To communicate with far-away endpoints over slow and unreliable links, you= need a lot of memory, or your throughput suffers. The solution could be a = proxy on the border of this network. Such proxy would mediate QUIC connecti= ons between the limited-memory devices and Internet endpoints. The proxy would ACK all packets itself, while main= taining big enough buffers to retransmit stream data sent to the Internet a= nd reassemble streams from the Internet. (One can think of similar situatio= ns closer to Earth, of course.)

-----Original Message-----
From: Jana Iyengar [jri@google.com]
Received: Thursday, 06 Jul 2017, 9:48PM
To: Subodh Iyengar [subodh@fb.com]
CC: Lubashev, Igor [ilubashe@akamai.com]; Kazuho Oku [kazuhooku@gmai= l.com]; Ian Swett [ianswett@google.com]; Mike Bishop [Michael.Bishop@micros= oft.com]; Dmitri Tikhonov [dtikhonov@litespeedtech.com]; Swindells, Thomas = (Nokia - GB/Cambridge, UK) [thomas.swindells@nokia.com]; Jo Kulik [jokulik@google.com]; Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail= .com]; QUIC WG [quic@ietf.org]; Martin Thomson [martin.thomson@gmail.com] Subject: Re: Unidirectional streams PR

On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar = <subodh@fb.com>= ; wrote:

> Without such a signal, a gene= ric proxy that is not aware of your application internals is not able to kn= ow when to send the FIN

I see, this use case does make somewhat= sense, however I'm curious if someone has a concrete use ca= se for a generic QUIC proxy which is not aware of the application protocol at all. In TCP this was more common for middleboxes t= o do because there was no end to end encryption of the transport, however Q= UIC is encrypted. Even with cases when we tunneling protocols at our e= nd, we usually have some knowledge of the app that we are running because we need to route them differently to d= ifferent backends. I was mostly thinking that proxies would at le= ast have some knowledge about HTTP/2 or app protocols.

This is my thinking too. I'm not sure I understand what sort of proxy = would want to know about stream closures... but if such a proxy exists, it = justifies the explicit signal.

Maybe it is possible to make #656 = more palatable, at least to me. I had 2 things against it initially, which = were:

We might need to add another state to the machine to the sender state, = i.e. normally when sending a FIN, it is ok to keep receiving stream frames = after, however in a uni directional stream it is illegal to get a stream fr= ame.
In its current form it also has an implicit requirement to not= open lower streams. I think opening lower streams have some desirable prop= erties which I've commented on in https://github.com/quicwg/base-drafts/issue= s/662.

An implementation could probably implement 1. with not too much troubl= e by doing a special case in the stream state machine when it receives a st= ream frame in the half closed local state.

I think this is covered by the current half-closed state. When an outg= oing uni stream is created, it should have a final received offset of 0. If= any STREAM frames are received that have data at an offset > the final = received offset (which is 0 in this case), then the connection is torn down with QUIC_STREAM_DATA_AFTER_TERMIN= ATION error (see Section 11.3).

For 2. thinking about it a bit more I think the underlying question he= re is who enforces directionality, i.e. did I receive data I should no= t have. If it is the transport, then we need to answer that question with i= ssue #662, however if it can be the application or a higher layer API between the application and transport that enforces = directionality then we don't need to know whether a lower stream is bi-dire= ctional or not. I'm leaning towards an API between the transport and applic= ation enforcing directionality. The reason for that is that an application that needs to use unidirectiona= lity needs to use a different API anyway. Given that we could lea= ve lower streams to be opened as it is now, but leaving the exact semantics= of enforcing bi-directionality or uni-directionality to a higher layer. That should suffice for even a generic proxy right?&nbs= p;

I thought about this, and I'm leaning towards having the transport enforce = this.

I like your suggestion of moving this logic up to the application. Imp= licit open is then just "open", and then the stream moves into ha= lf-closed state as it receives an application signal or a STREAM frame with= the bit set. The tradeoff to consider here is that an implementation will not be able to instantiate an "optimiz= ed" uni stream on implicit creation (or will have to swap a bidirectio= nal stream with a uni one). There's value in allowing implementations to im= plement optimized uni/bi stream objects, which would mean that the transport ought to be able to create one of these two = types of objects, therefore allowing (requiring?) enforcement of directiona= lity in the transport.

Can you resolve #662 with a separate state? Meaning that implicitly op= en streams are now considered "reserved" (or some such). This all= ows you to have a separate state until you know for sure which type of stre= am you're constructing, which can happen via an application signal or from a received STREAM frame.

I still prefer do nothing with app directed close though.

Having an explicit bit in the frame does allow for some more flexibili= ty, which may be useful.

> But I do not think that we should require every application protocol built abo= ve QUIC to do its own framing.

Second Kazuho on this one.

+1. This is the biggest argument for bidirectionality -- most appl= ications need that, and expecting them to all create their own correlators = and state machine to manage bidirectionality goes against what I'd consider= useful transport API design. Extremely common design patterns, such as bidirectionality, should be part of the tr= ansport.

- jana

Subodh

F= rom: QUIC <quic-bounces@ietf.org> on behalf of Lubashev, Igor <ilubashe= @akamai.com>
Sent: Wednesday, July 5, 2017 8:50:05 PM
To: Kazuho Oku; Ian Swett
Cc: Mike Bishop; Dmitri Tikhonov; Swindells, Thomas (Nokia - GB/Camb= ridge, UK); Jo Kulik; Mikkel Fahn=F8e J=F8rgensen; QUIC WG; Martin Thomson

Subject: RE: Unidirectional streams PR

> If a client needs= a way to reset the server's response before observing the first frame, it = cannot use FIN as an indicator of the end of the request.

There is a DISINTEREST frame proposal (PR #171: https://github.com/quicwg/base-drafts/pull/171). That's some= thing that I believe is valuable independent of this Unidirectional streams= PR.

- Igor

-----Original Message-----
From: Kazuho Oku [= mailto:kazuhooku@gmail.com]
Sent: Wednesday, July 05, 2017 1:41 AM
To: Ian Swett <= ianswett@google.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Mike Bishop <Michael.Bishop@microsoft.com&g= t;; Dmitri Tikhonov <dtikhonov@litespeedtech.com>; Swindells, Thomas (Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.com>; = Jo Kulik <jokuli= k@google.com>; Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.o= rg>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Unidirectional streams PR

2017-06-29 10:23 GMT+09:00 Ian Swett <ianswett@google.com>:
> I updated my PR(#656) today, sorry for the delay. I attempted to=
> address the issues identified with text. Some may prefer more tw= eaks
> to the state diagram, which are also possible, so I'm open to suggesti= ons.

After all, I think that the approach proposed here is the most well-balance= d one.

As much as I think that having first-class support for unidirectional strea= ms is preferable, I also think that we should keep the overall architecture= (i.e. sum of the complexity in the transport layer and the application lay= er) as simple as possible.

IMO having support for bidirectional streams (along with support for unidir= ectional streams) aligns with such intention.

Most of the application protocols that will be deployed over the QUIC trans= port will be in request-response style, at least to some extent.
Hence it is preferable for the transport layer to provide a framework that = fits such style.

Bidirectional streams provide the necessary features. FIN provides a way to= indicate the end of the message. RST provides a way to cancel the exchange= of the message in both directions.

IMO the biggest issue with the unidirectional-only approach is that you can= not have the two features together. If a client needs a way to reset the se= rver's response before observing the first frame, it cannot use FIN as an i= ndicator of the end of the request.

It is true that the issue can be evaded by doing one's own framing in the a= pplication layer. #643 does that by introducing a CANCEL_REQUEST frame.

But I do not think that we should require every application protocol built = above QUIC to do its own framing. In addition to that, need to keep two uni= -directional streams open would consume more resources than being able to c= lose one direction of a bi-directional stream at an earlier moment.

> In the meantime, I've been considering other alternatives, including <= br> > variations on Mike's direction and a variation of the "Do Nothing= "
> option which involved the application signaling to the transport that =
> streams of a certain sort(ie: server to client for server push) were <= br> > unidirectional, as GQUIC does today. Overall, I think the approa= ch
> I've outlined does a good job of iterating on existing deployment
> experience and adding explicit signaling for unidirectional streams > instead of implicit signaling at the application layer. There ar= e
> pros and cons to both explicit and implicit signaling, but I think > explicit signaling is more complete and less prone to application erro= r.
>
> Thanks, Ian
>
>
> On Wed, Jun 28, 2017 at 8:14 PM, Lubashev, Igor <ilubashe@akamai.com> wrote: >>
>> > unless what the transport provides is a perfect fit for appli= cation
>> > semantics, you end up building those semantics into the appli= cation anyway.
>>
>> I agree with this. We should avoid adding complexity into transpor= t
>> for rare use cases, since it goes against KISS principle.
>>
>> On the other hand, adding support for a by far the most common use=
>> case makes a lot of sense. This helps apps avoid screwing up=
>> implementing that common case and lets us optimize that common cas= e
>> in the lower layer. BiDi streams are such common cases. Uni stream= s
>> are likely to be the second-most-common cases (hence you offered t= his PR to optimize them).
>>
>>
>> The Associated Streams proposal offers extra semantic flexibility = at
>> a cost of some semantic complexity (someone would need to verify t= hat
>> the associated stream numbers make sense -- api? apps?) and a few = extra bytes.
>>
>> I'd like to wait to see Ian's revised proposal. The initial = proposal
>> offered to do only one thing -- offer a choice of uni/bi-direction= al
>> streams
>> -- but it did it in a very simple way, which is nice.
>>
>> - Igor
>>
>>
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: Wednesday, June 28, 2017 7:28 PM
>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>> Cc: Swindells, Thomas (Nokia - GB/Cambridge, UK)
>> <thomas.swindells@nokia.com>; QUIC WG <quic@ietf.org>; Mikkel Fahn=F8e
>> J=F8rgensen <mikkelfj@gmail.com>; Dmitri Tikhonov
>> <dtikhonov@litespeedtech.com>; Jo Kulik <jokulik@google.com>
>> Subject: Re: Unidirectional streams PR
>>
>> There is probably a simpler approach here, take a bit (as Ian did)=
>> and say that if that bit is set, then the stream is in response to=
>> another and the stream ID of the stream to which this is respondin= g
>> follows immediately after the stream ID of the stream itself. = ; You
>> could then include that only at the start of the stream, or in mul= tiple frames (or as we decide).
>>
>> The problem with this, as with several of the other issues we're <= br> >> discussing, is that unless what the transport provides is a perfec= t
>> fit for application semantics, you end up building those semantics=
>> into the application anyway. HTTP certainly can't survive wi= thout
>> its own association semantics for pushes. That suggests to m= e that
>> having bidirectional semantics in the transport creates more
>> duplication than otherwise. Hence my proposal.
>>
>> On 28 June 2017 at 15:26, Mike Bishop <Michael.Bishop@microsoft.com&= gt;
>> wrote:
>> > As promised, a PR for adding =93associated streams=94 is at <= br> >> > https://github.com/quicwg/base-drafts/pull/672. This very >> > deliberately builds on top of MT=92s PR =96 it=92s adding a p= rimitive
>> > which can be used to construct various abstractions atop
>> > unidirectional streams, but the lifecycle is still fundamenta= lly unidirectional.
>> >
>> >
>> >
>> > Copying my notes here for list discussion purposes.
>> >
>> > Major changes
>> >
>> > Leveraging @igorlord's insight that OO=3D00 only occurs on th= e first
>> > STREAM frame of a stream, I used that as the trigger for a St= ream
>> > Properties byte.
>> > Two bits of that byte describe the directionality of the stre= am:
>> >
>> > Unidirectional (no response expected) Initial bidirectional (= one
>> > response expected) Initial multi-response (one or more respon= ses
>> > expected; needs a better name) Response
>> >
>> > If the type is Response, there's an Associated Stream ID fiel= d,
>> > length given by two more bits following the same pattern as t= he SS
>> > bits in the STREAM frame ID.
>> >
>> > Personal Opinion
>> >
>> > On the plus side, these stream types seem to cover the abstra= ctions
>> > I can envision for most applications. You can unilaterally se= nd
>> > something (unidirectional), do request/response (bidirectiona= l), or
>> > pub/sub (single subscription stream, series of update streams= ).
>> >
>> > I don't care for the fact that I still need the stream type h= eader
>> > in HTTP after putting this in the transport. That will be >> > ameliorated if we go back to one stream per request, since al= l
>> > unidirectional streams will be push streams. (As a side-note,= I
>> > considered using the multiple-response option in the HTTP map= ping,
>> > but then I need a stream header again to indicate which is th= e
>> > response and which the pushes.)
>> >
>> > I particularly don't like that you now have to look at the fr= ame
>> > type header to find out whether a field exists which tells yo= u the
>> > length of something else in the header. I'd like to simplify = that.
>> > I went with this model over a CREATE_STREAM frame because of =
>> > @mikkelfj's use-case of very small messages
>> > -- this adds only one byte to the first frame on a stream in = one
>> > direction and 2-5 bytes to the first frame of response stream= s. A
>> > separate frame type would be somewhat larger, but could be cl= eaner
>> > in that respect.
>> >
>> >
>> >
>> >
>> >
>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Swindells,
>> > Thomas (Nokia - GB/Cambridge, UK)
>> > Sent: Wednesday, June 28, 2017 7:56 AM
>> > To: Jo Kulik <jokulik@google.com>; Mikkel Fahn=F8e J=F8rgensen
>> > <m= ikkelfj@gmail.com>
>> > Cc: QUIC WG <quic@ietf.org>; Dmitri Tikhonov
>> > <dtikhonov@litespeedtech.com>
>> > Subject: RE: Unidirectional streams PR
>> >
>> >
>> >
>> > I agree that looking at the layers of abstraction is useful. = In
>> > principle having the wire protocol just have constructs for <= br> >> > unidirectional streams does not in itself limit creating
>> > bi-directional communication flows, supported at either the l= ibrary
>> > or application layer.
>> >
>> >
>> >
>> > However, there need to be a standard way of doing bi-directio= nal
>> > communication for migrating applications implemented using a = socket
>> > style api. It needs to be easy to move an existing applicatio= n from
>> > TCP to QUIC.
>> > This move may be attractive in many situations as QUIC gives =
>> > improved security and may allow greater throughput due to the= more
>> > modern (and
>> > customizable) congestion control algorithms compared to the O= S TCP
>> > stack.
>> >
>> >
>> >
>> > For migrating standard socket api applications I don=92t thin= k it
>> > would be appropriate to leave the work to the application to = do
>> > correlation, at least the library should be providing this se= rvice
>> > using the wire protocol as appropriate. Clearly we want a cli= ent
>> > written with one library to be able to communicate successful= ly
>> > with a server written using a different library.
>> > This needs some form of standardization of the signalling. Th= is
>> > could either be a building block overlay on top of QUIC, or <= br> >> > implemented at the wire protocol level.
>> >
>> >
>> >
>> > In terms of patterns I think the following may be some of the= most
>> > common patterns (with potential to be provided at the library= and
>> > or wire protocol level).
>> >
>> > I/O pattern : Example
>> >
>> > 1/0   : An input only flow, perhaps a data logger l= ike syslog with no
>> > confirmation/feedback
>> >
>> > 0/1 : an output only flow, perhaps a topic message bus = service
>> > with no confirmation/feedback
>> >
>> > 1/1 : standard TCP applications with a single flow per connec= tion
>> >
>> > 1/* : single input, many output, modelling STDIN/STDOUT+S= TDERR
>> >
>> > (1/1)* : multiplexed pairs of flows =96 supporting multiple s= ockets
>> > muxed onto a single QUIC connection
>> >
>> >
>> >
>> > Obviously, an application would always have the option to com= bine
>> > any single direction flows with application level correlators= to
>> > construct more complex flows if desired.
>> >
>> >
>> >
>> > At the moment my gut says the 1/1 use-case is common enough t= hat
>> > the wire protocol should provide a standard mechanism to supp= ort it
>> > as a standard overlay would probably end up being treated as = part
>> > of the wire format anyway.
>> >
>> >
>> >
>> > Perhaps streams should be explicitly created with a CREATE_ST= REAM
>> > frame which would be capable of defining multiple related str= eams?
>> >
>> > There is the option of whether only (1/1) pairs can be create= d this
>> > way, or
>> > (1/n) combinations could be supported (with an application de= fined
>> > way to identify the use of each of the output streams). A ste= p
>> > further may be that there is a transport parameter that defin= es
>> > whether the server is allowed to create additional streams, o= r if
>> > stream creation is purely client driven (like TCP). I don=92t= know if
>> > either of these would simplify how to handle stream accountin= g, and
>> > in particular only creating a flow when all parties have suff= icient allowances left.
>> >
>> >
>> >
>> > Thomas
>> >
>> >
>> >
>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jo Kulik
>> > Sent: 28 June 2017 15:09
>> > To: Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.com>
>> > Cc: QUIC WG <quic@ietf.org>; Dmitri Tikhonov
>> > <dtikhonov@litespeedtech.com>
>> > Subject: Re: Unidirectional streams PR
>> >
>> >
>> >
>> > I'd like to pop back up to a comment Igor made last week, bec= ause I
>> > find it helpful in thinking about the design space:
>> >
>> >
>> >
>> > I think of three layers of abstraction:
>> >
>> > 1.       QUIC Wire Protocol (th= e thing described by the QUIC Transport
>> > RFC)
>> > 2.       QUIC Library API (a li= brary exposing some useful abstractions
>> > --
>> > such as blocking/non-blocking unidirectional streams and
>> > bidirectional =93sockets=94 -- and implementing them using QU= IC Wire Protocol)
>> > 3.       Application (something= that uses QUIC Library APIs)
>> >
>> > I think there is some argument to be made that Martin's origi= nal
>> > proposal did not take into account how we would achieve (2) f= or
>> > bi-directional streams. (I don't think it strictly said= "thou
>> > shalt not do (2)" either, but that is up to interpretati= on.)
>> >
>> >
>> >
>> > Several people have argued that we do not want every applicat= ion to
>> > have to re-implement bi-directional streams (3) for every >> > application, and this is not how g-quic (our largest deployme= nt) works right now.
>> > These arguments make sense to me, but YMMV.
>> >
>> >
>> >
>> > Just because the particular *mechanism* that is being propose= d has
>> > some issues, however, doesn't scream out to me, at least, tha= t we
>> > should abandon this particular *design goal*. The goal = being a
>> > transport protocol that can elegantly fit with a uni/bi strea= m model.
>> > Now, if we conclude that there can never be an elegant model = that
>> > achieves this goal, then so be it. But I also feel like= we haven't
>> > reached that point in the discussion yet. (At the very = least, this
>> > discussion has been fruitful to me in terms of mapping the de= sign
>> > space and elucidating requirements).
>> >
>> >
>> >
>> > One of the reasons I still think this design goal is under >> > consideration is that Ian and Igor/Mike have been talking abo= ut
>> > alternate solutions which have a similar flavor. During= the recent
>> > "quiet"ness on the thread, personally, I've been wa= iting to hear
>> > more from them.
>> >
>> >
>> >
>> > On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahn=F8e J=F8rgensen =
>> > <m= ikkelfj@gmail.com> wrote:
>> >
>> > In reply to Ranjeeth
>> >
>> >
>> >
>> > It is not only a matter of simplicity for the sake of simplic= ity:
>> >
>> >
>> >
>> > - A complex transport layer might end up being poorly impleme= nted
>> > leading to reduced interoperability and ultimately adoption. = This
>> > complexity is not only in implementation but also in understa= nding
>> > the exact semantics of stream lifetime. Even if the spec is <= br> >> > sufficiently clear, it will still be open to misinterpretatio= ns.
>> >
>> >
>> >
>> > - Bi-directional state may have to be maintained longer and w= ith
>> > more overhead than with uni-directional streams, especially u= nder
>> > loss, potentially leading to poor performance and poor resour= ce
>> > utilisation because the transport layer has insufficient info= rmation.
>> >
>> >
>> >
>> > - The extra complexity at the application layer may be overst= ated -
>> > it is significantly simpler to manage a map that associates t= o two
>> > streams than it is to maintain bi-directional state at the >> > transport layer. It is even possible to implicitly link strea= ms
>> > with same identifiers, e.g. in a RPC scenario. That said, I d= o see
>> > a potential benefit of a wrapper that implements the common b= i-directional case.
>> >
>> >
>> >
>> > - Complexity at the application layer may be duplicated, but =
>> > implementation errors are also isolated to that application.<= br> >> > Specifically for HTTP I would assume that QUIC transport and = QUIC
>> > HTTP implementers would be large the same for a long time to = come,
>> > so I would not expect the tradeoff here to be particularly co= ncerning.
>> >
>> >
>> >
>> > - Unix pipes are traditionally constructed as a pair of
>> > uni-directional file descriptors and that is a reasonably pro= ven
>> > model. C=92s standard library stdin, stdout and stderr is an = example
>> > of an asymmetric model with implicit linkage between
>> > uni-directional file descriptors.
>> >
>> >
>> >
>> > - There are lots of use cases for non-HTTP like connectivity = -
>> > Kafka high volume message queuing for example. The industry t= rend
>> > appears to move towards asynchronous processing and messaging= . It
>> > depends on whether you look at QUIC as a TCP + TLS replac= ement, or
>> > as a HTTPS / REST RPC replacement.
>> >
>> >
>> >
>> > - Uni-directional streams may currently be unproven in the wi= ld,
>> > but a proposal is needed before an implementation can be made= and
>> > testet. I agree that it is easy to design into wrong assumpti= ons
>> > without real world testing.
>> >
>> >
>> >
>> > - There will hopefully not be a large number of successors to= QUIC
>> > - perhaps some purpose specific variants, e.g. for embedded u= se.
>> > Widespread adaptation and compatibility is very necessary so = it
>> > makes sense to have QUIC being sufficiently simple and expres= sive
>> > to achieve this goal. A polymorf QUIC will not achieve that g= oal.
>> > On the other hand, a solid QUIC foundation can be used for a = large
>> > number of application protocols.
>> >
>> >
>> >
>> > - Finally, it may turn out that uni-directional streams just = is a
>> > bad idea - I doubt it, but I do believe real world tests are = needed.
>> >
>> >
>> >
>> > Kind Regards,
>> >
>> > Mikkel Fahn=F8e J=F8rgensen
>> >
>> >
>> >
>> > On 28 June 2017 at 14.42.36, Dmitri Tikhonov
>> > (dtikhonov@litespeedtech.com)
>> > wrote:
>> >
>> > On Tue, Jun 27, 2017 at 02:31:38PM -0700, Ranjeeth Kumar Dasi= neni wrote:
>> >> 2. We are overplaying the simplicity of design. Even if w= e deem
>> >> deployment experience not a concern, if every application= layer
>> >> protocol that needs support for bidirectional streams has= to
>> >> implement some correlators and such above, that's a net n= egative
>> >> in terms of complexity.
>> >
>> > This is an important point: we want QUIC adoption to be made = easy.
>> > A program that speaks HTTP today should be able to use an exi= sting
>> > QUIC library without having to emulate bidirectional streams = in
>> > order to fit it into HTTP usage pattern. Forcing every one of= these
>> > programs to do this is certainly a hurdle.
>> >
>> > - Dmitri.
>> >
>> >
>>
>

--
Kazuho Oku

--_000_070fb70b3674407b817da845f8ed524cusma1exdag1mb5msgcorpak_-- From nobody Thu Jul 6 20:33: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 D0217129B67 for ; Thu, 6 Jul 2017 20:33:53 -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 pDIc-ouC6cmt for ; Thu, 6 Jul 2017 20:33:52 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 1EF8D12741D for ; Thu, 6 Jul 2017 20:33:52 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m68so20698933ith.1 for ; Thu, 06 Jul 2017 20:33: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=DpCpQOX0Mnrp5rf9gUFAz2saKf0pUjpq0JS+BHEIITY=; b=KUCa9oJIO1cWVPoC3G4SOQ4cLv0XAmw/rPfF3UGFNmxnhCcmvA+Dda712m6K8w+CfA N17xxhaIaely8m6iwRy+P0Ajq5/YNKd7IHFCFoDbtZ1vQtPSw1Cr9wJREvh79qaw6BD1 VX9wS70DGWSj4WghPSksQ6FlyPfnN1yR/Es/B/khyPj/Tk1vOz0WPRvVk4SlMcLyrkfW gUWrRa2cWssOLQgDB0LX214wbF0S1NI0v0l8DehbnTwn1pxFuUrnEwewrN6PmkEu7uYf t4fkOuoDk5SnpTtYrqil2JTAv0qeB982fKuBlX2Q8un1urMU5Z0JvHtm0NQEFwdfzJHT nrCQ== 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=DpCpQOX0Mnrp5rf9gUFAz2saKf0pUjpq0JS+BHEIITY=; b=e/yJDUmQnoJngCZAEnLM2TDfaS7BblbH7EiOXsooK78/HL+Pd7qclFsQ2nGtpMD3mH BVSZInXBGCU8I5M9xGKtU0Twtdl9rs4r3r4/EVlBV1Pq9Gi+VLNqrO+qBEtobV9U9JJ5 c/KzdRijmFoUBXieY+PmojD3UcpnMJ3nE789+fzX/mSIMamdMtKnrNeS/LM24N9JFAT+ BtKYXr24Wluvfk94rD0aG46loZM5ee2/TZlCu95TDpB6q4hggLZFaOnQ2qGsHuCJbS+p 0kuImv+gOjJfv+4TzSjJK8vRq2liUuVMW1sY5cY43J+RDzTkIV1avJnBdEJ7JbGhjPDf VsQQ== X-Gm-Message-State: AKS2vOwKByWQfvrz+52iRTDCvOHmMGyJikqdm8wgM4iz1DWuILKkWYC2 wQLHl/euRGnDAdd7COwiIO2TIL8kBg== X-Received: by 10.107.133.84 with SMTP id h81mr49701597iod.230.1499398431486; Thu, 06 Jul 2017 20:33:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.162 with HTTP; Thu, 6 Jul 2017 20:33:50 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 7 Jul 2017 13:33:50 +1000 Message-ID: Subject: Re: Unidirectional streams PR To: Kazuho Oku 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: Fri, 07 Jul 2017 03:33:54 -0000 On 7 July 2017 at 12:21, Kazuho Oku wrote: > Considering the complexity of guessing when the server runs out of > stream IDs, it might be easier if we could use a server-sent > CANCEL_REQUEST frame as an indication that the client needs to resend > the request on a new connection. If we ever get to the point where we have a good graceful shutdown, then that should mostly cover this. CANCEL_REQUEST is likely still useful here to cover reordering. Here's my thinking on this: the server sends a GOAWAY identifying the highest numbered request that it has accepted (requests, not pushes). Anything higher than this will not be processed. The connection goes away when responses to all those requests have been delivered, including all the promises that attach to those. The only trick here is that the server might be able to answer a request on stream X, but find that it can't answer X-1, which could arrive out of order. So, yeah, CANCEL_REQUEST is a good fit for that. RST_STREAM isn't useful here because the stream can be closed when the server makes this discovery. Either way, having the server being able to cancel requests is good practice, because it might not be in a position to use RST_STREAM. From nobody Thu Jul 6 22:05: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 D769F12EC4D for ; Thu, 6 Jul 2017 22:05:04 -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, 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=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 WZ6wkhKDBUux for ; Thu, 6 Jul 2017 22:05:03 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 26D02129AF6 for ; Thu, 6 Jul 2017 22:05:03 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e7so11447364pfk.0 for ; Thu, 06 Jul 2017 22:05:03 -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=thquKinraqaxiullo4UFfBWeW8ZQV0ZhSJTZp/wK454=; b=RReRGTtXxvtuwVm9ps8TNKBQhV4/xSdTmqCDvLNu64kCc/uNQzvJqG1RPmUUcwS29T 4z+dJq4GA9ztitvkVinvRdL1KUusDywzlEg0x2+ytuOJUIhSK81LTCG5fS7HS4AM4zFV mW5qLVajVMYJkFs4RCX/ayWfe7A5EucUJv2EVnkZNTaNzwCNiGQnh9YKr8G36wjIfLvk KFO+6E8jto5ldtSSknkbIR2358sgsN6ElHFg6CxTM991Jwj34tv8P1hYF+cRpLZJjGsH j5tYBr15lt+ZhX+CybkLTdL2/xrU67VDp5kBlvu4u5/wGO/s4TJOGQKcwHFMYGj1zNYT NQew== 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=thquKinraqaxiullo4UFfBWeW8ZQV0ZhSJTZp/wK454=; b=OmxFcIRNfHdN//RMcufcKFh86BCSQhXQVKIJLIxs2I24A+RSuOXmyUsc9MuyU/WKvz o8mN7RKNO5aTeOaGkCkRbUeMpT+K+EDi1dxXOt3gPyfaDyF1IuPf+t46rxbsJh5yhUK5 SvSHwtUpW1XhDBJVbEBhKtTyd9ZfkfYl3mXZPDk3VFtq2PjEGtYQe+35CTVBWd89E3ER PDUR7akRyYUl1dDz9v/tWOM5OHFqevOXQnJ6o/+FVN1yONURKwhGVPfJ6WRjTb+q4jKy tFi/SpAXFpXlaB0dx5BMwtrZUSTdxDzoHSedYPwP3u46Vwzy6FCDY1AbldFSqzACLno/ ENwQ== X-Gm-Message-State: AIVw1110rqKKzAYOEUSDtHmTJbH0CpkxlITpsq7aA3cQIh+Ceyp9WeyU ej6Tv72HI+5OQMAl2u9qnnQmBdjdzw== X-Received: by 10.98.38.129 with SMTP id m123mr29262988pfm.183.1499403902636; Thu, 06 Jul 2017 22:05:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Thu, 6 Jul 2017 22:05:01 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 7 Jul 2017 14:05:01 +0900 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson , "Lubashev, Igor" 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: Fri, 07 Jul 2017 05:05:05 -0000 2017-07-07 12:33 GMT+09:00 Martin Thomson : > On 7 July 2017 at 12:21, Kazuho Oku wrote: >> Considering the complexity of guessing when the server runs out of >> stream IDs, it might be easier if we could use a server-sent >> CANCEL_REQUEST frame as an indication that the client needs to resend >> the request on a new connection. > > If we ever get to the point where we have a good graceful shutdown, > then that should mostly cover this. CANCEL_REQUEST is likely still > useful here to cover reordering. > > Here's my thinking on this: the server sends a GOAWAY identifying the > highest numbered request that it has accepted (requests, not pushes). > Anything higher than this will not be processed. The connection goes > away when responses to all those requests have been delivered, > including all the promises that attach to those. > > The only trick here is that the server might be able to answer a > request on stream X, but find that it can't answer X-1, which could > arrive out of order. So, yeah, CANCEL_REQUEST is a good fit for that. > RST_STREAM isn't useful here because the stream can be closed when the > server makes this discovery. > > Either way, having the server being able to cancel requests is good > practice, because it might not be in a position to use RST_STREAM. Thank you for the answer. I agree with your observations. In https://mailarchive.ietf.org/arch/msg/quic/9VqjoX4acCDrxMKV2AmOQjspe3Q Igor has suggested using DISINTEREST frame for cancelling requests from the client-side. In the end, it might make sense for the uni-directional-stream-only approach to have a frame that can be sent in any direction for cancelling a request. -- Kazuho Oku From nobody Fri Jul 7 09:48: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 F295D131777 for ; Fri, 7 Jul 2017 09:48:26 -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, FREEMAIL_FROM=0.001, 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=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 HTzzRyB_SK1C for ; Fri, 7 Jul 2017 09:48:25 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 346BD131765 for ; Fri, 7 Jul 2017 09:48:25 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id i2so31668596qta.3 for ; Fri, 07 Jul 2017 09:48:25 -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=vlpB2uUlBoMioH0OHbkxtxcCH4E8uecT4lfGspuEVfI=; b=YwwXyHWStpvjF9nQO17Hs1bOJBofsjiQH/l5cr3WABnfPLrDABg/jo2oP3Ex7jrUNd vUCjl/3go7lSa2YljqKAojg8G3tHyA9vYjW+zpfWyqe8KVX40Knu27ZjY6kpBM4l8yw2 Xla7rc5alKcQwxpu7rZtNwR91WJPSYEXNtIagcELNW2R8stmBRHUZVmtJphel9FpW+II XiLUvMcg39eNqOzyMYwMalAwI8PJVawi9agNl83O058UYkHcrS4748XJumaWdGemBca7 MXMpb8fbuQQoGkalUtB9UYZ1GD5aLt4SsLWPILRmaiQATKnw2eWWe0LM7f4JDaMvrZLk EMcQ== 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=vlpB2uUlBoMioH0OHbkxtxcCH4E8uecT4lfGspuEVfI=; b=H16O8ONOww0vSbFlJXJLJqFjdZAZU0h8JPGBzxMiW+cK7a6Fc2HGoWD0v3Lgbd+7Kh fBneWGbyys5Bixip1+Xb3+6TK0T4wDQdiCXmc9D5e3wTG/f+i3W4SP0dKiRaq4hM63k9 QFgD5YspyigEZ26l1U358X4dfSMjyR8HX79XQbNYGftXzOGigZcxGdD1R2zLcVw/246x 2NMrQ1ZtORgSMP+J3AZll3iVDSPsiiUsBqJxzGEqkzJNrIxFHDNmOV9jk2Rw7vfiViBz zCyFUEnjwZDkFHGPO3XKtFFMY9qdVfiFwCexamiCPXLtaLI2QaEsWZAi2k76Pif3atpB F+LA== X-Gm-Message-State: AIVw110zUBnMJOc7pEg8EMPf2EHUYZfP9yD3Oo3kMT+9ZKd2PDvO7zz/ UUlhaPiERQ+XRSB2PKRLGlA6xrpauw== X-Received: by 10.237.47.39 with SMTP id l36mr18156775qtd.181.1499446104414; Fri, 07 Jul 2017 09:48:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.71 with HTTP; Fri, 7 Jul 2017 09:48:23 -0700 (PDT) In-Reply-To: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Duke Date: Fri, 7 Jul 2017 09:48:23 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Subodh Iyengar Cc: "Lubashev, Igor" , Kazuho Oku , Ian Swett , Mike Bishop , Dmitri Tikhonov , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Jo Kulik , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c0d03ba69ddb50553bd0073" 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, 07 Jul 2017 16:48:27 -0000 --94eb2c0d03ba69ddb50553bd0073 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar wrote: > > Without such a signal, a generic proxy that is not aware of your > application internals is not able to know when to send the FIN > > I see, this use case does make somewhat sense, however I'm curious > if someone has a concrete use case for a generic QUIC proxy which is not > aware of the application protocol at all. In TCP this was more common for > middleboxes to do because there was no end to end encryption of the > transport, however QUIC is encrypted. Even with cases when we tunneling > protocols at our end, we usually have some knowledge of the app that we are > running because we need to route them differently to different backends. I > was mostly thinking that proxies would at least have some knowledge about > HTTP/2 or app protocols. > Some load balancers (including ours) terminate the transport connection. Being trusted middleboxes, they have the certificates and this sort of thing works in principle. That said, in such a case it's entirely feasible to implement HTTP/2 on the middlebox as well. However, I think we should look forward to the day where QUIC is implemented in kernel space and HTTP/2 (and everything else) remains an application. I imagine counting on all applications to do this kind of garbage collection could cause problems. --94eb2c0d03ba69ddb50553bd0073 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar <<= a href=3D"mailto:subodh@fb.com" target=3D"_blank">subodh@fb.com> wrote:

>=C2=A0Without such a signal, a gene= ric proxy that is not aware of your application internals is not able to kn= ow when to send the FIN

I see, this use case does make somewhat= sense, however I'm curious if=C2=A0someone has=C2=A0a concrete=C2=A0us= e case for a generic QUIC proxy which is not aware of the application protocol at all. In TCP this was more common for middleboxes t= o do because there was no end to end encryption of the transport, however Q= UIC is encrypted. Even with cases when we=C2=A0tunneling protocols at our e= nd, we usually have some knowledge of the app that we are running because we need to route them differently to d= ifferent backends.=C2=A0I was mostly thinking that=C2=A0proxies would at le= ast have some knowledge=C2=A0about HTTP/2 or app protocols.=C2=A0

Some load bala= ncers (including ours) terminate the transport connection. Being trusted mi= ddleboxes, they have the certificates and this sort of thing works in princ= iple.

That said, in such a case it's entirely = feasible to implement HTTP/2 on the middlebox as well.

=
However, I think we should look forward to the day where QUIC is imple= mented in kernel space and HTTP/2 (and everything else) remains an applicat= ion. I imagine counting on all applications to do this kind of garbage coll= ection could cause problems.
--94eb2c0d03ba69ddb50553bd0073-- From nobody Fri Jul 7 09:58: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 85D47131783 for ; Fri, 7 Jul 2017 09:58:25 -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, RP_MATCHES_RCVD=-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=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 YrC4hFE4LE7v for ; Fri, 7 Jul 2017 09:58:23 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 9E93B13173B for ; Fri, 7 Jul 2017 09:58:23 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id t186so20000153pgb.1 for ; Fri, 07 Jul 2017 09:58: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=jRlps+g6vTcXSAOrBnOLka66EJhUP/buvEP7cl6nrRQ=; b=BlJU3859TwVn2ylJMeFcNEbPK8pFlo5x+edEAHv/wiNcivTb4gXGjpPCU/PrjUIpVt 57s/YFTo2MFXkTDMOdpveaH7OLSYX0WdSN/FCveOm8gCuHNKxmUcGnHOXbagdz7muEtt oyXBXi6cWEz4Ar7jJ8yCe8JRGdIlhnXfdYWjKm8QdaffBcavGhBEW6J5aYQUZAJL99eY //rWOcRUvDlkYJASiIuQ0rxdgL3UBE99XGWP1KTdLuD12yJH7Ngqsto1+a8bj+1to8Bi WRDHIRSElc0FWIhgpnXsH3E+HCwUCcaOEEUnXEX+9gY3BDBAX6cSUmP6ZBAbpg+Eg9Kn Pdww== 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=jRlps+g6vTcXSAOrBnOLka66EJhUP/buvEP7cl6nrRQ=; b=okPfd0nNmi9AZpNAoG9tyznWeJ+ppyWCpYs9oLLL8V6mu2yFAXFSD7/lJQ9CQ3t3rs if0o+aU0sN74mUxXi0dzw6q4o1Bywi4UMiKnnGyF/XXNruyUcaNEvajKdQvBVKwhkSRn WOfJu9DoFj788irYD8KAbgZPsRXwYB7x6vuUEgsuU4d3Osaq262cLovu8MwyMnfiSMea TiMsFs27LMXHTqY38EjJ5QPLcqBsKEHcFwQ96QTvBTdRDZ6xOWCzG0XRHhyHJxmt55uL yipruSFBApiKjIhFKRz1fZe7qHWPSzJ2/pUChxs5VemBei2b1m1/Is1yvUNT2DmbCkto p8kA== X-Gm-Message-State: AIVw110AcfQqesvaueDwckq5bTyXe4wC8auubWlUEzMfpSZK3bZyUr47 IOKJeExevFboaUCrOomNvEB54xlmZx8X X-Received: by 10.84.224.11 with SMTP id r11mr3953510plj.267.1499446703003; Fri, 07 Jul 2017 09:58:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.153.19 with HTTP; Fri, 7 Jul 2017 09:58:21 -0700 (PDT) In-Reply-To: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> From: Jana Iyengar Date: Fri, 7 Jul 2017 09:58:21 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Duke Cc: Subodh Iyengar , Mike Bishop , Dmitri Tikhonov , Ian Swett , "Lubashev, Igor" , Jo Kulik , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Martin Thomson , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Kazuho Oku Content-Type: multipart/alternative; boundary="f403043a6168181b630553bd24b4" 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, 07 Jul 2017 16:58:25 -0000 --f403043a6168181b630553bd24b4 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 9:48 AM, Martin Duke wrote: > > > On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar wrote: > >> > Without such a signal, a generic proxy that is not aware of your >> application internals is not able to know when to send the FIN >> >> I see, this use case does make somewhat sense, however I'm curious >> if someone has a concrete use case for a generic QUIC proxy which is not >> aware of the application protocol at all. In TCP this was more common for >> middleboxes to do because there was no end to end encryption of the >> transport, however QUIC is encrypted. Even with cases when we tunneling >> protocols at our end, we usually have some knowledge of the app that we are >> running because we need to route them differently to different backends. I >> was mostly thinking that proxies would at least have some knowledge about >> HTTP/2 or app protocols. >> > > Some load balancers (including ours) terminate the transport connection. > Being trusted middleboxes, they have the certificates and this sort of > thing works in principle. > > That said, in such a case it's entirely feasible to implement HTTP/2 on > the middlebox as well. > If these middleboxes terminate the transport connection for QUIC, would they need to understand stream semantics? Or would they simply terminate the QUIC connection, but relay the STREAM frames without any changes? I'll note that all transports after TCP have two general parts to them -- the packet transport part, and the application semantics part. Middleboxes are usually interested in the "lower half" of the transport - the packet transport part. That said, I'm not opposed to having an explicit bit. I'm also wondering if there's a real use case, or if we're provisioning for the future here. - jana However, I think we should look forward to the day where QUIC is > implemented in kernel space and HTTP/2 (and everything else) remains an > application. I imagine counting on all applications to do this kind of > garbage collection could cause problems. > --f403043a6168181b630553bd24b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 9:48 AM, Martin Duke <martin.h.duke@gmail.com= > wrote:

<= div class=3D"gmail_extra">
O= n Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar <subodh@fb.com> w= rote:

>=C2=A0Without such a signal, a gene= ric proxy that is not aware of your application internals is not able to kn= ow when to send the FIN

I see, this use case does make somewhat= sense, however I'm curious if=C2=A0someone has=C2=A0a concrete=C2=A0us= e case for a generic QUIC proxy which is not aware of the application protocol at all. In TCP this was more common for middleboxes t= o do because there was no end to end encryption of the transport, however Q= UIC is encrypted. Even with cases when we=C2=A0tunneling protocols at our e= nd, we usually have some knowledge of the app that we are running because we need to route them differently to d= ifferent backends.=C2=A0I was mostly thinking that=C2=A0proxies would at le= ast have some knowledge=C2=A0about HTTP/2 or app protocols.=C2=A0

Some lo= ad balancers (including ours) terminate the transport connection. Being tru= sted middleboxes, they have the certificates and this sort of thing works i= n principle.

That said, in such a case it's en= tirely feasible to implement HTTP/2 on the middlebox as well.

If these middleboxes terminate t= he transport connection for QUIC, would they need to understand stream sema= ntics? Or would they simply terminate the QUIC connection, but relay the ST= REAM frames without any changes?
I'll note that all transport= s after TCP have two general parts to them -- the packet transport part, an= d the application semantics part. Middleboxes are usually interested in the= "lower half" of the transport - the packet transport part.

That said, I'm not opposed to having an explici= t bit. I'm also wondering if there's a real use case, or if we'= re provisioning for the future here.

- jana
<= div>
However, I think we should lo= ok forward to the day where QUIC is implemented in kernel space and HTTP/2 = (and everything else) remains an application. I imagine counting on all app= lications to do this kind of garbage collection could cause problems.
=
=C2=A0
--f403043a6168181b630553bd24b4-- From nobody Fri Jul 7 13:44: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 22EBA12EC2F for ; Fri, 7 Jul 2017 13:44:43 -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, FREEMAIL_FROM=0.001, 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=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 Jxm30_KLFJ5k for ; Fri, 7 Jul 2017 13:44:41 -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 C0684126D05 for ; Fri, 7 Jul 2017 13:44:40 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id k67so61922057wrc.2 for ; Fri, 07 Jul 2017 13:44:40 -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=0imJr9LxatnTh5MAUw0ye5owPAcguX9VOkTCDKF2V6A=; b=vR0TutALgRSx8LRNGb8iO+zYDzN7Ye1Uee7AOV5RF2beaAWDoWXshTJTESTxTRqyew c8IJF0ng8XOhBqseZd0TwUF92dn0Vts+qsbXBuGg4T4g1S7QzX8X4Gxj1LRQoWqPdEy+ 3WrjNsmNlqmJDp52DZ9Sd1639UTmAIRU5SKLnSczthIiKSMvAFaoP/2W+sn4z5QfzFIx lMNc38nuQjc32S3lhCpbm5jfNpOGvUPTYVu4XKzm3eWn49NZYBmHs/wG/AZLz944ibQO 4Ar2m8wgzR+XqmSuQyau+Xqx2jHP1xcBfsEpq+TdyIlvfUCm9paqjJvoWko78h6lSLwc NpKQ== 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=0imJr9LxatnTh5MAUw0ye5owPAcguX9VOkTCDKF2V6A=; b=i4mZ6GIsc3nuqLWxOGMdR8WHBoZayv5vrvIrVsGBGluRUhCoxVnOyGkZZMI949XaZC PwuL5FIRw2HIpJkL/FGgmyyBFJPaHLb/ckwNXt7woehFpLl8FnoWEYCNPlw63gdcFrXo yurR/28uTLC9W3oyL6hCkXHVEi66Q8Xv2Ou7WNNPrPYLfMIm5su8I4XtkioRyiUASMB3 EpErKjk/zUvGTfYjjTlBFS9gG+m6UwLSFH20cB4Wwl5yDmv06tYbOGKPF88/ltUuypoD NcRq9NV769ttBj8By0XV1KaXIslGT3Y0r5SF90HlYYWoUq8LfLSa6my4/UT92RChY3Mv j50g== X-Gm-Message-State: AIVw112JTjKcqFRILKu5mx6MqD2M5IOEXcDfmzTN2EoGku5JW31Ewm9H meweI0nfShtkQvhkIEEkh9fjx6p/NQ== X-Received: by 10.28.156.202 with SMTP id f193mr401275wme.22.1499460279260; Fri, 07 Jul 2017 13:44:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.137.26 with HTTP; Fri, 7 Jul 2017 13:44:38 -0700 (PDT) In-Reply-To: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Duke Date: Fri, 7 Jul 2017 13:44:38 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Jana Iyengar Cc: Subodh Iyengar , Mike Bishop , Dmitri Tikhonov , Ian Swett , "Lubashev, Igor" , Jo Kulik , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Martin Thomson , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Kazuho Oku Content-Type: multipart/alternative; boundary="001a114b2d104ceb0e0553c04d3b" 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, 07 Jul 2017 20:44:43 -0000 --001a114b2d104ceb0e0553c04d3b Content-Type: text/plain; charset="UTF-8" As I understand it, QUIC's contract with the upper layer includes streams, so any such middlebox would maintain state for each stream. In general, these middleboxes will support awareness of most L7s, and users will turn it on. The exceptions are probably kind of corner-case-ish. Perhaps there's a new application directly on top of QUIC that the middlebox doesn't understand natively. In that case, with no FIN the middlebox would be forced to hold stream state until the end of the connection. I guess one question is if passing STREAM frames whole (at most changing the stream ID) is stateless for the middlebox. Also, I'm not clear where we ended up on silent close. If we're indeed expecting endpoints to see that all the streams are closed to begin the shutdown, then we *have to see that all the streams are closed.* On Fri, Jul 7, 2017 at 9:58 AM, Jana Iyengar wrote: > On Fri, Jul 7, 2017 at 9:48 AM, Martin Duke > wrote: > >> >> >> On Wed, Jul 5, 2017 at 10:16 PM, Subodh Iyengar wrote: >> >>> > Without such a signal, a generic proxy that is not aware of your >>> application internals is not able to know when to send the FIN >>> >>> I see, this use case does make somewhat sense, however I'm curious >>> if someone has a concrete use case for a generic QUIC proxy which is not >>> aware of the application protocol at all. In TCP this was more common for >>> middleboxes to do because there was no end to end encryption of the >>> transport, however QUIC is encrypted. Even with cases when we tunneling >>> protocols at our end, we usually have some knowledge of the app that we are >>> running because we need to route them differently to different backends. I >>> was mostly thinking that proxies would at least have some knowledge about >>> HTTP/2 or app protocols. >>> >> >> Some load balancers (including ours) terminate the transport connection. >> Being trusted middleboxes, they have the certificates and this sort of >> thing works in principle. >> >> That said, in such a case it's entirely feasible to implement HTTP/2 on >> the middlebox as well. >> > > If these middleboxes terminate the transport connection for QUIC, would > they need to understand stream semantics? Or would they simply terminate > the QUIC connection, but relay the STREAM frames without any changes? > I'll note that all transports after TCP have two general parts to them -- > the packet transport part, and the application semantics part. Middleboxes > are usually interested in the "lower half" of the transport - the packet > transport part. > > That said, I'm not opposed to having an explicit bit. I'm also wondering > if there's a real use case, or if we're provisioning for the future here. > > - jana > > However, I think we should look forward to the day where QUIC is >> implemented in kernel space and HTTP/2 (and everything else) remains an >> application. I imagine counting on all applications to do this kind of >> garbage collection could cause problems. >> > > --001a114b2d104ceb0e0553c04d3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I understand it, QUIC's contract with the upper lay= er includes streams, so any such middlebox would maintain state for each st= ream. In general, these middleboxes will support awareness of most L7s, and= users will turn it on.

The exceptions are probably kind= of corner-case-ish. Perhaps there's a new application directly on top = of QUIC that the middlebox doesn't understand natively. In that case, w= ith no FIN the middlebox would be forced to hold stream state until the end= of the connection.=C2=A0 I guess one question is if passing STREAM frames = whole (at most changing the stream ID) is stateless for the middlebox.

Also, I'm not clear where we ended up on silent cl= ose. If we're indeed expecting endpoints to see that all the streams ar= e closed to begin the shutdown, then we have to see that all the streams= are closed.

On Fri, Jul 7, 2017 at 9:58 AM, Jana Iyengar &= lt;jri@google.com&g= t; wrote:
On Fri, Jul= 7, 2017 at 9:48 AM, Martin Duke <martin.h.duke@gmail.com> wrote:

On Wed, Jul 5, 2017= at 10:16 PM, Subodh Iyengar <subodh@fb.com> wrote:

>=C2=A0Without such a signal, a gene= ric proxy that is not aware of your application internals is not able to kn= ow when to send the FIN

I see, this use case does make somewhat= sense, however I'm curious if=C2=A0someone has=C2=A0a concrete=C2=A0us= e case for a generic QUIC proxy which is not aware of the application protocol at all. In TCP this was more common for middleboxes t= o do because there was no end to end encryption of the transport, however Q= UIC is encrypted. Even with cases when we=C2=A0tunneling protocols at our e= nd, we usually have some knowledge of the app that we are running because we need to route them differently to d= ifferent backends.=C2=A0I was mostly thinking that=C2=A0proxies would at le= ast have some knowledge=C2=A0about HTTP/2 or app protocols.=C2=A0

Some lo= ad balancers (including ours) terminate the transport connection. Being tru= sted middleboxes, they have the certificates and this sort of thing works i= n principle.

That said, in such a case it's en= tirely feasible to implement HTTP/2 on the middlebox as well.

If these middleboxes term= inate the transport connection for QUIC, would they need to understand stre= am semantics? Or would they simply terminate the QUIC connection, but relay= the STREAM frames without any changes?
I'll note that all tr= ansports after TCP have two general parts to them -- the packet transport p= art, and the application semantics part. Middleboxes are usually interested= in the "lower half" of the transport - the packet transport part= .

That said, I'm not opposed to having an = explicit bit. I'm also wondering if there's a real use case, or if = we're provisioning for the future here.

- jana

However, I think we= should look forward to the day where QUIC is implemented in kernel space a= nd HTTP/2 (and everything else) remains an application. I imagine counting = on all applications to do this kind of garbage collection could cause probl= ems.
=C2=A0

--001a114b2d104ceb0e0553c04d3b-- From nobody Sat Jul 8 09: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 7F7BA12EC0F for ; Sat, 8 Jul 2017 09:45:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 35k3cI8o5wwV for

On Thu, Jul 13, 2017 at 8:42 PM, Mart= in Duke wrote:

--001a114be9a2ed9fd205543c622c-- From nobody Thu Jul 13 17:48:00 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 4C6FA126B72 for ; Thu, 13 Jul 2017 17:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 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_FONT_FACE_BAD=0.981, 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 5O0_IaRQ-_Zw for

On Thu, Jul 13, 2017 at 8:47 PM, Martin Duk= e wrote:

I'm a little concerned that a blend o= f the strategies leaves us with something that still allows ossification an= d isn't quite enough for decent performance testing. But I did add your= further clarifications about HTTP/2, and the "at scale" provisio= n.

Is your option 3 the MVP for something you'd like= to do with this iteration?

On Thu, Jul 1= 3, 2017 at 5:28 PM, Ian Swett <ianswett@google.com> wrote:=
Thanks for the update.= =C2=A0 I would suggest a third potential option, which is a mix of what you= have with a small clarification(in bold):

Further revisions to mechanisms in the First Implementation Draft = (e.g. changes to the public header format, connection close).
Transport Parameter Exchange. A= t the very least, the four parameters specified as MUST in the draft.
Address validation and = HelloRetryRequest
= An HTTP/2 application to require multiple streams (with stateless HPACK = compression, no QPACK, QCRAM, etc) and no server push.

Any implementations that deploy at any scale must also do:
<= font color=3D"#24292e" face=3D"-apple-system, system-ui, Segoe UI, Helvetic= a, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol"><= span style=3D"font-size:16px">
Loss Recovery beyond the exising 1-RTO retransmissi= ons. (I believe this includes a number of concepts that are extensively tes= ted in TCP and has low interoperability concerns).
Congestion Control

The reasoning being= that both stateless reset and 0RTT are a fair bit of work to get right bas= ed on my experience, and are not critical to having a useful QUIC applicati= on. =C2=A0

On Thu, Jul 13, 2017 at 7:46 PM, Martin Duke <martin.h.duke@gm= ail.com> wrote:
Alright, I updated the second implementation draft significantly.
https://github.com/quicwg/base-drafts/wiki/Second-Implementation-Draft

There are now two strategies: "Lock down the wire image" an= d "do what we need to allow useful performance testing". I much p= refer the former but it is worth discussing, since people appear to be inte= rested in both.

It's also clear (at least to m= e) that we need to do basic stream life-cycle stuff in either case, so that= has moved into the "must include" category.

Martin

On Mon, Jul 10, 2017 at 5:06 PM, Ian Swett <ianswett@google.com= > wrote:
Agree= d, performance analysis is going to be useless in the absence of loss recov= ery and congestion control.=C2=A0 Presumably anyone deploying this at scale= would implement the recovery draft in a relatively complete manner, but th= at doesn't mean everyone has to do it.

But there'= ;s nothing interesting to measure with no application.
=

On Mon, Jul = 10, 2017 at 12:55 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
I'm not= sure how "performance analysis" is going to function in the abse= nce of loss recovery or congestion control. An alternate approach to implem= entations is to tackle the big performance drivers first, presumably loss r= ecovery, congestion control, and streaming to prevent HOL blocking. However= , this would run directly opposite to Jana's suggestion to lock down th= e wire image to prevent ossification.

On Mon, Jul 10, 2017 at 12:32 AM, Kazuho Oku <<= a href=3D"mailto:kazuhooku@gmail.com" target=3D"_blank">kazuhooku@gmail.com= > wrote:
2017-07-10 12:28 GMT+09:00 Ryan Hamilton <rch@google.com>:
>
>
> On Sun, Jul 9, 2017 at 5:39 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2017-07-09 1:45 GMT+09:00 Jana Iyengar <jri@google.com>:
>> > I've been thinking about this, and I'm starting to th= ink that we should
>> > cover more ground in the second implementation draft.
>> >
>> > I'm hearing about increasing deployments of gQUIC, largel= y due to market
>> > pressures. The availability of the Chromium implementation ma= kes it
>> > particularly easy for folks to deploy QUIC with that code. I = think we
>> > need
>> > to move with some urgency, even if we don't change everyt= hing about QUIC
>> > to
>> > make it perfect, so that we can start getting IETF QUIC deplo= yments out
>> > there. Specifically, I think we should:
>> > 1. work out the wire-visible invariants and finalize all of t= hose for
>> > the
>> > second impl draft. We know that there are some middleboxes th= at already
>> > have
>> > classifiers for gQUIC, and we need to move quickly and push I= ETF-QUIC so
>> > we
>> > can test that IETF-QUIC is deployable. I fear that the longer= we take,
>> > the
>> > more widespread gQUIC ossification will be.
>> > 2. allow impls to make serious progress towards a basic HTTP = mapping
>> > over
>> > QUIC. We can punt on header compression (QPACK/QCRAM), but pe= rhaps test
>> > a
>> > basic HTTP request-response over QUIC. We can still punt
>> > performance-oriented things such as full loss recovery and co= ngestion
>> > control to later. This forces us to try and finalize the HTTP= mapping
>> > details, which is a good thing, IMO.
>>
>> I agree with Jana.
>>
>> If we can have some basic HTTP mapping (it can be as basic as usin= g
>> HTTP/1.0 over each stream), we can use that to test how the IETF >> version of QUIC performs well in the field, by comparing its
>> performance to HTTP over TCP.
>
>
> Interesting idea. One challenge with performance analysis is that it&#= 39;ll be a
> bit of an apples to oranges comparison. QUIC will be doing HTTP/1 (wit= hout
> header compression) against HTTP/2 (with header compression) or HTTP/1= .1
> (over multiple connections).

Agreed.

Though I might argue that collecting metrics of a QUIC implementation
without header compression could be useful. We can use that as a
baseline when we formalize QPACK / QCRAM.

--
Kazuho Oku

--001a1142ee163584f505543c8878-- From nobody Thu Jul 13 18:33: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 879621315DA for ; Thu, 13 Jul 2017 18:33: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, FREEMAIL_FROM=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 wGqIJj1-zfUJ for ; Thu, 13 Jul 2017 18:33:38 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e: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 4F7DC12EBF7 for

Here's the half-baked attack I was suggesting tod= ay.

Suppose we have a manipulation of packets that= induces an immediate

response from the server, like if a recipie= nt responds to an

out-of-order packet with an immediate ACK. The = bit flipping thus

potentially allows an attacker to differentiate= a *response* packet

from a packet which was organically generate= d by the other side

(by looking for the bit flip).

Now, suppose you *also* have a non constant time cryptographic

implementation. The manipulation above would allow an attacker to<= /div>

--001a113f43902dec400554d1ab22-- From nobody Fri Jul 21 04:14:44 2017 Return-Path:

Ian

--94eb2c064ed24477bb0554d26c59-- From nobody Fri Jul 21 05:01: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 02841131A87 for ; Fri, 21 Jul 2017 05:01: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, 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 lvidqqzsbZ5U for

2. trust a= single entropy source (like possibly backdoor=E2=80=99ed on-chip PRNG) or = a faulty OS implementation, or vice versa, avoiding them entirely and miss = quality entropy.

3. entropy pollution: allowing an attacker to feed bad entropy such= that the PRNG moves to a predictable state space. A good PRNG will only=C2= =A0increase entropy but apparently not all PRNGs have this property. Fortun= a attempts to address this by hashing=C2=A0various entropy sources.<= /font>

So there plenty of pitfalls, but requiring that the QUIC impleme= ntation to protect against bad PRNG rather than the crypto library seems wr= ong to me. Granted, you don=E2=80=99t need to make the protocol more vulner= able than necessary, and indeed, I have also thought about all these random= values being released into the wild is an easy way to make serious crypto = mistakes..

On 22 July 2017 = at 14.05.13, Stephen Farrell (= stephen.farrell@cs.tcd.ie) wrote:

But one coul= d equally generate a connection ID=C2= =A0
from something else (e.g. via a hash) that has suffici= ent randomness=C2=A0(Christian suggested the first flight, though I may be getting the=C2=A0
term wrong there), an= d achieve the properties one needs, but without=C2=A0
exposing bits output from the prng in cle= ar. I

--f403045e32e8db2cba0554eaad0d-- From nobody Sat Jul 22 10:58: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 4039C131838 for

On Sun, Jul 23, 2017 at 4:56 AM, Philipp S.= Tiesel <> wrote:

Hi,

too b= ad that I missed that discussion.=C2=A0

Separating= DATA and Request/Response to different streams would be beneficial if we a= dd unreliable streams. I will try to write up something (at least considera= tions) before the interim.=C2=A0

On 22. Jul 2017, at 03:04, = Mike Bishop <Michael.Bishop@microsoft.com> wrote:

No, the consensus both in Paris and Prague was = a single stream, which means the DATA frame is back to stay.=C2=A0 The HPAC= K-without-dynamic-table piece is temporary, until we pick a direction for h= eader compression.
=C2=A0
Sent = from my Windows 10 phone
=C2=A0
Fro= m:=C2=A0= Lucas Pardue
Sent:= =C2=A0Friday, July 21, 2017 8:20 AM
To:=C2=A0IETF QUIC WG
Subject:=C2=A0HTTP requests on one stream #692
=C2=A0
Hi,
=C2= =A0
Apologies if this was discussed already in Prague= but I=E2=80=99d like some clarification on the intended lifetime scope of = the changes in= =C2=A0PR#692.= =C2=A0
=C2=A0
Is the intention that this= change unblocks specification / development so that the WG can continue?
= Will these changes be unwound once progress has been made?
The DATA frame has been r= esurrected (I presume to demark frames in the same stream). Will it be stru= ck with a wooden stake in the future, or continue to hang around?=
=C2=A0
Thank= s
Lucas

AVE!
=C2=A0 Philipp S. Tiesel / phils=E2=80= =A6
--=C2=A0
=C2=A0 = =C2=A0{phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
=C2=A0 =C2= =A0 =C2=A0 wenn w eine =C2=A0 aube ist dn =C2=A0 =C2=A0 =C2=A0man au dran d= re en =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=A0o =C2=A0 =C2=A0 Schr =C2=A0 =C2=A0= =C2=A0 =C2=A0an muss =C2=A0 =C2=A0 hc =C2=A0 =C2=A0 =C2=A0 =C2=A0 h =C2=A0= (Kurt Schwitters) |
:wq! =C2=A0<----(phone: +49-179-6737439)-= --<---(jabber: phils@in-panik.de)----'

--001a11490b3e37a48f0554f9256a-- From nobody Sun Jul 23 04:58: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 DF754127869 for ; Sun, 23 Jul 2017 04:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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=nokia.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 0m_koMNi4vEC for ; Sun, 23 Jul 2017 04:57:50 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0092.outbound.protection.outlook.com [104.47.2.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF2A1276AF for ; Sun, 23 Jul 2017 04:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JLGnEk7fL2zM7KUxtvDlGAJBDmbnDeFZGE1YKJKA8ho=; b=Y13huUe3IIu7tQ5OALwvxy+Z50ydSsQiVBNU5zelOLlFB8M34BRVzBiDnYk484AelVdketFgpabp39S2UrrTAYd2TWVbJBrqDHFxwPf4/M5xGSyXBuKmER0MtVwUyAaWqHo73YR6HIOk1iBfIpI4sMdqD7nxIw5KOryFk+CFXq0= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB1173.eurprd07.prod.outlook.com (10.169.32.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Sun, 23 Jul 2017 11:57:46 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354%13]) with mapi id 15.01.1304.011; Sun, 23 Jul 2017 11:57:46 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Ian Swett , "Philipp S. Tiesel" CC: Lucas Pardue , Mike Bishop , IETF QUIC WG Subject: RE: HTTP requests on one stream #692 Thread-Topic: HTTP requests on one stream #692 Thread-Index: AdMCNJiq1/jFQyapRDqdWSVpnV2UvgAUdAmMAELNc4AAAid+AAAA+mRQ Date: Sun, 23 Jul 2017 11:57:46 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; x-originating-ip: [82.69.101.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB1173; 7:4LlnoxdDX13HsjuFho8uSu/geTplPxOlcfprbKgOIgKSDNklaCq4gBBZdvwAjWQBKk+rd4MfNNiOw4lXUQ43Yvz9967zV35Rbxrphf/VR/ZS6K8UR+cKZUk9aZjYgBucgPAJU0R0JvGpJVFCNEYSjyXZgGbpj78em0PO3C2MISp+moaQIKMOFo0O1baq10dFI0f+DvYd48anSHaPHnwmBfox0g0A8E/eGCOp1JXBGccmslLe50id7EiSm/1Fl+3qlhMkqaP7DN9wACLKqtxRVYBdCmLsEQcSBgdWFztAJGPWwkYC1l+3aY96c1fIsXzzLtKH3fzpBOXev7ROMw6hW3wqw6fuIKZ9k2f9m4ymY0yRIXZOCBLvKtQdoBdt/kqf9TvN4/zattRjjOtDyjcW0FTKLIlBrOG5FhfosuBRmgLEtVofuY4i4b1oSIg7ML8nAwK8fWQrdXiccq/OVpLBCiibBwpJd/PD5wHAQ5VA4dpf9gRe4aYb6CI1I4UjU9i66aCDLXy1PT8BqCeeSvcPYvlNkogvTvX1iu9EVIJI5Ev9OxDhmGBYJ0eHuW6ogODgwaaDiyRUzR9zj8dpeDbBQBaYo1eHdg26wPOnkmPMPtW1dG/gk1BO4nFiA2B/ny+WzSwASum9RRip+XQI+aNVg+Nyr5Ek1zUQYYU1Q77h+nRcpL4GgREDxvjdtqh7lbJjWYKIpyA2j/e22t99bLNu3hI8k4pGxbQfQk/EXQoR5Xe6Hq/g5DfJDjyq0EKaOYFNAwtDWBon5S8R+sPOyyXpTyIzH2x2nX4Xrmc3K9uIbTI= x-ms-office365-filtering-correlation-id: 24581d2a-6cba-4441-dcb3-08d4d1c208af x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB1173; x-ms-traffictypediagnostic: DB5PR07MB1173: x-exchange-antispam-report-test: UriScan:(89211679590171)(189930954265078)(100405760836317)(219752817060721)(127952516941037)(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)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1173; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1173; x-forefront-prvs: 0377802854 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39410400002)(39850400002)(39840400002)(39860400002)(24454002)(377454003)(199003)(189002)(101416001)(6246003)(106356001)(8936002)(97736004)(229853002)(33656002)(50986999)(76176999)(54356999)(53386004)(189998001)(38730400002)(3660700001)(93886004)(6506006)(25786009)(2906002)(5250100002)(2950100002)(8676002)(81166006)(4326008)(2900100001)(81156014)(66066001)(14454004)(105586002)(606006)(53936002)(53546010)(54906002)(9686003)(236005)(54896002)(3280700002)(6306002)(55016002)(8666007)(99286003)(45080400002)(478600001)(7696004)(6436002)(102836003)(7736002)(74316002)(86362001)(68736007)(5660300001)(6116002)(3846002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1173; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB1237D364086129C462AAC19D84BA0DB5PR07MB1237eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2017 11:57:46.3654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1173 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, 23 Jul 2017 11:57:53 -0000 --_000_DB5PR07MB1237D364086129C462AAC19D84BA0DB5PR07MB1237eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBmZXcgY29tbWVudHMgbGlubGluZS4NCg0KVGhvbWFzDQoNCkZyb206IFFVSUMgW21haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IDIzIEp1 bHkgMjAxNyAxMDo1OQ0KVG86IFBoaWxpcHAgUy4gVGllc2VsIDxwaGlsc0Bpbi1wYW5pay5kZT4N CkNjOiBMdWNhcyBQYXJkdWUgPEx1Y2FzLlBhcmR1ZUBiYmMuY28udWs+OyBNaWtlIEJpc2hvcCA8 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBIVFRQIHJlcXVlc3RzIG9uIG9uZSBzdHJlYW0gIzY5Mg0KDQpBIGZl dyBjb21tZW50cyBvbiB1bnJlbGlhYmxlIHN0cmVhbXMgaW4gUVVJQywgYW5kIHRoaXMgbWF5IGJl IGEgbG9uZ2VyIGRpc2N1c3Npb24gYW5kIEknZCBiZSBjdXJpb3VzIHRvIHJlYWQgdGhlIGNvbnNp ZGVyYXRpb25zIHlvdSBoYXZlIGluIG1pbmQuDQoNClFVSUMgYXMgc3BlY2lmaWVkIHRvZGF5IGRl ZmluaXRlbHkgZW5hYmxlcyB1bnJlbGlhYmlsaXR5LiAgRm9yIGV4YW1wbGUsIEkgY2FuIHNlbmQg c3RyZWFtIGRhdGEgb25jZSwgYW5kIGlmIHNvbWUgcG9ydGlvbiBvZiBpdCBpcyBsb3N0LCBhdCB0 aGF0IHBvaW50IEkgY2FuIGRlY2lkZSBpZiBJIHdhbnQgdG8gcmV0cmFuc21pdCBpdCBvciBqdXN0 IGNhbmNlbCB0aGUgc3RyZWFtLg0KW1Rob21hcyBTd2luZGVsbHNdIEFzIHN0cmVhbSBmcmFtZXMg Y29udGFpbiB0aGUgb2Zmc2V0ICBjbGllbnQgcG90ZW50aWFsbHkgYWxzbyBoYXMgdGhlIG9wdGlv biBvZiBqdXN0IGFja25vd2xlZGdpbmcgcmVjZXB0aW9uIGV2ZW4gaXQgZGlkbuKAmXQgYWN0dWFs bHkgcmVjZWl2ZSB0aGVtIC0gdGhvdWdoIG9idmlvdXNseSB0aGlzIHdvdWxkIGFuZCBjYXVzZSBw cm9ibGVtcyBpZiBub24tc3RyZWFtIGZyYW1lcyB3ZXJlIGFsc28gYmVpbmcgYWNrbm93bGVkZ2Vk IHdoZW4gaW4gZmFjdCB0aGUgY2xpZW50IGhhZG7igJl0IGFja25vd2xlZGdlIHRoZW0uIC4NCkkg Z2VuZXJhbGx5IGNvbnNpZGVyIHVucmVsaWFiaWxpdHkgdG8gYmUgYSBtYXR0ZXIgb2Ygc2VuZGVy IHNpZGUgcG9saWN5Lg0KW1Rob21hcyBTd2luZGVsbHNdIEkgZG9u4oCZdCB0aGluayBJIGFncmVl IHdpdGggdGhhdC4gT2Z0ZW4gaXQgaXMgdGhlIGNsaWVudCB3aGljaCBoYXMgdGhlIGtub3dsZWRn ZSBhYm91dCB3aGV0aGVyIGRhdGEgaXMgb3IgaXMgbm90IGltcG9ydGFudC4gTGl2ZSB2aWRlbyBz dHJlYW1pbmcgaXMgdGhlIGJlc3QgZXhhbXBsZSBmb3IgdGhpcywgaWYgdGhlIGNsaWVudCBoYXMg ZW5vdWdoIGJ1ZmZlciBhbmQgaXMgcGxheWluZyB0aGUgb3V0cHV0IG91dCBsaXZlIHRoZW4gaXQg d291bGQgcHJlZmVyIHRvIGdldCB0aGUgZGF0YSByZS10cmFuc21pdHRlZCwgaG93ZXZlciBkYXRh IG92ZXIgYSBjZXJ0YWluIGFnZSBpc27igJl0IHVzZWZ1bCBhbmQgaXQgbWF5IHByZWZlciB0byBs b3NlIHNvbWUgZnJhbWVzIGFuZCBqdW1wIGJhY2sgdXAgdG8gbGl2ZS4gSG93ZXZlciBpZiB0aGUg Y2xpZW50IGlzIGFjdHVhbGx5IHJlY29yZGluZyB0aGUgb3V0cHV0IChvciBoYXMgYSBsb25nZXIg YnVmZmVyKSBpdCBtYXkgcHJlZmVyIHRvIHN0YWxsIGFuZCBnZXQgYWxsIHRoZSBkYXRhLg0KDQpN YWtpbmcgdGhpcyB3b3JrIHdlbGwgbWF5IHJlcXVpcmUgYSBtb3JlIHJvYnVzdCBpbnRlcmZhY2Ug YmV0d2VlbiB0aGUgYXBwbGljYXRpb24gYW5kIFFVSUMgc3RyZWFtLCBvciBtYXkganVzdCByZXF1 aXJlIHNvbWUgbmV3IGZlYXR1cmVzLCB3ZSdsbCBzZWUuICBJIGNhbid0IHRoaW5rIG9mIGFueXRo aW5nIGFib3V0IG1vdmluZyBmcm9tIDIgdG8gMSBzdHJlYW1zIGNoYW5nZXMgdGhpcywgZXNwZWNp YWxseSBnaXZlbiB0aGUgbmV3IGhlYWRlciBjb21wcmVzc2lvbiBzY2hlbWVzIHdpbGwgYWxsb3cg Y2FuY2VsbGF0aW9uIG9mIHRoZSBoZWFkZXJzIGFzIHdlbGwgYXMgdGhlIHBheWxvYWQsIHVubGlr ZSBiZWZvcmUuDQoNCg0KDQoNCk9uIFN1biwgSnVsIDIzLCAyMDE3IGF0IDQ6NTYgQU0sIFBoaWxp cHAgUy4gVGllc2VsIDxwaGlsc0Bpbi1wYW5pay5kZTxtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGU+ PiB3cm90ZToNCkhpLA0KDQp0b28gYmFkIHRoYXQgSSBtaXNzZWQgdGhhdCBkaXNjdXNzaW9uLg0K DQpTZXBhcmF0aW5nIERBVEEgYW5kIFJlcXVlc3QvUmVzcG9uc2UgdG8gZGlmZmVyZW50IHN0cmVh bXMgd291bGQgYmUgYmVuZWZpY2lhbCBpZiB3ZSBhZGQgdW5yZWxpYWJsZSBzdHJlYW1zLiBJIHdp bGwgdHJ5IHRvIHdyaXRlIHVwIHNvbWV0aGluZyAoYXQgbGVhc3QgY29uc2lkZXJhdGlvbnMpIGJl Zm9yZSB0aGUgaW50ZXJpbS4NCg0KDQpPbiAyMi4gSnVsIDIwMTcsIGF0IDAzOjA0LCBNaWtlIEJp c2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BA bWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpObywgdGhlIGNvbnNlbnN1cyBib3RoIGluIFBhcmlz IGFuZCBQcmFndWUgd2FzIGEgc2luZ2xlIHN0cmVhbSwgd2hpY2ggbWVhbnMgdGhlIERBVEEgZnJh bWUgaXMgYmFjayB0byBzdGF5LiAgVGhlIEhQQUNLLXdpdGhvdXQtZHluYW1pYy10YWJsZSBwaWVj ZSBpcyB0ZW1wb3JhcnksIHVudGlsIHdlIHBpY2sgYSBkaXJlY3Rpb24gZm9yIGhlYWRlciBjb21w cmVzc2lvbi4NCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgMTAgcGhvbmUNCg0KRnJvbTogTHVjYXMg UGFyZHVlPG1haWx0bzpMdWNhcy5QYXJkdWVAYmJjLmNvLnVrPg0KU2VudDogRnJpZGF5LCBKdWx5 IDIxLCAyMDE3IDg6MjAgQU0NClRvOiBJRVRGIFFVSUMgV0c8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBIVFRQIHJlcXVlc3RzIG9uIG9uZSBzdHJlYW0gIzY5Mg0KDQpIaSwNCg0KQXBv bG9naWVzIGlmIHRoaXMgd2FzIGRpc2N1c3NlZCBhbHJlYWR5IGluIFByYWd1ZSBidXQgSeKAmWQg bGlrZSBzb21lIGNsYXJpZmljYXRpb24gb24gdGhlIGludGVuZGVkIGxpZmV0aW1lIHNjb3BlIG9m IHRoZSBjaGFuZ2VzIGluIFBSIzY5MjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNl LWRyYWZ0cyUyRnB1bGwlMkY2OTIlMkZmaWxlcyZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hv cCU0MG1pY3Jvc29mdC5jb20lN0MxYTY2ODczZWM5ODM0OTdiZjdkZTA4ZDRkMDRjMDMyNiU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjI0NzIyODM0MTUz NDcmc2RhdGE9ZFpNWHBpQ1lvNWI3dFZ1S3JiSkNzbmFQUDQybXFSVmklMkIzeDRnYXJXcnZJJTNE JnJlc2VydmVkPTA+Lg0KDQoNCiAgMS4gIElzIHRoZSBpbnRlbnRpb24gdGhhdCB0aGlzIGNoYW5n ZSB1bmJsb2NrcyBzcGVjaWZpY2F0aW9uIC8gZGV2ZWxvcG1lbnQgc28gdGhhdCB0aGUgV0cgY2Fu IGNvbnRpbnVlPw0KICAyLiAgV2lsbCB0aGVzZSBjaGFuZ2VzIGJlIHVud291bmQgb25jZSBwcm9n cmVzcyBoYXMgYmVlbiBtYWRlPw0KDQogICAgICogICBUaGUgREFUQSBmcmFtZSBoYXMgYmVlbiBy ZXN1cnJlY3RlZCAoSSBwcmVzdW1lIHRvIGRlbWFyayBmcmFtZXMgaW4gdGhlIHNhbWUgc3RyZWFt KS4gV2lsbCBpdCBiZSBzdHJ1Y2sgd2l0aCBhIHdvb2RlbiBzdGFrZSBpbiB0aGUgZnV0dXJlLCBv ciBjb250aW51ZSB0byBoYW5nIGFyb3VuZD8NCg0KVGhhbmtzDQpMdWNhcw0KDQpBVkUhDQogIFBo aWxpcHAgUy4gVGllc2VsIC8gcGhpbHPigKYNCi0tDQogICB7cGhpbHN9LS0tPi0tLShwaGlsc0Bp bi1wYW5pay5kZTxtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGU+KS0tLT4tLS0oaHR0cDovL3BoaWxz LmluLXBhbmlrLmRlKS0tLS0sDQogICAgICB3ZW5uIHcgZWluZSAgIGF1YmUgaXN0IGRuICAgICAg bWFuIGF1IGRyYW4gZHJlIGVuICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgbyAgICAg U2NociAgICAgICAgYW4gbXVzcyAgICAgaGMgICAgICAgICBoICAgKEt1cnQgU2Nod2l0dGVycykg fA0KOndxISAgPC0tLS0ocGhvbmU6ICs0OS0xNzktNjczNzQzOTx0ZWw6KzQ5JTIwMTc5JTIwNjcz NzQzOT4pLS0tPC0tLShqYWJiZXI6IHBoaWxzQGluLXBhbmlrLmRlPG1haWx0bzpwaGlsc0Bpbi1w YW5pay5kZT4pLS0tLScNCg0KDQo= --_000_DB5PR07MB1237D364086129C462AAC19D84BA0DB5PR07MB1237eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4ubS0yODQ5ODE5OTgyOTcxMDI4MjA1YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHls ZS1uYW1lOm1fLTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bh bi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIy MjkxNDQ5NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMzE1MzQ1NjY7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6Njg2MDU5OTg3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozMzQyODQy NTA7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZl bC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDINCgl7bXNvLWxpc3QtaWQ6MTQxNzk0MTQ2OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTIy ODQ4MzUwO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6 bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1H QiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5BIGZldyBjb21tZW50cyBsaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaG9tYXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlDIFttYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5JYW4gU3dldHQ8 YnI+DQo8Yj5TZW50OjwvYj4gMjMgSnVseSAyMDE3IDEwOjU5PGJyPg0KPGI+VG86PC9iPiBQaGls aXBwIFMuIFRpZXNlbCAmbHQ7cGhpbHNAaW4tcGFuaWsuZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBM dWNhcyBQYXJkdWUgJmx0O0x1Y2FzLlBhcmR1ZUBiYmMuY28udWsmZ3Q7OyBNaWtlIEJpc2hvcCAm bHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVp Y0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEhUVFAgcmVxdWVzdHMgb24g b25lIHN0cmVhbSAjNjkyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGZldyBjb21tZW50cyBvbiB1bnJlbGlhYmxlIHN0cmVhbXMg aW4gUVVJQywgYW5kIHRoaXMgbWF5IGJlIGEgbG9uZ2VyIGRpc2N1c3Npb24gYW5kIEknZCBiZSBj dXJpb3VzIHRvIHJlYWQgdGhlIGNvbnNpZGVyYXRpb25zIHlvdSBoYXZlIGluIG1pbmQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlFVSUMgYXMg c3BlY2lmaWVkIHRvZGF5IGRlZmluaXRlbHkgZW5hYmxlcyB1bnJlbGlhYmlsaXR5LiZuYnNwOyBG b3IgZXhhbXBsZSwgSSBjYW4gc2VuZCBzdHJlYW0gZGF0YSBvbmNlLCBhbmQgaWYgc29tZSBwb3J0 aW9uIG9mIGl0IGlzIGxvc3QsIGF0IHRoYXQgcG9pbnQgSSBjYW4gZGVjaWRlIGlmIEkgd2FudCB0 byByZXRyYW5zbWl0IGl0IG9yIGp1c3QgY2FuY2VsIHRoZSBzdHJlYW0uJm5ic3A7DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1Ro b21hcyBTd2luZGVsbHNdIEFzIHN0cmVhbSBmcmFtZXMgY29udGFpbiB0aGUgb2Zmc2V0ICZuYnNw O2NsaWVudCBwb3RlbnRpYWxseSBhbHNvIGhhcyB0aGUgb3B0aW9uIG9mIGp1c3QgYWNrbm93bGVk Z2luZyByZWNlcHRpb24gZXZlbiBpdCBkaWRu4oCZdCBhY3R1YWxseSByZWNlaXZlIHRoZW0gLQ0K IHRob3VnaCBvYnZpb3VzbHkgdGhpcyB3b3VsZCBhbmQgY2F1c2UgcHJvYmxlbXMgaWYgbm9uLXN0 cmVhbSBmcmFtZXMgd2VyZSBhbHNvIGJlaW5nIGFja25vd2xlZGdlZCB3aGVuIGluIGZhY3QgdGhl IGNsaWVudCBoYWRu4oCZdCBhY2tub3dsZWRnZSB0aGVtLiAuPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGdlbmVyYWxseSBjb25zaWRlciB1bnJl bGlhYmlsaXR5IHRvIGJlIGEgbWF0dGVyIG9mIHNlbmRlciBzaWRlIHBvbGljeS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1Rob21h cyBTd2luZGVsbHNdIEkgZG9u4oCZdCB0aGluayBJIGFncmVlIHdpdGggdGhhdC4gT2Z0ZW4gaXQg aXMgdGhlIGNsaWVudCB3aGljaCBoYXMgdGhlIGtub3dsZWRnZSBhYm91dCB3aGV0aGVyIGRhdGEg aXMgb3IgaXMgbm90IGltcG9ydGFudC4gTGl2ZSB2aWRlbyBzdHJlYW1pbmcgaXMNCiB0aGUgYmVz dCBleGFtcGxlIGZvciB0aGlzLCBpZiB0aGUgY2xpZW50IGhhcyBlbm91Z2ggYnVmZmVyIGFuZCBp cyBwbGF5aW5nIHRoZSBvdXRwdXQgb3V0IGxpdmUgdGhlbiBpdCB3b3VsZCBwcmVmZXIgdG8gZ2V0 IHRoZSBkYXRhIHJlLXRyYW5zbWl0dGVkLCBob3dldmVyIGRhdGEgb3ZlciBhIGNlcnRhaW4gYWdl IGlzbuKAmXQgdXNlZnVsIGFuZCBpdCBtYXkgcHJlZmVyIHRvIGxvc2Ugc29tZSBmcmFtZXMgYW5k IGp1bXAgYmFjayB1cCB0byBsaXZlLg0KIEhvd2V2ZXIgaWYgdGhlIGNsaWVudCBpcyBhY3R1YWxs eSByZWNvcmRpbmcgdGhlIG91dHB1dCAob3IgaGFzIGEgbG9uZ2VyIGJ1ZmZlcikgaXQgbWF5IHBy ZWZlciB0byBzdGFsbCBhbmQgZ2V0IGFsbCB0aGUgZGF0YS48L3NwYW4+PC9pPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TWFraW5nIHRoaXMgd29yayB3ZWxsIG1heSByZXF1aXJlIGEgbW9yZSBy b2J1c3QgaW50ZXJmYWNlIGJldHdlZW4gdGhlIGFwcGxpY2F0aW9uIGFuZCBRVUlDIHN0cmVhbSwg b3IgbWF5IGp1c3QgcmVxdWlyZSBzb21lIG5ldyBmZWF0dXJlcywgd2UnbGwgc2VlLiZuYnNwOyBJ IGNhbid0IHRoaW5rIG9mIGFueXRoaW5nIGFib3V0IG1vdmluZyBmcm9tIDIgdG8gMSBzdHJlYW1z IGNoYW5nZXMgdGhpcywgZXNwZWNpYWxseSBnaXZlbg0KIHRoZSBuZXcgaGVhZGVyIGNvbXByZXNz aW9uIHNjaGVtZXMgd2lsbCBhbGxvdyBjYW5jZWxsYXRpb24gb2YgdGhlIGhlYWRlcnMgYXMgd2Vs bCBhcyB0aGUgcGF5bG9hZCwgdW5saWtlIGJlZm9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBKdWwgMjMsIDIwMTcg YXQgNDo1NiBBTSwgUGhpbGlwcCBTLiBUaWVzZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsc0Bp bi1wYW5pay5kZSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWxzQGluLXBhbmlrLmRlPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvbyBiYWQgdGhhdCBJIG1pc3NlZCB0 aGF0IGRpc2N1c3Npb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNlcGFyYXRpbmcgREFUQSBhbmQgUmVxdWVzdC9SZXNwb25zZSB0 byBkaWZmZXJlbnQgc3RyZWFtcyB3b3VsZCBiZSBiZW5lZmljaWFsIGlmIHdlIGFkZCB1bnJlbGlh YmxlIHN0cmVhbXMuIEkgd2lsbCB0cnkgdG8gd3JpdGUgdXAgc29tZXRoaW5nIChhdCBsZWFzdCBj b25zaWRlcmF0aW9ucykgYmVmb3JlIHRoZSBpbnRlcmltLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDIyLiBKdWwgMjAxNywgYXQgMDM6MDQsIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5vLCB0aGUgY29u c2Vuc3VzIGJvdGggaW4gUGFyaXMgYW5kIFByYWd1ZSB3YXMgYSBzaW5nbGUgc3RyZWFtLCB3aGlj aCBtZWFucyB0aGUgREFUQSBmcmFtZSBpcyBiYWNrIHRvIHN0YXkuJm5ic3A7IFRoZSBIUEFDSy13 aXRob3V0LWR5bmFtaWMtdGFibGUgcGllY2UgaXMgdGVtcG9yYXJ5LCB1bnRpbCB3ZSBwaWNrDQog YSBkaXJlY3Rpb24gZm9yIGhlYWRlciBjb21wcmVzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudCBmcm9tIG15IFdpbmRvd3MgMTAgcGhvbmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8c3BhbiBjbGFzcz0ibS0yODQ5ODE5OTgyOTcxMDI4MjA1YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48YSBocmVmPSJtYWls dG86THVjYXMuUGFyZHVlQGJiYy5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojOTU0RjcyIj5MdWNhcw0KIFBhcmR1ZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48YnI+DQo8Yj5TZW50OjxzcGFuIGNsYXNzPSJtLTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RnJpZGF5LCBKdWx5IDIxLCAyMDE3IDg6 MjAgQU08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ibS0yODQ5ODE5OTgyOTcxMDI4MjA1YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0 RjcyIj5JRVRGIFFVSUMgV0c8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+U3Vi amVjdDo8c3BhbiBjbGFzcz0ibS0yODQ5ODE5OTgyOTcxMDI4MjA1YXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9iPkhUVFAgcmVxdWVzdHMgb24gb25lIHN0cmVhbSAjNjkyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5BcG9sb2dpZXMgaWYgdGhpcyB3YXMgZGlzY3Vzc2VkIGFscmVhZHkgaW4gUHJhZ3Vl IGJ1dCBJ4oCZZCBsaWtlIHNvbWUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgaW50ZW5kZWQgbGlmZXRp bWUgc2NvcGUgb2YgdGhlIGNoYW5nZXMgaW48c3BhbiBjbGFzcz0ibS0yODQ5ODE5OTgyOTcxMDI4 MjA1YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGcHVsbCUyRjY5MiUyRmZp bGVzJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0Mx YTY2ODczZWM5ODM0OTdiZjdkZTA4ZDRkMDRjMDMyNiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjI0NzIyODM0MTUzNDcmYW1wO3NkYXRhPWRaTVhwaUNZ bzViN3RWdUtyYkpDc25hUFA0Mm1xUlZpJTJCM3g0Z2FyV3J2SSUzRCZhbXA7cmVzZXJ2ZWQ9MCIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyIj5QUiM2OTI8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LjxzcGFuIGNsYXNzPSJtLTI4NDk4MTk5ODI5NzEwMjgy MDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPG9sIHN0eWxlPSJtYXJnaW4t dG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SXMgdGhlIGludGVudGlvbiB0aGF0IHRoaXMgY2hhbmdlIHVuYmxvY2tzIHNwZWNpZmljYXRp b24gLyBkZXZlbG9wbWVudCBzbyB0aGF0IHRoZSBXRyBjYW4gY29udGludWU/PG86cD48L286cD48 L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTtt c28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaWxsIHRoZXNlIGNoYW5n ZXMgYmUgdW53b3VuZCBvbmNlIHByb2dyZXNzIGhhcyBiZWVuIG1hZGU/PG86cD48L286cD48L3Nw YW4+PC9saT48L29sPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjIiIHR5cGU9 IjEiPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDIgbGV2 ZWwyIGxmbzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIERBVEEgZnJhbWUgaGFzIGJlZW4gcmVzdXJy ZWN0ZWQgKEkgcHJlc3VtZSB0byBkZW1hcmsgZnJhbWVzIGluIHRoZSBzYW1lIHN0cmVhbSkuIFdp bGwgaXQgYmUgc3RydWNrIHdpdGggYSB3b29kZW4gc3Rha2UNCiBpbiB0aGUgZnV0dXJlLCBvciBj b250aW51ZSB0byBoYW5nIGFyb3VuZD88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8L29s Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkx1Y2FzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QVZFITxicj4NCiZuYnNwOyBQaGlsaXBwIFMuIFRp ZXNlbCAvIHBoaWxz4oCmPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8 c3BhbiBjbGFzcz0iaG9lbnpiIj4tLSZuYnNwOzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9l bnpiIj4mbmJzcDsgJm5ic3A7e3BoaWxzfS0tLSZndDstLS0oPC9zcGFuPjwvc3Bhbj48YSBocmVm PSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiIHRhcmdldD0iX2JsYW5rIj5waGlsc0Bpbi1wYW5p ay5kZTwvYT48c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+ KS0tLSZndDstLS0oPC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwOi8vcGhpbHMuaW4tcGFuaWsu ZGUiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vcGhpbHMuaW4tcGFuaWsuZGU8L2E+PHNwYW4gY2xh c3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiktLS0tLDwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdlbm4gdyBlaW5lICZuYnNwOyBhdWJlIGlzdCBkbiAmbmJz cDsgJm5ic3A7ICZuYnNwO21hbiBhdSBkcmFuIGRyZSBlbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJob2VuemIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7byAmbmJzcDsgJm5ic3A7IFNjaHIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW4gbXVz cyAmbmJzcDsgJm5ic3A7IGhjICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBoICZuYnNwOyAo S3VydCBTY2h3aXR0ZXJzKSB8PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPjp3cSEg Jm5ic3A7Jmx0Oy0tLS0ocGhvbmU6IDwvc3Bhbj48L3NwYW4+PGEgaHJlZj0idGVsOiYjNDM7NDkl MjAxNzklMjA2NzM3NDM5IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0OS0xNzktNjczNzQzOTwvYT48 c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+KS0tLSZsdDst LS0oamFiYmVyOg0KPC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbHNAaW4tcGFuaWsu ZGUiIHRhcmdldD0iX2JsYW5rIj5waGlsc0Bpbi1wYW5pay5kZTwvYT48c3BhbiBjbGFzcz0iaG9l bnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+KS0tLS0nPC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_DB5PR07MB1237D364086129C462AAC19D84BA0DB5PR07MB1237eurp_-- From nobody Sun Jul 23 06:03: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 A5E1D1270B4 for ; Sun, 23 Jul 2017 06:03:20 -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, RP_MATCHES_RCVD=-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=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 6tICmTW1XDbt for ; Sun, 23 Jul 2017 06:03:18 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 00460129AA8 for ; Sun, 23 Jul 2017 06:03:17 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i6so3516126ywb.1 for ; Sun, 23 Jul 2017 06:03:17 -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=7lFBCL+9el1p0YPssZQ3EfWNVVi8B/9uwxjxvvXxNSM=; b=sP1gc0kKCu41A6una1MRkBlXSH0LiJfvVU3aQi01LOxmiOgbucLhg5nBUzZCEXsjct P65js/y90xWkd/S4lEODlIa1szljU+bv0Q2zp86IWPCoIiU7z911qTg1oBhSi/lxdL4u j7t3fDd0kqD5xVgbiJyBVVUs0lwDES4ZmU3ju598vCnPhAalGW1D8hcs3jFFo9f8ZXCd ZA3wKM5d3xirzZTzWzYFCQnFBQBcmJjpbljoYk06kJPCszXNuCbXLTBuebrPpu7vFf9U XTvWp/ciW0JmmazBg5etK7Dk1ffqZlxg18AK1HSwCawFvBUwphpjpl3n+g4wivXVXrEO IVDA== 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=7lFBCL+9el1p0YPssZQ3EfWNVVi8B/9uwxjxvvXxNSM=; b=Q3qCL7yGjisV3LLvPkRctx5sdj++fnZCKfnLd8HN3IMnOBGivtPeMJc9/4J5p0pfH6 RfWMW26hQwVw3ary5X6YSyIoEHZCBFMcKRH+lK36LDfbuElqkRn0IHXvT6UJJ8lrkLcM 2Z4DZLSV6XtWOZ/8v7BNbnan8PwyritzZUlv7RKtiuGbIeH0ZlvVVWsi41YyPE2il/3Q 9YBuvzentzlqEyfUest3/1w4UkxHraN8DySdIMy/1kDY9gonq9P7E6201Jk2auXbeBPM V6t/dgs8O2YPHVftrqTDZiKqua1SfCG5mox2k0EYTGVRkQ0mioB3EWAkct7D28JXQv/t HKNA== X-Gm-Message-State: AIVw112gHjKK4/1vCPA1hW3NGf2r8i3N7GIua7WXOI8pkUnOlgucoVqI MPP8nH49+MBovcMMYV44hTiz0BDDX2jh X-Received: by 10.129.92.3 with SMTP id q3mr10845073ywb.298.1500814996955; Sun, 23 Jul 2017 06:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.163.130 with HTTP; Sun, 23 Jul 2017 06:02:56 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> From: Ian Swett Date: Sun, 23 Jul 2017 09:02:56 -0400 Message-ID: Subject: Re: HTTP requests on one stream #692 To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" Cc: "Philipp S. Tiesel" , Lucas Pardue , Mike Bishop , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114d6f02c508e20554fbb894" 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, 23 Jul 2017 13:03:21 -0000 --001a114d6f02c508e20554fbb894 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: > A few comments linline. > > > > Thomas > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* 23 July 2017 10:59 > *To:* Philipp S. Tiesel > *Cc:* Lucas Pardue ; Mike Bishop < > Michael.Bishop@microsoft.com>; IETF QUIC WG > *Subject:* Re: HTTP requests on one stream #692 > > > > A few comments on unreliable streams in QUIC, and this may be a longer > discussion and I'd be curious to read the considerations you have in mind= . > > > > QUIC as specified today definitely enables unreliability. For example, I > can send stream data once, and if some portion of it is lost, at that poi= nt > I can decide if I want to retransmit it or just cancel the stream. > > *[Thomas Swindells] As stream frames contain the offset client > potentially also has the option of just acknowledging reception even it > didn=E2=80=99t actually receive them - though obviously this would and ca= use > problems if non-stream frames were also being acknowledged when in fact t= he > client hadn=E2=80=99t acknowledge them. .* > This is prohibited currently, and for good reason, since acking packets you haven't received breaks congestion control and potentially flow control. Also, you'd be assuming what was in the packets was what you expected, and if you were wrong, it could go really poorly. ie: imagine if you acked a packet containing QPACK compression context, but didn't receive it. The connection would then be in a completely invalid state. > I generally consider unreliability to be a matter of sender side policy. > > *[Thomas Swindells] I don=E2=80=99t think I agree with that. Often it is = the > client which has the knowledge about whether data is or is not important. > Live video streaming is the best example for this, if the client has enou= gh > buffer and is playing the output out live then it would prefer to get the > data re-transmitted, however data over a certain age isn=E2=80=99t useful= and it > may prefer to lose some frames and jump back up to live. However if the > client is actually recording the output (or has a longer buffer) it may > prefer to stall and get all the data.* > > > This is definitely an interesting use case and one I think should be in scope for HTTP over QUIC. However, at the end of the day the server needs to send what the client wants, so it's better to inform the server what to send than trick it. Given we're discussing HTTP, ideally the HTTP/2 priorities + cancellation would provide what you need, but I'll admit at the moment it's not a natural mapping. > Making this work well may require a more robust interface between the > application and QUIC stream, or may just require some new features, we'll > see. I can't think of anything about moving from 2 to 1 streams changes > this, especially given the new header compression schemes will allow > cancellation of the headers as well as the payload, unlike before. > > > > > > > > > > On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel > wrote: > > Hi, > > > > too bad that I missed that discussion. > > > > Separating DATA and Request/Response to different streams would be > beneficial if we add unreliable streams. I will try to write up something > (at least considerations) before the interim. > > > > > > On 22. Jul 2017, at 03:04, Mike Bishop > wrote: > > > > No, the consensus both in Paris and Prague was a single stream, which > means the DATA frame is back to stay. The HPACK-without-dynamic-table > piece is temporary, until we pick a direction for header compression. > > > > Sent from my Windows 10 phone > > > > *From: *Lucas Pardue > *Sent: *Friday, July 21, 2017 8:20 AM > *To: *IETF QUIC WG > *Subject: *HTTP requests on one stream #692 > > > > Hi, > > > > Apologies if this was discussed already in Prague but I=E2=80=99d like so= me > clarification on the intended lifetime scope of the changes in PR#692 > > . > > > > 1. Is the intention that this change unblocks specification / > development so that the WG can continue? > 2. Will these changes be unwound once progress has been made? > > > 1. The DATA frame has been resurrected (I presume to demark frames in > the same stream). Will it be struck with a wooden stake in the futu= re, or > continue to hang around? > > > > Thanks > > Lucas > > > > AVE! > Philipp S. Tiesel / phils=E2=80=A6 > -- > {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 <+49%20179%206737439>)---<---(jabber: > phils@in-panik.de)----' > > > > > --001a114d6f02c508e20554fbb894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (Nokia - GB/Cambridge, U= K) <thomas.swindells@nokia.com> wrote:

A few comments linline.

=C2=A0

Thomas

=C2=A0

From: = QUIC [mailto:qui= c-bounces@ietf.org] On Behalf Of Ian Swett
Sent: 23 July 2017 10:59
To: Philipp S. Tiesel <phils@in-panik.de>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Mike Bishop <Michael.Bishop@microsof= t.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: HTTP requests on one stream #692

=C2=A0

A few comments on unreliable streams in QUIC, and th= is may be a longer discussion and I'd be curious to read the considerat= ions you have in mind.

=C2=A0

QUIC as specified today definitely enables unreliabi= lity.=C2=A0 For example, I can send stream data once, and if some portion o= f it is lost, at that point I can decide if I want to retransmit it or just= cancel the stream.=C2=A0

[Thomas Swindells] As stream frames co= ntain the offset =C2=A0client potentially also has the option of just ackno= wledging reception even it didn=E2=80=99t actually receive them - though obviously this would and cause problems if non-stream frames were a= lso being acknowledged when in fact the client hadn=E2=80=99t acknowledge t= hem. .
This is prohibited currently, and for good reason, since ackin= g packets you haven't received breaks congestion control and potentiall= y flow control.=C2=A0 Also, you'd be assuming what was in the packets w= as what you expected, and=C2=A0 if you were wrong, it could go really poorl= y.=C2=A0 ie: imagine if you acked a packet containing QPACK compression con= text, but didn't receive it.=C2=A0 The connection would then be in a co= mpletely invalid state.
=C2=A0
<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">=

I generally consider unreliability to be a matter of= sender side policy.

[Thomas Swindells] I don=E2=80=99t thi= nk I agree with that. Often it is the client which has the knowledge about = whether data is or is not important. Live video streaming is the best example for this, if the client has enough buffer and is playing = the output out live then it would prefer to get the data re-transmitted, ho= wever data over a certain age isn=E2=80=99t useful and it may prefer to los= e some frames and jump back up to live. However if the client is actually recording the output (or has a longer bu= ffer) it may prefer to stall and get all the data.

=C2=A0

This is definitely an interesting u= se case and one I think should be in scope for HTTP over QUIC.=C2=A0 Howeve= r, at the end of the day the server needs to send what the client wants, so= it's better to inform the server what to send than trick it.=C2=A0 Giv= en we're discussing HTTP, ideally the HTTP/2 priorities + cancellation = would provide what you need, but I'll admit at the moment it's not = a natural mapping.
=C2=A0

Making this work well may require a more robust inte= rface between the application and QUIC stream, or may just require some new= features, we'll see.=C2=A0 I can't think of anything about moving = from 2 to 1 streams changes this, especially given the new header compression schemes will allow cancellation of the headers = as well as the payload, unlike before.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel &= lt;phils@in-panik.de= > wrote:

Hi,

=C2=A0

too bad that I missed that discussion.=C2=A0<= u>

=C2=A0

Separating DATA and Request/Response to different st= reams would be beneficial if we add unreliable streams. I will try to write= up something (at least considerations) before the interim.=C2=A0=

=C2=A0

=C2=A0

On 22. Jul 2017, at 03:04, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

=C2=A0

No, the consensus both in Paris and Prague was a si= ngle stream, which means the DATA frame is back to stay.=C2=A0 The HPACK-wi= thout-dynamic-table piece is temporary, until we pick a direction for header compression.

=C2=A0

Sent from my Windows 10 phone<= /p>

=C2=A0

From:=C2=A0Lucas Pardue
Sent:=C2=A0Friday, July 21, 2017 8:20 AM
To:=C2=A0IETF QUIC WG
Subject:=C2=A0HTTP requests on one stream #692

=C2=A0

Hi,

=C2=A0

Apologies if this was discussed already in Prague b= ut I=E2=80=99d like some clarification on the intended lifetime scope of th= e changes in=C2=A0PR#692.=C2=A0

=C2=A0

Is the intention that th= is change unblocks specification / development so that the WG can continue?=
Will these changes be unwound once progress has been made?<= /span>

The DATA frame has been = resurrected (I presume to demark frames in the same stream). Will it be str= uck with a wooden stake in the future, or continue to hang around?

=C2=A0

Thanks

Lucas

=C2=A0

AVE!
=C2=A0 Philipp S. Tiesel / phils=E2=80=A6
--=C2=A0
=C2=A0 =C2=A0{phils}--->---= (phils= @in-panik.de)--->---(http://phils.in-panik.de)----,
=C2=A0 =C2=A0 =C2=A0 wenn w ei= ne =C2=A0 aube ist dn =C2=A0 =C2=A0 =C2=A0man au dran dre en =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=A0o =C2=A0 =C2=A0 Schr =C2=A0 =C2=A0 =C2=A0 =C2=A0an muss =C2=A0= =C2=A0 hc =C2=A0 =C2=A0 =C2=A0 =C2=A0 h =C2=A0 (Kurt Schwitters) |<= br> :wq! =C2=A0<----(phone: +49-179-67= 37439)---<---(jabber: phils@= in-panik.de)----'<= u>

=C2=A0

=C2=A0

--001a114d6f02c508e20554fbb894-- From nobody Sun Jul 23 09:04:00 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 85B2B12714F for ; Sun, 23 Jul 2017 09:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 BBCMAO02GeYS for ; Sun, 23 Jul 2017 09:03:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A457D12704A for ; Sun, 23 Jul 2017 09:03:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9FBADBE2C; Sun, 23 Jul 2017 17:03:53 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8TzBcWjqfu3; Sun, 23 Jul 2017 17:03:52 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 40068BE24; Sun, 23 Jul 2017 17:03:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500825832; bh=OlOF+m/umWMFsbpMKPzbYqvpXdnG5mf0gzvZuw3n/ZY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=p5kN6771gWqjVcPtMVm+pjlH+EqR78Aull98pVL4FyYy43TWAZURXvqwjm+B2Rn0r qSDeiaw1z0ypVhVW+0SVmY+Cghc2B7B4MFrG+pfPF4Qo0kE+yR3mK4rhqor6+zgXLr i0JBO6iXzBxAnDJ8nw9c5aKZclC/dC7JOaoY0B+8= Subject: Re: Randomizer state attacks To: Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Martin Thomson Cc: IETF QUIC WG , Ryan Hamilton References: <80c7cebc-30f1-79a3-3503-224b97d27377@huitema.net> <6bc0beec-8353-1dd2-b743-2fb3fab9f152@cs.tcd.ie> <7fe2f1dd-a1c1-e55f-860b-fdc3c54f3504@cs.tcd.ie> <37ea6f22-5a55-0248-fdbf-1db6d4ef14a7@cs.tcd.ie> <6560224e-9453-5809-cfe7-932b41643c6a@huitema.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <96c6b185-f8dd-a3b8-68d7-2f83ac50ba38@cs.tcd.ie> Date: Sun, 23 Jul 2017 17:03:51 +0100 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: <6560224e-9453-5809-cfe7-932b41643c6a@huitema.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4gPSKxdIKIeK6vvaHc3BPtv02gTS9WGBt" 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, 23 Jul 2017 16:03:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4gPSKxdIKIeK6vvaHc3BPtv02gTS9WGBt Content-Type: multipart/mixed; boundary="olewipthLqgGAhGAvqBam0un5Pmc19G2m"; protected-headers="v1" From: Stephen Farrell To: Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Martin Thomson Cc: IETF QUIC WG , Ryan Hamilton Message-ID: <96c6b185-f8dd-a3b8-68d7-2f83ac50ba38@cs.tcd.ie> Subject: Re: Randomizer state attacks References: <80c7cebc-30f1-79a3-3503-224b97d27377@huitema.net> <6bc0beec-8353-1dd2-b743-2fb3fab9f152@cs.tcd.ie> <7fe2f1dd-a1c1-e55f-860b-fdc3c54f3504@cs.tcd.ie> <37ea6f22-5a55-0248-fdbf-1db6d4ef14a7@cs.tcd.ie> <6560224e-9453-5809-cfe7-932b41643c6a@huitema.net> In-Reply-To: <6560224e-9453-5809-cfe7-932b41643c6a@huitema.net> --olewipthLqgGAhGAvqBam0un5Pmc19G2m Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 23/07/17 01:33, Christian Huitema wrote: >=20 >=20 > On 7/22/2017 10:58 AM, Stephen Farrell wrote: >> >> On 22/07/17 17:43, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >>> So there plenty of pitfalls, but requiring that the QUIC implementati= on to >>> protect against bad PRNG rather than the crypto library seems wrong t= o me. >>> Granted, you don=E2=80=99t need to make the protocol more vulnerable = than >>> necessary, and indeed, I have also thought about all these random val= ues >>> being released into the wild is an easy way to make serious crypto mi= stakes. >> I'd assert that lack of entropy or a significantly imperfect prng >> is a different issue, compared to the dual-ec attack... > Stephen, from our previous discussions, I conclude that you are looking= > at some kind of "defense in depth". If the local PRNG is robust, there= > is not much risk in disclosing random numbers in connection ID, initial= > sequence numbers or nonce. But we don't always know that the PRNG is > robust. In the Dual-EC case, implementers believed it was, when in fact= > it was not. The defense in depth argument is that we should somehow > control the random values published in clear text, so that even if the > PRNG happens to be weak, the weakness will be difficult to exploit. > Also, long random fields in protocol messages can be abused as side > channels. Correct. >=20 > On the other hand, nonce and other random fields are useful to prevent= > off path attacks. >=20 Also correct. > Also, QUIC relies on TLS 1.3. The TLS 1.3 Client Hello and Server Hello= > are sent in clear text. Both carry a 32 byte random field.=20 Yeah, I'll take a peek back at the TLS list/git repo to see why what's changed from 28->32. I forget tbh. > Even if QUIC > did not use 12 bytes used in QUIC for Connection ID and Initial Sequenc= e > Number, TLS would still use 32 bytes, which would be plenty for dual-EC= > style attacks. So I am not sure that we should pile a lot of complexity= > in QUIC to mitigate random number disclosure. I agree that adding a "lot of complexity" would be wrong. OTOH, the dual-ec attack is real and has been attempted multiple times in multiple ways (bsafe & juniper), so the attacker in that case appears not to have stopped attacking. So doing the analysis is worthwhile. Maybe the right thing for now is to open an issue to check the protocol vs. dual-ec attacks? S. >=20 > -- Christian Huitema > =20 >=20 > =20 >=20 > =20 >=20 --olewipthLqgGAhGAvqBam0un5Pmc19G2m-- --4gPSKxdIKIeK6vvaHc3BPtv02gTS9WGBt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZdMjnAAoJEC88hzaAX42ijGoH+wZQzLwUjZxJninTNB0eUgW+ gmBFGW44BqabVT37LIQol7odATWDseiPBDf/5SPPFElT8ZBsGlQZnGlOUSkwfNXq PtdmRcf+GCwcMhVPHyUgqLiFxFc8v9jBLOAfrNVlyAnkKcS8NGWdsa46fw7ukmui BehTXpN0X7PQCoqakbi6+u/T5TBqQMmAygjHTy5XJH8oKKeUKfXvrC1k07KIgQHt FheexBi7bI8a0Xy2Vg598qA+W3fKVE5OS+rJdb/Gytn5V6zeUco9KuKrNbhNoGdu NEbTs/18NaHMsTtAZ+m3WFymsbsT+IhUQwORh7lGSi90bba1dtcrl4JF2SaTpbg= =8Ylb -----END PGP SIGNATURE----- --4gPSKxdIKIeK6vvaHc3BPtv02gTS9WGBt-- From nobody Sun Jul 23 11:29: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 C9D1C131600 for ; Sun, 23 Jul 2017 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=nokia.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 1m5fTm2lw7iC for ; Sun, 23 Jul 2017 11:29:10 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0127.outbound.protection.outlook.com [104.47.2.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 6FDDD131471 for ; Sun, 23 Jul 2017 11:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TmI6j1EXS0/HC55DelOw37fa3hP3g6n1WBSxuDv2VRY=; b=UL7RBjDx7rIX5VahgHu45o1xla4HQKU9UGnwMC6WHLxi2N/OLfpMgQ5kGsJck2+uevABRTRzrivQCSpRP07LCbUkJf2Hw7OUfBBWKYej/tIlZ8qLnkNDMaO1fgYqgk1Z1TX5tCJQ4dk9Mp1DOgwU0fF284dhW+APe9WG2S2I4d8= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB1607.eurprd07.prod.outlook.com (10.166.12.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Sun, 23 Jul 2017 18:29:06 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354%13]) with mapi id 15.01.1304.011; Sun, 23 Jul 2017 18:29:06 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Ian Swett CC: "Philipp S. Tiesel" , Lucas Pardue , Mike Bishop , "IETF QUIC WG" Subject: RE: HTTP requests on one stream #692 Thread-Topic: HTTP requests on one stream #692 Thread-Index: AdMCNJiq1/jFQyapRDqdWSVpnV2UvgAUdAmMAELNc4AAAid+AAAA+mRQAAV2kgAAANuvsA== Date: Sun, 23 Jul 2017 18:29:06 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; x-originating-ip: [82.69.101.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB1607; 7:VCh7SYSmiTJduWucl23uJ714Bbz2YZNqPefjxfu3lTwKbbpWW5ZIE1HYD2QylmR2L/irNc8cUwaGlAVwRmYnDv+AdLsjXzAnVCUID248SZ3Da4cHupG9y0HttzKioTHSFG8m98QUG6aHKcAqK0B3mFfSLHKHgTebR3JeFKzS9RF99+4N8IebOFVpRdvJlQ/xwLYIH0NXj1pZ4F2GYgOynC/LfsfEfHC7U+77NK0LtTd4HX2FWLPuYxAA9fpupveu81pxi9AHBFGegeqSDx6OAMoVgHBHMOEm8OppZ5v3aLlIQTIqlhYDpvwmYa2GdP9BecMuXlCkBROVBvp2bJVtSmjG1ZUGqxbNAIi1C4wQGIPf2xVjBkeXQmPrJ6WmSXJiJF9XvUNMc5l5LQEnnDY58zzaaJo8IqDdjCSSIzdxk97uYUOsKBBZi+1WVQvoUhwuRSdndvWJXIIx+IC4V0asW0r1x31lzizTHmlNKVPwvs36ilCAU+tGyuRQRI2VhJ86hANSM70ytefKUXyrXDzO8D27UhBTeviDfr79dULz+5/2fzcsjkEvntjqJYG0OuTEu70lCsw0nKqRbe/YcWsBgW/6xq4xcoQhWisZl6GuTQ7eUEQGJ+1QOtXSmca3WdmHm3lOpIgU5F2Tf2N67cBlB0VaA7p5N00iXMI70mLQsFc6oOoGZ594/7zue8msC+S7ad01yvpt8yCjPqIWZ6EDDcpwWbHJ48cK3UGMk6/xHbZ14oKX9DgbH6WImsbF6eGGiV/9eBMYtM2bSU24rtzsHMmuq2QbhF1fXL3MGfNcS8w= x-ms-office365-filtering-correlation-id: 7c38e23e-1f40-4eb4-83d4-08d4d1f8b3ab x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB1607; x-ms-traffictypediagnostic: DB5PR07MB1607: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(189930954265078)(82608151540597)(211936372134217)(100405760836317)(219752817060721)(127952516941037)(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)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(920507026)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1607; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1607; x-forefront-prvs: 0377802854 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(377454003)(199003)(24454002)(189002)(2906002)(8666007)(9686003)(5660300001)(236005)(229853002)(3660700001)(55016002)(4326008)(54906002)(6306002)(54896002)(99286003)(6506006)(6436002)(3280700002)(53386004)(38730400002)(6116002)(3846002)(102836003)(790700001)(8676002)(2950100002)(6916009)(2900100001)(110136004)(189998001)(97736004)(6246003)(7736002)(7696004)(53936002)(68736007)(5250100002)(54356999)(14454004)(50986999)(106356001)(105586002)(25786009)(8936002)(81156014)(81166006)(101416001)(66066001)(93886004)(53546010)(76176999)(45080400002)(74316002)(86362001)(478600001)(33656002)(606006)(34040400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1607; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB1237A77FC6F791C1A95239F784BA0DB5PR07MB1237eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2017 18:29:06.1132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1607 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, 23 Jul 2017 18:29:13 -0000 --_000_DB5PR07MB1237A77FC6F791C1A95239F784BA0DB5PR07MB1237eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IGJsaW5kbHkgYWNraW5nIHBhY2tldHMgd291bGQgY2F1c2UgYmlnIHByb2Js ZW1zIHdpdGggdGhlIGN1cnJlbnQgb3BlcmF0aW9ucy4gQnV0IHBlcmhhcHMgaWYvd2hlbiB3ZSBn ZXQgb250byB1bnJlbGlhYmxlIHN0cmVhbXMgYSB3YXkgdG8gZXhwbGljaXRseSBuYWNrIHBhY2tl dHMgYnV0IHN0YXRlIGRvbuKAmXQgYm90aGVyIHJldHJhbnNtaXR0aW5nIHRoZSBvbmVzIGZvciBz dHJlYW0geCB3b3VsZCBiZSBhIHBvdGVudGlhbCBtZWNoYW5pc20/DQoNClRob21hcw0KDQpGcm9t OiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KU2VudDogMjMgSnVseSAy MDE3IDE0OjAzDQpUbzogU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBV SykgPHRob21hcy5zd2luZGVsbHNAbm9raWEuY29tPg0KQ2M6IFBoaWxpcHAgUy4gVGllc2VsIDxw aGlsc0Bpbi1wYW5pay5kZT47IEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5jby51az47 IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPjsgSUVURiBRVUlDIFdH IDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEhUVFAgcmVxdWVzdHMgb24gb25lIHN0cmVh bSAjNjkyDQoNCg0KT24gU3VuLCBKdWwgMjMsIDIwMTcgYXQgNzo1NyBBTSwgU3dpbmRlbGxzLCBU aG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSykgPHRob21hcy5zd2luZGVsbHNAbm9raWEu Y29tPG1haWx0bzp0aG9tYXMuc3dpbmRlbGxzQG5va2lhLmNvbT4+IHdyb3RlOg0KQSBmZXcgY29t bWVudHMgbGlubGluZS4NCg0KVGhvbWFzDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBJ YW4gU3dldHQNClNlbnQ6IDIzIEp1bHkgMjAxNyAxMDo1OQ0KVG86IFBoaWxpcHAgUy4gVGllc2Vs IDxwaGlsc0Bpbi1wYW5pay5kZTxtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGU+Pg0KQ2M6IEx1Y2Fz IFBhcmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5jby51azxtYWlsdG86THVjYXMuUGFyZHVlQGJiYy5j by51az4+OyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IEhUVFAgcmVxdWVzdHMgb24g b25lIHN0cmVhbSAjNjkyDQoNCkEgZmV3IGNvbW1lbnRzIG9uIHVucmVsaWFibGUgc3RyZWFtcyBp biBRVUlDLCBhbmQgdGhpcyBtYXkgYmUgYSBsb25nZXIgZGlzY3Vzc2lvbiBhbmQgSSdkIGJlIGN1 cmlvdXMgdG8gcmVhZCB0aGUgY29uc2lkZXJhdGlvbnMgeW91IGhhdmUgaW4gbWluZC4NCg0KUVVJ QyBhcyBzcGVjaWZpZWQgdG9kYXkgZGVmaW5pdGVseSBlbmFibGVzIHVucmVsaWFiaWxpdHkuICBG b3IgZXhhbXBsZSwgSSBjYW4gc2VuZCBzdHJlYW0gZGF0YSBvbmNlLCBhbmQgaWYgc29tZSBwb3J0 aW9uIG9mIGl0IGlzIGxvc3QsIGF0IHRoYXQgcG9pbnQgSSBjYW4gZGVjaWRlIGlmIEkgd2FudCB0 byByZXRyYW5zbWl0IGl0IG9yIGp1c3QgY2FuY2VsIHRoZSBzdHJlYW0uDQpbVGhvbWFzIFN3aW5k ZWxsc10gQXMgc3RyZWFtIGZyYW1lcyBjb250YWluIHRoZSBvZmZzZXQgIGNsaWVudCBwb3RlbnRp YWxseSBhbHNvIGhhcyB0aGUgb3B0aW9uIG9mIGp1c3QgYWNrbm93bGVkZ2luZyByZWNlcHRpb24g ZXZlbiBpdCBkaWRu4oCZdCBhY3R1YWxseSByZWNlaXZlIHRoZW0gLSB0aG91Z2ggb2J2aW91c2x5 IHRoaXMgd291bGQgYW5kIGNhdXNlIHByb2JsZW1zIGlmIG5vbi1zdHJlYW0gZnJhbWVzIHdlcmUg YWxzbyBiZWluZyBhY2tub3dsZWRnZWQgd2hlbiBpbiBmYWN0IHRoZSBjbGllbnQgaGFkbuKAmXQg YWNrbm93bGVkZ2UgdGhlbS4gLg0KDQpUaGlzIGlzIHByb2hpYml0ZWQgY3VycmVudGx5LCBhbmQg Zm9yIGdvb2QgcmVhc29uLCBzaW5jZSBhY2tpbmcgcGFja2V0cyB5b3UgaGF2ZW4ndCByZWNlaXZl ZCBicmVha3MgY29uZ2VzdGlvbiBjb250cm9sIGFuZCBwb3RlbnRpYWxseSBmbG93IGNvbnRyb2wu ICBBbHNvLCB5b3UnZCBiZSBhc3N1bWluZyB3aGF0IHdhcyBpbiB0aGUgcGFja2V0cyB3YXMgd2hh dCB5b3UgZXhwZWN0ZWQsIGFuZCAgaWYgeW91IHdlcmUgd3JvbmcsIGl0IGNvdWxkIGdvIHJlYWxs eSBwb29ybHkuICBpZTogaW1hZ2luZSBpZiB5b3UgYWNrZWQgYSBwYWNrZXQgY29udGFpbmluZyBR UEFDSyBjb21wcmVzc2lvbiBjb250ZXh0LCBidXQgZGlkbid0IHJlY2VpdmUgaXQuICBUaGUgY29u bmVjdGlvbiB3b3VsZCB0aGVuIGJlIGluIGEgY29tcGxldGVseSBpbnZhbGlkIHN0YXRlLg0KDQpJ IGdlbmVyYWxseSBjb25zaWRlciB1bnJlbGlhYmlsaXR5IHRvIGJlIGEgbWF0dGVyIG9mIHNlbmRl ciBzaWRlIHBvbGljeS4NCltUaG9tYXMgU3dpbmRlbGxzXSBJIGRvbuKAmXQgdGhpbmsgSSBhZ3Jl ZSB3aXRoIHRoYXQuIE9mdGVuIGl0IGlzIHRoZSBjbGllbnQgd2hpY2ggaGFzIHRoZSBrbm93bGVk Z2UgYWJvdXQgd2hldGhlciBkYXRhIGlzIG9yIGlzIG5vdCBpbXBvcnRhbnQuIExpdmUgdmlkZW8g c3RyZWFtaW5nIGlzIHRoZSBiZXN0IGV4YW1wbGUgZm9yIHRoaXMsIGlmIHRoZSBjbGllbnQgaGFz IGVub3VnaCBidWZmZXIgYW5kIGlzIHBsYXlpbmcgdGhlIG91dHB1dCBvdXQgbGl2ZSB0aGVuIGl0 IHdvdWxkIHByZWZlciB0byBnZXQgdGhlIGRhdGEgcmUtdHJhbnNtaXR0ZWQsIGhvd2V2ZXIgZGF0 YSBvdmVyIGEgY2VydGFpbiBhZ2UgaXNu4oCZdCB1c2VmdWwgYW5kIGl0IG1heSBwcmVmZXIgdG8g bG9zZSBzb21lIGZyYW1lcyBhbmQganVtcCBiYWNrIHVwIHRvIGxpdmUuIEhvd2V2ZXIgaWYgdGhl IGNsaWVudCBpcyBhY3R1YWxseSByZWNvcmRpbmcgdGhlIG91dHB1dCAob3IgaGFzIGEgbG9uZ2Vy IGJ1ZmZlcikgaXQgbWF5IHByZWZlciB0byBzdGFsbCBhbmQgZ2V0IGFsbCB0aGUgZGF0YS4NCg0K DQpUaGlzIGlzIGRlZmluaXRlbHkgYW4gaW50ZXJlc3RpbmcgdXNlIGNhc2UgYW5kIG9uZSBJIHRo aW5rIHNob3VsZCBiZSBpbiBzY29wZSBmb3IgSFRUUCBvdmVyIFFVSUMuICBIb3dldmVyLCBhdCB0 aGUgZW5kIG9mIHRoZSBkYXkgdGhlIHNlcnZlciBuZWVkcyB0byBzZW5kIHdoYXQgdGhlIGNsaWVu dCB3YW50cywgc28gaXQncyBiZXR0ZXIgdG8gaW5mb3JtIHRoZSBzZXJ2ZXIgd2hhdCB0byBzZW5k IHRoYW4gdHJpY2sgaXQuICBHaXZlbiB3ZSdyZSBkaXNjdXNzaW5nIEhUVFAsIGlkZWFsbHkgdGhl IEhUVFAvMiBwcmlvcml0aWVzICsgY2FuY2VsbGF0aW9uIHdvdWxkIHByb3ZpZGUgd2hhdCB5b3Ug bmVlZCwgYnV0IEknbGwgYWRtaXQgYXQgdGhlIG1vbWVudCBpdCdzIG5vdCBhIG5hdHVyYWwgbWFw cGluZy4NCg0KTWFraW5nIHRoaXMgd29yayB3ZWxsIG1heSByZXF1aXJlIGEgbW9yZSByb2J1c3Qg aW50ZXJmYWNlIGJldHdlZW4gdGhlIGFwcGxpY2F0aW9uIGFuZCBRVUlDIHN0cmVhbSwgb3IgbWF5 IGp1c3QgcmVxdWlyZSBzb21lIG5ldyBmZWF0dXJlcywgd2UnbGwgc2VlLiAgSSBjYW4ndCB0aGlu ayBvZiBhbnl0aGluZyBhYm91dCBtb3ZpbmcgZnJvbSAyIHRvIDEgc3RyZWFtcyBjaGFuZ2VzIHRo aXMsIGVzcGVjaWFsbHkgZ2l2ZW4gdGhlIG5ldyBoZWFkZXIgY29tcHJlc3Npb24gc2NoZW1lcyB3 aWxsIGFsbG93IGNhbmNlbGxhdGlvbiBvZiB0aGUgaGVhZGVycyBhcyB3ZWxsIGFzIHRoZSBwYXls b2FkLCB1bmxpa2UgYmVmb3JlLg0KDQoNCg0KDQpPbiBTdW4sIEp1bCAyMywgMjAxNyBhdCA0OjU2 IEFNLCBQaGlsaXBwIFMuIFRpZXNlbCA8cGhpbHNAaW4tcGFuaWsuZGU8bWFpbHRvOnBoaWxzQGlu LXBhbmlrLmRlPj4gd3JvdGU6DQpIaSwNCg0KdG9vIGJhZCB0aGF0IEkgbWlzc2VkIHRoYXQgZGlz Y3Vzc2lvbi4NCg0KU2VwYXJhdGluZyBEQVRBIGFuZCBSZXF1ZXN0L1Jlc3BvbnNlIHRvIGRpZmZl cmVudCBzdHJlYW1zIHdvdWxkIGJlIGJlbmVmaWNpYWwgaWYgd2UgYWRkIHVucmVsaWFibGUgc3Ry ZWFtcy4gSSB3aWxsIHRyeSB0byB3cml0ZSB1cCBzb21ldGhpbmcgKGF0IGxlYXN0IGNvbnNpZGVy YXRpb25zKSBiZWZvcmUgdGhlIGludGVyaW0uDQoNCg0KT24gMjIuIEp1bCAyMDE3LCBhdCAwMzow NCwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KTm8sIHRoZSBjb25zZW5zdXMgYm90 aCBpbiBQYXJpcyBhbmQgUHJhZ3VlIHdhcyBhIHNpbmdsZSBzdHJlYW0sIHdoaWNoIG1lYW5zIHRo ZSBEQVRBIGZyYW1lIGlzIGJhY2sgdG8gc3RheS4gIFRoZSBIUEFDSy13aXRob3V0LWR5bmFtaWMt dGFibGUgcGllY2UgaXMgdGVtcG9yYXJ5LCB1bnRpbCB3ZSBwaWNrIGEgZGlyZWN0aW9uIGZvciBo ZWFkZXIgY29tcHJlc3Npb24uDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIDEwIHBob25lDQoNCkZy b206IEx1Y2FzIFBhcmR1ZTxtYWlsdG86THVjYXMuUGFyZHVlQGJiYy5jby51az4NClNlbnQ6IEZy aWRheSwgSnVseSAyMSwgMjAxNyA4OjIwIEFNDQpUbzogSUVURiBRVUlDIFdHPG1haWx0bzpxdWlj QGlldGYub3JnPg0KU3ViamVjdDogSFRUUCByZXF1ZXN0cyBvbiBvbmUgc3RyZWFtICM2OTINCg0K SGksDQoNCkFwb2xvZ2llcyBpZiB0aGlzIHdhcyBkaXNjdXNzZWQgYWxyZWFkeSBpbiBQcmFndWUg YnV0IEnigJlkIGxpa2Ugc29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBpbnRlbmRlZCBsaWZldGlt ZSBzY29wZSBvZiB0aGUgY2hhbmdlcyBpbiBQUiM2OTI8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGcXVp Y3dnJTJGYmFzZS1kcmFmdHMlMkZwdWxsJTJGNjkyJTJGZmlsZXMmZGF0YT0wMiU3QzAxJTdDbWlj aGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDMWE2Njg3M2VjOTgzNDk3YmY3ZGUwOGQ0ZDA0 YzAzMjYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzYy NDcyMjgzNDE1MzQ3JnNkYXRhPWRaTVhwaUNZbzViN3RWdUtyYkpDc25hUFA0Mm1xUlZpJTJCM3g0 Z2FyV3J2SSUzRCZyZXNlcnZlZD0wPi4NCg0KDQogIDEuICBJcyB0aGUgaW50ZW50aW9uIHRoYXQg dGhpcyBjaGFuZ2UgdW5ibG9ja3Mgc3BlY2lmaWNhdGlvbiAvIGRldmVsb3BtZW50IHNvIHRoYXQg dGhlIFdHIGNhbiBjb250aW51ZT8NCiAgMi4gIFdpbGwgdGhlc2UgY2hhbmdlcyBiZSB1bndvdW5k IG9uY2UgcHJvZ3Jlc3MgaGFzIGJlZW4gbWFkZT8NCg0KICAgICAqICAgVGhlIERBVEEgZnJhbWUg aGFzIGJlZW4gcmVzdXJyZWN0ZWQgKEkgcHJlc3VtZSB0byBkZW1hcmsgZnJhbWVzIGluIHRoZSBz YW1lIHN0cmVhbSkuIFdpbGwgaXQgYmUgc3RydWNrIHdpdGggYSB3b29kZW4gc3Rha2UgaW4gdGhl IGZ1dHVyZSwgb3IgY29udGludWUgdG8gaGFuZyBhcm91bmQ/DQoNClRoYW5rcw0KTHVjYXMNCg0K QVZFIQ0KICBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmDQotLQ0KICAge3BoaWxzfS0tLT4t LS0ocGhpbHNAaW4tcGFuaWsuZGU8bWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlPiktLS0+LS0tKGh0 dHA6Ly9waGlscy5pbi1wYW5pay5kZSktLS0tLA0KICAgICAgd2VubiB3IGVpbmUgICBhdWJlIGlz dCBkbiAgICAgIG1hbiBhdSBkcmFuIGRyZSBlbiAgICAgICAgICAgICAgICAgICB8DQogICAgICAg ICAgIG8gICAgIFNjaHIgICAgICAgIGFuIG11c3MgICAgIGhjICAgICAgICAgaCAgIChLdXJ0IFNj aHdpdHRlcnMpIHwNCjp3cSEgIDwtLS0tKHBob25lOiArNDktMTc5LTY3Mzc0Mzk8dGVsOis0OSUy MDE3OSUyMDY3Mzc0Mzk+KS0tLTwtLS0oamFiYmVyOiBwaGlsc0Bpbi1wYW5pay5kZTxtYWlsdG86 cGhpbHNAaW4tcGFuaWsuZGU+KS0tLS0nDQoNCg0KDQo= --_000_DB5PR07MB1237A77FC6F791C1A95239F784BA0DB5PR07MB1237eurp_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4ubS0yNDc5MTQ5MzM3 MDM1NDg2MDkzbS0yODQ5ODE5OTgyOTcxMDI4MjA1YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21z by1zdHlsZS1uYW1lOm1fLTI0NzkxNDkzMzcwMzU0ODYwOTNtLTI4NDk4MTk5ODI5NzEwMjgyMDVh cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5tLTI0NzkxNDkzMzcwMzU0ODYwOTNob2VuemIN Cgl7bXNvLXN0eWxlLW5hbWU6bV8tMjQ3OTE0OTMzNzAzNTQ4NjA5M2hvZW56Yjt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDo0Mjg3NDUxMjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEzOTUxNzI3MDQ7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoy MTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxDQoJe21z by1saXN0LWlkOjEwNjA1MTQ4OTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc5Nzg3OTIzODt9 DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNjUwMzI4NzI3Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTYzMjIxNzc4ODt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcy LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwy OmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDYN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMy NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MjE0MTcyNjA0OTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTI2NDc0MDIzMDt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFncmVl IHRoYXQgYmxpbmRseSBhY2tpbmcgcGFja2V0cyB3b3VsZCBjYXVzZSBiaWcgcHJvYmxlbXMgd2l0 aCB0aGUgY3VycmVudCBvcGVyYXRpb25zLiBCdXQgcGVyaGFwcyBpZi93aGVuIHdlIGdldCBvbnRv IHVucmVsaWFibGUgc3RyZWFtcyBhIHdheQ0KIHRvIGV4cGxpY2l0bHkgbmFjayBwYWNrZXRzIGJ1 dCBzdGF0ZSBkb27igJl0IGJvdGhlciByZXRyYW5zbWl0dGluZyB0aGUgb25lcyBmb3Igc3RyZWFt IHggd291bGQgYmUgYSBwb3RlbnRpYWwgbWVjaGFuaXNtPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaG9tYXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQg W21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIzIEp1bHkg MjAxNyAxNDowMzxicj4NCjxiPlRvOjwvYj4gU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0gR0Iv Q2FtYnJpZGdlLCBVSykgJmx0O3Rob21hcy5zd2luZGVsbHNAbm9raWEuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gUGhpbGlwcCBTLiBUaWVzZWwgJmx0O3BoaWxzQGluLXBhbmlrLmRlJmd0OzsgTHVj YXMgUGFyZHVlICZsdDtMdWNhcy5QYXJkdWVAYmJjLmNvLnVrJmd0OzsgTWlrZSBCaXNob3AgJmx0 O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBIVFRQIHJlcXVlc3RzIG9uIG9u ZSBzdHJlYW0gIzY5MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gU3VuLCBKdWwgMjMsIDIwMTcgYXQgNzo1NyBBTSwgU3dpbmRlbGxzLCBU aG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9t YXMuc3dpbmRlbGxzQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRob21hcy5zd2luZGVsbHNA bm9raWEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkEgZmV3IGNvbW1lbnRzIGxpbmxpbmUuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UaG9tYXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUVVJQw0K IFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5xdWljLWJvdW5jZXNA aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxiPk9u IEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IDIzIEp1bHkgMjAxNyAx MDo1OTxicj4NCjxiPlRvOjwvYj4gUGhpbGlwcCBTLiBUaWVzZWwgJmx0Ozwvc3Bhbj48YSBocmVm PSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5waGlsc0Bpbi1wYW5pay5kZTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTHVjYXMgUGFyZHVlICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkx1Y2FzLlBhcmR1ZUBiYmMuY28udWsiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5MdWNhcy5QYXJkdWVAYmJjLmNvLnVr PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Ow0KIE1pa2UgQmlz aG9wICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7Ow0KIElFVEYgUVVJQyBXRyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWlj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ cXVpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSFRUUCByZXF1ZXN0cyBvbiBvbmUgc3RyZWFtICM2 OTI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5BIGZldyBjb21tZW50cyBvbiB1bnJlbGlhYmxlIHN0cmVhbXMgaW4gUVVJQywg YW5kIHRoaXMgbWF5IGJlIGEgbG9uZ2VyIGRpc2N1c3Npb24gYW5kIEknZCBiZSBjdXJpb3VzIHRv IHJlYWQgdGhlIGNvbnNpZGVyYXRpb25zIHlvdSBoYXZlIGluIG1pbmQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5RVUlDIGFzIHNwZWNp ZmllZCB0b2RheSBkZWZpbml0ZWx5IGVuYWJsZXMgdW5yZWxpYWJpbGl0eS4mbmJzcDsgRm9yIGV4 YW1wbGUsIEkgY2FuIHNlbmQgc3RyZWFtIGRhdGEgb25jZSwgYW5kIGlmIHNvbWUgcG9ydGlvbiBv ZiBpdCBpcyBsb3N0LCBhdCB0aGF0IHBvaW50IEkgY2FuIGRlY2lkZSBpZiBJIHdhbnQgdG8gcmV0 cmFuc21pdA0KIGl0IG9yIGp1c3QgY2FuY2VsIHRoZSBzdHJlYW0uJm5ic3A7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltUaG9t YXMgU3dpbmRlbGxzXSBBcyBzdHJlYW0gZnJhbWVzIGNvbnRhaW4gdGhlIG9mZnNldCAmbmJzcDtj bGllbnQgcG90ZW50aWFsbHkgYWxzbyBoYXMgdGhlIG9wdGlvbiBvZiBqdXN0IGFja25vd2xlZGdp bmcNCiByZWNlcHRpb24gZXZlbiBpdCBkaWRu4oCZdCBhY3R1YWxseSByZWNlaXZlIHRoZW0gLSB0 aG91Z2ggb2J2aW91c2x5IHRoaXMgd291bGQgYW5kIGNhdXNlIHByb2JsZW1zIGlmIG5vbi1zdHJl YW0gZnJhbWVzIHdlcmUgYWxzbyBiZWluZyBhY2tub3dsZWRnZWQgd2hlbiBpbiBmYWN0IHRoZSBj bGllbnQgaGFkbuKAmXQgYWNrbm93bGVkZ2UgdGhlbS4gLjwvc3Bhbj48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgcHJvaGliaXRlZCBj dXJyZW50bHksIGFuZCBmb3IgZ29vZCByZWFzb24sIHNpbmNlIGFja2luZyBwYWNrZXRzIHlvdSBo YXZlbid0IHJlY2VpdmVkIGJyZWFrcyBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHBvdGVudGlhbGx5 IGZsb3cgY29udHJvbC4mbmJzcDsgQWxzbywgeW91J2QgYmUgYXNzdW1pbmcgd2hhdCB3YXMgaW4g dGhlIHBhY2tldHMgd2FzIHdoYXQgeW91IGV4cGVjdGVkLCBhbmQmbmJzcDsgaWYgeW91IHdlcmUN CiB3cm9uZywgaXQgY291bGQgZ28gcmVhbGx5IHBvb3JseS4mbmJzcDsgaWU6IGltYWdpbmUgaWYg eW91IGFja2VkIGEgcGFja2V0IGNvbnRhaW5pbmcgUVBBQ0sgY29tcHJlc3Npb24gY29udGV4dCwg YnV0IGRpZG4ndCByZWNlaXZlIGl0LiZuYnNwOyBUaGUgY29ubmVjdGlvbiB3b3VsZCB0aGVuIGJl IGluIGEgY29tcGxldGVseSBpbnZhbGlkIHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkkgZ2VuZXJhbGx5IGNvbnNpZGVyIHVucmVsaWFiaWxpdHkgdG8gYmUgYSBt YXR0ZXIgb2Ygc2VuZGVyIHNpZGUgcG9saWN5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltUaG9tYXMgU3dpbmRlbGxzXSBJIGRv buKAmXQgdGhpbmsgSSBhZ3JlZSB3aXRoIHRoYXQuIE9mdGVuIGl0IGlzIHRoZSBjbGllbnQgd2hp Y2ggaGFzIHRoZSBrbm93bGVkZ2UgYWJvdXQgd2hldGhlcg0KIGRhdGEgaXMgb3IgaXMgbm90IGlt cG9ydGFudC4gTGl2ZSB2aWRlbyBzdHJlYW1pbmcgaXMgdGhlIGJlc3QgZXhhbXBsZSBmb3IgdGhp cywgaWYgdGhlIGNsaWVudCBoYXMgZW5vdWdoIGJ1ZmZlciBhbmQgaXMgcGxheWluZyB0aGUgb3V0 cHV0IG91dCBsaXZlIHRoZW4gaXQgd291bGQgcHJlZmVyIHRvIGdldCB0aGUgZGF0YSByZS10cmFu c21pdHRlZCwgaG93ZXZlciBkYXRhIG92ZXIgYSBjZXJ0YWluIGFnZSBpc27igJl0IHVzZWZ1bCBh bmQgaXQgbWF5DQogcHJlZmVyIHRvIGxvc2Ugc29tZSBmcmFtZXMgYW5kIGp1bXAgYmFjayB1cCB0 byBsaXZlLiBIb3dldmVyIGlmIHRoZSBjbGllbnQgaXMgYWN0dWFsbHkgcmVjb3JkaW5nIHRoZSBv dXRwdXQgKG9yIGhhcyBhIGxvbmdlciBidWZmZXIpIGl0IG1heSBwcmVmZXIgdG8gc3RhbGwgYW5k IGdldCBhbGwgdGhlIGRhdGEuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgaXMgZGVmaW5pdGVseSBhbiBpbnRlcmVzdGluZyB1c2UgY2FzZSBhbmQgb25lIEkgdGhpbmsg c2hvdWxkIGJlIGluIHNjb3BlIGZvciBIVFRQIG92ZXIgUVVJQy4mbmJzcDsgSG93ZXZlciwgYXQg dGhlIGVuZCBvZiB0aGUgZGF5IHRoZSBzZXJ2ZXIgbmVlZHMgdG8gc2VuZCB3aGF0IHRoZSBjbGll bnQgd2FudHMsIHNvIGl0J3MgYmV0dGVyIHRvIGluZm9ybSB0aGUgc2VydmVyIHdoYXQgdG8gc2Vu ZCB0aGFuIHRyaWNrDQogaXQuJm5ic3A7IEdpdmVuIHdlJ3JlIGRpc2N1c3NpbmcgSFRUUCwgaWRl YWxseSB0aGUgSFRUUC8yIHByaW9yaXRpZXMgJiM0MzsgY2FuY2VsbGF0aW9uIHdvdWxkIHByb3Zp ZGUgd2hhdCB5b3UgbmVlZCwgYnV0IEknbGwgYWRtaXQgYXQgdGhlIG1vbWVudCBpdCdzIG5vdCBh IG5hdHVyYWwgbWFwcGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk1ha2luZyB0aGlzIHdvcmsgd2VsbCBtYXkgcmVxdWlyZSBhIG1vcmUgcm9i dXN0IGludGVyZmFjZSBiZXR3ZWVuIHRoZSBhcHBsaWNhdGlvbiBhbmQgUVVJQyBzdHJlYW0sIG9y IG1heSBqdXN0IHJlcXVpcmUgc29tZSBuZXcgZmVhdHVyZXMsIHdlJ2xsIHNlZS4mbmJzcDsgSSBj YW4ndCB0aGluayBvZiBhbnl0aGluZyBhYm91dA0KIG1vdmluZyBmcm9tIDIgdG8gMSBzdHJlYW1z IGNoYW5nZXMgdGhpcywgZXNwZWNpYWxseSBnaXZlbiB0aGUgbmV3IGhlYWRlciBjb21wcmVzc2lv biBzY2hlbWVzIHdpbGwgYWxsb3cgY2FuY2VsbGF0aW9uIG9mIHRoZSBoZWFkZXJzIGFzIHdlbGwg YXMgdGhlIHBheWxvYWQsIHVubGlrZSBiZWZvcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBTdW4sIEp1bCAyMywgMjAxNyBhdCA0OjU2IEFNLCBQaGlsaXBw IFMuIFRpZXNlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlIiB0YXJnZXQ9 Il9ibGFuayI+cGhpbHNAaW4tcGFuaWsuZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+dG9vIGJhZCB0aGF0IEkgbWlzc2VkIHRoYXQgZGlzY3Vzc2lv bi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlNlcGFyYXRpbmcgREFUQSBhbmQgUmVxdWVzdC9SZXNwb25zZSB0byBkaWZmZXJl bnQgc3RyZWFtcyB3b3VsZCBiZSBiZW5lZmljaWFsIGlmIHdlIGFkZCB1bnJlbGlhYmxlIHN0cmVh bXMuIEkgd2lsbCB0cnkgdG8gd3JpdGUgdXAgc29tZXRoaW5nIChhdCBsZWFzdCBjb25zaWRlcmF0 aW9ucykgYmVmb3JlIHRoZQ0KIGludGVyaW0uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g MjIuIEp1bCAyMDE3LCBhdCAwMzowNCwgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5vLCB0aGUg Y29uc2Vuc3VzIGJvdGggaW4gUGFyaXMgYW5kIFByYWd1ZSB3YXMgYSBzaW5nbGUgc3RyZWFtLCB3 aGljaCBtZWFucyB0aGUgREFUQSBmcmFtZSBpcyBiYWNrIHRvIHN0YXkuJm5ic3A7IFRoZQ0KIEhQ QUNLLXdpdGhvdXQtZHluYW1pYy10YWJsZSBwaWVjZSBpcyB0ZW1wb3JhcnksIHVudGlsIHdlIHBp Y2sgYSBkaXJlY3Rpb24gZm9yIGhlYWRlciBjb21wcmVzc2lvbi48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlbnQgZnJvbSBteSBXaW5kb3dzIDEwIHBo b25lPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNsYXNzPSJtLTI0NzkxNDkzMzcw MzU0ODYwOTNtLTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzpMdWNhcy5QYXJkdWVAYmJjLmNvLnVr IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5NTRGNzIiPkx1Y2FzDQog UGFyZHVlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlNlbnQ6PHNwYW4gY2xh c3M9Im0tMjQ3OTE0OTMzNzAzNTQ4NjA5M20tMjg0OTgxOTk4Mjk3MTAyODIwNWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5GcmlkYXksIEp1bHkgMjEsIDIwMTcgODoyMCBB TTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJtLTI0NzkxNDkzMzcwMzU0ODYwOTNtLTI4NDk4MTk5 ODI5NzEwMjgyMDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM5NTRGNzIiPklFVEYgUVVJQyBXRzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJtLTI0NzkxNDkzMzcwMzU0ODYwOTNt LTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L2I+SFRUUCByZXF1ZXN0cyBvbiBvbmUgc3RyZWFtICM2OTI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXBv bG9naWVzIGlmIHRoaXMgd2FzIGRpc2N1c3NlZCBhbHJlYWR5IGluIFByYWd1ZSBidXQgSeKAmWQg bGlrZSBzb21lIGNsYXJpZmljYXRpb24gb24gdGhlIGludGVuZGVkIGxpZmV0aW1lIHNjb3BlDQog b2YgdGhlIGNoYW5nZXMgaW48c3BhbiBjbGFzcz0ibS0yNDc5MTQ5MzM3MDM1NDg2MDkzbS0yODQ5 ODE5OTgyOTcxMDI4MjA1YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGcHVs bCUyRjY5MiUyRmZpbGVzJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jv c29mdC5jb20lN0MxYTY2ODczZWM5ODM0OTdiZjdkZTA4ZDRkMDRjMDMyNiU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjI0NzIyODM0MTUzNDcmYW1wO3Nk YXRhPWRaTVhwaUNZbzViN3RWdUtyYkpDc25hUFA0Mm1xUlZpJTJCM3g0Z2FyV3J2SSUzRCZhbXA7 cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0Rjcy Ij5QUiM2OTI8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LjxzcGFuIGNsYXNzPSJtLTI0Nzkx NDkzMzcwMzU0ODYwOTNtLTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5JcyB0aGUgaW50ZW50aW9uIHRoYXQgdGhpcyBjaGFuZ2UgdW5ibG9ja3Mgc3Bl Y2lmaWNhdGlvbiAvIGRldmVsb3BtZW50IHNvIHRoYXQgdGhlIFdHIGNhbiBjb250aW51ZT88L3Nw YW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGNt O21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2lsbCB0aGVzZSBj aGFuZ2VzIGJlIHVud291bmQgb25jZSBwcm9ncmVzcyBoYXMgYmVlbiBtYWRlPzwvc3Bhbj48bzpw PjwvbzpwPjwvbGk+PC9vbD4NCjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+DQo8b2wgc3RhcnQ9IjEi IHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowY207bXNvLWxp c3Q6bDIgbGV2ZWwyIGxmbzYiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgREFUQSBmcmFtZSBoYXMg YmVlbiByZXN1cnJlY3RlZCAoSSBwcmVzdW1lIHRvIGRlbWFyayBmcmFtZXMgaW4gdGhlIHNhbWUg c3RyZWFtKS4gV2lsbCBpdCBiZSBzdHJ1Y2sgd2l0aCBhIHdvb2RlbiBzdGFrZSBpbiB0aGUgZnV0 dXJlLCBvciBjb250aW51ZSB0byBoYW5nIGFyb3VuZD88L3NwYW4+PG86cD48L286cD48L2xpPjwv b2w+DQo8L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pkx1Y2FzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFWRSE8YnI+DQom bmJzcDsgUGhpbGlwcCBTLiBUaWVzZWwgLyBwaGlsc+KApjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9Im0tMjQ3OTE0OTMzNzAzNTQ4NjA5M2hvZW56 YiI+LS0mbmJzcDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tMjQ3OTE0OTMzNzAzNTQ4NjA5 M2hvZW56YiI+Jm5ic3A7ICZuYnNwO3twaGlsc30tLS0mZ3Q7LS0tKDwvc3Bhbj48L3NwYW4+PGEg aHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlIiB0YXJnZXQ9Il9ibGFuayI+cGhpbHNAaW4t cGFuaWsuZGU8L2E+PHNwYW4gY2xhc3M9Im0tMjQ3OTE0OTMzNzAzNTQ4NjA5M2hvZW56YiI+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiktLS0mZ3Q7LS0tKDwvc3Bhbj48L3NwYW4+PGEgaHJl Zj0iaHR0cDovL3BoaWxzLmluLXBhbmlrLmRlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3BoaWxz LmluLXBhbmlrLmRlPC9hPjxzcGFuIGNsYXNzPSJtLTI0NzkxNDkzMzcwMzU0ODYwOTNob2VuemIi PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4pLS0tLSw8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0ibS0yNDc5MTQ5MzM3MDM1NDg2 MDkzaG9lbnpiIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB3ZW5uIHcgZWluZSAmbmJzcDsgYXViZSBp c3QgZG4gJm5ic3A7ICZuYnNwOyAmbmJzcDttYW4gYXUgZHJhbiBkcmUgZW4gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0ibS0yNDc5MTQ5MzM3MDM1NDg2MDkzaG9lbnpiIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7ICZuYnNwOyBTY2hyICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuIG11c3MgJm5ic3A7ICZuYnNwOyBoYyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaCAmbmJzcDsgKEt1cnQgU2Nod2l0dGVycykgfDwvc3Bhbj48 YnI+DQo8c3BhbiBjbGFzcz0ibS0yNDc5MTQ5MzM3MDM1NDg2MDkzaG9lbnpiIj46d3EhICZuYnNw OyZsdDstLS0tKHBob25lOiA8L3NwYW4+PC9zcGFuPjxhIGhyZWY9InRlbDomIzQzOzQ5JTIwMTc5 JTIwNjczNzQzOSIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDktMTc5LTY3Mzc0Mzk8L2E+PHNwYW4g Y2xhc3M9Im0tMjQ3OTE0OTMzNzAzNTQ4NjA5M2hvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPiktLS0mbHQ7LS0tKGphYmJlcjoNCjwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRv OnBoaWxzQGluLXBhbmlrLmRlIiB0YXJnZXQ9Il9ibGFuayI+cGhpbHNAaW4tcGFuaWsuZGU8L2E+ PHNwYW4gY2xhc3M9Im0tMjQ3OTE0OTMzNzAzNTQ4NjA5M2hvZW56YiI+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPiktLS0tJzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB5PR07MB1237A77FC6F791C1A95239F784BA0DB5PR07MB1237eurp_-- From nobody Sun Jul 23 11:53: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 DD5BF13178D for ; Sun, 23 Jul 2017 11:53:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 QLaa75lMx2ak for ; Sun, 23 Jul 2017 11:53:07 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 E4559131771 for ; Sun, 23 Jul 2017 11:53:06 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 80so65106682uas.0 for ; Sun, 23 Jul 2017 11:53:06 -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=9jEDWvFppgFDLD6rTWpKwMw/2bMFrW93NePylePPMIM=; b=p/4xUWTnvBJ47Be8HX7VxBP6zfvQIo+6rN1zP8pienUmbXGVW3nvUvOT0+hAOtQPf7 DqpXEB8+ReDqgTh9oOYIdraQnHhjVL9N+RuWjPY9FbUG5dLKw/FYPc502GO4n7DTjXvy zAn5QCtq9HibOFdUENSVHJNDFQB0vZK4/5mC2GtrxehONoObTlmfcPcg3TSCdDQb0es4 Yr7/bb/iXwGpMKIjiXR6f/KGp/2bKXdCMc8htzE1eQimHgnaIICevAFGqmsl+0t3Hrjr HdbRemu7wOq9LubrW8twN7LrQn8U1LKX7nbqhbYmQvCAmullIGix8PCxCuc8fQbZW/fJ 0Nug== 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=9jEDWvFppgFDLD6rTWpKwMw/2bMFrW93NePylePPMIM=; b=r/lSLMZTly6Q3RHp016CvJizTq5XVE4k6K3bqQdeLT2AE9J2JUJ+wZo62uuI2kn7Vg PUcScUnXQn96xtvgL3wu6YCmP+Z52rb/3ZEQ/RITZRli4oYr9OJkY7/8qu65MEUiGKcK WAq0DsqqvrViHQOgKwyCEJNmZiJPo1zSYBX6K/ouAqOiMR++FIpx4rsRQBgLGNAzlO0W 6MYWZYARkqfwx/ReNUrO+yAHOYgIt2cy4WWUeD2B5C+YDjT+TKPqyzpKkjzjT0ahFNH9 YK71ybdZ0T6ZugtA+aVDfWvXQVL+I6s+eEA6ILpqsXaoNF6kd3czDor085sNp4RbKSbU AzvA== X-Gm-Message-State: AIVw110cxoUWgMS22JDbeXTVM5T/p79OzaEBiQKABRhXYS2vVeVEkmMh LKx02fP5DygBM5R+hpQAunj1R4e5wg== X-Received: by 10.159.52.79 with SMTP id s15mr9078611uab.157.1500835986012; Sun, 23 Jul 2017 11:53:06 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 23 Jul 2017 14:53:05 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 23 Jul 2017 14:53:05 -0400 Message-ID: Subject: RE: HTTP requests on one stream #692 To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Ian Swett Cc: Lucas Pardue , IETF QUIC WG , Mike Bishop , "Philipp S. Tiesel" Content-Type: multipart/alternative; boundary="f403043ed1d4d000600555009b33" 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, 23 Jul 2017 18:53:10 -0000 --f403043ed1d4d000600555009b33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If stream identifiers move to 64 bit, unidirectional streams can be used as unreliable streams by storing an association context at the start of each stream. Then ack/nack becomes irrelevant because the receiver can just send a no longer interested frame instead (if it makes sense - since it might be too late). This has the benefit that packet boundaries are neatly defined in the length of the stream. I previously tried to define an unreliable concept within a single stream but it was not nearly as elegant as using separate streams. However, if stream identifiers are 32-bit or they are not explicitly uni-directional, this concept no longer works nearly as well. 32-bit only lasts an hour in high volume traffic. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 23 July 2017 at 20.29.19, Swindells, Thomas (Nokia - GB/Cambridge, UK) ( thomas.swindells@nokia.com) wrote: I agree that blindly acking packets would cause big problems with the current operations. But perhaps if/when we get onto unreliable streams a way to explicitly nack packets but state don=E2=80=99t bother retransmittin= g the ones for stream x would be a potential mechanism? Thomas *From:* Ian Swett [mailto:ianswett@google.com] *Sent:* 23 July 2017 14:03 *To:* Swindells, Thomas (Nokia - GB/Cambridge, UK) < thomas.swindells@nokia.com> *Cc:* Philipp S. Tiesel ; Lucas Pardue < Lucas.Pardue@bbc.co.uk>; Mike Bishop ; IETF QUIC WG *Subject:* Re: HTTP requests on one stream #692 On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: A few comments linline. Thomas *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett *Sent:* 23 July 2017 10:59 *To:* Philipp S. Tiesel *Cc:* Lucas Pardue ; Mike Bishop < Michael.Bishop@microsoft.com>; IETF QUIC WG *Subject:* Re: HTTP requests on one stream #692 A few comments on unreliable streams in QUIC, and this may be a longer discussion and I'd be curious to read the considerations you have in mind. QUIC as specified today definitely enables unreliability. For example, I can send stream data once, and if some portion of it is lost, at that point I can decide if I want to retransmit it or just cancel the stream. *[Thomas Swindells] As stream frames contain the offset client potentially also has the option of just acknowledging reception even it didn=E2=80=99t = actually receive them - though obviously this would and cause problems if non-stream frames were also being acknowledged when in fact the client hadn=E2=80=99t acknowledge them. .* This is prohibited currently, and for good reason, since acking packets you haven't received breaks congestion control and potentially flow control. Also, you'd be assuming what was in the packets was what you expected, and if you were wrong, it could go really poorly. ie: imagine if you acked a packet containing QPACK compression context, but didn't receive it. The connection would then be in a completely invalid state. I generally consider unreliability to be a matter of sender side policy. *[Thomas Swindells] I don=E2=80=99t think I agree with that. Often it is th= e client which has the knowledge about whether data is or is not important. Live video streaming is the best example for this, if the client has enough buffer and is playing the output out live then it would prefer to get the data re-transmitted, however data over a certain age isn=E2=80=99t useful a= nd it may prefer to lose some frames and jump back up to live. However if the client is actually recording the output (or has a longer buffer) it may prefer to stall and get all the data.* This is definitely an interesting use case and one I think should be in scope for HTTP over QUIC. However, at the end of the day the server needs to send what the client wants, so it's better to inform the server what to send than trick it. Given we're discussing HTTP, ideally the HTTP/2 priorities + cancellation would provide what you need, but I'll admit at the moment it's not a natural mapping. Making this work well may require a more robust interface between the application and QUIC stream, or may just require some new features, we'll see. I can't think of anything about moving from 2 to 1 streams changes this, especially given the new header compression schemes will allow cancellation of the headers as well as the payload, unlike before. On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel wrote: Hi, too bad that I missed that discussion. Separating DATA and Request/Response to different streams would be beneficial if we add unreliable streams. I will try to write up something (at least considerations) before the interim. On 22. Jul 2017, at 03:04, Mike Bishop wrote= : No, the consensus both in Paris and Prague was a single stream, which means the DATA frame is back to stay. The HPACK-without-dynamic-table piece is temporary, until we pick a direction for header compression. Sent from my Windows 10 phone *From: *Lucas Pardue *Sent: *Friday, July 21, 2017 8:20 AM *To: *IETF QUIC WG *Subject: *HTTP requests on one stream #692 Hi, Apologies if this was discussed already in Prague but I=E2=80=99d like some clarification on the intended lifetime scope of the changes in PR#692 . 1. Is the intention that this change unblocks specification / development so that the WG can continue? 2. Will these changes be unwound once progress has been made? 1. The DATA frame has been resurrected (I presume to demark frames in the same stream). Will it be struck with a wooden stake in the future= , or continue to hang around? Thanks Lucas 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 <+49%20179%206737439>)---<---(jabber: phils@in-panik.de)----' --f403043ed1d4d000600555009b33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
If stream identifiers move to 64 bit, unidirectio= nal streams can be used as unreliable streams by storing an association con= text at the start of each stream. Then ack/nack becomes irrelevant because = the receiver can just send a no longer interested frame instead (if it make= s sense - since it might be too late). This has the benefit that packet bou= ndaries are neatly defined in the length of the stream. I previously tried = to define an unreliable concept within a single stream but it was not nearl= y as elegant as using separate streams. However, if stream identifiers are = 32-bit or they are not explicitly uni-directional, this concept no longer w= orks nearly as well. 32-bit only lasts an hour in high volume traffic.

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

On 23 July 2= 017 at 20.29.19, Swindells, Thomas (Nokia - GB/Cambridge, UK) (thomas.swindells@nokia.com) wrote:

I agree that blindly acking packets would cause big= problems with the current operations. But perhaps if/when we get onto unre= liable streams a way to explicitly nack packets but state don=E2=80=99t bother retransmitting t= he ones for stream x would be a potential mechanism?

=C2=A0

Thomas

=C2=A0

From: = Ian Swett [mailto:ianswett@google.co= m]
Sent: 23 July 2017 14:03
To: Swindells, Thomas (Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.com>
Cc: Philipp S. Tiesel <phils= @in-panik.de>; Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Mike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC = WG <quic@ietf.org>
Subject: Re: HTTP requests on one stream #692

=C2=A0

=C2=A0

On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (= Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.com> wrote:

A few comments linline.

=C2=A0

Thomas

=C2=A0

From: QUIC [mailto:= quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: 23 July 2017 10:59
To: Philipp S. Tiesel <phils@in-panik.de>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Mike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: HTTP requests on one stream #692

=C2=A0

A few comments on unreliable streams in QUIC, and this may be a lo= nger discussion and I'd be curious to read the considerations you have = in mind.

=C2=A0

QUIC as specified today definitely enables unreliability.=C2=A0 Fo= r example, I can send stream data once, and if some portion of it is lost, = at that point I can decide if I want to retransmit it or just cancel the stream.=C2=A0

[Thomas Swindells] As stream frames contain the offset =C2= =A0client potentially also has the option of just acknowledging reception even it didn=E2=80=99t actually receive them - though obviously = this would and cause problems if non-stream frames were also being acknowle= dged when in fact the client hadn=E2=80=99t acknowledge them. .<= /b>

=C2=A0

This is prohibited currently, and for good reason, s= ince acking packets you haven't received breaks congestion control and = potentially flow control.=C2=A0 Also, you'd be assuming what was in the= packets was what you expected, and=C2=A0 if you were wrong, it could go really poorly.=C2=A0 ie: imagine if you acked a packet = containing QPACK compression context, but didn't receive it.=C2=A0 The = connection would then be in a completely invalid state.

=C2=A0

I generally consider unreliability to be a matter of sender side p= olicy.

[Thomas Swindells] I don=E2=80=99t think I agree with that.= Often it is the client which has the knowledge about whether data is or is not important. Live video streaming is the best example for = this, if the client has enough buffer and is playing the output out live th= en it would prefer to get the data re-transmitted, however data over a cert= ain age isn=E2=80=99t useful and it may prefer to lose some frames and jump back up to live. However if the client= is actually recording the output (or has a longer buffer) it may prefer to= stall and get all the data.

=C2=A0

=C2=A0

This is definitely an interesting use case and one I= think should be in scope for HTTP over QUIC.=C2=A0 However, at the end of = the day the server needs to send what the client wants, so it's better = to inform the server what to send than trick it.=C2=A0 Given we're discussing HTTP, ideally the HTTP/2 priorities += cancellation would provide what you need, but I'll admit at the moment= it's not a natural mapping.

=C2=A0

Making this work well may require a more robust interface between = the application and QUIC stream, or may just require some new features, we&= #39;ll see.=C2=A0 I can't think of anything about moving from 2 to 1 streams changes this, especially given the new header c= ompression schemes will allow cancellation of the headers as well as the pa= yload, unlike before.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel <phils@in-panik.de> wrote= :

Hi,

=C2=A0

too bad that I missed that discussion.=C2=A0

=C2=A0

Separating DATA and Request/Response to different streams would be= beneficial if we add unreliable streams. I will try to write up something = (at least considerations) before the interim.=C2=A0

=C2=A0

=C2=A0

On 22. Jul 2017, at 03:04, Mike Bishop <Michael.Bishop@microsoft.com= > wrote:

=C2=A0

No, the consensus both in Paris and Prague was a single stream, w= hich means the DATA frame is back to stay.=C2=A0 The HPACK-without-dynamic-table piece is temporary, until we pick a direction = for header compression.

=C2=A0

Sent from my Windows 10 phone

=C2=A0

From:=C2=A0Lucas Pardue
Sent:=C2=A0Friday, July 21, 2017 8:20 AM
To:=C2=A0IETF QUIC WG
Subject:=C2=A0HTTP requests on one stream #692

=C2=A0

Hi,

=C2=A0

Apologies if this was discussed already in Prague but I=E2=80=99d= like some clarification on the intended lifetime scope of the changes in=C2=A0PR#692.=C2=A0

=C2=A0

Is the intention that this change unblocks specification / development so = that the WG can continue?
Will these changes be unwound once progress has been made?

The DATA frame has been resurrected (I presume to demark frames in the sam= e stream). Will it be struck with a wooden stake in the future, or continue= to hang around?

=C2=A0

Thanks

Lucas

=C2=A0

AVE!
=C2=A0 Philipp S. Tiesel / phils=E2=80=A6
--=C2=A0
=C2=A0 =C2=A0{phils}--->---(= phils@= in-panik.de)--->---(http://phils.in-panik.de)----,
=C2=A0 =C2=A0 =C2=A0 wenn w ein= e =C2=A0 aube ist dn =C2=A0 =C2=A0 =C2=A0man au dran dre en =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=A0o =C2=A0 =C2=A0 Schr =C2=A0 =C2=A0 =C2=A0 =C2=A0an muss =C2=A0 = =C2=A0 hc =C2=A0 =C2=A0 =C2=A0 =C2=A0 h =C2=A0 (Kurt Schwitters) | :wq! =C2=A0<----(phone: +49-179-673= 7439)---<---(jabber: phils@= in-panik.de)----'

=C2=A0

=C2=A0

=C2=A0

--f403043ed1d4d000600555009b33-- From nobody Sun Jul 23 13:21: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 E9B5B129B15 for ; Sun, 23 Jul 2017 13:21:28 -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, RP_MATCHES_RCVD=-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=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 COKne4N1G1Op for ; Sun, 23 Jul 2017 13:21:26 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::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 BDCFC1270AC for ; Sun, 23 Jul 2017 13:21:25 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id w187so19468884ybc.0 for ; Sun, 23 Jul 2017 13:21:25 -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=Vg4e37lGBp3AOIE4A4n1zYD2Jyo5UBZM/bcvFFrSKT8=; b=OLjsoIAAlzizDk/6Q2tc2rT9PUlq4BqTSym0HQ86Mlu526MngWsVKSlADCkAVa8k2F n3+fRXLXZQfuWqGWj11wuDDwog+yUhRv2A76QrXJ7vhalG+KLY0Fy4X13QZsuYwtPEiB JWDVNtR4OWuUy89CgzEbKbnwaY8CwlJGP+jc6N6v4yKS4nOQl6oD76e9jkLSvlvv6a3m GNm3G7hPpDKs4tMLP1rNkORL8AY9Py/KLobCAYOzmB/j6HheJdUA5/egrk29FqRyMHZP AntJ+G+bD+TlNGc9+bkU66sddjaSgCqPNGpRcoJcRzxm3jMwcIuoFZr6wH344IUmm8/k HzOg== 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=Vg4e37lGBp3AOIE4A4n1zYD2Jyo5UBZM/bcvFFrSKT8=; b=a5fz0rn675BSfrNW/6lRwGozhh47jJfeIIDBJeF04kUa/+nV8NaUiHYCt2JZ6rMB6p aF5RI8/fFXEydqPuvMU0kVuLzglJyxRPSlkdvH/8IPTDhhtLourV6j/Qy4u+41oiY3gh t9pgHNcVuGZb7e7Awf67NlRBtofZipBOnlNHfoxXXY+FQoNtCSmte2uquBQa3W90VeWY sdm9mG1LGLptnxTPBOD0b92Iw861H4Ih4h743e4E+mOfwJYv5vqE3x1M2kfjUwn9cbqd U2s2d2WPthVq8XJ85BVgFpptRU+FwqdPGSVmEtNtyDSxis4ZFhXkPMy7YC6yz5ylEcNK ZEQA== X-Gm-Message-State: AIVw111YAMUxCOnTYaMlL+6ORA6Wih6FA6bTi1PdCKvKC8lTK7UJiytf fuGw4+qk6DC7X1mLlqivpkQg4Pq2HAft X-Received: by 10.37.189.204 with SMTP id g12mr12498891ybk.336.1500841284527; Sun, 23 Jul 2017 13:21:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.163.130 with HTTP; Sun, 23 Jul 2017 13:21:04 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> From: Ian Swett Date: Sun, 23 Jul 2017 16:21:04 -0400 Message-ID: Subject: Re: HTTP requests on one stream #692 To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Lucas Pardue , IETF QUIC WG , Mike Bishop , "Philipp S. Tiesel" Content-Type: multipart/alternative; boundary="089e082311d0a1668f055501d7d1" 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, 23 Jul 2017 20:21:29 -0000 --089e082311d0a1668f055501d7d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good points Mikkel. When we did the math on using one stream ID per video or audio frame in WebRTC at the Tokyo interim, I believe it worked out to enough for 2 weeks of video. But for other applications, it is very possible to hit the 32 bit limit in a moderate amount of time. On Sun, Jul 23, 2017 at 2:53 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > If stream identifiers move to 64 bit, unidirectional streams can be used > as unreliable streams by storing an association context at the start of > each stream. Then ack/nack becomes irrelevant because the receiver can ju= st > send a no longer interested frame instead (if it makes sense - since it > might be too late). This has the benefit that packet boundaries are neatl= y > defined in the length of the stream. I previously tried to define an > unreliable concept within a single stream but it was not nearly as elegan= t > as using separate streams. However, if stream identifiers are 32-bit or > they are not explicitly uni-directional, this concept no longer works > nearly as well. 32-bit only lasts an hour in high volume traffic. > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 23 July 2017 at 20.29.19, Swindells, Thomas (Nokia - GB/Cambridge, UK)= ( > thomas.swindells@nokia.com) wrote: > > I agree that blindly acking packets would cause big problems with the > current operations. But perhaps if/when we get onto unreliable streams a > way to explicitly nack packets but state don=E2=80=99t bother retransmitt= ing the > ones for stream x would be a potential mechanism? > > > > Thomas > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* 23 July 2017 14:03 > *To:* Swindells, Thomas (Nokia - GB/Cambridge, UK) < > thomas.swindells@nokia.com> > *Cc:* Philipp S. Tiesel ; Lucas Pardue < > Lucas.Pardue@bbc.co.uk>; Mike Bishop ; IETF > QUIC WG > *Subject:* Re: HTTP requests on one stream #692 > > > > > > On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (Nokia - GB/Cambridge, > UK) wrote: > > A few comments linline. > > > > Thomas > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* 23 July 2017 10:59 > *To:* Philipp S. Tiesel > *Cc:* Lucas Pardue ; Mike Bishop < > Michael.Bishop@microsoft.com>; IETF QUIC WG > *Subject:* Re: HTTP requests on one stream #692 > > > > A few comments on unreliable streams in QUIC, and this may be a longer > discussion and I'd be curious to read the considerations you have in mind= . > > > > QUIC as specified today definitely enables unreliability. For example, I > can send stream data once, and if some portion of it is lost, at that poi= nt > I can decide if I want to retransmit it or just cancel the stream. > > *[Thomas Swindells] As stream frames contain the offset client > potentially also has the option of just acknowledging reception even it > didn=E2=80=99t actually receive them - though obviously this would and ca= use > problems if non-stream frames were also being acknowledged when in fact t= he > client hadn=E2=80=99t acknowledge them. .* > > > > This is prohibited currently, and for good reason, since acking packets > you haven't received breaks congestion control and potentially flow > control. Also, you'd be assuming what was in the packets was what you > expected, and if you were wrong, it could go really poorly. ie: imagine > if you acked a packet containing QPACK compression context, but didn't > receive it. The connection would then be in a completely invalid state. > > > > I generally consider unreliability to be a matter of sender side policy. > > *[Thomas Swindells] I don=E2=80=99t think I agree with that. Often it is = the > client which has the knowledge about whether data is or is not important. > Live video streaming is the best example for this, if the client has enou= gh > buffer and is playing the output out live then it would prefer to get the > data re-transmitted, however data over a certain age isn=E2=80=99t useful= and it > may prefer to lose some frames and jump back up to live. However if the > client is actually recording the output (or has a longer buffer) it may > prefer to stall and get all the data.* > > > > > > This is definitely an interesting use case and one I think should be in > scope for HTTP over QUIC. However, at the end of the day the server need= s > to send what the client wants, so it's better to inform the server what t= o > send than trick it. Given we're discussing HTTP, ideally the HTTP/2 > priorities + cancellation would provide what you need, but I'll admit at > the moment it's not a natural mapping. > > > > Making this work well may require a more robust interface between the > application and QUIC stream, or may just require some new features, we'll > see. I can't think of anything about moving from 2 to 1 streams changes > this, especially given the new header compression schemes will allow > cancellation of the headers as well as the payload, unlike before. > > > > > > > > > > On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel > wrote: > > Hi, > > > > too bad that I missed that discussion. > > > > Separating DATA and Request/Response to different streams would be > beneficial if we add unreliable streams. I will try to write up something > (at least considerations) before the interim. > > > > > > On 22. Jul 2017, at 03:04, Mike Bishop > wrote: > > > > No, the consensus both in Paris and Prague was a single stream, which > means the DATA frame is back to stay. The HPACK-without-dynamic-table > piece is temporary, until we pick a direction for header compression. > > > > Sent from my Windows 10 phone > > > > *From: *Lucas Pardue > *Sent: *Friday, July 21, 2017 8:20 AM > *To: *IETF QUIC WG > *Subject: *HTTP requests on one stream #692 > > > > Hi, > > > > Apologies if this was discussed already in Prague but I=E2=80=99d like so= me > clarification on the intended lifetime scope of the changes in PR#692 > > . > > > > 1. Is the intention that this change unblocks specification / > development so that the WG can continue? > 2. Will these changes be unwound once progress has been made? > > > 1. The DATA frame has been resurrected (I presume to demark frames in > the same stream). Will it be struck with a wooden stake in the futu= re, or > continue to hang around? > > > > Thanks > > Lucas > > > > AVE! > Philipp S. Tiesel / phils=E2=80=A6 > -- > {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 <+49%20179%206737439>)---<---(jabber: > phils@in-panik.de)----' > > > > > > > > --089e082311d0a1668f055501d7d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good points Mikkel.=C2=A0 When we did the math on usi= ng one stream ID per video or audio frame in WebRTC at the Tokyo interim, I= believe it worked out to enough for 2 weeks of video.=C2=A0 But for other = applications, it is very possible to hit the 32 bit limit in a moderate amo= unt of time.

On Sun, Jul 23, 2017 at 2:53 PM, Mikkel Fahn=C3=B8e J=C3=B8rgens= en <mikkelfj@gmail.com> wrote:
If stream identifiers move to = 64 bit, unidirectional streams can be used as unreliable streams by storing= an association context at the start of each stream. Then ack/nack becomes = irrelevant because the receiver can just send a no longer interested frame = instead (if it makes sense - since it might be too late). This has the bene= fit that packet boundaries are neatly defined in the length of the stream. = I previously tried to define an unreliable concept within a single stream b= ut it was not nearly as elegant as using separate streams. However, if stre= am identifiers are 32-bit or they are not explicitly uni-directional, this = concept no longer works nearly as well. 32-bit only lasts an hour in high v= olume traffic.

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

On 23 July 2017 at 20.29.19, Swindells, Thomas (Nokia - G= B/Cambridge, UK) (thomas.swindells@nokia.com) wrote:

I agree that blindly acking packets would cause big= problems with the current operations. But perhaps if/when we get onto unre= liable streams a way to explicitly nack packets but state don=E2=80=99t bother retransmitting t= he ones for stream x would be a potential mechanism?

=C2=A0

Thomas

=C2=A0

From: = Ian Swett [mailto:= ianswett@google.com]
Sent: 23 July 2017 14:03
To: Swindells, Thomas (Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.com= >
Cc: Philipp S. Tiesel <phils@in-panik.de>; Lucas Pardue <Lucas.Pardue@bbc.co.uk>; M= ike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: HTTP requests on one stream #692

=C2=A0

=C2=A0

On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (= Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.com> wrote:

A few comments linline.

=C2=A0

Thomas

=C2=A0

From: = QUIC [mailto:= quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: 23 July 2017 10:59
To: Philipp S. Tiesel <phils@in-panik.de>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Mike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: HTTP requests on one stream #692

=C2=A0

A few comments on unreliable streams in QUIC, and th= is may be a longer discussion and I'd be curious to read the considerat= ions you have in mind.

=C2=A0

QUIC as specified today definitely enables unreliabi= lity.=C2=A0 For example, I can send stream data once, and if some portion o= f it is lost, at that point I can decide if I want to retransmit it or just cancel the stream.=C2=A0

[Thomas Swindells] As stream frames contain t= he offset =C2=A0client potentially also has the option of just acknowledgin= g reception even it didn=E2=80=99t actually receive them - though obviously = this would and cause problems if non-stream frames were also being acknowle= dged when in fact the client hadn=E2=80=99t acknowledge them. .<= /b>

=C2=A0

This is prohibited currently, and for good reason, s= ince acking packets you haven't received breaks congestion control and = potentially flow control.=C2=A0 Also, you'd be assuming what was in the= packets was what you expected, and=C2=A0 if you were wrong, it could go really poorly.=C2=A0 ie: imagine if you acked a packet = containing QPACK compression context, but didn't receive it.=C2=A0 The = connection would then be in a completely invalid state.

=C2=A0

I generally consider unreliability to be a matter of= sender side policy.

[Thomas Swindells] I don=E2=80=99t think I ag= ree with that. Often it is the client which has the knowledge about whether data is or is not important. Live video streaming is the best example for = this, if the client has enough buffer and is playing the output out live th= en it would prefer to get the data re-transmitted, however data over a cert= ain age isn=E2=80=99t useful and it may prefer to lose some frames and jump back up to live. However if the client= is actually recording the output (or has a longer buffer) it may prefer to= stall and get all the data.

=C2=A0

=C2=A0

This is definitely an interesting use case and one I= think should be in scope for HTTP over QUIC.=C2=A0 However, at the end of = the day the server needs to send what the client wants, so it's better = to inform the server what to send than trick it.=C2=A0 Given we're discussing HTTP, ideally the HTTP/2 priorities += cancellation would provide what you need, but I'll admit at the moment= it's not a natural mapping.

=C2=A0

Making this work well may require a more robust inte= rface between the application and QUIC stream, or may just require some new= features, we'll see.=C2=A0 I can't think of anything about moving from 2 to 1 streams changes this, especially given the new header c= ompression schemes will allow cancellation of the headers as well as the pa= yload, unlike before.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel &= lt;phils@in-panik.de= > wrote:

Hi,

=C2=A0

too bad that I missed that discussion.=C2=A0

=C2=A0

Separating DATA and Request/Response to different st= reams would be beneficial if we add unreliable streams. I will try to write= up something (at least considerations) before the interim.=C2=A0

=C2=A0

=C2=A0

On 22. Jul 2017, at 03:04, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

=C2=A0

No, the consensus both in Paris and Prague was a si= ngle stream, which means the DATA frame is back to stay.=C2=A0 The HPACK-without-dynamic-table piece is temporary, until we pick a direction = for header compression.

=C2=A0

Sent from my Windows 10 phone

=C2=A0

From:=C2=A0Lucas Pardue
Sent:=C2=A0Friday, July 21, 2017 8:= 20 AM
To:=C2=A0IETF QUIC WG
Subject:=C2=A0HTTP requests on one = stream #692

=C2=A0

Hi,

=C2=A0

Apologies if this was discussed already in Prague b= ut I=E2=80=99d like some clarification on the intended lifetime scope of the changes in=C2=A0PR#692.=C2=A0=

=C2=A0

Is the intention that this change unblocks specification / development so = that the WG can continue?
Will these changes be unwound once progress has been made?

The DATA frame has been resurrected (I presume to demark frames in the sam= e stream). Will it be struck with a wooden stake in the future, or continue= to hang around?

=C2=A0

Thanks

Lucas

=C2=A0

AVE!
=C2=A0 Philipp S. Tiesel / phils=E2=80=A6
--=C2=A0
=C2=A0 =C2= =A0{phils}--->---(phils@in-panik.de)--->---(http://p= hils.in-panik.de)----,
=C2=A0 =C2= =A0 =C2=A0 wenn w eine =C2=A0 aube ist dn =C2=A0 =C2=A0 =C2=A0man au dran d= re en =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=A0o =C2=A0 =C2=A0 Schr =C2=A0 =C2=A0 =C2=A0 = =C2=A0an muss =C2=A0 =C2=A0 hc =C2=A0 =C2=A0 =C2=A0 =C2=A0 h =C2=A0 (Kurt S= chwitters) |
:wq! =C2= =A0<----(phone: +49-179-6737439)---<---(jabber: phils@= in-panik.de)----'

=C2=A0

=C2=A0

=C2=A0

--089e082311d0a1668f055501d7d1-- From nobody Sun Jul 23 14:30: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 50449127180 for ; Sun, 23 Jul 2017 14:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 OHb9KvLMNYP1 for ; Sun, 23 Jul 2017 14:30:33 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 8845E127342 for ; Sun, 23 Jul 2017 14:30:33 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id v205so8174992itf.1 for ; Sun, 23 Jul 2017 14:30:33 -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=+cUvSRNGBacTgJKj/906CHtASv8EeuF/0UohrQ3h7yY=; b=cJxBFqryL/MVQb1mreqj4vN7OdgAwrfSVtYU5fAU79zh9oa5y7QAgQHbGpVEInOsG3 /9MSXFULnBjfMefartDDw2a96m0FKgnIm0tQGLooMFzj/rjlfUNBENW+17StFFKEDtdn l52xIxB9Vg64YDGymje59F3sT1Dt/AccIwfmD+43XDhmHajbaS5cDHTUZgYF6hdOt6Ed G0rz8I2r6ISqSfHysRzGuCR9qGPG6OUYCh5u4sbd8qXrzqeEJ0HpeZ58xplRGAqhIUkm 3brG1pF0XgjTzwnyR6xcDGXn5Q1QSaqtiajXGT5ENCnohZPu5V1/e72TLiI3hb1r/2Ck Lwyw== 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=+cUvSRNGBacTgJKj/906CHtASv8EeuF/0UohrQ3h7yY=; b=fdRpsDROwVpWC0HbicNj36KhbvJmlHM1cVgdLYZkSO2X3dZe9/+OZXe0BXdrPrGpg9 IF2s76KFD3fsYeqA3J+NAXQ43vXEgkLHd59V12XAqut6SKrVZNJs+tmfAEsRncs9OsIH nzXCk7rpOG3aC8R++jDA8gzqGL7ajtB6WbDXqTcoQttVMUpWJmYWahDNmSiSgSg/DxsH LIfEf+hpaFnFngNE7JzI9uR5knMKROWs2dClrDsf8M/tf31tlTf/9WZgZigrYXBqm5Dm 4M55qJMFREgUuhuego4DVyczhGeHKmCieraQMrbQCGaZJeH0ip92QFNcbcpQUAWSFCXf bN7A== X-Gm-Message-State: AIVw113UJG+XaT0nBEw/jGTnKaCDBAVRl2rdggI6oIq0ttexFBgCu4D0 +c54WSnkhAxWGio3gxSOmBRlToqaCg== X-Received: by 10.36.53.70 with SMTP id k67mr5452207ita.79.1500845432866; Sun, 23 Jul 2017 14:30:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Sun, 23 Jul 2017 14:30:31 -0700 (PDT) Received: by 10.107.164.26 with HTTP; Sun, 23 Jul 2017 14:30:31 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> From: Martin Thomson Date: Sun, 23 Jul 2017 23:30:31 +0200 Message-ID: Subject: RE: HTTP requests on one stream #692 To: "Swindells, Thomas (Nokia - GB)" Cc: Ian Swett , Mike Bishop , Lucas Pardue , IETF QUIC WG , "Philipp S. Tiesel" Content-Type: multipart/alternative; boundary="001a114abeece38f7f055502ceee" 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, 23 Jul 2017 21:30:36 -0000 --001a114abeece38f7f055502ceee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And you can't acknowledge stream data either, only packets. If you want to keep some frames but not others, which seems likely, over-acknowledgement doesn't work. On 24 Jul. 2017 04:29, "Swindells, Thomas (Nokia - GB/Cambridge, UK)" < thomas.swindells@nokia.com> wrote: > I agree that blindly acking packets would cause big problems with the > current operations. But perhaps if/when we get onto unreliable streams a > way to explicitly nack packets but state don=E2=80=99t bother retransmitt= ing the > ones for stream x would be a potential mechanism? > > > > Thomas > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* 23 July 2017 14:03 > *To:* Swindells, Thomas (Nokia - GB/Cambridge, UK) < > thomas.swindells@nokia.com> > *Cc:* Philipp S. Tiesel ; Lucas Pardue < > Lucas.Pardue@bbc.co.uk>; Mike Bishop ; IETF > QUIC WG > *Subject:* Re: HTTP requests on one stream #692 > > > > > > On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (Nokia - GB/Cambridge, > UK) wrote: > > A few comments linline. > > > > Thomas > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* 23 July 2017 10:59 > *To:* Philipp S. Tiesel > *Cc:* Lucas Pardue ; Mike Bishop < > Michael.Bishop@microsoft.com>; IETF QUIC WG > *Subject:* Re: HTTP requests on one stream #692 > > > > A few comments on unreliable streams in QUIC, and this may be a longer > discussion and I'd be curious to read the considerations you have in mind= . > > > > QUIC as specified today definitely enables unreliability. For example, I > can send stream data once, and if some portion of it is lost, at that poi= nt > I can decide if I want to retransmit it or just cancel the stream. > > *[Thomas Swindells] As stream frames contain the offset client > potentially also has the option of just acknowledging reception even it > didn=E2=80=99t actually receive them - though obviously this would and ca= use > problems if non-stream frames were also being acknowledged when in fact t= he > client hadn=E2=80=99t acknowledge them. .* > > > > This is prohibited currently, and for good reason, since acking packets > you haven't received breaks congestion control and potentially flow > control. Also, you'd be assuming what was in the packets was what you > expected, and if you were wrong, it could go really poorly. ie: imagine > if you acked a packet containing QPACK compression context, but didn't > receive it. The connection would then be in a completely invalid state. > > > > I generally consider unreliability to be a matter of sender side policy. > > *[Thomas Swindells] I don=E2=80=99t think I agree with that. Often it is = the > client which has the knowledge about whether data is or is not important. > Live video streaming is the best example for this, if the client has enou= gh > buffer and is playing the output out live then it would prefer to get the > data re-transmitted, however data over a certain age isn=E2=80=99t useful= and it > may prefer to lose some frames and jump back up to live. However if the > client is actually recording the output (or has a longer buffer) it may > prefer to stall and get all the data.* > > > > > > This is definitely an interesting use case and one I think should be in > scope for HTTP over QUIC. However, at the end of the day the server need= s > to send what the client wants, so it's better to inform the server what t= o > send than trick it. Given we're discussing HTTP, ideally the HTTP/2 > priorities + cancellation would provide what you need, but I'll admit at > the moment it's not a natural mapping. > > > > Making this work well may require a more robust interface between the > application and QUIC stream, or may just require some new features, we'll > see. I can't think of anything about moving from 2 to 1 streams changes > this, especially given the new header compression schemes will allow > cancellation of the headers as well as the payload, unlike before. > > > > > > > > > > On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel > wrote: > > Hi, > > > > too bad that I missed that discussion. > > > > Separating DATA and Request/Response to different streams would be > beneficial if we add unreliable streams. I will try to write up something > (at least considerations) before the interim. > > > > > > On 22. Jul 2017, at 03:04, Mike Bishop > wrote: > > > > No, the consensus both in Paris and Prague was a single stream, which > means the DATA frame is back to stay. The HPACK-without-dynamic-table > piece is temporary, until we pick a direction for header compression. > > > > Sent from my Windows 10 phone > > > > *From: *Lucas Pardue > *Sent: *Friday, July 21, 2017 8:20 AM > *To: *IETF QUIC WG > *Subject: *HTTP requests on one stream #692 > > > > Hi, > > > > Apologies if this was discussed already in Prague but I=E2=80=99d like so= me > clarification on the intended lifetime scope of the changes in PR#692 > > . > > > > 1. Is the intention that this change unblocks specification / > development so that the WG can continue? > 2. Will these changes be unwound once progress has been made? > > > 1. The DATA frame has been resurrected (I presume to demark frames in > the same stream). Will it be struck with a wooden stake in the futu= re, or > continue to hang around? > > > > Thanks > > Lucas > > > > AVE! > Philipp S. Tiesel / phils=E2=80=A6 > -- > {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 <+49%20179%206737439>)---<---(jabber: > phils@in-panik.de)----' > > > > > > > --001a114abeece38f7f055502ceee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And you can't acknowledge stream data either, only pa= ckets. If you want to keep some frames but not others, which seems likely, = over-acknowledgement doesn't work.=C2=A0

On 24 Jul. 2017 04:29, "Swindells, Th= omas (Nokia - GB/Cambridge, UK)" <thomas.swindells@nokia.com> wrote:

I agree that blindly acking packets would cause big= problems with the current operations. But perhaps if/when we get onto unre= liable streams a way to explicitly nack packets but state don=E2=80=99t bother retransmitting t= he ones for stream x would be a potential mechanism?
=C2=A0

Thomas

=C2=A0

From: = Ian Swett [mailto:= ianswett@google.com]
Sent: 23 July 2017 14:03
To: Swindells, Thomas (Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.com= >
Cc: Philipp S. Tiesel <phils@in-panik.de>; Lucas Pardue <Lucas.Pardue@bbc.co.uk>; M= ike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: HTTP requests on one stream #692

=C2=A0

=C2=A0

On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (= Nokia - GB/Cambridge, UK) <thomas.swindells@nokia.com> wrote:<= /p>

A few comments linline.

=C2=A0

Thomas

=C2=A0

From: = QUIC [mailto:= quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: 23 July 2017 10:59
To: Philipp S. Tiesel <phils@in-panik.de>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Mike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: HTTP requests on one stream #692

=C2=A0

A few comments on unreliable streams in QUIC, and th= is may be a longer discussion and I'd be curious to read the considerat= ions you have in mind.

=C2=A0

QUIC as specified today definitely enables unreliabi= lity.=C2=A0 For example, I can send stream data once, and if some portion o= f it is lost, at that point I can decide if I want to retransmit it or just cancel the stream.=C2=A0

[Thomas Swindells] As stream frames contain t= he offset =C2=A0client potentially also has the option of just acknowledgin= g reception even it didn=E2=80=99t actually receive them - though obviously = this would and cause problems if non-stream frames were also being acknowle= dged when in fact the client hadn=E2=80=99t acknowledge them. .<= /b>

=C2=A0

This is prohibited currently, and for good reason, s= ince acking packets you haven't received breaks congestion control and = potentially flow control.=C2=A0 Also, you'd be assuming what was in the= packets was what you expected, and=C2=A0 if you were wrong, it could go really poorly.=C2=A0 ie: imagine if you acked a packet = containing QPACK compression context, but didn't receive it.=C2=A0 The = connection would then be in a completely invalid state.

=C2=A0

I generally consider unreliability to be a matter of= sender side policy.

[Thomas Swindells] I don=E2=80=99t think I ag= ree with that. Often it is the client which has the knowledge about whether data is or is not important. Live video streaming is the best example for = this, if the client has enough buffer and is playing the output out live th= en it would prefer to get the data re-transmitted, however data over a cert= ain age isn=E2=80=99t useful and it may prefer to lose some frames and jump back up to live. However if the client= is actually recording the output (or has a longer buffer) it may prefer to= stall and get all the data.

=C2=A0

=C2=A0

This is definitely an interesting use case and one I= think should be in scope for HTTP over QUIC.=C2=A0 However, at the end of = the day the server needs to send what the client wants, so it's better = to inform the server what to send than trick it.=C2=A0 Given we're discussing HTTP, ideally the HTTP/2 priorities += cancellation would provide what you need, but I'll admit at the moment= it's not a natural mapping.

=C2=A0

Making this work well may require a more robust inte= rface between the application and QUIC stream, or may just require some new= features, we'll see.=C2=A0 I can't think of anything about moving from 2 to 1 streams changes this, especially given the new header c= ompression schemes will allow cancellation of the headers as well as the pa= yload, unlike before.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel &= lt;phils@in-panik.de= > wrote:

Hi,

=C2=A0

too bad that I missed that discussion.=C2=A0<= u>

=C2=A0

Separating DATA and Request/Response to different st= reams would be beneficial if we add unreliable streams. I will try to write= up something (at least considerations) before the interim.=C2=A0

=C2=A0

=C2=A0

On 22. Jul 2017, at 03:04, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

=C2=A0

No, the consensus both in Paris and Prague was a si= ngle stream, which means the DATA frame is back to stay.=C2=A0 The HPACK-without-dynamic-table piece is temporary, until we pick a direction = for header compression.

=C2=A0

Sent from my Windows 10 phone<= /p>

=C2=A0

From:=C2=A0Lucas Pardue
Sent:=C2=A0Friday, July 21, 2017 8:= 20 AM
To:=C2=A0IETF QUIC WG
Subject:=C2=A0HTTP requests on one = stream #692

=C2=A0

Hi,

=C2=A0

Apologies if this was discussed already in Prague b= ut I=E2=80=99d like some clarification on the intended lifetime scope of the changes in=C2=A0PR#692.=C2=A0=

=C2=A0

Is the intention that this change unblocks specification / development so = that the WG can continue?
Will these changes be unwound once progress has been made?

The DATA frame has been resurrected (I presume to demark frames in the sam= e stream). Will it be struck with a wooden stake in the future, or continue= to hang around?

=C2=A0

Thanks

Lucas

=C2=A0

AVE!
=C2=A0 Philipp S. Tiesel / phils=E2=80=A6
--=C2=A0
=C2=A0 =C2= =A0{phils}--->---(phils@in-panik.de)--->---(http://p= hils.in-panik.de)----,
=C2=A0 =C2= =A0 =C2=A0 wenn w eine =C2=A0 aube ist dn =C2=A0 =C2=A0 =C2=A0man au dran d= re en =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=A0o =C2=A0 =C2=A0 Schr =C2=A0 =C2=A0 =C2=A0 = =C2=A0an muss =C2=A0 =C2=A0 hc =C2=A0 =C2=A0 =C2=A0 =C2=A0 h =C2=A0 (Kurt S= chwitters) |
:wq! =C2= =A0<----(phone: +49-179-6737439)---<---(jabber: phils@= in-panik.de)----'

=C2=A0

=C2=A0

=C2=A0

--001a114abeece38f7f055502ceee-- From nobody Sun Jul 23 14:37: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 DCBD712EC18 for ; Sun, 23 Jul 2017 14:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 7JCyvGQpFwEu for ; Sun, 23 Jul 2017 14:37:52 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 1CCB5126C23 for ; Sun, 23 Jul 2017 14:37:52 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id v127so26859054itd.0 for ; Sun, 23 Jul 2017 14:37: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=OeQawBZSgRTTy41JqQ5YFCHRRZ6vZBicvCl1xTXLJjA=; b=WciO+VATZJx8uZ+ihnDipE+zLmVNj5K+82bHpYXLSGBonu1bFwiwkCzEWCob9vZxOm EDJQhmEdtYc9vB6lMH1HL1EhU6RVd1LmFwTJGA0tX178YSU0kltVwU8kHzGVe+CvVeUF 6lzbXmAOKaeBjWqfoQGfeZ+WxK+gdRVSEfcpwWfbopqTc1iOCNcMpvfi0EXRPiR5/qwK C9BpxWn5YMYnKruCKH5zELipV1dNkbaq08F+aRg/axEwbI2/FTAoOmSA281jWeGwrNcI BdZ/Lf3BBUUd7jo52P9+ktVJ0NqrOp9rRLUETsWClWIbkXkU/0RcIaoYo6FGCb6zlUgX vGXg== 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=OeQawBZSgRTTy41JqQ5YFCHRRZ6vZBicvCl1xTXLJjA=; b=goHCiTqUseKlLfScK3h9YuDPjTyNuEU/02+mYPy9HNFZz6by5i7ehhUKn/9n6rUDXM 4SOtC2/Wyh1Z7tg+bCX3tl8zbTy0x+R70aLq+0wky26Y/nHanaJapmkJkdLqbH5DMeiY SKhWcAcB+jM8t8VG8CEdsWkkAARfAF4ckFVnoVCIbK47tJsE4s6plHBeROVdW04T4sQV v2nfMQdLM4CkHgMeEFqConJCwJ1fYft4lHWYVc+Co3WJv2rVhw3o9ezjX5u/aSHCKt6/ QPl5aiVuyQTkRtUqWyAxQqzYCDrbjQB2LqZYnU7snxtQ2ubsW2v5ffplKCos86SzqqE4 79BA== X-Gm-Message-State: AIVw110HXOFLY+mluDZWSNH4WlA66HKtbMUlQ7HY8x9jAELhATmH2Vzr q1+9xROs9ekvmmLN58oUlhqZpjx7zA== X-Received: by 10.36.152.136 with SMTP id n130mr5418360itd.79.1500845871465; Sun, 23 Jul 2017 14:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Sun, 23 Jul 2017 14:37:50 -0700 (PDT) Received: by 10.107.164.26 with HTTP; Sun, 23 Jul 2017 14:37:50 -0700 (PDT) In-Reply-To: <7fe2f1dd-a1c1-e55f-860b-fdc3c54f3504@cs.tcd.ie> References: <80c7cebc-30f1-79a3-3503-224b97d27377@huitema.net> <6bc0beec-8353-1dd2-b743-2fb3fab9f152@cs.tcd.ie> <7fe2f1dd-a1c1-e55f-860b-fdc3c54f3504@cs.tcd.ie> From: Martin Thomson Date: Sun, 23 Jul 2017 23:37:50 +0200 Message-ID: Subject: Re: Randomizer state attacks To: Stephen Farrell Cc: Ryan Hamilton , Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c05e63c080f9d055502e92c" 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, 23 Jul 2017 21:37:54 -0000 --94eb2c05e63c080f9d055502e92c Content-Type: text/plain; charset="UTF-8" On 22 Jul. 2017 22:05, "Stephen Farrell" wrote: > This principle would have to apply to a peer as well. That is, even > encrypted bits count. I'm not sure I understand or agree there. How would encrypted bits affect a dual-ec kind of attack? Or did you mean something else? State recovery depends only on seeing output. For a server in particular, if becoming a client is advantageous to an attacker, then that is what they will do. For example, prior to considering this putative new principle, it'd be natural to say that a connection ID be random, and it'd be natural to implement by getting a value from a prng and using that. Fair point. The requirement on connection ID is not randomness, but uniqueness, or maybe not even that, so it is reasonable to state the actual requirement. --94eb2c05e63c080f9d055502e92c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 22 Jul. 2017 22:05, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
> This principle would have to apply to a peer as well.=C2=A0 That is, e= ven
> encrypted bits count.

I'm not sure I understand or agree there. How would encrypted bit= s
affect a dual-ec kind of attack? Or did you mean something else?

State= recovery depends only on seeing output. For a server in particular, if bec= oming a client is advantageous to an attacker, then that is what they will = do.=C2=A0

For example, prior to considering = this putative
new principle, it'd be natural to say that a connection ID be
random, and it'd be natural to implement by getting a value from a
prng and using that.

<= /div>
Fair point. The requirement on connection ID is not = randomness, but uniqueness, or maybe not even that, so it is reasonable to = state the actual requirement.
--94eb2c05e63c080f9d055502e92c-- From nobody Sun Jul 23 22:19:00 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 A3FE91272E1 for ; Sun, 23 Jul 2017 22:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 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_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no 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 t-Ukbb6XMi_1 for ; Sun, 23 Jul 2017 22:18:56 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0111.outbound.protection.outlook.com [104.47.33.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9349F1205F0 for ; Sun, 23 Jul 2017 22:18:55 -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=vtnkPyHq7zY/RQK/5GsALYYGBiAr5hqHnDDJrWx0se0=; b=ZY2JiIKJSFP2+nCGC9DXkaZqzJthhcK04TBkfPSs7FtlH8pNadGxwYYBCPUy+pfOYZ4o0JnjXriitCHmaaG1xxey9FZnkxkdVs4XmMQMTohuNaEPYmhNsGntEwzrFvegRqHpGc7JzdbqzJB2exEdiWV2WkouGye+FUFnZT3nLNs= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0127.namprd21.prod.outlook.com (10.173.52.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Mon, 24 Jul 2017 05:18:53 +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.01.1282.008; Mon, 24 Jul 2017 05:18:53 +0000 From: Mike Bishop To: Martin Thomson , "Swindells, Thomas (Nokia - GB)" CC: Ian Swett , Lucas Pardue , IETF QUIC WG , "Philipp S. Tiesel" Subject: RE: HTTP requests on one stream #692 Thread-Topic: HTTP requests on one stream #692 Thread-Index: AdMCNJiq1/jFQyapRDqdWSVpnV2UvgAUdAmMAELNc4AAAid+AAAA+mRQAAV2kgAAANuvsAAQ3neAABAmcHA= Date: Mon, 24 Jul 2017 05:18:52 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8080:5a28:a558:ef13:687c:db68] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0127; 7:fQJj9Qjlz6fo6jUf6CwpOJpAS1/BTKbdD8Zg1u79WQa2P/F5EkV8+yycpJcusitsJzfrSRZiHR3AHAXCE1xNZFgOPfs6AhwpyVyZAKNel5ugIR51fdTX7jUVFEt4M+rStzXjhwf/S0U/03nob6A8POBw0v4sCkJklyyt3Ai5L63C7bGs/GN5mnA+3/5Wwcj6wDHaBMJIq+im+dQYFOEmVIAFMc/YiRtmMT/SdfYkE0WfjE6jDfB6K/+eZKHLKEsnobClhYq+Ux7HUvJlyVXI07kvClcCOxSqFU3rB114zRhJyr8KdDrymfmYbzwLL7B790BvIjZLlo2QUUK2sp3ETJps6rKSzIYmzA0hbUYOYVc1ldL/nYYPKsQU4zPgRyIz2XySvoQiVpfTHRM+MQXy3PxxT/7O+1bP46jSmMUTTux2ugr63jHm+r1pAGsp0BeXFfaMybHB062goEgnRTwo6aketlm0I4gJEM2A3Kxhd2g5A6xrBPnCZ2nlQLxnI/7rfC+/alyJg2lZlcS6KBjMD4R5BAjQuszQBHWKN8mtvIw2yLAAkBZh+G79gf5ft7QFbEszxOnwRjY8PdBzMLO2PqbasQu8K8ZriW4nkhbYe8gQNpUa4now9DtlBqTO+IOBv+WQiT3h+Ms+BkJ6VpLIDBahUsyb5yVfB7Gd1hjQFPEMCvJNXCszD0r0Vz2sTAEhNvupuT1IJKgVUgbYElhhrYDYYUzPjATLi9ibl+wGehMgxB4FjBVPS3Y/JWpKkvhl5N0jgBKgV6WWiyrDidRkXUe7f+2U/4KgKNqj8M+qQxBWGpE71A8vtNECArTizeHd x-ms-office365-filtering-correlation-id: a755db43-0874-4786-c90f-08d4d25379ba x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0127; x-ms-traffictypediagnostic: MWHPR21MB0127: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(189930954265078)(82608151540597)(211936372134217)(100405760836317)(153496737603132)(219752817060721)(127952516941037)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0127; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0127; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39850400002)(39860400002)(39840400002)(39400400002)(47760400005)(189002)(199003)(377454003)(24454002)(72206003)(39060400002)(97736004)(53546010)(53386004)(38730400002)(86362001)(6246003)(86612001)(4326008)(5005710100001)(8676002)(33656002)(10290500003)(478600001)(2900100001)(2950100002)(229853002)(14454004)(19609705001)(34040400001)(3280700002)(6116002)(102836003)(3660700001)(74316002)(50986999)(790700001)(2906002)(76176999)(54356999)(101416001)(236005)(25786009)(6436002)(7696004)(6506006)(8990500004)(54896002)(9686003)(99286003)(55016002)(93886004)(6306002)(606006)(7736002)(81156014)(8936002)(81166006)(5660300001)(54906002)(189998001)(105586002)(53936002)(77096006)(68736007)(106356001)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0127; 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: multipart/alternative; boundary="_000_MWHPR21MB0141C6AA46DFF0B005972F2287BB0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 05:18:53.0753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0127 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, 24 Jul 2017 05:18:58 -0000 --_000_MWHPR21MB0141C6AA46DFF0B005972F2287BB0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIE5BQ0sgaGFzIHRoZSBzYW1lIHByb2JsZW0gYXMgb3Zlci1hY2tpbmcg4oCTIHlvdSBjYW7i gJl0IGFjayBmcmFtZXMsIHlvdSBhY2sgcGFja2V0cy4gIFdoaWxlIEkgc2VlIHRoZSBhcmd1bWVu dCBmb3Igc2F5aW5nIHRoYXQgdW5yZWxpYWJsZSBkZWxpdmVyeSBpcyBhIGNsaWVudCBjaG9pY2Us IG5vdCBhIHNlbmRlciBvbmUsIGl0IHNlZW1zIGxpa2Ugc29tZXRoaW5nIHdlIGNvdWxkIHJlYXNv bmFibGUgZXhwcmVzcyBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgYW5kIHRoZW4gaGF2ZSB0aGUg c2VuZGVyIGFjdHVhbGx5IHBlcmZvcm0uDQoNClNpbXBsZXN0IG9wdGlvbnMgSSBzZWUgd291bGQg YmU6DQoNCiAgKiAgIE5vIHJldHJhbnNtaXNzaW9ucyBldmVyIChsb2NhbCBjb25maWd1cmF0aW9u IHRvIHN0YWNrLCBSU1RfU1RSRUFNIGFmdGVyIHN0cmVhbSBjb21wbGV0aW9uKQ0KICAqICAgTm8g cmV0cmFuc21pc3Npb25zIGFmdGVyIGEgY2VydGFpbiB0aW1lb3V0IChSU1RfU1RSRUFNIG9uIGEg dGltZXIsIGlmIHlvdSBhc3N1bWUgdGhlIHN0cmVhbSBkYXRhIGFsbCBiZWNvbWVzIGF2YWlsYWJs ZSBhdCBvbmNlKQ0KDQpTbGlnaHRseSBtb3JlIGNvbXBsZXggd291bGQgYmUgc29tZXRoaW5nIGxp a2Ug4oCcb25seSByZXRyYW5zbWl0IGFueSBnaXZlbiBzZWdtZW50IG9uY2XigJ0gb3Ig4oCcZ2l2 ZSB1cCBvbiByZXRyYW5zbWlzc2lvbnMgYWZ0ZXIgYSBzZWdtZW50IGlzIFggbXMgb2xkLuKAnQ0K DQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0N ClNlbnQ6IFN1bmRheSwgSnVseSAyMywgMjAxNyAyOjMxIFBNDQpUbzogU3dpbmRlbGxzLCBUaG9t YXMgKE5va2lhIC0gR0IpIDx0aG9tYXMuc3dpbmRlbGxzQG5va2lhLmNvbT4NCkNjOiBJYW4gU3dl dHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWlj cm9zb2Z0LmNvbT47IEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5jby51az47IElFVEYg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBoaWxpcHAgUy4gVGllc2VsIDxwaGlsc0Bpbi1wYW5p ay5kZT4NClN1YmplY3Q6IFJFOiBIVFRQIHJlcXVlc3RzIG9uIG9uZSBzdHJlYW0gIzY5Mg0KDQpB bmQgeW91IGNhbid0IGFja25vd2xlZGdlIHN0cmVhbSBkYXRhIGVpdGhlciwgb25seSBwYWNrZXRz LiBJZiB5b3Ugd2FudCB0byBrZWVwIHNvbWUgZnJhbWVzIGJ1dCBub3Qgb3RoZXJzLCB3aGljaCBz ZWVtcyBsaWtlbHksIG92ZXItYWNrbm93bGVkZ2VtZW50IGRvZXNuJ3Qgd29yay4NCg0KT24gMjQg SnVsLiAyMDE3IDA0OjI5LCAiU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdl LCBVSykiIDx0aG9tYXMuc3dpbmRlbGxzQG5va2lhLmNvbTxtYWlsdG86dGhvbWFzLnN3aW5kZWxs c0Bub2tpYS5jb20+PiB3cm90ZToNCkkgYWdyZWUgdGhhdCBibGluZGx5IGFja2luZyBwYWNrZXRz IHdvdWxkIGNhdXNlIGJpZyBwcm9ibGVtcyB3aXRoIHRoZSBjdXJyZW50IG9wZXJhdGlvbnMuIEJ1 dCBwZXJoYXBzIGlmL3doZW4gd2UgZ2V0IG9udG8gdW5yZWxpYWJsZSBzdHJlYW1zIGEgd2F5IHRv IGV4cGxpY2l0bHkgbmFjayBwYWNrZXRzIGJ1dCBzdGF0ZSBkb27igJl0IGJvdGhlciByZXRyYW5z bWl0dGluZyB0aGUgb25lcyBmb3Igc3RyZWFtIHggd291bGQgYmUgYSBwb3RlbnRpYWwgbWVjaGFu aXNtPw0KDQpUaG9tYXMNCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xl LmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT5dDQpTZW50OiAyMyBKdWx5IDIwMTcgMTQ6 MDMNClRvOiBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSA8dGhv bWFzLnN3aW5kZWxsc0Bub2tpYS5jb208bWFpbHRvOnRob21hcy5zd2luZGVsbHNAbm9raWEuY29t Pj4NCkNjOiBQaGlsaXBwIFMuIFRpZXNlbCA8cGhpbHNAaW4tcGFuaWsuZGU8bWFpbHRvOnBoaWxz QGluLXBhbmlrLmRlPj47IEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5jby51azxtYWls dG86THVjYXMuUGFyZHVlQGJiYy5jby51az4+OyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+OyBJRVRG IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IEhUVFAgcmVxdWVzdHMgb24gb25lIHN0cmVhbSAjNjkyDQoNCg0KT24gU3VuLCBKdWwgMjMs IDIwMTcgYXQgNzo1NyBBTSwgU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdl LCBVSykgPHRob21hcy5zd2luZGVsbHNAbm9raWEuY29tPG1haWx0bzp0aG9tYXMuc3dpbmRlbGxz QG5va2lhLmNvbT4+IHdyb3RlOg0KQSBmZXcgY29tbWVudHMgbGlubGluZS4NCg0KVGhvbWFzDQoN CkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IDIzIEp1bHkgMjAx NyAxMDo1OQ0KVG86IFBoaWxpcHAgUy4gVGllc2VsIDxwaGlsc0Bpbi1wYW5pay5kZTxtYWlsdG86 cGhpbHNAaW4tcGFuaWsuZGU+Pg0KQ2M6IEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5j by51azxtYWlsdG86THVjYXMuUGFyZHVlQGJiYy5jby51az4+OyBNaWtlIEJpc2hvcCA8TWljaGFl bC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNv bT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IEhUVFAgcmVxdWVzdHMgb24gb25lIHN0cmVhbSAjNjkyDQoNCkEgZmV3IGNv bW1lbnRzIG9uIHVucmVsaWFibGUgc3RyZWFtcyBpbiBRVUlDLCBhbmQgdGhpcyBtYXkgYmUgYSBs b25nZXIgZGlzY3Vzc2lvbiBhbmQgSSdkIGJlIGN1cmlvdXMgdG8gcmVhZCB0aGUgY29uc2lkZXJh dGlvbnMgeW91IGhhdmUgaW4gbWluZC4NCg0KUVVJQyBhcyBzcGVjaWZpZWQgdG9kYXkgZGVmaW5p dGVseSBlbmFibGVzIHVucmVsaWFiaWxpdHkuICBGb3IgZXhhbXBsZSwgSSBjYW4gc2VuZCBzdHJl YW0gZGF0YSBvbmNlLCBhbmQgaWYgc29tZSBwb3J0aW9uIG9mIGl0IGlzIGxvc3QsIGF0IHRoYXQg cG9pbnQgSSBjYW4gZGVjaWRlIGlmIEkgd2FudCB0byByZXRyYW5zbWl0IGl0IG9yIGp1c3QgY2Fu Y2VsIHRoZSBzdHJlYW0uDQpbVGhvbWFzIFN3aW5kZWxsc10gQXMgc3RyZWFtIGZyYW1lcyBjb250 YWluIHRoZSBvZmZzZXQgIGNsaWVudCBwb3RlbnRpYWxseSBhbHNvIGhhcyB0aGUgb3B0aW9uIG9m IGp1c3QgYWNrbm93bGVkZ2luZyByZWNlcHRpb24gZXZlbiBpdCBkaWRu4oCZdCBhY3R1YWxseSBy ZWNlaXZlIHRoZW0gLSB0aG91Z2ggb2J2aW91c2x5IHRoaXMgd291bGQgYW5kIGNhdXNlIHByb2Js ZW1zIGlmIG5vbi1zdHJlYW0gZnJhbWVzIHdlcmUgYWxzbyBiZWluZyBhY2tub3dsZWRnZWQgd2hl biBpbiBmYWN0IHRoZSBjbGllbnQgaGFkbuKAmXQgYWNrbm93bGVkZ2UgdGhlbS4gLg0KDQpUaGlz IGlzIHByb2hpYml0ZWQgY3VycmVudGx5LCBhbmQgZm9yIGdvb2QgcmVhc29uLCBzaW5jZSBhY2tp bmcgcGFja2V0cyB5b3UgaGF2ZW4ndCByZWNlaXZlZCBicmVha3MgY29uZ2VzdGlvbiBjb250cm9s IGFuZCBwb3RlbnRpYWxseSBmbG93IGNvbnRyb2wuICBBbHNvLCB5b3UnZCBiZSBhc3N1bWluZyB3 aGF0IHdhcyBpbiB0aGUgcGFja2V0cyB3YXMgd2hhdCB5b3UgZXhwZWN0ZWQsIGFuZCAgaWYgeW91 IHdlcmUgd3JvbmcsIGl0IGNvdWxkIGdvIHJlYWxseSBwb29ybHkuICBpZTogaW1hZ2luZSBpZiB5 b3UgYWNrZWQgYSBwYWNrZXQgY29udGFpbmluZyBRUEFDSyBjb21wcmVzc2lvbiBjb250ZXh0LCBi dXQgZGlkbid0IHJlY2VpdmUgaXQuICBUaGUgY29ubmVjdGlvbiB3b3VsZCB0aGVuIGJlIGluIGEg Y29tcGxldGVseSBpbnZhbGlkIHN0YXRlLg0KDQpJIGdlbmVyYWxseSBjb25zaWRlciB1bnJlbGlh YmlsaXR5IHRvIGJlIGEgbWF0dGVyIG9mIHNlbmRlciBzaWRlIHBvbGljeS4NCltUaG9tYXMgU3dp bmRlbGxzXSBJIGRvbuKAmXQgdGhpbmsgSSBhZ3JlZSB3aXRoIHRoYXQuIE9mdGVuIGl0IGlzIHRo ZSBjbGllbnQgd2hpY2ggaGFzIHRoZSBrbm93bGVkZ2UgYWJvdXQgd2hldGhlciBkYXRhIGlzIG9y IGlzIG5vdCBpbXBvcnRhbnQuIExpdmUgdmlkZW8gc3RyZWFtaW5nIGlzIHRoZSBiZXN0IGV4YW1w bGUgZm9yIHRoaXMsIGlmIHRoZSBjbGllbnQgaGFzIGVub3VnaCBidWZmZXIgYW5kIGlzIHBsYXlp bmcgdGhlIG91dHB1dCBvdXQgbGl2ZSB0aGVuIGl0IHdvdWxkIHByZWZlciB0byBnZXQgdGhlIGRh dGEgcmUtdHJhbnNtaXR0ZWQsIGhvd2V2ZXIgZGF0YSBvdmVyIGEgY2VydGFpbiBhZ2UgaXNu4oCZ dCB1c2VmdWwgYW5kIGl0IG1heSBwcmVmZXIgdG8gbG9zZSBzb21lIGZyYW1lcyBhbmQganVtcCBi YWNrIHVwIHRvIGxpdmUuIEhvd2V2ZXIgaWYgdGhlIGNsaWVudCBpcyBhY3R1YWxseSByZWNvcmRp bmcgdGhlIG91dHB1dCAob3IgaGFzIGEgbG9uZ2VyIGJ1ZmZlcikgaXQgbWF5IHByZWZlciB0byBz dGFsbCBhbmQgZ2V0IGFsbCB0aGUgZGF0YS4NCg0KDQpUaGlzIGlzIGRlZmluaXRlbHkgYW4gaW50 ZXJlc3RpbmcgdXNlIGNhc2UgYW5kIG9uZSBJIHRoaW5rIHNob3VsZCBiZSBpbiBzY29wZSBmb3Ig SFRUUCBvdmVyIFFVSUMuICBIb3dldmVyLCBhdCB0aGUgZW5kIG9mIHRoZSBkYXkgdGhlIHNlcnZl ciBuZWVkcyB0byBzZW5kIHdoYXQgdGhlIGNsaWVudCB3YW50cywgc28gaXQncyBiZXR0ZXIgdG8g aW5mb3JtIHRoZSBzZXJ2ZXIgd2hhdCB0byBzZW5kIHRoYW4gdHJpY2sgaXQuICBHaXZlbiB3ZSdy ZSBkaXNjdXNzaW5nIEhUVFAsIGlkZWFsbHkgdGhlIEhUVFAvMiBwcmlvcml0aWVzICsgY2FuY2Vs bGF0aW9uIHdvdWxkIHByb3ZpZGUgd2hhdCB5b3UgbmVlZCwgYnV0IEknbGwgYWRtaXQgYXQgdGhl IG1vbWVudCBpdCdzIG5vdCBhIG5hdHVyYWwgbWFwcGluZy4NCg0KTWFraW5nIHRoaXMgd29yayB3 ZWxsIG1heSByZXF1aXJlIGEgbW9yZSByb2J1c3QgaW50ZXJmYWNlIGJldHdlZW4gdGhlIGFwcGxp Y2F0aW9uIGFuZCBRVUlDIHN0cmVhbSwgb3IgbWF5IGp1c3QgcmVxdWlyZSBzb21lIG5ldyBmZWF0 dXJlcywgd2UnbGwgc2VlLiAgSSBjYW4ndCB0aGluayBvZiBhbnl0aGluZyBhYm91dCBtb3Zpbmcg ZnJvbSAyIHRvIDEgc3RyZWFtcyBjaGFuZ2VzIHRoaXMsIGVzcGVjaWFsbHkgZ2l2ZW4gdGhlIG5l dyBoZWFkZXIgY29tcHJlc3Npb24gc2NoZW1lcyB3aWxsIGFsbG93IGNhbmNlbGxhdGlvbiBvZiB0 aGUgaGVhZGVycyBhcyB3ZWxsIGFzIHRoZSBwYXlsb2FkLCB1bmxpa2UgYmVmb3JlLg0KDQoNCg0K DQpPbiBTdW4sIEp1bCAyMywgMjAxNyBhdCA0OjU2IEFNLCBQaGlsaXBwIFMuIFRpZXNlbCA8cGhp bHNAaW4tcGFuaWsuZGU8bWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlPj4gd3JvdGU6DQpIaSwNCg0K dG9vIGJhZCB0aGF0IEkgbWlzc2VkIHRoYXQgZGlzY3Vzc2lvbi4NCg0KU2VwYXJhdGluZyBEQVRB IGFuZCBSZXF1ZXN0L1Jlc3BvbnNlIHRvIGRpZmZlcmVudCBzdHJlYW1zIHdvdWxkIGJlIGJlbmVm aWNpYWwgaWYgd2UgYWRkIHVucmVsaWFibGUgc3RyZWFtcy4gSSB3aWxsIHRyeSB0byB3cml0ZSB1 cCBzb21ldGhpbmcgKGF0IGxlYXN0IGNvbnNpZGVyYXRpb25zKSBiZWZvcmUgdGhlIGludGVyaW0u DQoNCg0KT24gMjIuIEp1bCAyMDE3LCBhdCAwMzowNCwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3 cm90ZToNCg0KTm8sIHRoZSBjb25zZW5zdXMgYm90aCBpbiBQYXJpcyBhbmQgUHJhZ3VlIHdhcyBh IHNpbmdsZSBzdHJlYW0sIHdoaWNoIG1lYW5zIHRoZSBEQVRBIGZyYW1lIGlzIGJhY2sgdG8gc3Rh eS4gIFRoZSBIUEFDSy13aXRob3V0LWR5bmFtaWMtdGFibGUgcGllY2UgaXMgdGVtcG9yYXJ5LCB1 bnRpbCB3ZSBwaWNrIGEgZGlyZWN0aW9uIGZvciBoZWFkZXIgY29tcHJlc3Npb24uDQoNClNlbnQg ZnJvbSBteSBXaW5kb3dzIDEwIHBob25lDQoNCkZyb206IEx1Y2FzIFBhcmR1ZTxtYWlsdG86THVj YXMuUGFyZHVlQGJiYy5jby51az4NClNlbnQ6IEZyaWRheSwgSnVseSAyMSwgMjAxNyA4OjIwIEFN DQpUbzogSUVURiBRVUlDIFdHPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogSFRUUCBy ZXF1ZXN0cyBvbiBvbmUgc3RyZWFtICM2OTINCg0KSGksDQoNCkFwb2xvZ2llcyBpZiB0aGlzIHdh cyBkaXNjdXNzZWQgYWxyZWFkeSBpbiBQcmFndWUgYnV0IEnigJlkIGxpa2Ugc29tZSBjbGFyaWZp Y2F0aW9uIG9uIHRoZSBpbnRlbmRlZCBsaWZldGltZSBzY29wZSBvZiB0aGUgY2hhbmdlcyBpbiBQ UiM2OTI8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGcXVpY3dnJTJGYmFzZS1kcmFmdHMlMkZwdWxsJTJG NjkyJTJGZmlsZXMmZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29t JTdDMWE2Njg3M2VjOTgzNDk3YmY3ZGUwOGQ0ZDA0YzAzMjYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzYyNDcyMjgzNDE1MzQ3JnNkYXRhPWRaTVhwaUNZ bzViN3RWdUtyYkpDc25hUFA0Mm1xUlZpJTJCM3g0Z2FyV3J2SSUzRCZyZXNlcnZlZD0wPi4NCg0K DQogIDEuICBJcyB0aGUgaW50ZW50aW9uIHRoYXQgdGhpcyBjaGFuZ2UgdW5ibG9ja3Mgc3BlY2lm aWNhdGlvbiAvIGRldmVsb3BtZW50IHNvIHRoYXQgdGhlIFdHIGNhbiBjb250aW51ZT8NCiAgMi4g IFdpbGwgdGhlc2UgY2hhbmdlcyBiZSB1bndvdW5kIG9uY2UgcHJvZ3Jlc3MgaGFzIGJlZW4gbWFk ZT8NCg0KICAgICAqICAgVGhlIERBVEEgZnJhbWUgaGFzIGJlZW4gcmVzdXJyZWN0ZWQgKEkgcHJl c3VtZSB0byBkZW1hcmsgZnJhbWVzIGluIHRoZSBzYW1lIHN0cmVhbSkuIFdpbGwgaXQgYmUgc3Ry dWNrIHdpdGggYSB3b29kZW4gc3Rha2UgaW4gdGhlIGZ1dHVyZSwgb3IgY29udGludWUgdG8gaGFu ZyBhcm91bmQ/DQoNClRoYW5rcw0KTHVjYXMNCg0KQVZFIQ0KICBQaGlsaXBwIFMuIFRpZXNlbCAv IHBoaWxz4oCmDQotLQ0KICAge3BoaWxzfS0tLT4tLS0ocGhpbHNAaW4tcGFuaWsuZGU8bWFpbHRv OnBoaWxzQGluLXBhbmlrLmRlPiktLS0+LS0tKGh0dHA6Ly9waGlscy5pbi1wYW5pay5kZTxodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJG JTJGcGhpbHMuaW4tcGFuaWsuZGUmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5CaXNob3AlNDBtaWNy b3NvZnQuY29tJTdDNzgzYWQ4OWFlY2UyNGFkMWNlYTYwOGQ0ZDIxMjBjZjUlN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzY0NDIyNDI3MDcwMjYzJnNkYXRh PXV2RThBN3NTTEliMmJZViUyRlBGSmRPakZFZXN1eWNpY0hkZiUyQmtqcW11cyUyRk0lM0QmcmVz ZXJ2ZWQ9MD4pLS0tLSwNCiAgICAgIHdlbm4gdyBlaW5lICAgYXViZSBpc3QgZG4gICAgICBtYW4g YXUgZHJhbiBkcmUgZW4gICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICBvICAgICBTY2hy ICAgICAgICBhbiBtdXNzICAgICBoYyAgICAgICAgIGggICAoS3VydCBTY2h3aXR0ZXJzKSB8DQo6 d3EhICA8LS0tLShwaG9uZTogKzQ5LTE3OS02NzM3NDM5PHRlbDorNDklMjAxNzklMjA2NzM3NDM5 PiktLS08LS0tKGphYmJlcjogcGhpbHNAaW4tcGFuaWsuZGU8bWFpbHRvOnBoaWxzQGluLXBhbmlr LmRlPiktLS0tJw0KDQoNCg0K --_000_MWHPR21MB0141C6AA46DFF0B005972F2287BB0MWHPR21MB0141namp_ 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 YW5zLXNlcmlmO30NCnNwYW4ubTc0MDg3MjkzNjMxNTU0MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYw OTNtLTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxl LW5hbWU6bV83NDA4NzI5MzYzMTU1NDIxMzUzbS0yNDc5MTQ5MzM3MDM1NDg2MDkzbS0yODQ5ODE5 OTgyOTcxMDI4MjA1YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4ubTc0MDg3MjkzNjMxNTU0 MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6bV83NDA4 NzI5MzYzMTU1NDIxMzUzbS0yNDc5MTQ5MzM3MDM1NDg2MDkzaG9lbnpiO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjc3OTk1MzkwMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6NTY2Nzc0MTIwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjExMDg2MjUyOTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEzMjE0Nzk4ODQ7fQ0KQGxp c3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyDQoJe21zby1saXN0 LWlkOjE2NjIwMDc5NzQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEzNTg4Njg2MDY7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBOQUNLIGhh cyB0aGUgc2FtZSBwcm9ibGVtIGFzIG92ZXItYWNraW5nIOKAkyB5b3UgY2Fu4oCZdCBhY2sgZnJh bWVzLCB5b3UgYWNrIHBhY2tldHMuJm5ic3A7IFdoaWxlIEkgc2VlIHRoZSBhcmd1bWVudCBmb3Ig c2F5aW5nIHRoYXQgdW5yZWxpYWJsZSBkZWxpdmVyeSBpcyBhIGNsaWVudCBjaG9pY2UsIG5vdCBh IHNlbmRlciBvbmUsIGl0IHNlZW1zIGxpa2Ugc29tZXRoaW5nIHdlIGNvdWxkIHJlYXNvbmFibGUg ZXhwcmVzcw0KIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBhbmQgdGhlbiBoYXZlIHRoZSBzZW5k ZXIgYWN0dWFsbHkgcGVyZm9ybS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltcGxlc3Qgb3B0 aW9ucyBJIHNlZSB3b3VsZCBiZTo8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5ObyByZXRyYW5zbWlzc2lv bnMgZXZlciAobG9jYWwgY29uZmlndXJhdGlvbiB0byBzdGFjaywgUlNUX1NUUkVBTSBhZnRlciBz dHJlYW0gY29tcGxldGlvbik8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5ObyBy ZXRyYW5zbWlzc2lvbnMgYWZ0ZXIgYSBjZXJ0YWluIHRpbWVvdXQgKFJTVF9TVFJFQU0gb24gYSB0 aW1lciwgaWYgeW91IGFzc3VtZSB0aGUgc3RyZWFtIGRhdGEgYWxsIGJlY29tZXMgYXZhaWxhYmxl IGF0IG9uY2UpPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNsaWdodGx5IG1vcmUgY29t cGxleCB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSDigJxvbmx5IHJldHJhbnNtaXQgYW55IGdpdmVu IHNlZ21lbnQgb25jZeKAnSBvciDigJxnaXZlIHVwIG9uIHJldHJhbnNtaXNzaW9ucyBhZnRlciBh IHNlZ21lbnQgaXMgWCBtcyBvbGQu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEp1bHkgMjMsIDIwMTcgMjozMSBQTTxicj4NCjxiPlRv OjwvYj4gU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0gR0IpICZsdDt0aG9tYXMuc3dpbmRlbGxz QG5va2lhLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29v Z2xlLmNvbSZndDs7IE1pa2UgQmlzaG9wICZsdDtNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t Jmd0OzsgTHVjYXMgUGFyZHVlICZsdDtMdWNhcy5QYXJkdWVAYmJjLmNvLnVrJmd0OzsgSUVURiBR VUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgUGhpbGlwcCBTLiBUaWVzZWwgJmx0O3BoaWxz QGluLXBhbmlrLmRlJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogSFRUUCByZXF1ZXN0cyBv biBvbmUgc3RyZWFtICM2OTI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB5b3Ug Y2FuJ3QgYWNrbm93bGVkZ2Ugc3RyZWFtIGRhdGEgZWl0aGVyLCBvbmx5IHBhY2tldHMuIElmIHlv dSB3YW50IHRvIGtlZXAgc29tZSBmcmFtZXMgYnV0IG5vdCBvdGhlcnMsIHdoaWNoIHNlZW1zIGxp a2VseSwgb3Zlci1hY2tub3dsZWRnZW1lbnQgZG9lc24ndCB3b3JrLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjQgSnVsLiAyMDE3IDA0OjI5 LCAmcXVvdDtTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5zd2luZGVsbHNAbm9raWEuY29tIj50aG9tYXMu c3dpbmRlbGxzQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+SSBhZ3JlZSB0aGF0IGJsaW5kbHkgYWNraW5nIHBhY2tldHMgd291bGQgY2F1c2UgYmln IHByb2JsZW1zIHdpdGggdGhlIGN1cnJlbnQgb3BlcmF0aW9ucy4gQnV0IHBlcmhhcHMgaWYvd2hl biB3ZSBnZXQgb250byB1bnJlbGlhYmxlIHN0cmVhbXMgYSB3YXkgdG8gZXhwbGljaXRseQ0KIG5h Y2sgcGFja2V0cyBidXQgc3RhdGUgZG9u4oCZdCBib3RoZXIgcmV0cmFuc21pdHRpbmcgdGhlIG9u ZXMgZm9yIHN0cmVhbSB4IHdvdWxkIGJlIGEgcG90ZW50aWFsIG1lY2hhbmlzbT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj5UaG9tYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IElhbiBTd2V0dCBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFu c3dldHRAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjMgSnVseSAyMDE3IDE0 OjAzPGJyPg0KPGI+VG86PC9iPiBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlk Z2UsIFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5zd2luZGVsbHNAbm9raWEuY29tIiB0 YXJnZXQ9Il9ibGFuayI+dGhvbWFzLnN3aW5kZWxsc0Bub2tpYS5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gUGhpbGlwcCBTLiBUaWVzZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsc0Bpbi1w YW5pay5kZSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWxzQGluLXBhbmlrLmRlPC9hPiZndDs7IEx1Y2Fz IFBhcmR1ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkx1Y2FzLlBhcmR1ZUBiYmMuY28udWsiIHRhcmdl dD0iX2JsYW5rIj5MdWNhcy5QYXJkdWVAYmJjLmNvLnVrPC9hPiZndDs7IE1pa2UgQmlzaG9wICZs dDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsNCiBJRVRGIFFVSUMg V0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp Y0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBIVFRQIHJlcXVlc3Rz IG9uIG9uZSBzdHJlYW0gIzY5MjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+ T24gU3VuLCBKdWwgMjMsIDIwMTcgYXQgNzo1NyBBTSwgU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lh IC0gR0IvQ2FtYnJpZGdlLCBVSykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXMuc3dpbmRlbGxz QG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRob21hcy5zd2luZGVsbHNAbm9raWEuY29tPC9h PiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+QSBmZXcgY29tbWVudHMgbGlubGluZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj5UaG9tYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0 bzo8c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5xdWljLWJvdW5jZXNAaWV0Zi5v cmc8L3NwYW4+PC9hPjwvc3Bhbj5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPklhbiBTd2V0dDxicj4N CjxiPlNlbnQ6PC9iPiAyMyBKdWx5IDIwMTcgMTA6NTk8YnI+DQo8Yj5Ubzo8L2I+IFBoaWxpcHAg Uy4gVGllc2VsICZsdDs8c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOnBoaWxzQGlu LXBhbmlrLmRlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPnBoaWxzQGluLXBh bmlrLmRlPC9zcGFuPjwvYT48L3NwYW4+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTHVjYXMgUGFyZHVl ICZsdDs8c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOkx1Y2FzLlBhcmR1ZUBiYmMu Y28udWsiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+THVjYXMuUGFyZHVlQGJi Yy5jby51azwvc3Bhbj48L2E+PC9zcGFuPiZndDs7IE1pa2UgQmlzaG9wICZsdDs8c3BhbiBsYW5n PSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0 LmNvbTwvc3Bhbj48L2E+PC9zcGFuPiZndDs7DQogSUVURiBRVUlDIFdHICZsdDs8c3BhbiBsYW5n PSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBsYW5nPSJFTi1VUyI+cXVpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEhUVFAgcmVxdWVzdHMgb24gb25lIHN0cmVhbSAjNjkyPHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiPkEgZmV3IGNvbW1lbnRzIG9uIHVucmVsaWFibGUgc3RyZWFtcyBpbiBRVUlD LCBhbmQgdGhpcyBtYXkgYmUgYSBsb25nZXIgZGlzY3Vzc2lvbiBhbmQgSSdkIGJlIGN1cmlvdXMg dG8gcmVhZCB0aGUgY29uc2lkZXJhdGlvbnMgeW91IGhhdmUgaW4gbWluZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5RVUlDIGFzIHNwZWNpZmll ZCB0b2RheSBkZWZpbml0ZWx5IGVuYWJsZXMgdW5yZWxpYWJpbGl0eS4mbmJzcDsgRm9yIGV4YW1w bGUsIEkgY2FuIHNlbmQgc3RyZWFtIGRhdGEgb25jZSwgYW5kIGlmIHNvbWUgcG9ydGlvbiBvZiBp dCBpcyBsb3N0LCBhdCB0aGF0IHBvaW50IEkgY2FuIGRlY2lkZQ0KIGlmIEkgd2FudCB0byByZXRy YW5zbWl0IGl0IG9yIGp1c3QgY2FuY2VsIHRoZSBzdHJlYW0uJm5ic3A7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tR0Ii PltUaG9tYXMgU3dpbmRlbGxzXSBBcyBzdHJlYW0gZnJhbWVzIGNvbnRhaW4gdGhlIG9mZnNldCAm bmJzcDtjbGllbnQgcG90ZW50aWFsbHkgYWxzbyBoYXMgdGhlIG9wdGlvbiBvZiBqdXN0IGFja25v d2xlZGdpbmcgcmVjZXB0aW9uIGV2ZW4gaXQgZGlkbuKAmXQgYWN0dWFsbHkgcmVjZWl2ZQ0KIHRo ZW0gLSB0aG91Z2ggb2J2aW91c2x5IHRoaXMgd291bGQgYW5kIGNhdXNlIHByb2JsZW1zIGlmIG5v bi1zdHJlYW0gZnJhbWVzIHdlcmUgYWxzbyBiZWluZyBhY2tub3dsZWRnZWQgd2hlbiBpbiBmYWN0 IHRoZSBjbGllbnQgaGFkbuKAmXQgYWNrbm93bGVkZ2UgdGhlbS4gLjwvc3Bhbj48L2k+PC9iPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPlRoaXMgaXMgcHJvaGliaXRlZCBjdXJyZW50bHksIGFuZCBmb3IgZ29vZCByZWFzb24sIHNp bmNlIGFja2luZyBwYWNrZXRzIHlvdSBoYXZlbid0IHJlY2VpdmVkIGJyZWFrcyBjb25nZXN0aW9u IGNvbnRyb2wgYW5kIHBvdGVudGlhbGx5IGZsb3cgY29udHJvbC4mbmJzcDsgQWxzbywgeW91J2QN CiBiZSBhc3N1bWluZyB3aGF0IHdhcyBpbiB0aGUgcGFja2V0cyB3YXMgd2hhdCB5b3UgZXhwZWN0 ZWQsIGFuZCZuYnNwOyBpZiB5b3Ugd2VyZSB3cm9uZywgaXQgY291bGQgZ28gcmVhbGx5IHBvb3Js eS4mbmJzcDsgaWU6IGltYWdpbmUgaWYgeW91IGFja2VkIGEgcGFja2V0IGNvbnRhaW5pbmcgUVBB Q0sgY29tcHJlc3Npb24gY29udGV4dCwgYnV0IGRpZG4ndCByZWNlaXZlIGl0LiZuYnNwOyBUaGUg Y29ubmVjdGlvbiB3b3VsZCB0aGVuIGJlIGluIGEgY29tcGxldGVseSBpbnZhbGlkDQogc3RhdGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+SSBnZW5lcmFsbHkgY29uc2lkZXIg dW5yZWxpYWJpbGl0eSB0byBiZSBhIG1hdHRlciBvZiBzZW5kZXIgc2lkZSBwb2xpY3kuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBsYW5n PSJFTi1HQiI+W1Rob21hcyBTd2luZGVsbHNdIEkgZG9u4oCZdCB0aGluayBJIGFncmVlIHdpdGgg dGhhdC4gT2Z0ZW4gaXQgaXMgdGhlIGNsaWVudCB3aGljaCBoYXMgdGhlIGtub3dsZWRnZSBhYm91 dCB3aGV0aGVyIGRhdGEgaXMgb3IgaXMgbm90IGltcG9ydGFudC4gTGl2ZSB2aWRlbw0KIHN0cmVh bWluZyBpcyB0aGUgYmVzdCBleGFtcGxlIGZvciB0aGlzLCBpZiB0aGUgY2xpZW50IGhhcyBlbm91 Z2ggYnVmZmVyIGFuZCBpcyBwbGF5aW5nIHRoZSBvdXRwdXQgb3V0IGxpdmUgdGhlbiBpdCB3b3Vs ZCBwcmVmZXIgdG8gZ2V0IHRoZSBkYXRhIHJlLXRyYW5zbWl0dGVkLCBob3dldmVyIGRhdGEgb3Zl ciBhIGNlcnRhaW4gYWdlIGlzbuKAmXQgdXNlZnVsIGFuZCBpdCBtYXkgcHJlZmVyIHRvIGxvc2Ug c29tZSBmcmFtZXMgYW5kIGp1bXAgYmFjaw0KIHVwIHRvIGxpdmUuIEhvd2V2ZXIgaWYgdGhlIGNs aWVudCBpcyBhY3R1YWxseSByZWNvcmRpbmcgdGhlIG91dHB1dCAob3IgaGFzIGEgbG9uZ2VyIGJ1 ZmZlcikgaXQgbWF5IHByZWZlciB0byBzdGFsbCBhbmQgZ2V0IGFsbCB0aGUgZGF0YS48L3NwYW4+ PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj5UaGlzIGlzIGRlZmluaXRlbHkgYW4gaW50ZXJlc3RpbmcgdXNlIGNh c2UgYW5kIG9uZSBJIHRoaW5rIHNob3VsZCBiZSBpbiBzY29wZSBmb3IgSFRUUCBvdmVyIFFVSUMu Jm5ic3A7IEhvd2V2ZXIsIGF0IHRoZSBlbmQgb2YgdGhlIGRheSB0aGUgc2VydmVyIG5lZWRzIHRv IHNlbmQgd2hhdA0KIHRoZSBjbGllbnQgd2FudHMsIHNvIGl0J3MgYmV0dGVyIHRvIGluZm9ybSB0 aGUgc2VydmVyIHdoYXQgdG8gc2VuZCB0aGFuIHRyaWNrIGl0LiZuYnNwOyBHaXZlbiB3ZSdyZSBk aXNjdXNzaW5nIEhUVFAsIGlkZWFsbHkgdGhlIEhUVFAvMiBwcmlvcml0aWVzICYjNDM7IGNhbmNl bGxhdGlvbiB3b3VsZCBwcm92aWRlIHdoYXQgeW91IG5lZWQsIGJ1dCBJJ2xsIGFkbWl0IGF0IHRo ZSBtb21lbnQgaXQncyBub3QgYSBuYXR1cmFsIG1hcHBpbmcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5NYWtpbmcgdGhpcyB3b3JrIHdlbGwgbWF5IHJl cXVpcmUgYSBtb3JlIHJvYnVzdCBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgYXBwbGljYXRpb24gYW5k IFFVSUMgc3RyZWFtLCBvciBtYXkganVzdCByZXF1aXJlIHNvbWUgbmV3IGZlYXR1cmVzLCB3ZSds bCBzZWUuJm5ic3A7IEkgY2FuJ3QNCiB0aGluayBvZiBhbnl0aGluZyBhYm91dCBtb3ZpbmcgZnJv bSAyIHRvIDEgc3RyZWFtcyBjaGFuZ2VzIHRoaXMsIGVzcGVjaWFsbHkgZ2l2ZW4gdGhlIG5ldyBo ZWFkZXIgY29tcHJlc3Npb24gc2NoZW1lcyB3aWxsIGFsbG93IGNhbmNlbGxhdGlvbiBvZiB0aGUg aGVhZGVycyBhcyB3ZWxsIGFzIHRoZSBwYXlsb2FkLCB1bmxpa2UgYmVmb3JlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPk9uIFN1biwg SnVsIDIzLCAyMDE3IGF0IDQ6NTYgQU0sIFBoaWxpcHAgUy4gVGllc2VsICZsdDs8YSBocmVmPSJt YWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiIHRhcmdldD0iX2JsYW5rIj5waGlsc0Bpbi1wYW5pay5k ZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj50b28gYmFkIHRoYXQgSSBtaXNzZWQgdGhhdCBkaXNjdXNzaW9uLiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii PlNlcGFyYXRpbmcgREFUQSBhbmQgUmVxdWVzdC9SZXNwb25zZSB0byBkaWZmZXJlbnQgc3RyZWFt cyB3b3VsZCBiZSBiZW5lZmljaWFsIGlmIHdlIGFkZCB1bnJlbGlhYmxlIHN0cmVhbXMuIEkgd2ls bCB0cnkgdG8gd3JpdGUgdXAgc29tZXRoaW5nIChhdCBsZWFzdCBjb25zaWRlcmF0aW9ucykNCiBi ZWZvcmUgdGhlIGludGVyaW0uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+T24gMjIuIEp1bCAyMDE3LCBhdCAwMzowNCwgTWlrZSBCaXNob3AgJmx0OzxhIGhy ZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Tm8sIHRoZSBjb25zZW5zdXMg Ym90aCBpbiBQYXJpcyBhbmQgUHJhZ3VlIHdhcyBhIHNpbmdsZSBzdHJlYW0sIHdoaWNoIG1lYW5z IHRoZSBEQVRBIGZyYW1lIGlzIGJhY2sgdG8gc3RheS4mbmJzcDsgVGhlIEhQQUNLLXdpdGhvdXQt ZHluYW1pYy10YWJsZSBwaWVjZSBpcyB0ZW1wb3JhcnksDQogdW50aWwgd2UgcGljayBhIGRpcmVj dGlvbiBmb3IgaGVhZGVyIGNvbXByZXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlbnQgZnJvbSBteSBXaW5kb3dzIDEwIHBob25lPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBsYW5nPSJFTi1HQiI+RnJvbTo8c3BhbiBjbGFzcz0ibTc0MDg3MjkzNjMxNTU0 MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNtLTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIj48 YSBocmVmPSJtYWlsdG86THVjYXMuUGFyZHVlQGJiYy5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5MdWNhcw0KIFBhcmR1ZTwvc3Bhbj48L2E+PGJyPg0K PGI+U2VudDo8c3BhbiBjbGFzcz0ibTc0MDg3MjkzNjMxNTU0MjEzNTNtLTI0NzkxNDkzMzcwMzU0 ODYwOTNtLTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L2I+RnJpZGF5LCBKdWx5IDIxLCAyMDE3IDg6MjAgQU08YnI+DQo8Yj5Ubzo8c3BhbiBj bGFzcz0ibTc0MDg3MjkzNjMxNTU0MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNtLTI4NDk4MTk5 ODI5NzEwMjgyMDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+PGEgaHJl Zj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6Izk1NEY3MiI+SUVURiBRVUlDIFdHPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjxzcGFu IGNsYXNzPSJtNzQwODcyOTM2MzE1NTQyMTM1M20tMjQ3OTE0OTMzNzAzNTQ4NjA5M20tMjg0OTgx OTk4Mjk3MTAyODIwNWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5IVFRQ IHJlcXVlc3RzIG9uIG9uZSBzdHJlYW0gIzY5MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkFw b2xvZ2llcyBpZiB0aGlzIHdhcyBkaXNjdXNzZWQgYWxyZWFkeSBpbiBQcmFndWUgYnV0IEnigJlk IGxpa2Ugc29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBpbnRlbmRlZCBsaWZldGltZSBzY29wZSBv ZiB0aGUgY2hhbmdlcyBpbjxzcGFuIGNsYXNzPSJtNzQwODcyOTM2MzE1NTQyMTM1M20tMjQ3OTE0 OTMzNzAzNTQ4NjA5M20tMjg0OTgxOTk4Mjk3MTAyODIwNWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2Ut ZHJhZnRzJTJGcHVsbCUyRjY5MiUyRmZpbGVzJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJp c2hvcCU0MG1pY3Jvc29mdC5jb20lN0MxYTY2ODczZWM5ODM0OTdiZjdkZTA4ZDRkMDRjMDMyNiU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjI0NzIyODM0 MTUzNDcmYW1wO3NkYXRhPWRaTVhwaUNZbzViN3RWdUtyYkpDc25hUFA0Mm1xUlZpJTJCM3g0Z2Fy V3J2SSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjojOTU0RjcyIj5QUiM2OTI8L3NwYW4+PC9hPi48c3BhbiBjbGFzcz0ibTc0MDg3MjkzNjMxNTU0 MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNtLTI4NDk4MTk5ODI5NzEwMjgyMDVhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEg bGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1HQiI+SXMgdGhlIGludGVudGlvbiB0aGF0IHRoaXMgY2hh bmdlIHVuYmxvY2tzIHNwZWNpZmljYXRpb24gLyBkZXZlbG9wbWVudCBzbyB0aGF0IHRoZSBXRyBj YW4gY29udGludWU/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJF Ti1HQiI+V2lsbCB0aGVzZSBjaGFuZ2VzIGJlIHVud291bmQgb25jZSBwcm9ncmVzcyBoYXMgYmVl biBtYWRlPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxvbCBzdGFydD0iMiIgdHlwZT0i MSI+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzIiPg0KPHNwYW4gbGFuZz0iRU4tR0Ii PlRoZSBEQVRBIGZyYW1lIGhhcyBiZWVuIHJlc3VycmVjdGVkIChJIHByZXN1bWUgdG8gZGVtYXJr IGZyYW1lcyBpbiB0aGUgc2FtZSBzdHJlYW0pLiBXaWxsIGl0IGJlIHN0cnVjayB3aXRoIGEgd29v ZGVuIHN0YWtlIGluIHRoZSBmdXR1cmUsIG9yIGNvbnRpbnVlIHRvIGhhbmcgYXJvdW5kPzxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjwvb2w+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhh bmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+THVjYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+QVZF ITxicj4NCiZuYnNwOyBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9Im03NDA4 NzI5MzYzMTU1NDIxMzUzbS0yNDc5MTQ5MzM3MDM1NDg2MDkzaG9lbnpiIj4tLSZuYnNwOzwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0ibTc0MDg3MjkzNjMxNTU0MjEzNTNtLTI0NzkxNDkzMzcwMzU0 ODYwOTNob2VuemIiPiZuYnNwOyAmbmJzcDt7cGhpbHN9LS0tJmd0Oy0tLSg8L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48YSBocmVmPSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiIHRh cmdldD0iX2JsYW5rIj5waGlsc0Bpbi1wYW5pay5kZTwvYT48c3BhbiBjbGFzcz0ibTc0MDg3Mjkz NjMxNTU0MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNob2VuemIiPjxzcGFuIHN0eWxlPSJjb2xv cjojODg4ODg4Ij4pLS0tJmd0Oy0tLSg8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZwaGls cy5pbi1wYW5pay5kZSZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5CaXNob3AlNDBtaWNyb3Nv ZnQuY29tJTdDNzgzYWQ4OWFlY2UyNGFkMWNlYTYwOGQ0ZDIxMjBjZjUlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzY0NDIyNDI3MDcwMjYzJmFtcDtzZGF0 YT11dkU4QTdzU0xJYjJiWVYlMkZQRkpkT2pGRWVzdXljaWNIZGYlMkJranFtdXMlMkZNJTNEJmFt cDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3BoaWxzLmluLXBhbmlrLmRlPC9h PjxzcGFuIGNsYXNzPSJtNzQwODcyOTM2MzE1NTQyMTM1M20tMjQ3OTE0OTMzNzAzNTQ4NjA5M2hv ZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiktLS0tLDwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJtNzQwODcyOTM2MzE1 NTQyMTM1M20tMjQ3OTE0OTMzNzAzNTQ4NjA5M2hvZW56YiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg d2VubiB3IGVpbmUgJm5ic3A7IGF1YmUgaXN0IGRuICZuYnNwOyAmbmJzcDsgJm5ic3A7bWFuIGF1 IGRyYW4gZHJlIGVuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im03NDA4NzI5MzYz MTU1NDIxMzUzbS0yNDc5MTQ5MzM3MDM1NDg2MDkzaG9lbnpiIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7ICZuYnNwOyBTY2hyICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2FuIG11c3MgJm5ic3A7ICZuYnNwOyBoYyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgaCAmbmJzcDsgKEt1cnQgU2Nod2l0dGVycykgfDwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0ibTc0MDg3MjkzNjMxNTU0MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNob2VuemIiPjp3 cSEgJm5ic3A7Jmx0Oy0tLS0ocGhvbmU6IDwvc3Bhbj4NCjwvc3Bhbj48YSBocmVmPSJ0ZWw6JiM0 Mzs0OSUyMDE3OSUyMDY3Mzc0MzkiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ5LTE3OS02NzM3NDM5 PC9hPjxzcGFuIGNsYXNzPSJtNzQwODcyOTM2MzE1NTQyMTM1M20tMjQ3OTE0OTMzNzAzNTQ4NjA5 M2hvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiktLS0mbHQ7LS0tKGphYmJlcjoN Cjwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlIiB0YXJnZXQ9 Il9ibGFuayI+cGhpbHNAaW4tcGFuaWsuZGU8L2E+PHNwYW4gY2xhc3M9Im03NDA4NzI5MzYzMTU1 NDIxMzUzbS0yNDc5MTQ5MzM3MDM1NDg2MDkzaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+KS0tLS0nPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR21MB0141C6AA46DFF0B005972F2287BB0MWHPR21MB0141namp_-- From nobody Sun Jul 23 22:20: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 012A41296C6 for ; Sun, 23 Jul 2017 22:20:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 0xohbfpaY62b for ; Sun, 23 Jul 2017 22:20:54 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0104.outbound.protection.outlook.com [104.47.38.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5F4128B8F for ; Sun, 23 Jul 2017 22:20:53 -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=ABGbIxrgSTOilMzrg9a4XbHrJGpR8QHtvqinm/kF5YM=; b=I+WJ28NJWgRkrjQAQADS7dwNUEon2iH9ayvnZyo/3rbgiN8Kp+IT3p/3Ihhr5lcIbwYXx5a2T1YVqQrVeL6BykveK6fbutUAPJegBLY6ND9lrOWCSBwC9HUUmvCcpBOm96pltOdSQZHvHffE7q9JGdxe6nSH4fh8tLZtQTWUiRI= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0160.namprd21.prod.outlook.com (10.173.52.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Mon, 24 Jul 2017 05:20:51 +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.01.1282.008; Mon, 24 Jul 2017 05:20:51 +0000 From: Mike Bishop To: Patrick McManus , Eric Rescorla CC: Lucas Pardue , IETF QUIC WG , Martin Thomson , Martin Duke Subject: RE: New Second Implementation Draft Thread-Topic: New Second Implementation Draft Thread-Index: AQHTAYMPsVZ1kdsT/kGX6kMckMKBMaJdcN8AgAB7CgCAABgsgIAAFmUAgAABiICABFnMUA== Date: Mon, 24 Jul 2017 05:20:50 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A37748A01@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A37748A51@bgb01xud1012> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8080:5a28:a558:ef13:687c:db68] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0160; 7:T8KkAiNIyliCtJmHRPhyoQLCRe32NLDqlQ3qjVKbaJ3vfN5PvxmfQ6kV5jBvOG8Anwv0eAVt85iapNsKj5gML9Fo9K//Fh1r/SMMO2xL+5Gg1xpIlcH9AxL65Ja2nluDGjRP9DM0UpWf7frLwXH3UjWX2X7c8/us/YEyS02xpdAd4EVBmBBLoyKhuTNrgyWeQ73bVQeUO7Rg0563qEAomQ7jaDMTmOxJPSnY4NR6mbYyFogPLr8PVF+Bu12fazNt6d3b9sEZb39b+bO7vv5y6RbZY6OaptOTishj62lJy9m6Am0TCNKwn9M0D1qHqcmtLt3HsnAzINwOaoZVntuRwo6UVE0cPO/fG1TG2YcgedD2KGSXHw+h83PGxhVnQuI5EVF+sybV4Lbxqhr3QOrIClatMK7/nAeacticV16FerNtawL2WDFu/T6XsmNfO1eya7NbV3RIsmk+Kl/vGKYkmuheiiYWTkpfxSp4s7HevEp3dnrRw3SG0tXqIJPK1SAD2/tdHKAB9wWAJaztOZn2TmjrIgtf2N/j1guBJC52jzxL/XEzUnYriNlDN0K8jlRiomuDr3LHHPMUoGtwgs04jGj4siWwfQFvUTfw24J4VUgAIhXkyCr2JbkDvRj3kIM7dao7C48XZQ97CuDfhR+bxJ1ogppb//MvyQiglTAHi7CCMEAlTP+MdQ+Plwbq6bNv65NmETV3JEfWMvyEjRcNWyHhyJp6q5jYR0oCuAsGWsvWAut/26VB8LQQVfpkEe5RQqZx+NleQ5PuVshPj8urvPoBMMm7J5BrBKaMFNvpddcKL5pNHwIi8in5TqktHVr5 x-ms-office365-filtering-correlation-id: 292a262a-d5a0-4acd-78bc-08d4d253c001 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0160; x-ms-traffictypediagnostic: MWHPR21MB0160: x-exchange-antispam-report-test: UriScan:(127952516941037)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0160; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0160; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39400400002)(39860400002)(39840400002)(39450400003)(47760400005)(199003)(24454002)(377454003)(189002)(57704003)(229853002)(81166006)(6436002)(4326008)(97736004)(14454004)(8676002)(72206003)(189998001)(3280700002)(3660700001)(7736002)(81156014)(105586002)(6506006)(77096006)(7696004)(5660300001)(106356001)(8936002)(25786009)(3480700004)(2950100002)(74316002)(38730400002)(2906002)(10090500001)(39060400002)(6246003)(2900100001)(478600001)(93886004)(33656002)(6116002)(790700001)(101416001)(561944003)(50986999)(86612001)(6306002)(54896002)(10290500003)(53546010)(8990500004)(5005710100001)(55016002)(54906002)(99286003)(86362001)(9686003)(236005)(19609705001)(102836003)(53936002)(76176999)(54356999)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0160; 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_MWHPR21MB0141E6CD40B97385610701E887BB0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 05:20:51.0312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0160 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, 24 Jul 2017 05:20:56 -0000 --_000_MWHPR21MB0141E6CD40B97385610701E887BB0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgZm9sbG93IHByZWNlZGVudCDigJMgaHR0cC8xLjEgaXMgYWxyZWFkeSBkZWZpbmVkLCBz byB3aHkgbm90IGh0dHAvMC45Pw0KDQpJ4oCZZCBhbHNvIGxpa2UgdG8gbWVudGlvbiB0aGF0IG15 IHdpZmUgaXMgcGFydGljdWxhcmx5IGZvbmQgb2YgdGhlIHBhaW50IGNvbG9yIOKAnFJoaW5v4oCd IGZvciB0aGUgYXNzb2NpYXRlZCBiaWtlc2hlZC4gIPCfmIkNCg0KRnJvbTogUVVJQyBbbWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhdHJpY2sgTWNNYW51cw0KU2Vu dDogRnJpZGF5LCBKdWx5IDIxLCAyMDE3IDM6NTMgQU0NClRvOiBFcmljIFJlc2NvcmxhIDxla3JA cnRmbS5jb20+DQpDYzogTHVjYXMgUGFyZHVlIDxMdWNhcy5QYXJkdWVAYmJjLmNvLnVrPjsgSUVU RiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT47IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4NClN1Ympl Y3Q6IFJlOiBOZXcgU2Vjb25kIEltcGxlbWVudGF0aW9uIERyYWZ0DQoNCml0cyBhIGdvb2QgaWRl YSB0aGF0IG5lZWRzIGEgYmlrZXNoZWQuIGhxLW5vcCB3b3VsZCBiZSBteSBwcmVmZXJlbmNlIChz dGF5IGluIHRoZSBocSBuYW1lc3BhY2UpLi4NCg0KT24gRnJpLCBKdWwgMjEsIDIwMTcgYXQgMTI6 NDcgUE0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4g d3JvdGU6DQpoMDlxLTA1PyA6KQ0KDQpPbiBGcmksIEp1bCAyMSwgMjAxNyBhdCAyOjI3IEFNLCBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCkRvIHdlIG5lZWQgYSBwZXJtYW5lbnQgQUxQTiB0b2tl biBmb3IgdGhpcz8gIEl0IHNlZW1zIGxpa2UgYSB1c2VmdWwNCmZhY2lsaXR5IHRvIGJ1aWxkIGlu dG8gc3RhY2tzIHRoYXQgYXJlIHRyYW5zcG9ydC1vbmx5LiAgTWF5YmUgImgwOXEiLg0KDQpPbiAy MSBKdWx5IDIwMTcgYXQgMTA6MDAsIEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5jby51 azxtYWlsdG86THVjYXMuUGFyZHVlQGJiYy5jby51az4+IHdyb3RlOg0KPiBJIGFwcHJlY2lhdGUg dGhlIGZsZXhpYmlsaXR5IGJ1dCBoYXZlIGRpZmZpY3VsdHkgaW4gc2VlaW5nIGhvdyB0aGlzIHdv dWxkDQo+IGZsb3cgdGhyb3VnaCB0byBpbnRlcm9wIHRlc3RpbmcsIGhvdyBkbyB3ZSBtZWFzdXJl IHN1Y2Nlc3M/IE9uZSBwb3NzaWJsZQ0KPiBvdXRjb21lIGlzIGludGVyb3AgbGltaXRlZCB0byBz ZWxmLXRlc3Qgb2Yg4oCcYmVzcG9rZS1zaW1wbGUtYXBw4oCdIG92ZXIgUVVJQywNCj4gaXMgdGhh dCBnb29kIGVub3VnaD8gTXkgcHJlZmVyZW5jZSBpcyB0byBwaWNrIGEgbWluaW1hbCBiYXNlbGlu ZSAo4oCcZWNobyBhbmQNCj4gYW1wbGlmeeKAnSBvciB3aGF0ZXZlciBlbHNlKSBhbmQgdGhlbiBh ZGRpdGlvbmFscyBhcmUgYSBib251cyB0aGF0IGlzIHVwIHRvDQo+IGV4dGVybmFsIGNvb3JkaW5h dGlvbi4gSSB0aGluayB0aGlzIGNvbW1vbiBiYXNlbGluZSBjb3VsZCBhbHNvIGhlbHAgdG93YXJk cw0KPiBvbmdvaW5nIGNvbnNpZGVyYXRpb24gZm9yIHBlcmZvcm1hbmNlIG9yIGJlbmNobWFya2lu Zywgb3ZlciBkaXNwYXJhdGUNCj4gaW1wbGVtZW50YXRpb25zLCBhcyBhc3BlY3RzIG9mIHRoZSBw cm90b2NvbCBldm9sdmUgb3IgY2hhbmdlLg0KPg0KPg0KPg0KPiBUaGUgcHJvcG9zYWwgdG8gZG8g SFRUUCAwLjkgR0VULCBkaXNjdXNzZWQgaW4gUHJhZ3VlLCBhZGRyZXNzZXMgbXkgY29uY2VybnMu DQo+DQo+DQo+DQo+IEx1Y2FzDQo+DQo+DQoNCg0K --_000_MWHPR21MB0141E6CD40B97385610701E887BB0MWHPR21MB0141namp_ 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 LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J 4oCZZCBmb2xsb3cgcHJlY2VkZW50IOKAkyBodHRwLzEuMSBpcyBhbHJlYWR5IGRlZmluZWQsIHNv IHdoeSBub3QgaHR0cC8wLjk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJlkIGFsc28gbGlr ZSB0byBtZW50aW9uIHRoYXQgbXkgd2lmZSBpcyBwYXJ0aWN1bGFybHkgZm9uZCBvZiB0aGUgcGFp bnQgY29sb3Ig4oCcUmhpbm/igJ0gZm9yIHRoZSBhc3NvY2lhdGVkIGJpa2VzaGVkLiZuYnNwOw0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMt c2VyaWYiPiYjMTI4NTIxOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0K PC9iPlBhdHJpY2sgTWNNYW51czxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMjEsIDIw MTcgMzo1MyBBTTxicj4NCjxiPlRvOjwvYj4gRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTHVjYXMgUGFyZHVlICZsdDtMdWNhcy5QYXJkdWVAYmJjLmNv LnVrJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgTWFydGluIFRob21z b24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs7IE1hcnRpbiBEdWtlICZsdDttYXJ0 aW4uaC5kdWtlQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBTZWNv bmQgSW1wbGVtZW50YXRpb24gRHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPml0 cyBhIGdvb2QgaWRlYSB0aGF0IG5lZWRzIGEgYmlrZXNoZWQuIGhxLW5vcCB3b3VsZCBiZSBteSBw cmVmZXJlbmNlIChzdGF5IGluIHRoZSBocSBuYW1lc3BhY2UpLi4NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdWwgMjEsIDIwMTcgYXQgMTI6 NDcgUE0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRh cmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aDA5cS0wNT8gOik8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBKdWwgMjEsIDIwMTcgYXQgMjoyNyBBTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhy ZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB3ZSBuZWVkIGEgcGVybWFuZW50IEFMUE4g dG9rZW4gZm9yIHRoaXM/Jm5ic3A7IEl0IHNlZW1zIGxpa2UgYSB1c2VmdWw8YnI+DQpmYWNpbGl0 eSB0byBidWlsZCBpbnRvIHN0YWNrcyB0aGF0IGFyZSB0cmFuc3BvcnQtb25seS4mbmJzcDsgTWF5 YmUgJnF1b3Q7aDA5cSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAyMSBK dWx5IDIwMTcgYXQgMTA6MDAsIEx1Y2FzIFBhcmR1ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkx1Y2Fz LlBhcmR1ZUBiYmMuY28udWsiIHRhcmdldD0iX2JsYW5rIj5MdWNhcy5QYXJkdWVAYmJjLmNvLnVr PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBJIGFwcHJlY2lhdGUgdGhlIGZsZXhpYmlsaXR5IGJ1 dCBoYXZlIGRpZmZpY3VsdHkgaW4gc2VlaW5nIGhvdyB0aGlzIHdvdWxkPGJyPg0KJmd0OyBmbG93 IHRocm91Z2ggdG8gaW50ZXJvcCB0ZXN0aW5nLCBob3cgZG8gd2UgbWVhc3VyZSBzdWNjZXNzPyBP bmUgcG9zc2libGU8YnI+DQomZ3Q7IG91dGNvbWUgaXMgaW50ZXJvcCBsaW1pdGVkIHRvIHNlbGYt dGVzdCBvZiDigJxiZXNwb2tlLXNpbXBsZS1hcHDigJ0gb3ZlciBRVUlDLDxicj4NCiZndDsgaXMg dGhhdCBnb29kIGVub3VnaD8gTXkgcHJlZmVyZW5jZSBpcyB0byBwaWNrIGEgbWluaW1hbCBiYXNl bGluZSAo4oCcZWNobyBhbmQ8YnI+DQomZ3Q7IGFtcGxpZnnigJ0gb3Igd2hhdGV2ZXIgZWxzZSkg YW5kIHRoZW4gYWRkaXRpb25hbHMgYXJlIGEgYm9udXMgdGhhdCBpcyB1cCB0bzxicj4NCiZndDsg ZXh0ZXJuYWwgY29vcmRpbmF0aW9uLiBJIHRoaW5rIHRoaXMgY29tbW9uIGJhc2VsaW5lIGNvdWxk IGFsc28gaGVscCB0b3dhcmRzPGJyPg0KJmd0OyBvbmdvaW5nIGNvbnNpZGVyYXRpb24gZm9yIHBl cmZvcm1hbmNlIG9yIGJlbmNobWFya2luZywgb3ZlciBkaXNwYXJhdGU8YnI+DQomZ3Q7IGltcGxl bWVudGF0aW9ucywgYXMgYXNwZWN0cyBvZiB0aGUgcHJvdG9jb2wgZXZvbHZlIG9yIGNoYW5nZS48 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBwcm9wb3NhbCB0byBk byBIVFRQIDAuOSBHRVQsIGRpc2N1c3NlZCBpbiBQcmFndWUsIGFkZHJlc3NlcyBteSBjb25jZXJu cy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEx1Y2FzPGJyPg0KJmd0 Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_MWHPR21MB0141E6CD40B97385610701E887BB0MWHPR21MB0141namp_-- From nobody Mon Jul 24 07:02: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 2653C1317B1 for ; Mon, 24 Jul 2017 07:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 KnlEG4cNztQm for ; Mon, 24 Jul 2017 07:02:40 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A67D13167B for ; Mon, 24 Jul 2017 07:02:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3xGNNt0D1fz15K8l; Mon, 24 Jul 2017 16:02:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16osZX24TvA9; Mon, 24 Jul 2017 16:02:36 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11658.dip0.t-ipconnect.de [217.225.22.88]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 24 Jul 2017 16:02:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 $3273$) Subject: Re: DRAFT minutes rom IETF99 (Prague) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <067CF332-5289-40CD-9901-698446A6C212@mnot.net> Date: Mon, 24 Jul 2017 16:02:35 +0200 Cc: IETF QUIC WG , Lars Eggert Content-Transfer-Encoding: 7bit Message-Id: References: <067CF332-5289-40CD-9901-698446A6C212@mnot.net> To: Mark Nottingham 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, 24 Jul 2017 14:02:42 -0000 > Am 21.07.2017 um 15:05 schrieb Mark Nottingham : > > ... are at: > https://github.com/quicwg/wg-materials/blob/master/ietf99/minutes.md > > Corrections welcome as pull requests and in e-mail. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > > From nobody Mon Jul 24 09:34: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 9206B131E9E for ; Mon, 24 Jul 2017 09:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, LOTS_OF_MONEY=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 QiVLgy9YgEsf for ; Mon, 24 Jul 2017 09:34:31 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 A5D48131EA0 for ; Mon, 24 Jul 2017 09:34:30 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id c184so30452054wmd.0 for ; Mon, 24 Jul 2017 09:34:30 -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=njCHv3Lcyr2OMloUiankSH3i0+NRHVxejtzEXzvsNdc=; b=fz6iJ2yr1QDtU4bxg5uG+ufLcpGDds7nA1re+BIPqBTECnQlTuJyKUTWfoKsGFq29G 0kypBgQwcHgN3teJkRI3O4iclZvAIAvimmFBz5Ze6k6I0SAxzNUIlSCWa+yptEHCBpF6 YONG8zAf/DfhVDDakp8KaJUxOyNaPTdGKoq1kLjw3uu2xbLYCCK01I9GJf/LlDUo77RN KKuSRgcYDwhX9asqPr0nU42Twyy9ETutJYb3rDVW7UyTOy8bFJSI18dDfL6D1ayQqeSM 4O2jcM5BnL2LPqeD3ELMzTNEnsrr++OsBEu/VcgR8nALvnOlY2n+rDetnHJe5LtwJIQu 1nJg== 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=njCHv3Lcyr2OMloUiankSH3i0+NRHVxejtzEXzvsNdc=; b=eYzket43UpS3FKQ7+2uItvGuDP2g7XE/K+5WzABX+hSierBzX3HzHwS9fUiRRej0lT WBCJ/C1DmqqF/S+y8ds8L+YGDYsapRXa1jsfzGAH9AkgCtoD67v8uqyxp50vDDx43zi7 11F0nUi3vE9cFnBEbDFhd8ZeOHpGacY/LJyb9aKHACNSOj7AmAF6OM75PYOABDdAIeDz EN6DJLZQ9Ll+d3AjhOWOzuosvDfpTSVTgl58GBvXEJH9WD5S8gwd4XO7SEd0na4T3lRE ta9sbQ8yYs7kbSc4B+ZeIP1/H1fFmCBTuJKTKtVAnLJhibBPzU9kYoIblrsSjy3Zr2mU gkRw== X-Gm-Message-State: AIVw110bDkSlTc1ztnWn8ntYiKCXd8uCyOhu3RPAcI6IB4LH6+3S5c/o VMFIyKJmL4cQ5O/gt6TtXQv6RhgqqEGXGEo= X-Received: by 10.28.45.10 with SMTP id t10mr5722691wmt.105.1500914068844; Mon, 24 Jul 2017 09:34:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.119 with HTTP; Mon, 24 Jul 2017 09:34:28 -0700 (PDT) From: Martin Duke Date: Mon, 24 Jul 2017 09:34:28 -0700 Message-ID: Subject: Patents on RTT marking? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114240d6e97898055512c996" 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, 24 Jul 2017 16:34:34 -0000 --001a114240d6e97898055512c996 Content-Type: text/plain; charset="UTF-8" A colleague sent me this Telecom Italia patent: https://www.google.com/patents/US9264336 This seems to be at least in the neighborhood of the preferred approach for RTT measurement by middleboxes (option 3a in Prague). I find reading patents to be among the least enjoyable and productive things to do, but my reading is that this doesn't quite describe our approach here. This is partly because the concept seems to be endpoint measurement rather than middlebox measurement. Anyhow, I'm putting this out there for consideration. If people smarter than me think this covers 3a, perhaps this steers towards something like Packet Number Echo. Martin Duke --001a114240d6e97898055512c996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A colleague sent me this Telecom Italia patent:

https://www.g= oogle.com/patents/US9264336

This seems to = be at least in the neighborhood of the preferred approach for RTT measureme= nt by middleboxes (option 3a in Prague). I find reading patents to be among= the least enjoyable and productive things to do, but my reading is that th= is doesn't quite describe our approach here. This is partly because the= concept seems to be endpoint measurement rather than middlebox measurement= .

Anyhow, I'm putting this out there for consi= deration. If people smarter than me think this covers 3a, perhaps this stee= rs towards something like Packet Number Echo.

Mart= in Duke
--001a114240d6e97898055512c996-- From nobody Mon Jul 24 09:51: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 B00E7131EA9 for ; Mon, 24 Jul 2017 09:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 Itve1sgKAz1M for ; Mon, 24 Jul 2017 09:51:16 -0700 (PDT) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (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 B13E9131D21 for ; Mon, 24 Jul 2017 09:51:15 -0700 (PDT) Received: from BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v6OGpDe7006330; Mon, 24 Jul 2017 17:51:13 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) with mapi id 14.03.0319.002; Mon, 24 Jul 2017 17:51:12 +0100 From: Lucas Pardue To: Mike Bishop , Martin Thomson , "Swindells, Thomas (Nokia - GB)" CC: Ian Swett , IETF QUIC WG , "Philipp S. Tiesel" Subject: RE: HTTP requests on one stream #692 Thread-Topic: HTTP requests on one stream #692 Thread-Index: AdMCNJiq1/jFQyapRDqdWSVpnV2UvgAUdAmMAEC1AoAAAid+AAAEKlMAAAJGowAAC2QoAAAGVf6AABBbYAAAGRWsEA== Date: Mon, 24 Jul 2017 16:51:11 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A37749FC7@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> 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.213] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23214.007 x-tm-as-result: No--26.976300-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A37749FC7bgb01xud1012_" 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: Mon, 24 Jul 2017 16:51:18 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A37749FC7bgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlrZSwNCg0KVGhhbmtzIGZvciBhbnN3ZXJpbmcgbXkgaW5pdGlhbCBxdWVzdGlvbnMuDQoNClRo ZSBkaXNjdXNzaW9uIGhhcyBnb25lIG9mZiBvbiBhIGJpdCBvZiBhIHRhbmdlbnQgYnV0IGl0IGlz IHZlcnkgaW50ZXJlc3RpbmcuDQoNCk1pa2UgQmlzaG9wIHdyb3RlOg0KDQpUaGUgTkFDSyBoYXMg dGhlIHNhbWUgcHJvYmxlbSBhcyBvdmVyLWFja2luZyDigJMgeW91IGNhbuKAmXQgYWNrIGZyYW1l cywgeW91IGFjayBwYWNrZXRzLiAgV2hpbGUgSSBzZWUgdGhlIGFyZ3VtZW50IGZvciBzYXlpbmcg dGhhdCB1bnJlbGlhYmxlIGRlbGl2ZXJ5IGlzIGEgY2xpZW50IGNob2ljZSwgbm90IGEgc2VuZGVy IG9uZSwgaXQgc2VlbXMgbGlrZSBzb21ldGhpbmcgd2UgY291bGQgcmVhc29uYWJsZSBleHByZXNz IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBhbmQgdGhlbiBoYXZlIHRoZSBzZW5kZXIgYWN0dWFs bHkgcGVyZm9ybS4NCg0KU2ltcGxlc3Qgb3B0aW9ucyBJIHNlZSB3b3VsZCBiZToNCg0KICAqICAg Tm8gcmV0cmFuc21pc3Npb25zIGV2ZXIgKGxvY2FsIGNvbmZpZ3VyYXRpb24gdG8gc3RhY2ssIFJT VF9TVFJFQU0gYWZ0ZXIgc3RyZWFtIGNvbXBsZXRpb24pDQogICogICBObyByZXRyYW5zbWlzc2lv bnMgYWZ0ZXIgYSBjZXJ0YWluIHRpbWVvdXQgKFJTVF9TVFJFQU0gb24gYSB0aW1lciwgaWYgeW91 IGFzc3VtZSB0aGUgc3RyZWFtIGRhdGEgYWxsIGJlY29tZXMgYXZhaWxhYmxlIGF0IG9uY2UpDQoN ClNsaWdodGx5IG1vcmUgY29tcGxleCB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSDigJxvbmx5IHJl dHJhbnNtaXQgYW55IGdpdmVuIHNlZ21lbnQgb25jZeKAnSBvciDigJxnaXZlIHVwIG9uIHJldHJh bnNtaXNzaW9ucyBhZnRlciBhIHNlZ21lbnQgaXMgWCBtcyBvbGQu4oCdDQoNCk91ciBpbXBsZW1l bnRhdGlvbiBvZiBIVFRQIG92ZXIgbXVsdGljYXN0IFFVSUM8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXBhcmR1ZS1xdWljLWh0dHAtbWNhc3Q+IGRvZXMgc29tZXRoaW5nIHNpbWls YXIgdG8geW91ciBmaXJzdCBvcHRpb24uIFRoZSBzZW5kZXIgKHNlcnZlcikgaXMgYSBjb250aW51 YWwgc2V0IG9mIFNlcnZlciBQdXNoZXMgYW5kIGNodXJucyBvdXQgZnJhbWVzLCBpdCBwcm9ncmVz c2VzIHN0cmVhbSBzdGF0ZSBpbnRvIGNvbXBsZXRpb24gaXRzZWxmLiBUaGlzIHNlZW1zIHNpbWls YXIgdG8gdGhlIGRlc2NyaXB0aW9uIElhbiBnYXZlIGluIFByYWd1ZSAod2hlbiB0YWxraW5nIGFi b3V0IGdRVUlDIFNlcnZlciBQdXNoKSBkdXJpbmcgdGhlIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMg ZGlzY3Vzc2lvbi4NCg0KVG8gZWNobyBUaG9tYXPigJkgdmlldyBvbiBjbGllbnQgZGVjaXNpb24g bWFraW5nOyBpbiBvdXIgc2V0IHVwIHRoZSBRVUlDIGNvbnRleHQgaXMgZW50aXJlbHkgdW5pZGly ZWN0aW9uYWwgYW5kIHRoZXJlIGlzIG5vIGNoYW5uZWwgZm9yIGEgY2xpZW50IHRvIGV4cHJlc3Mg ZGVzaXJlcyBvZiBwYXJ0aWFsIHJlbGlhYmlsaXR5IG9yIHRvIE5BQ0suIEluIHRoZSBtYW55LXRv LW9uZSByZWxhdGlvbnNoaXAgZGlmZmVyZW50IHJlY2VpdmVycyAoY2xpZW50cykgbWF5IGV4cGVy aWVuY2UgZGlmZmVyZW50IG5ldHdvcmsgY29uZGl0aW9ucyBsZWFkaW5nIHRvIHZhcmlhbmNlIGlu IGxvc3QgcGFja2V0cy4gV2l0aCB0aGVzZSBjb25zdHJhaW50cyB3ZSBjdXJyZW50bHkgZGVsZWdh dGUgdGhlIGxvc3MgcmVjb3ZlcnkgdG8gYXBwbGljYXRpb24tbGF5ZXIgbWVhbnMgKEhUVFAgYnl0 ZS1yYW5nZSByZXF1ZXN0cykgb3V0c2lkZSBvZiB0aGUgUVVJQyBjb250ZXh0IChlLmcuIGJhY2sg dG8gYSBDRE4pLiBBIHRpZ2h0ZXIgaW50ZWdyYXRpb24gaXMgc29tZXRoaW5nIHdlIGFyZSBleHBs b3JpbmcsIGhlbmNlIHdoeSBJIGZpbmQgdGhpcyBkaXNjdXNzaW9uIGludGVyZXN0aW5nLiBJIGNh biBzZWUgc29tZSBraW5kIG9mIGh5YnJpZCBtb2RlIGFzIGJlaW5nIHVzZWZ1bCBpLmUuIHNlcnZl ciBkaXJlY3RlZCBwb2xpY3kgKHBlcmhhcHMgbGltaXRlZCB0byBjb25uZWN0aW9uLCBwYXRoIGV0 Yy4pIHdpdGggc3Ryb25nIGNsaWVudCBkZWNpc2lvbiBtYWtpbmcgYXNzaXN0ZWQgYnkgY2xpZW50 LXRvLXNlcnZlciBoaW50cyBmb3IgZWFjaCByZXNvdXJjZS4NCg0KTHVjYXMNCg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KaHR0cDovL3d3dy5iYmMuY28udWsNClRoaXMgZS1t YWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWlu IHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBub3QgdGhlIHZpZXdzIG9mIHRoZSBCQkMgdW5sZXNz IHNwZWNpZmljYWxseSBzdGF0ZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwg cGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0KRG8gbm90IHVzZSwgY29weSBvciBk aXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNlIG9u IGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS4NClBsZWFzZSBub3RlIHRoYXQg dGhlIEJCQyBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3IgcmVjZWl2ZWQuDQpGdXJ0aGVyIGNvbW11 bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0byB0aGlzLg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg== --_000_7CF7F94CB496BF4FAB1676F375F9666A37749FC7bgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjwhLS0gVGVtcGxhdGUgZ2VuZXJhdGVkIGJ5IEV4Y2xh aW1lciBNYWlsIERpc2NsYWltZXJzIG9uIDA1OjUxOjEyIE1vbmRheSwgMjQgSnVseSAyMDE3IC0t Pg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo YXJzZXQ9dXRmLTgiPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj5QLmI1MTA2ZDZhLTE0ZGItNGM1 ZS1iNTk0LTZhN2E0MTE3NTAzYiB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KTEkuYjUxMDZk NmEtMTRkYi00YzVlLWI1OTQtNmE3YTQxMTc1MDNiIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9 DQpESVYuYjUxMDZkNmEtMTRkYi00YzVlLWI1OTQtNmE3YTQxMTc1MDNiIHsNCglNQVJHSU46IDBj bSAwY20gMHB0DQp9DQpUQUJMRS5iNTEwNmQ2YS0xNGRiLTRjNWUtYjU5NC02YTdhNDExNzUwM2JU YWJsZSB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBT ZWN0aW9uMQ0KfQ0KPC9zdHlsZT4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWlj cm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQg RGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBh bm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJv dHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5tNzQwODcyOTM2MzE1NTQyMTM1M20tMjQ3OTE0OTMzNzAzNTQ4NjA5M20tMjg0OTgxOTk4 Mjk3MTAyODIwNWFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTptXzc0MDg3 MjkzNjMxNTU0MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNtLTI4NDk4MTk5ODI5NzEwMjgyMDVh cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5tNzQwODcyOTM2MzE1NTQyMTM1M20tMjQ3OTE0 OTMzNzAzNTQ4NjA5M2hvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXzc0MDg3MjkzNjMxNTU0MjEz NTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MjU5NDg5NzA7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjM5ODI0OTA3MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3Nzk5NTM5MDE7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjU2Njc3NDEyMCA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMTA4NjI1Mjk2Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxMzIxNDc5ODg0O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwy OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJ e21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNjYyMDA3OTc0 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzU4ODY4NjA2O30NCkBsaXN0IGwzOmxldmVsMQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJ e21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoxODU4NTQyNTE0 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjI1NzMyMDM2O30NCkBsaXN0IGw1DQoJe21zby1s aXN0LWlkOjE4Njc4Njg1Nzk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTMyMzA3MDIwO30N CkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8cCBjbGFzcz0iYjUxMDZkNmEtMTRk Yi00YzVlLWI1OTQtNmE3YTQxMTc1MDNiIj48L3A+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5NaWtlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgZm9yIGFuc3dlcmluZyBteSBpbml0aWFsIHF1ZXN0 aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+VGhlIGRpc2N1c3Npb24gaGFzIGdvbmUgb2ZmIG9uIGEgYml0IG9mIGEgdGFu Z2VudCBidXQgaXQgaXMgdmVyeSBpbnRlcmVzdGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWlrZSBCaXNob3Agd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoZSBOQUNLIGhhcyB0aGUgc2FtZSBwcm9ibGVtIGFzIG92ZXItYWNraW5nIOKA kyB5b3UgY2Fu4oCZdCBhY2sgZnJhbWVzLCB5b3UgYWNrIHBhY2tldHMuJm5ic3A7IFdoaWxlIEkg c2VlIHRoZSBhcmd1bWVudCBmb3Igc2F5aW5nIHRoYXQgdW5yZWxpYWJsZSBkZWxpdmVyeSBpcyBh IGNsaWVudCBjaG9pY2UsIG5vdCBhIHNlbmRlciBvbmUsIGl0IHNlZW1zIGxpa2Ugc29tZXRoaW5n IHdlIGNvdWxkDQogcmVhc29uYWJsZSBleHByZXNzIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBh bmQgdGhlbiBoYXZlIHRoZSBzZW5kZXIgYWN0dWFsbHkgcGVyZm9ybS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlNpbXBsZXN0IG9wdGlvbnMgSSBzZWUgd291bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+ PHNwYW4gbGFuZz0iRU4tVVMiPk5vIHJldHJhbnNtaXNzaW9ucyBldmVyIChsb2NhbCBjb25maWd1 cmF0aW9uIHRvIHN0YWNrLCBSU1RfU1RSRUFNIGFmdGVyIHN0cmVhbSBjb21wbGV0aW9uKTxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDowY207bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5ObyByZXRy YW5zbWlzc2lvbnMgYWZ0ZXIgYSBjZXJ0YWluIHRpbWVvdXQgKFJTVF9TVFJFQU0gb24gYSB0aW1l ciwgaWYgeW91IGFzc3VtZSB0aGUgc3RyZWFtIGRhdGEgYWxsIGJlY29tZXMgYXZhaWxhYmxlIGF0 IG9uY2UpPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TbGlnaHRseSBtb3JlIGNvbXBsZXggd291 bGQgYmUgc29tZXRoaW5nIGxpa2Ug4oCcb25seSByZXRyYW5zbWl0IGFueSBnaXZlbiBzZWdtZW50 IG9uY2XigJ0gb3Ig4oCcZ2l2ZSB1cCBvbiByZXRyYW5zbWlzc2lvbnMgYWZ0ZXIgYSBzZWdtZW50 IGlzIFggbXMgb2xkLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PdXIgaW1wbGVtZW50 YXRpb24gb2YgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhcmR1 ZS1xdWljLWh0dHAtbWNhc3QiPg0KSFRUUCBvdmVyIG11bHRpY2FzdCBRVUlDPC9hPiBkb2VzIHNv bWV0aGluZyBzaW1pbGFyIHRvIHlvdXIgZmlyc3Qgb3B0aW9uLiBUaGUgc2VuZGVyIChzZXJ2ZXIp IGlzIGEgY29udGludWFsIHNldCBvZiBTZXJ2ZXIgUHVzaGVzIGFuZCBjaHVybnMgb3V0IGZyYW1l cywgaXQgcHJvZ3Jlc3NlcyBzdHJlYW0gc3RhdGUgaW50byBjb21wbGV0aW9uIGl0c2VsZi4gVGhp cyBzZWVtcyBzaW1pbGFyIHRvIHRoZSBkZXNjcmlwdGlvbiBJYW4gZ2F2ZSBpbiBQcmFndWUNCiAo d2hlbiB0YWxraW5nIGFib3V0IGdRVUlDIFNlcnZlciBQdXNoKSBkdXJpbmcgdGhlIHVuaWRpcmVj dGlvbmFsIHN0cmVhbXMgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvIGVjaG8gVGhv bWFz4oCZIHZpZXcgb24gY2xpZW50IGRlY2lzaW9uIG1ha2luZzsgaW4gb3VyIHNldCB1cCB0aGUg UVVJQyBjb250ZXh0IGlzIGVudGlyZWx5IHVuaWRpcmVjdGlvbmFsIGFuZCB0aGVyZSBpcyBubyBj aGFubmVsIGZvciBhIGNsaWVudCB0byBleHByZXNzIGRlc2lyZXMgb2YgcGFydGlhbCByZWxpYWJp bGl0eSBvciB0byBOQUNLLiBJbiB0aGUgbWFueS10by1vbmUgcmVsYXRpb25zaGlwDQogZGlmZmVy ZW50IHJlY2VpdmVycyAoY2xpZW50cykgbWF5IGV4cGVyaWVuY2UgZGlmZmVyZW50IG5ldHdvcmsg Y29uZGl0aW9ucyBsZWFkaW5nIHRvIHZhcmlhbmNlIGluIGxvc3QgcGFja2V0cy4gV2l0aCB0aGVz ZSBjb25zdHJhaW50cyB3ZSBjdXJyZW50bHkgZGVsZWdhdGUgdGhlIGxvc3MgcmVjb3ZlcnkgdG8g YXBwbGljYXRpb24tbGF5ZXIgbWVhbnMgKEhUVFAgYnl0ZS1yYW5nZSByZXF1ZXN0cykgb3V0c2lk ZSBvZiB0aGUgUVVJQyBjb250ZXh0DQogKGUuZy4gYmFjayB0byBhIENETikuIEEgdGlnaHRlciBp bnRlZ3JhdGlvbiBpcyBzb21ldGhpbmcgd2UgYXJlIGV4cGxvcmluZywgaGVuY2Ugd2h5IEkgZmlu ZCB0aGlzIGRpc2N1c3Npb24gaW50ZXJlc3RpbmcuIEkgY2FuIHNlZSBzb21lIGtpbmQgb2YgaHli cmlkIG1vZGUgYXMgYmVpbmcgdXNlZnVsIGkuZS4gc2VydmVyIGRpcmVjdGVkIHBvbGljeSAocGVy aGFwcyBsaW1pdGVkIHRvIGNvbm5lY3Rpb24sIHBhdGggZXRjLikgd2l0aCBzdHJvbmcgY2xpZW50 DQogZGVjaXNpb24gbWFraW5nIGFzc2lzdGVkIGJ5IGNsaWVudC10by1zZXJ2ZXIgaGludHMgZm9y IGVhY2ggcmVzb3VyY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MdWNhczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHA+PC9wPg0KPHAgY2xhc3M9ImI1MTA2ZDZhLTE0ZGItNGM1ZS1iNTk0 LTZhN2E0MTE3NTAzYiI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9ImI1MTA2ZDZhLTE0ZGItNGM1ZS1i NTk0LTZhN2E0MTE3NTAzYiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxmb250 IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4N Cjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGEgaHJlZj0iaHR0cDovL3d3 dy5iYmMuY28udWsiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LjxzcGFuIGNsYXNzPSJpbCI+ YmJjPC9zcGFuPi48c3BhbiBjbGFzcz0iaWwiPmNvPC9zcGFuPi48c3BhbiBjbGFzcz0iaWwiPnVr PC9zcGFuPjwvYT48YnI+DQpUaGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29u ZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRo ZSB2aWV3cyBvZiB0aGUNCjxzcGFuIGNsYXNzPSJpbCI+QkJDPC9zcGFuPiB1bmxlc3Mgc3BlY2lm aWNhbGx5IHN0YXRlZC48YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxl YXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjxicj4NCkRvIG5vdCB1c2UsIGNvcHkgb3Ig ZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBv biBpdCBhbmQgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuPGJyPg0KUGxlYXNlIG5vdGUg dGhhdCB0aGUgPHNwYW4gY2xhc3M9ImlsIj5CQkM8L3NwYW4+IG1vbml0b3JzIGUtbWFpbHMgc2Vu dCBvciByZWNlaXZlZC48YnI+DQpGdXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlv dXIgY29uc2VudCB0byB0aGlzLjwvZm9udD48L2ZvbnQ+PC9mb250PjwvZm9udD48L3A+DQo8cCBj bGFzcz0iYjUxMDZkNmEtMTRkYi00YzVlLWI1OTQtNmE3YTQxMTc1MDNiIj4tLS0tLS0tLS0tLS0t LS0tLS0tLS08L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A37749FC7bgb01xud1012_-- From nobody Mon Jul 24 10:08: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 6139A126C0F for ; Mon, 24 Jul 2017 10:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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 wWmHtV6_7j3o for ; Mon, 24 Jul 2017 10:08:04 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0129.outbound.protection.outlook.com [104.47.37.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABAFE1241FC for ; Mon, 24 Jul 2017 10:08:04 -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=3KC5oywixnUOlzWMUz+WAi9vQQIAMy/3X8cwjq34kD8=; b=SkDSjomUbBceWEkPoI1nKQurg58DAnuUQYmrmhTFC9ZGZP8VmR3CriveepqSUAdk1S+YbntsRlmZgc+J4q27krDAOPO/9QQ1xsajo6t5TBcodK++L/Q9AH/6Ozn6XUX2PiD9FjL4MdutH4vCjPc5+yNY++ZDIFO8UDiLOQO/Cg0= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0159.namprd21.prod.outlook.com (10.173.52.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Mon, 24 Jul 2017 17:08:03 +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.01.1282.008; Mon, 24 Jul 2017 17:08:03 +0000 From: Mike Bishop To: Martin Duke , IETF QUIC WG Subject: RE: Patents on RTT marking? Thread-Topic: Patents on RTT marking? Thread-Index: AQHTBJq/902MDnRznU+DQU4IMuTT86JjNS+Q Date: Mon, 24 Jul 2017 17:08:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:a::6d4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0159; 7:y8p6spzgh6ZErPbOUBBIuvKmhTfN2MvbHIaqWB6rYg+Xcsw8x0Lg8F22zfaklCHqSsVnfLrPEwllj8P+qCpEax+ZH8/+Tyj4o47Zgsgrk9m6xqD1SCeSkRVlvJ3QOdtONMSxAl43z7kyK1yb2taL4FGqPpA2ZdggK9uSG3UNyOuaZBPO/koGZqDcDEGhgTn1E1oUf+vpx1kvrbPrObNufm7WbTbQ11bNrw3mOQD7x9IeP4dc2z8JeOOIzEZ3iq2yWVttTszgaqzOnEiySvh9uJZtOyCyMDppOLv3Zh4NjI6/9+RsTjtTNYXsfbP8IoxCkuuRnAQNo9hQKPkvmjy4xH3qE11grwDS53ScHOzPGJ1QvbxVAEbij1yOcSk3cHJKwhB9B5SLfkgw1JPy8lJ9ldfCPn41ppLiDZxfPnc/Ujri5GgdPBCu/8Dlmp9JNhh5vpp2FTBE9mtzgj/VyRVm9+Hrgw3Vi9JLJ99rUWyop4LFj4VFbxN7P+3MjUtXZDN0LloK4kYj6KAYIQ8Itoznaw65/RJTHVKIFhFX/az2TJwPXDJ8B7PbI2y2UsHkXISwzMcaHLyeVkJtGbiVrhUJL2cqZSXfEsMWFDAXyFTVRJwtZnwrOOGm6rysC7bWVhOhi2CGvSAKKiJHeqP3NaichhTTczjU2d4Wm3wLr6htCJk1oKKOgPhcZ1w2A+9coOGogeGtwafilgNMOyLO0DvvsFfviJIZGk7GUVTmW989DoCX50FSlS4ajv/UZAdmxJxO4ll6MD5AFueo+AezK/RYM1N8ty8RE/6yrdBbfoMXjieuD9Uj3mhFzGgW8TQlVWHd x-ms-office365-filtering-correlation-id: 98e9e105-a34c-45a9-f23e-08d4d2b68bbc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0159; x-ms-traffictypediagnostic: MWHPR21MB0159: x-exchange-antispam-report-test: UriScan:(189930954265078)(73312121905874)(211936372134217)(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)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(920507026)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0159; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0159; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39410400002)(39400400002)(39850400002)(39450400003)(47760400005)(377454003)(189002)(199003)(3480700004)(55016002)(54356999)(5005710100001)(8936002)(2950100002)(102836003)(6436002)(19609705001)(8676002)(53936002)(99286003)(7696004)(606006)(39060400002)(81156014)(33656002)(53546010)(966005)(478600001)(81166006)(25786009)(7736002)(38730400002)(50986999)(97736004)(76176999)(790700001)(6116002)(106356001)(10290500003)(6246003)(68736007)(236005)(34040400001)(101416001)(189998001)(229853002)(6306002)(9686003)(14454004)(105586002)(77096006)(3660700001)(6506006)(54896002)(2900100001)(86612001)(3280700002)(8990500004)(2906002)(86362001)(10090500001)(5660300001)(72206003)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0159; 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: multipart/alternative; boundary="_000_MWHPR21MB0141A81BB6DE600EC37D125C87BB0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 17:08:03.3879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0159 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, 24 Jul 2017 17:08:07 -0000 --_000_MWHPR21MB0141A81BB6DE600EC37D125C87BB0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsZWF2ZSBwYXRlbnQgcmVhZGluZyB0byB0aGUgbGF3eWVycy4gIExldOKAmXMgc3RhcnQgYnkg ZGVzaWduaW5nIHRoZSBiZXN0IHNvbHV0aW9uIHdlIGNhbiwgYW5kIGZpZ3VyZSBvdXQgYW55IGlt cGFjdGVkIElQIG9uY2Ugd2Uga25vdyB3aGF0IHdlIHdhbnQuDQoNCkZyb206IFFVSUMgW21haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gRHVrZQ0KU2VudDog TW9uZGF5LCBKdWx5IDI0LCAyMDE3IDk6MzQgQU0NClRvOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBQYXRlbnRzIG9uIFJUVCBtYXJraW5nPw0KDQpBIGNvbGxlYWd1ZSBz ZW50IG1lIHRoaXMgVGVsZWNvbSBJdGFsaWEgcGF0ZW50Og0KDQpodHRwczovL3d3dy5nb29nbGUu Y29tL3BhdGVudHMvVVM5MjY0MzM2PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmdvb2dsZS5jb20lMkZwYXRlbnRzJTJG VVM5MjY0MzM2JmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3 Qzg4YTMxMTQxZGNlZDQzZmUzNWZjMDhkNGQyYjFlMGNmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjM2NTEwODgwODMyNjIwNSZzZGF0YT1CcXdlTDVaNlJU QmhrZUhYaUpCUjdYV2FQakx2QXBNNSUyRkphNkUwNGJGQTAlM0QmcmVzZXJ2ZWQ9MD4NCg0KVGhp cyBzZWVtcyB0byBiZSBhdCBsZWFzdCBpbiB0aGUgbmVpZ2hib3Job29kIG9mIHRoZSBwcmVmZXJy ZWQgYXBwcm9hY2ggZm9yIFJUVCBtZWFzdXJlbWVudCBieSBtaWRkbGVib3hlcyAob3B0aW9uIDNh IGluIFByYWd1ZSkuIEkgZmluZCByZWFkaW5nIHBhdGVudHMgdG8gYmUgYW1vbmcgdGhlIGxlYXN0 IGVuam95YWJsZSBhbmQgcHJvZHVjdGl2ZSB0aGluZ3MgdG8gZG8sIGJ1dCBteSByZWFkaW5nIGlz IHRoYXQgdGhpcyBkb2Vzbid0IHF1aXRlIGRlc2NyaWJlIG91ciBhcHByb2FjaCBoZXJlLiBUaGlz IGlzIHBhcnRseSBiZWNhdXNlIHRoZSBjb25jZXB0IHNlZW1zIHRvIGJlIGVuZHBvaW50IG1lYXN1 cmVtZW50IHJhdGhlciB0aGFuIG1pZGRsZWJveCBtZWFzdXJlbWVudC4NCg0KQW55aG93LCBJJ20g cHV0dGluZyB0aGlzIG91dCB0aGVyZSBmb3IgY29uc2lkZXJhdGlvbi4gSWYgcGVvcGxlIHNtYXJ0 ZXIgdGhhbiBtZSB0aGluayB0aGlzIGNvdmVycyAzYSwgcGVyaGFwcyB0aGlzIHN0ZWVycyB0b3dh cmRzIHNvbWV0aGluZyBsaWtlIFBhY2tldCBOdW1iZXIgRWNoby4NCg0KTWFydGluIER1a2UNCg== --_000_MWHPR21MB0141A81BB6DE600EC37D125C87BB0MWHPR21MB0141namp_ 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 LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGxlYXZlIHBhdGVudCByZWFkaW5nIHRvIHRoZSBsYXd5ZXJzLiZuYnNwOyBMZXTigJlzIHN0YXJ0 IGJ5IGRlc2lnbmluZyB0aGUgYmVzdCBzb2x1dGlvbiB3ZSBjYW4sIGFuZCBmaWd1cmUgb3V0IGFu eSBpbXBhY3RlZCBJUCBvbmNlIHdlIGtub3cgd2hhdCB3ZSB3YW50LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10g PGI+T24gQmVoYWxmIE9mDQo8L2I+TWFydGluIER1a2U8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBKdWx5IDI0LCAyMDE3IDk6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7 cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUGF0ZW50cyBvbiBSVFQgbWFy a2luZz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgY29sbGVhZ3VlIHNlbnQgbWUg dGhpcyBUZWxlY29tIEl0YWxpYSBwYXRlbnQ6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5nb29nbGUuY29tJTJGcGF0ZW50 cyUyRlVTOTI2NDMzNiZhbXA7ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3Nv ZnQuY29tJTdDODhhMzExNDFkY2VkNDNmZTM1ZmMwOGQ0ZDJiMWUwY2YlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzY1MTA4ODA4MzI2MjA1JmFtcDtzZGF0 YT1CcXdlTDVaNlJUQmhrZUhYaUpCUjdYV2FQakx2QXBNNSUyRkphNkUwNGJGQTAlM0QmYW1wO3Jl c2VydmVkPTAiPmh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vcGF0ZW50cy9VUzkyNjQzMzY8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg c2VlbXMgdG8gYmUgYXQgbGVhc3QgaW4gdGhlIG5laWdoYm9yaG9vZCBvZiB0aGUgcHJlZmVycmVk IGFwcHJvYWNoIGZvciBSVFQgbWVhc3VyZW1lbnQgYnkgbWlkZGxlYm94ZXMgKG9wdGlvbiAzYSBp biBQcmFndWUpLiBJIGZpbmQgcmVhZGluZyBwYXRlbnRzIHRvIGJlIGFtb25nIHRoZSBsZWFzdCBl bmpveWFibGUgYW5kIHByb2R1Y3RpdmUgdGhpbmdzIHRvIGRvLCBidXQgbXkgcmVhZGluZyBpcyB0 aGF0DQogdGhpcyBkb2Vzbid0IHF1aXRlIGRlc2NyaWJlIG91ciBhcHByb2FjaCBoZXJlLiBUaGlz IGlzIHBhcnRseSBiZWNhdXNlIHRoZSBjb25jZXB0IHNlZW1zIHRvIGJlIGVuZHBvaW50IG1lYXN1 cmVtZW50IHJhdGhlciB0aGFuIG1pZGRsZWJveCBtZWFzdXJlbWVudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55aG93LCBJJ20gcHV0dGlu ZyB0aGlzIG91dCB0aGVyZSBmb3IgY29uc2lkZXJhdGlvbi4gSWYgcGVvcGxlIHNtYXJ0ZXIgdGhh biBtZSB0aGluayB0aGlzIGNvdmVycyAzYSwgcGVyaGFwcyB0aGlzIHN0ZWVycyB0b3dhcmRzIHNv bWV0aGluZyBsaWtlIFBhY2tldCBOdW1iZXIgRWNoby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFydGluIER1a2U8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR21MB0141A81BB6DE600EC37D125C87BB0MWHPR21MB0141namp_-- From nobody Mon Jul 24 10:11: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 17248126C0F for ; Mon, 24 Jul 2017 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 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_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no 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 tyTZlUWx-1ku for ; Mon, 24 Jul 2017 10:11:27 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0109.outbound.protection.outlook.com [104.47.41.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4995F1241FC for ; Mon, 24 Jul 2017 10:11:27 -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=QRe5TUCmFM4tj1cddu4dRTWyZDG6ggQtz02lbaG9vcI=; b=lsfUHzaBZ57XYvekGTp4UytwX5GesKecHGGCbhbLQPU0oWFhFFcOwIYEHn7Rz+ncWzHYgpKZMMmH6mwCS3Kuq1sbZ7SfmPVBtmi7I8BBP3hFO1g5v8u3O/gIF7vGr2NLRcVic7yNz5de63PMpGxY0RTa/8dMAwkl+5FL4G8PqXg= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0509.namprd21.prod.outlook.com (10.172.95.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1304.7; Mon, 24 Jul 2017 17:11:24 +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.01.1282.008; Mon, 24 Jul 2017 17:11:24 +0000 From: Mike Bishop To: Lucas Pardue , Martin Thomson , "Swindells, Thomas (Nokia - GB)" CC: "Philipp S. Tiesel" , Ian Swett , IETF QUIC WG Subject: RE: HTTP requests on one stream #692 Thread-Topic: HTTP requests on one stream #692 Thread-Index: AdMCNJiq1/jFQyapRDqdWSVpnV2UvgAUdAmMAELNc4AAAid+AAAA+mRQAAV2kgAAANuvsAAQ3neAABAmcHAAGGK7gAAAnvEQ Date: Mon, 24 Jul 2017 17:11:24 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> <7CF7F94CB496BF4FAB1676F375F9666A37749FC7@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A37749FC7@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:a::6d4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0509; 7:em8xcPwuxb9uOI5g7TU9ClOmx78Gkagv7boD5Tr2N45bd6485G6AI1uqPNCudAooQ19F/ZjN13K9RvHVzRh5aymYQvF+NeQH6EsuqNvYo4CDM7+WFRiw1Vcnjc+tFLKybhpb+4vtMTU6ryM3K4MLV1gjwR6JS0bzeHBd2QUDFaKA5QjAT5GBY4ClCX1b2qa8HA5qADlBEZ/DDnmwmqT4y/4dGJW3+2Ah3V/b4EXMRVimfzWMSFH/wHrg4z+J5veznfoAzOaiFnH1dv9SJtWQteA067cBNzzwQ6Nd8LULJD3l6Y8SdbN1pazyMh1/5FyeqxFATxR219AfTfb5XzuHZZXReqqRTIdRN/+HjdpyD/1Ezu+X5eVJdp9pKlcQG4Nkyh7V36Xn0s2q0OK7Hf1uHRSlTfMWGLXd9Ka9PpUQyyfWVTAGlIiUJHxhuXMIMj6bLRahCI6khz/MT2r+Kbkexsq9z8ZAfpx4b69IJ4uZ9Cy0CT3uwCpS0xgfYkDLZB3PhFCaCRokfq6cffq+TaQ6a77INfOiNe9fhK9ZRz9bgguyyGWTrOiG0Ztx1EBu9Cr+G4TLw8DOLhtZWqPhuSkYAz0Vk3yrebYJC0Bj9H/sKYKBo7UMF3cto1WYROVvtCfUPFuUMqdeb2bEzE0Kb04xQfr8mrWa3OE1HgZz1yjVM1OCJZRSNuVvZ5Thid7UAqleXB7G2Ib2XEgWVTw8M368qSwsoKMZqcJ66W4vgVr7emTHWyc3vKKEq+JaAwbwREaIN/0Uga+USsenVm3qfZB57sU6VVlPVUcqO8E/3IE5Czei8qAc2wbMXF1sQbm4f/pa x-ms-office365-filtering-correlation-id: 0f3e2988-b37a-42ce-3b90-08d4d2b703bd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0509; x-ms-traffictypediagnostic: MWHPR21MB0509: x-exchange-antispam-report-test: UriScan:(158342451672863)(204407124797145)(89211679590171)(189930954265078)(82608151540597)(211936372134217)(153496737603132)(219752817060721)(127952516941037)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0509; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0509; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(47760400005)(377454003)(189002)(24454002)(199003)(4326008)(189998001)(86362001)(68736007)(86612001)(53936002)(99286003)(8990500004)(55016002)(5005710100001)(54906002)(105586002)(2906002)(236005)(5660300001)(3280700002)(9686003)(2950100002)(2900100001)(790700001)(106356001)(10090500001)(93886004)(6436002)(74316002)(34040400001)(54896002)(102836003)(6116002)(3660700001)(606006)(19609705001)(10290500003)(478600001)(6246003)(50986999)(5890100001)(6506006)(76176999)(54356999)(97736004)(39060400002)(6306002)(101416001)(8676002)(14454004)(8936002)(81166006)(81156014)(53546010)(38730400002)(77096006)(966005)(7736002)(25786009)(72206003)(33656002)(229853002)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0509; 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: multipart/alternative; boundary="_000_MWHPR21MB0141CA1D9639DB4EA462223787BB0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 17:11:24.7163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0509 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, 24 Jul 2017 17:11:30 -0000 --_000_MWHPR21MB0141CA1D9639DB4EA462223787BB0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hpY2ggd291bGQgc2VlbSB0byBsZW5kIGl0c2VsZiBhZ2FpbiB0byB0aGUgaWRlYSB0aGF0IHRo ZSBzZW5kZXIgb2YgZGF0YSBkZWNpZGVzIGFuZCBjYXJyaWVzIG91dCB3aGF0IHJlbGlhYmlsaXR5 IHBvbGljeSBpdCB3YW50cy4gIChUaG91Z2ggb2YgY291cnNlLCB3aGVuIHlvdeKAmXJlIGRlYWxp bmcgd2l0aCBtdWx0aWNhc3QsIGFsbCBsb3NzIHJlY292ZXJ5IGlzIG91dCBpbiB0aGUgd2VlZHMu KQ0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTHVjYXMgUGFyZHVlDQpTZW50OiBNb25kYXksIEp1bHkgMjQsIDIwMTcgOTo1MSBBTQ0KVG86 IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPjsgTWFydGluIFRob21z b24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IFN3aW5kZWxscywgVGhvbWFzIChOb2tpYSAt IEdCKSA8dGhvbWFzLnN3aW5kZWxsc0Bub2tpYS5jb20+DQpDYzogUGhpbGlwcCBTLiBUaWVzZWwg PHBoaWxzQGluLXBhbmlrLmRlPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgSUVU RiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEhUVFAgcmVxdWVzdHMgb24g b25lIHN0cmVhbSAjNjkyDQoNCk1pa2UsDQoNClRoYW5rcyBmb3IgYW5zd2VyaW5nIG15IGluaXRp YWwgcXVlc3Rpb25zLg0KDQpUaGUgZGlzY3Vzc2lvbiBoYXMgZ29uZSBvZmYgb24gYSBiaXQgb2Yg YSB0YW5nZW50IGJ1dCBpdCBpcyB2ZXJ5IGludGVyZXN0aW5nLg0KDQpNaWtlIEJpc2hvcCB3cm90 ZToNCg0KVGhlIE5BQ0sgaGFzIHRoZSBzYW1lIHByb2JsZW0gYXMgb3Zlci1hY2tpbmcg4oCTIHlv dSBjYW7igJl0IGFjayBmcmFtZXMsIHlvdSBhY2sgcGFja2V0cy4gIFdoaWxlIEkgc2VlIHRoZSBh cmd1bWVudCBmb3Igc2F5aW5nIHRoYXQgdW5yZWxpYWJsZSBkZWxpdmVyeSBpcyBhIGNsaWVudCBj aG9pY2UsIG5vdCBhIHNlbmRlciBvbmUsIGl0IHNlZW1zIGxpa2Ugc29tZXRoaW5nIHdlIGNvdWxk IHJlYXNvbmFibGUgZXhwcmVzcyBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgYW5kIHRoZW4gaGF2 ZSB0aGUgc2VuZGVyIGFjdHVhbGx5IHBlcmZvcm0uDQoNClNpbXBsZXN0IG9wdGlvbnMgSSBzZWUg d291bGQgYmU6DQoNCiAgKiAgIE5vIHJldHJhbnNtaXNzaW9ucyBldmVyIChsb2NhbCBjb25maWd1 cmF0aW9uIHRvIHN0YWNrLCBSU1RfU1RSRUFNIGFmdGVyIHN0cmVhbSBjb21wbGV0aW9uKQ0KICAq ICAgTm8gcmV0cmFuc21pc3Npb25zIGFmdGVyIGEgY2VydGFpbiB0aW1lb3V0IChSU1RfU1RSRUFN IG9uIGEgdGltZXIsIGlmIHlvdSBhc3N1bWUgdGhlIHN0cmVhbSBkYXRhIGFsbCBiZWNvbWVzIGF2 YWlsYWJsZSBhdCBvbmNlKQ0KDQpTbGlnaHRseSBtb3JlIGNvbXBsZXggd291bGQgYmUgc29tZXRo aW5nIGxpa2Ug4oCcb25seSByZXRyYW5zbWl0IGFueSBnaXZlbiBzZWdtZW50IG9uY2XigJ0gb3Ig 4oCcZ2l2ZSB1cCBvbiByZXRyYW5zbWlzc2lvbnMgYWZ0ZXIgYSBzZWdtZW50IGlzIFggbXMgb2xk LuKAnQ0KDQpPdXIgaW1wbGVtZW50YXRpb24gb2YgSFRUUCBvdmVyIG11bHRpY2FzdCBRVUlDPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtcGFyZHVlLXF1aWMtaHR0cC1tY2Fz dCZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NhMTVjM2Y3 MTZhMTI0MTdlOTRlMDA4ZDRkMmI0Mzc2NiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzYzNjUxMTg4NjA2MDcxNTAmc2RhdGE9N1hXS2pvaEJxZ0JKdHA4Yldq RXdndDhKWEt5UG10eE91NzlwVlVlVGliZyUzRCZyZXNlcnZlZD0wPiBkb2VzIHNvbWV0aGluZyBz aW1pbGFyIHRvIHlvdXIgZmlyc3Qgb3B0aW9uLiBUaGUgc2VuZGVyIChzZXJ2ZXIpIGlzIGEgY29u dGludWFsIHNldCBvZiBTZXJ2ZXIgUHVzaGVzIGFuZCBjaHVybnMgb3V0IGZyYW1lcywgaXQgcHJv Z3Jlc3NlcyBzdHJlYW0gc3RhdGUgaW50byBjb21wbGV0aW9uIGl0c2VsZi4gVGhpcyBzZWVtcyBz aW1pbGFyIHRvIHRoZSBkZXNjcmlwdGlvbiBJYW4gZ2F2ZSBpbiBQcmFndWUgKHdoZW4gdGFsa2lu ZyBhYm91dCBnUVVJQyBTZXJ2ZXIgUHVzaCkgZHVyaW5nIHRoZSB1bmlkaXJlY3Rpb25hbCBzdHJl YW1zIGRpc2N1c3Npb24uDQoNClRvIGVjaG8gVGhvbWFz4oCZIHZpZXcgb24gY2xpZW50IGRlY2lz aW9uIG1ha2luZzsgaW4gb3VyIHNldCB1cCB0aGUgUVVJQyBjb250ZXh0IGlzIGVudGlyZWx5IHVu aWRpcmVjdGlvbmFsIGFuZCB0aGVyZSBpcyBubyBjaGFubmVsIGZvciBhIGNsaWVudCB0byBleHBy ZXNzIGRlc2lyZXMgb2YgcGFydGlhbCByZWxpYWJpbGl0eSBvciB0byBOQUNLLiBJbiB0aGUgbWFu eS10by1vbmUgcmVsYXRpb25zaGlwIGRpZmZlcmVudCByZWNlaXZlcnMgKGNsaWVudHMpIG1heSBl eHBlcmllbmNlIGRpZmZlcmVudCBuZXR3b3JrIGNvbmRpdGlvbnMgbGVhZGluZyB0byB2YXJpYW5j ZSBpbiBsb3N0IHBhY2tldHMuIFdpdGggdGhlc2UgY29uc3RyYWludHMgd2UgY3VycmVudGx5IGRl bGVnYXRlIHRoZSBsb3NzIHJlY292ZXJ5IHRvIGFwcGxpY2F0aW9uLWxheWVyIG1lYW5zIChIVFRQ IGJ5dGUtcmFuZ2UgcmVxdWVzdHMpIG91dHNpZGUgb2YgdGhlIFFVSUMgY29udGV4dCAoZS5nLiBi YWNrIHRvIGEgQ0ROKS4gQSB0aWdodGVyIGludGVncmF0aW9uIGlzIHNvbWV0aGluZyB3ZSBhcmUg ZXhwbG9yaW5nLCBoZW5jZSB3aHkgSSBmaW5kIHRoaXMgZGlzY3Vzc2lvbiBpbnRlcmVzdGluZy4g SSBjYW4gc2VlIHNvbWUga2luZCBvZiBoeWJyaWQgbW9kZSBhcyBiZWluZyB1c2VmdWwgaS5lLiBz ZXJ2ZXIgZGlyZWN0ZWQgcG9saWN5IChwZXJoYXBzIGxpbWl0ZWQgdG8gY29ubmVjdGlvbiwgcGF0 aCBldGMuKSB3aXRoIHN0cm9uZyBjbGllbnQgZGVjaXNpb24gbWFraW5nIGFzc2lzdGVkIGJ5IGNs aWVudC10by1zZXJ2ZXIgaGludHMgZm9yIGVhY2ggcmVzb3VyY2UuDQoNCkx1Y2FzDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCmh0dHA6Ly93d3cuYmJjLmNvLnVrPGh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYl MkZ3d3cuYmJjLmNvLnVrJmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0 LmNvbSU3Q2ExNWMzZjcxNmExMjQxN2U5NGUwMDhkNGQyYjQzNzY2JTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjM2NTExODg2MDYwNzE1MCZzZGF0YT1FTmFZ bkdpZmdoSXVqbXNoclI3cmM0N0RhSTJYR3ZyWENFdHJmU2dGcUZRJTNEJnJlc2VydmVkPTA+DQpU aGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkg Y29udGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUgQkJD IHVubGVzcyBzcGVjaWZpY2FsbHkgc3RhdGVkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4g ZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4NCkRvIG5vdCB1c2UsIGNv cHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxp YW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuDQpQbGVhc2Ugbm90 ZSB0aGF0IHRoZSBCQkMgbW9uaXRvcnMgZS1tYWlscyBzZW50IG9yIHJlY2VpdmVkLg0KRnVydGhl ciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5b3VyIGNvbnNlbnQgdG8gdGhpcy4NCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo= --_000_MWHPR21MB0141CA1D9639DB4EA462223787BB0MWHPR21MB0141namp_ 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 YW5zLXNlcmlmO30NCnAuYjUxMDZkNmEtMTRkYi00YzVlLWI1OTQtNmE3YTQxMTc1MDNiLCBsaS5i NTEwNmQ2YS0xNGRiLTRjNWUtYjU5NC02YTdhNDExNzUwM2IsIGRpdi5iNTEwNmQ2YS0xNGRiLTRj NWUtYjU5NC02YTdhNDExNzUwM2INCgl7bXNvLXN0eWxlLW5hbWU6YjUxMDZkNmEtMTRkYi00YzVl LWI1OTQtNmE3YTQxMTc1MDNiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5tNzQwODcyOTM2MzE1NTQyMTM1M20tMjQ3OTE0OTMzNzAzNTQ4NjA5M20tMjg0OTgx OTk4Mjk3MTAyODIwNWFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTptXzc0 MDg3MjkzNjMxNTU0MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNtLTI4NDk4MTk5ODI5NzEwMjgy MDVhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5tNzQwODcyOTM2MzE1NTQyMTM1M20tMjQ3 OTE0OTMzNzAzNTQ4NjA5M2hvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXzc0MDg3MjkzNjMxNTU0 MjEzNTNtLTI0NzkxNDkzMzcwMzU0ODYwOTNob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uaWwNCgl7bXNvLXN0eWxlLW5hbWU6aWw7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3Nzk5NTM5 MDE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjU2Njc3 NDEyMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxOTkzODI4OTYw Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzc4Njg2OTgyO30NCkBsaXN0IGwxOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWNoIHdvdWxkIHNlZW0g dG8gbGVuZCBpdHNlbGYgYWdhaW4gdG8gdGhlIGlkZWEgdGhhdCB0aGUgc2VuZGVyIG9mIGRhdGEg ZGVjaWRlcyBhbmQgY2FycmllcyBvdXQgd2hhdCByZWxpYWJpbGl0eSBwb2xpY3kgaXQgd2FudHMu Jm5ic3A7IChUaG91Z2ggb2YgY291cnNlLCB3aGVuIHlvdeKAmXJlIGRlYWxpbmcgd2l0aCBtdWx0 aWNhc3QsDQo8aT5hbGw8L2k+IGxvc3MgcmVjb3ZlcnkgaXMgb3V0IGluIHRoZSB3ZWVkcy4pPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVo YWxmIE9mDQo8L2I+THVjYXMgUGFyZHVlPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAy NCwgMjAxNyA5OjUxIEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5C aXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20mZ3Q7OyBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQikgJmx0O3Rob21h cy5zd2luZGVsbHNAbm9raWEuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUGhpbGlwcCBTLiBUaWVz ZWwgJmx0O3BoaWxzQGluLXBhbmlrLmRlJmd0OzsgSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29n bGUuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSRTogSFRUUCByZXF1ZXN0cyBvbiBvbmUgc3RyZWFtICM2OTI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5NaWtlLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+VGhhbmtzIGZvciBhbnN3ZXJpbmcgbXkgaW5pdGlhbCBxdWVzdGlv bnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgZGlzY3Vzc2lvbiBoYXMgZ29uZSBvZmYgb24gYSBi aXQgb2YgYSB0YW5nZW50IGJ1dCBpdCBpcyB2ZXJ5IGludGVyZXN0aW5nLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+TWlrZSBCaXNob3Agd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgTkFD SyBoYXMgdGhlIHNhbWUgcHJvYmxlbSBhcyBvdmVyLWFja2luZyDigJMgeW91IGNhbuKAmXQgYWNr IGZyYW1lcywgeW91IGFjayBwYWNrZXRzLiZuYnNwOyBXaGlsZSBJIHNlZSB0aGUgYXJndW1lbnQg Zm9yIHNheWluZyB0aGF0IHVucmVsaWFibGUgZGVsaXZlcnkgaXMgYSBjbGllbnQgY2hvaWNlLCBu b3QgYSBzZW5kZXIgb25lLCBpdCBzZWVtcyBsaWtlIHNvbWV0aGluZyB3ZSBjb3VsZCByZWFzb25h YmxlIGV4cHJlc3MNCiBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgYW5kIHRoZW4gaGF2ZSB0aGUg c2VuZGVyIGFjdHVhbGx5IHBlcmZvcm0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbXBsZXN0 IG9wdGlvbnMgSSBzZWUgd291bGQgYmU6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5ObyByZXRyYW5zbWlzc2lvbnMg ZXZlciAobG9jYWwgY29uZmlndXJhdGlvbiB0byBzdGFjaywgUlNUX1NUUkVBTSBhZnRlciBzdHJl YW0gY29tcGxldGlvbik8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPk5vIHJldHJhbnNtaXNz aW9ucyBhZnRlciBhIGNlcnRhaW4gdGltZW91dCAoUlNUX1NUUkVBTSBvbiBhIHRpbWVyLCBpZiB5 b3UgYXNzdW1lIHRoZSBzdHJlYW0gZGF0YSBhbGwgYmVjb21lcyBhdmFpbGFibGUgYXQgb25jZSk8 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2xpZ2h0bHkgbW9yZSBjb21wbGV4IHdvdWxk IGJlIHNvbWV0aGluZyBsaWtlIOKAnG9ubHkgcmV0cmFuc21pdCBhbnkgZ2l2ZW4gc2VnbWVudCBv bmNl4oCdIG9yIOKAnGdpdmUgdXAgb24gcmV0cmFuc21pc3Npb25zIGFmdGVyIGEgc2VnbWVudCBp cyBYIG1zIG9sZC7igJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdXIgaW1wbGVt ZW50YXRpb24gb2YgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFm dC1wYXJkdWUtcXVpYy1odHRwLW1jYXN0JmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hv cCU0MG1pY3Jvc29mdC5jb20lN0NhMTVjM2Y3MTZhMTI0MTdlOTRlMDA4ZDRkMmI0Mzc2NiU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjUxMTg4NjA2MDcx NTAmYW1wO3NkYXRhPTdYV0tqb2hCcWdCSnRwOGJXakV3Z3Q4SlhLeVBtdHhPdTc5cFZVZVRpYmcl M0QmYW1wO3Jlc2VydmVkPTAiPg0KSFRUUCBvdmVyIG11bHRpY2FzdCBRVUlDPC9hPiBkb2VzIHNv bWV0aGluZyBzaW1pbGFyIHRvIHlvdXIgZmlyc3Qgb3B0aW9uLiBUaGUgc2VuZGVyIChzZXJ2ZXIp IGlzIGEgY29udGludWFsIHNldCBvZiBTZXJ2ZXIgUHVzaGVzIGFuZCBjaHVybnMgb3V0IGZyYW1l cywgaXQgcHJvZ3Jlc3NlcyBzdHJlYW0gc3RhdGUgaW50byBjb21wbGV0aW9uIGl0c2VsZi4gVGhp cyBzZWVtcyBzaW1pbGFyIHRvIHRoZSBkZXNjcmlwdGlvbiBJYW4gZ2F2ZSBpbiBQcmFndWUNCiAo d2hlbiB0YWxraW5nIGFib3V0IGdRVUlDIFNlcnZlciBQdXNoKSBkdXJpbmcgdGhlIHVuaWRpcmVj dGlvbmFsIHN0cmVhbXMgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gZWNo byBUaG9tYXPigJkgdmlldyBvbiBjbGllbnQgZGVjaXNpb24gbWFraW5nOyBpbiBvdXIgc2V0IHVw IHRoZSBRVUlDIGNvbnRleHQgaXMgZW50aXJlbHkgdW5pZGlyZWN0aW9uYWwgYW5kIHRoZXJlIGlz IG5vIGNoYW5uZWwgZm9yIGEgY2xpZW50IHRvIGV4cHJlc3MgZGVzaXJlcyBvZiBwYXJ0aWFsIHJl bGlhYmlsaXR5IG9yIHRvIE5BQ0suIEluIHRoZSBtYW55LXRvLW9uZSByZWxhdGlvbnNoaXAgZGlm ZmVyZW50DQogcmVjZWl2ZXJzIChjbGllbnRzKSBtYXkgZXhwZXJpZW5jZSBkaWZmZXJlbnQgbmV0 d29yayBjb25kaXRpb25zIGxlYWRpbmcgdG8gdmFyaWFuY2UgaW4gbG9zdCBwYWNrZXRzLiBXaXRo IHRoZXNlIGNvbnN0cmFpbnRzIHdlIGN1cnJlbnRseSBkZWxlZ2F0ZSB0aGUgbG9zcyByZWNvdmVy eSB0byBhcHBsaWNhdGlvbi1sYXllciBtZWFucyAoSFRUUCBieXRlLXJhbmdlIHJlcXVlc3RzKSBv dXRzaWRlIG9mIHRoZSBRVUlDIGNvbnRleHQgKGUuZy4gYmFjaw0KIHRvIGEgQ0ROKS4gQSB0aWdo dGVyIGludGVncmF0aW9uIGlzIHNvbWV0aGluZyB3ZSBhcmUgZXhwbG9yaW5nLCBoZW5jZSB3aHkg SSBmaW5kIHRoaXMgZGlzY3Vzc2lvbiBpbnRlcmVzdGluZy4gSSBjYW4gc2VlIHNvbWUga2luZCBv ZiBoeWJyaWQgbW9kZSBhcyBiZWluZyB1c2VmdWwgaS5lLiBzZXJ2ZXIgZGlyZWN0ZWQgcG9saWN5 IChwZXJoYXBzIGxpbWl0ZWQgdG8gY29ubmVjdGlvbiwgcGF0aCBldGMuKSB3aXRoIHN0cm9uZyBj bGllbnQgZGVjaXNpb24NCiBtYWtpbmcgYXNzaXN0ZWQgYnkgY2xpZW50LXRvLXNlcnZlciBoaW50 cyBmb3IgZWFjaCByZXNvdXJjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+THVjYXM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJiNTEwNmQ2YS0xNGRiLTRjNWUtYjU5NC02YTdhNDExNzUwM2Ii PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iYjUxMDZkNmEtMTRkYi00YzVlLWI1OTQtNmE3YTQxMTc1MDNiIj48c3BhbiBsYW5nPSJFTi1H QiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LmJiYy5jby51ayZh bXA7ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYTE1YzNm NzE2YTEyNDE3ZTk0ZTAwOGQ0ZDJiNDM3NjYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MwJTdDNjM2MzY1MTE4ODYwNjA3MTUwJmFtcDtzZGF0YT1FTmFZbkdpZmdoSXVq bXNoclI3cmM0N0RhSTJYR3ZyWENFdHJmU2dGcUZRJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3d3dy48c3BhbiBjbGFzcz0iaWwiPmJiYzwvc3Bhbj4uPHNwYW4gY2xh c3M9ImlsIj5jbzwvc3Bhbj4uPHNwYW4gY2xhc3M9ImlsIj51azwvc3Bhbj48L2E+PGJyPg0KVGhp cyBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNv bnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0aGUgdmlld3Mgb2YgdGhlDQo8c3Bh biBjbGFzcz0iaWwiPkJCQzwvc3Bhbj4gdW5sZXNzIHNwZWNpZmljYWxseSBzdGF0ZWQuPGJyPg0K SWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5 b3VyIHN5c3RlbS48YnI+DQpEbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgd2F5IG5vciBhY3QgaW4gcmVsaWFuY2Ugb24gaXQgYW5kIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5Ljxicj4NClBsZWFzZSBub3RlIHRoYXQgdGhlIDxzcGFuIGNsYXNz PSJpbCI+QkJDPC9zcGFuPiBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3IgcmVjZWl2ZWQuPGJyPg0K RnVydGhlciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5b3VyIGNvbnNlbnQgdG8gdGhpcy48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJiNTEwNmQ2YS0xNGRiLTRjNWUtYjU5NC02YTdhNDExNzUwM2IiPjxzcGFuIGxhbmc9IkVOLUdC Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_MWHPR21MB0141CA1D9639DB4EA462223787BB0MWHPR21MB0141namp_-- From nobody Mon Jul 24 11:52: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 749D5131E9C for ; Mon, 24 Jul 2017 11:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 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_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 7nUDTvIZx3Oj for ; Mon, 24 Jul 2017 11:52:25 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0116.outbound.protection.outlook.com [104.47.37.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C788D131EE7 for ; Mon, 24 Jul 2017 11:52:22 -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=mnSKyoJFn/R/1jvF9AVqemmtDdj3U1IkOFEzI83ckFE=; b=QPA2ofQ0FdyZ+mG6Lg2lWcordCTYMpVYHlqqm17pfVL/k+bF3hUT3rL6Zwc4WvOKBU2DfJ3In2rIMvHwnU+TIwPPtULkSez8JKuGGxJ95YE5xrgcrQzQTDIHs16U9EBr+sJQhUngOJDH7tlbJ557EzNzWSKA7hAPhImCOFnTnIQ= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0638.namprd21.prod.outlook.com (10.175.141.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Mon, 24 Jul 2017 18:52:21 +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.01.1282.008; Mon, 24 Jul 2017 18:52:20 +0000 From: Mike Bishop To: IETF QUIC WG , "ietf-http-wg@w3.org" Subject: FW: New Version Notification for draft-bishop-httpbis-altsvc-quic-00.txt Thread-Topic: New Version Notification for draft-bishop-httpbis-altsvc-quic-00.txt Thread-Index: AQHTBK1dyiL63fQtrk235YezlvdytKJjUWWQ Date: Mon, 24 Jul 2017 18:52:20 +0000 Message-ID: References: <150092207410.31901.6837991788214025202.idtracker@ietfa.amsl.com> In-Reply-To: <150092207410.31901.6837991788214025202.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:a::6d4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0638; 7:84h++IocqjBXRKEJyWK7vvNpS39P7lV33073iexJHGQT8uXoVDZI98lGiFViLh2R3WfPj6514IdJUnIZVf6aIOMdjrlkpjmXTPJexagdarPlOt4pyJ0FOrtakZWo520Sf56tuX1KYysv4p6xSBVm6TmkUy041/RiHZPvqucjZoHTiFrQ62mnNoAug7lgHzEjh9+I54VCPnPCtJFP8ZQaG3ZBYzxs4ZA0TvOC6Xy80bGn9QiBJveGdw5Cl2EuhY5h59B9qPpi1fvA8Thie4+WBC6YGPo6Ym+flKJGajeBbUx3ILayg+3ywFDdphkUuD6v+/2ZCwXY2mnPwbC2CTMTwCM7NTKxKOKQrUI8O6SHk0yqL70PL8JFp5ZbJe61dksJ7r338vGN2ZHYPS+y2/S/48V520jP8Ek/UzywUQC5U+VK+MSONNduuvvfGOTpNuSPgZXOcRLkM2m242WtcQer79V0iOh8AGLmbRGEqN6ZxvLm1n2f8kRPFMhvAvwxy4slCdsBIMVB7rD7DAo5KuNUPZJh0WrzzOTxrp6nLsqnQnoVtyBCcmv4JLUl19hieu3nWpkmkoA7As5V6xJx3S8IlbOCqGw0yezUQlbr67epm5UChoULRxwy23NfC9b2xjKCH5t3NTvEjjOPdTxePnHqRYnS/MpYAsF00Ab6s72CmaLlUCbZwKQ5QJqtqhdwGE04XcUrR1f/2VM1HCHEYAfS2Z4EOVs2w8gGVbzl/CiFMd+fxMblUqRTGiRzavQb3Vm5FR5IZr3cTtIT3GLRh3Oid/QMgHI8Fl6msIlHkxWpBx+uf93zfupVyfoJ+Fvc5d4i x-ms-office365-filtering-correlation-id: d84ccafd-fe81-45fd-a3ac-08d4d2c51d6c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0638; x-ms-traffictypediagnostic: MWHPR21MB0638: x-exchange-antispam-report-test: UriScan:(89211679590171)(166708455590820)(189930954265078)(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)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0638; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0638; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(47760400005)(189002)(377424004)(377454003)(13464003)(199003)(15650500001)(9686003)(478600001)(6116002)(55016002)(68736007)(236005)(14454004)(2900100001)(25786009)(6506006)(81156014)(6306002)(81166006)(53936002)(54896002)(2473003)(72206003)(86612001)(102836003)(606006)(6436002)(99286003)(575784001)(790700001)(86362001)(8676002)(54356999)(33656002)(7696004)(8936002)(5660300001)(3660700001)(106356001)(3280700002)(97736004)(10290500003)(10090500001)(50986999)(230783001)(76176999)(77096006)(7110500001)(189998001)(38730400002)(966005)(53546010)(5005710100001)(74316002)(10710500007)(101416001)(2501003)(229853002)(2906002)(2950100002)(8990500004)(2420400007)(7736002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0638; 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: multipart/alternative; boundary="_000_MWHPR21MB0141132A1509DBED2FCE257F87BB0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 18:52:20.7631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0638 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, 24 Jul 2017 18:52:28 -0000 --_000_MWHPR21MB0141132A1509DBED2FCE257F87BB0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rml4ZXMgIzM3MTxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8z NzE+Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNlbnQ6IE1v bmRheSwgSnVseSAyNCwgMjAxNyAxMTo0OCBBTQ0KVG86IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJp c2hvcEBtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1iaXNob3AtaHR0cGJpcy1hbHRzdmMtcXVpYy0wMC50eHQNCg0KDQoNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmlzaG9wLWh0dHBiaXMtYWx0c3ZjLXF1aWMtMDAudHh0 DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWlrZSBCaXNob3AgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgICAgICAgICAg ICBkcmFmdC1iaXNob3AtaHR0cGJpcy1hbHRzdmMtcXVpYw0KDQpSZXZpc2lvbjogICAgICAgICAg ICAgIDAwDQoNClRpdGxlOiAgICAgICAgICAgICAgICAgICAgICBBTFRTVkMgRnJhbWUgaW4gSFRU UC9RVUlDDQoNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAgMjAxNy0wNy0yNA0KDQpHcm91 cDogICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAg ICAgICAgICAgICAgIDMNCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG aW50ZXJuZXQtZHJhZnRzJTJGZHJhZnQtYmlzaG9wLWh0dHBiaXMtYWx0c3ZjLXF1aWMtMDAudHh0 JmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2JiYTdhMjM2 YjE5NTQ4MTU1OTBkMDhkNGQyYzQ3ZjAxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN0MxJTdDMCU3QzYzNjM2NTE4ODc2NTQxNTk4MSZzZGF0YT1xdGZyak1jcE1wZHVwWHN1azJ6 NndvTXJ2bmZFUHh0WGFBbkUwWkM3bzE0JTNEJnJlc2VydmVkPTANCg0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1iaXNob3AtaHR0cGJp cy1hbHRzdmMtcXVpYyUyRiZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29m dC5jb20lN0NiYmE3YTIzNmIxOTU0ODE1NTkwZDA4ZDRkMmM0N2YwMSU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjUxODg3NjU0MTU5ODEmc2RhdGE9bGgy N3duR0txQmtCcDU2bjdzWW5sRGY2RlU5dThxTnNkdk1vMnluRjFMOCUzRCZyZXNlcnZlZD0wDQoN Ckh0bWxpemVkOiAgICAgICBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWJp c2hvcC1odHRwYmlzLWFsdHN2Yy1xdWljLTAwJmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9w JTQwbWljcm9zb2Z0LmNvbSU3Q2JiYTdhMjM2YjE5NTQ4MTU1OTBkMDhkNGQyYzQ3ZjAxJTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjM2NTE4ODc2NTQxNTk4 MSZzZGF0YT1kd1BQR2Jia0Ezam55VSUyQkhLRUtVNUlzb2hHJTJGajhtcXhCOTBCVXlIaEhodyUz RCZyZXNlcnZlZD0wDQoNCkh0bWxpemVkOiAgICAgICBodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYu b3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWJpc2hvcC1odHRwYmlzLWFsdHN2Yy1xdWljLTAwJmRh dGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2JiYTdhMjM2YjE5 NTQ4MTU1OTBkMDhkNGQyYzQ3ZjAxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjM2NTE4ODc2NTQxNTk4MSZzZGF0YT1hWFNKbnZYMXBicEwlMkJiNXQzWnZP RyUyRlRsR3NiTHh3VmNGJTJGdWkwS0VDJTJCNHMlM0QmcmVzZXJ2ZWQ9MA0KDQoNCg0KDQoNCkFi c3RyYWN0Og0KDQogICBbUkZDNzgzOF0gZGVmaW5lcyB0aGUgQUxUU1ZDIGZyYW1lIGZvciBIVFRQ LzIgW1JGQzc1NDBdLiAgVGhpcyBmcmFtZQ0KDQogICBpcyBlcXVhbGx5IGFwcGxpY2FibGUgdG8g SFRUUC9RVUlDIChbSS1ELmlldGYtcXVpYy1odHRwXSksIGJ1dCBuZWVkcw0KDQogICB0byBiZSBz ZXBhcmF0ZWx5IHJlZ2lzdGVyZWQuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgQUxUU1ZD DQoNCiAgIGZyYW1lIGZvciBIVFRQL1FVSUMuDQoNCg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_MWHPR21MB0141132A1509DBED2FCE257F87BB0MWHPR21MB0141namp_ 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 cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5GaXhlcyA8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8zNzEiPg0KIzM3MTwvYT4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSA8YnI+DQpTZW50OiBNb25kYXksIEp1bHkgMjQsIDIwMTcgMTE6NDggQU08YnI+DQpU bzogTWlrZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iaXNob3AtaHR0cGJp cy1hbHRzdmMtcXVpYy0wMC50eHQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWJpc2hvcC1odHRwYmlzLWFsdHN2Yy1xdWljLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaWtl IEJpc2hvcCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRyYWZ0LWJpc2hvcC1odHRwYmlzLWFsdHN2Yy1xdWljPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXZpc2lvbjombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg MDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRpdGxlOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBBTFRTVkMgRnJhbWUgaW4gSFRUUC9RVUlDPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5Eb2N1bWVudCBkYXRlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAy MDE3LTA3LTI0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Hcm91cDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBT dWJtaXNzaW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QYWdlczom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VVJMOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRmludGVybmV0LWRyYWZ0cyUyRmRyYWZ0LWJpc2hvcC1o dHRwYmlzLWFsdHN2Yy1xdWljLTAwLnR4dCZhbXA7ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNo b3AlNDBtaWNyb3NvZnQuY29tJTdDYmJhN2EyMzZiMTk1NDgxNTU5MGQwOGQ0ZDJjNDdmMDElN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzY1MTg4NzY1NDE1 OTgxJmFtcDtzZGF0YT1xdGZyak1jcE1wZHVwWHN1azJ6NndvTXJ2bmZFUHh0WGFBbkUwWkM3bzE0 JTNEJmFtcDtyZXNlcnZlZD0wIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5odHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRmludGVybmV0LWRyYWZ0cyUy RmRyYWZ0LWJpc2hvcC1odHRwYmlzLWFsdHN2Yy1xdWljLTAwLnR4dCZhbXA7ZGF0YT0wMiU3QzAx JTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYmJhN2EyMzZiMTk1NDgxNTU5MGQw OGQ0ZDJjNDdmMDElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2MzY1MTg4NzY1NDE1OTgxJmFtcDtzZGF0YT1xdGZyak1jcE1wZHVwWHN1azJ6NndvTXJ2bmZF UHh0WGFBbkUwWkM3bzE0JTNEJmFtcDtyZXNlcnZlZD0wPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5p ZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWJpc2hvcC1odHRwYmlzLWFsdHN2Yy1xdWljJTJGJmFtcDtk YXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NiYmE3YTIzNmIx OTU0ODE1NTkwZDA4ZDRkMmM0N2YwMSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdDMSU3QzAlN0M2MzYzNjUxODg3NjU0MTU5ODEmYW1wO3NkYXRhPWxoMjd3bkdLcUJrQnA1Nm43 c1lubERmNkZVOXU4cU5zZHZNbzJ5bkYxTDglM0QmYW1wO3Jlc2VydmVkPTAiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1iaXNob3AtaHR0cGJpcy1hbHRzdmMtcXVpYyUy RiZhbXA7ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYmJh N2EyMzZiMTk1NDgxNTU5MGQwOGQ0ZDJjNDdmMDElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3QzElN0MwJTdDNjM2MzY1MTg4NzY1NDE1OTgxJmFtcDtzZGF0YT1saDI3d25HS3FC a0JwNTZuN3NZbmxEZjZGVTl1OHFOc2R2TW8yeW5GMUw4JTNEJmFtcDtyZXNlcnZlZD0wPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkh0bWxpemVkOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xz LmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWJpc2hvcC1odHRwYmlzLWFsdHN2Yy1xdWljLTAwJmFt cDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NiYmE3YTIz NmIxOTU0ODE1NTkwZDA4ZDRkMmM0N2YwMSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzYzNjUxODg3NjU0MTU5ODEmYW1wO3NkYXRhPWR3UFBHYmJrQTNqbnlV JTJCSEtFS1U1SXNvaEclMkZqOG1xeEI5MEJVeUhoSGh3JTNEJmFtcDtyZXNlcnZlZD0wIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWJpc2hvcC1odHRwYmlzLWFsdHN2Yy1xdWlj LTAwJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0Ni YmE3YTIzNmIxOTU0ODE1NTkwZDA4ZDRkMmM0N2YwMSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjUxODg3NjU0MTU5ODEmYW1wO3NkYXRhPWR3UFBHYmJr QTNqbnlVJTJCSEtFS1U1SXNvaEclMkZqOG1xeEI5MEJVeUhoSGh3JTNEJmFtcDtyZXNlcnZlZD0w PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkh0bWxp emVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWJpc2hvcC1odHRwYmlz LWFsdHN2Yy1xdWljLTAwJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jv c29mdC5jb20lN0NiYmE3YTIzNmIxOTU0ODE1NTkwZDA4ZDRkMmM0N2YwMSU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNjUxODg3NjU0MTU5ODEmYW1wO3Nk YXRhPWFYU0pudlgxcGJwTCUyQmI1dDNadk9HJTJGVGxHc2JMeHdWY0YlMkZ1aTBLRUMlMkI0cyUz RCZhbXA7cmVzZXJ2ZWQ9MCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwl MkZkcmFmdC1iaXNob3AtaHR0cGJpcy1hbHRzdmMtcXVpYy0wMCZhbXA7ZGF0YT0wMiU3QzAxJTdD bWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDYmJhN2EyMzZiMTk1NDgxNTU5MGQwOGQ0 ZDJjNDdmMDElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 MzY1MTg4NzY1NDE1OTgxJmFtcDtzZGF0YT1hWFNKbnZYMXBicEwlMkJiNXQzWnZPRyUyRlRsR3Ni THh3VmNGJTJGdWkwS0VDJTJCNHMlM0QmYW1wO3Jlc2VydmVkPTA8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IFtSRkM3ODM4XSBkZWZpbmVzIHRoZSBBTFRTVkMgZnJhbWUgZm9y IEhUVFAvMiBbUkZDNzU0MF0uJm5ic3A7IFRoaXMgZnJhbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpcyBlcXVhbGx5IGFwcGxpY2FibGUgdG8g SFRUUC9RVUlDIChbSS1ELmlldGYtcXVpYy1odHRwXSksIGJ1dCBuZWVkczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHRvIGJlIHNlcGFyYXRlbHkg cmVnaXN0ZXJlZC4mbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIEFMVFNWQzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGZyYW1lIGZv ciBIVFRQL1FVSUMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgSUVURiBTZWNy ZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR21MB0141132A1509DBED2FCE257F87BB0MWHPR21MB0141namp_-- From nobody Tue Jul 25 00: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 8CCBE131897 for ; Tue, 25 Jul 2017 00:36:23 -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, 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 (2048-bit key) header.d=mnot.net header.b=MIN6eil5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UJUV7mGr 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 8c6YLDXSxTds for ; Tue, 25 Jul 2017 00:36:20 -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 A2431127978 for ; Tue, 25 Jul 2017 00:36:20 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 083DD208A1; Tue, 25 Jul 2017 03:36:20 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 25 Jul 2017 03:36:20 -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=4mRDW16xXbuCHLg6bOiY7/HKWZgBbPepW1fukx3R8 /0=; b=MIN6eil5EqKi9wwj9SCEGFlOhehfheiJqbKpVfGl/N2NdAFgZqsisvgkk M+hgPE4enGgtFuUnVIHNG+kxkKWGudvYUBEjxwmfF8hcOEyiVNOJIVnnz+rTBhXf v4BtdjWD1sQ3JawOkZkurPnj1NrfcofST056kVQTPBKByqoVHxlQStb+wdLSaD7U s6IWw89wmBnaEzxaGbvqLyZgi6ZUiRFrDZL2ThlyQApq+KYGcDDXVBpkum+3TFQf 958vPmwq/glUXEpPwOK1WG69xR+p3g0DfsrZ8Dl22P/UJlkCuVdohOpJb1A8L337 0M9Kn6aEoVA0/5QL0Rl6cp1/AW6sw== 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=4mRDW16xXbuCHLg6bO iY7/HKWZgBbPepW1fukx3R8/0=; b=UJUV7mGr5u69NkhUyLPFgQzAF0eE4sO09J 3NSlBks+ipg/CBLkyeal1QSY6GCBsNvSEOjk1iQQQoQQ6fHc1xlwiRqFCau0cd5N JvcNqFt0UhZBKQZ96ZFqpt/0SNquV/xdN8BGll82qcL7pBKkwlzSgKcdoZYjuRry srTalvpiBnZY9RlrMrXRuPOPZ4083VqffKHPhZu0gfLq/0xvj8BkqakCxk3M7dAl YYhua4Rwr+pcDR3Q5jqLNSFE3F770wCO0oFRhnfux+7Sly5xXDah9AEjnFCh+Y5A SUYPdTjudXYWB1iPHMr204dLnZ6GRCfjnYYGSraNHbW+vl9Hz37g== X-ME-Sender: X-Sasl-enc: 1sWLRHyJZexCo4lVdMeFwnmaczDbJj3aco+kPlMIcCzs 1500968179 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 0865F7E1D9; Tue, 25 Jul 2017 03:36:18 -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 10.3 $3273$) Subject: Unidirectional Streams discussion Message-Id: Date: Tue, 25 Jul 2017 17:36:15 +1000 Cc: Lars Eggert To: IETF 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, 25 Jul 2017 07:36:24 -0000 Everyone, In Prague, we discussed Unidirectional Streams. Issue: https://github.com/quicwg/base-drafts/issues/175 Draft minutes: = https://github.com/quicwg/wg-materials/blob/master/ietf99/minutes.md#unidi= rectional-streams The outcome of that discussion was that Martin would continue to work on = his proposal, and EKR would experiment with unidirectional streams in a = branch of his implementation, to gain experience with them and help = judge the amount of complexity they save or add. We'll take a look at their work at the October interim meeting. In the meantime, our approach remains bidirectional streams (including = for the purposes of Implementation Draft 2)*. Please refrain from discussing unidirectional streams on-list; if Martin = and EKR have questions to help guide their exploration, they should ask = the group, but otherwise we shouldn't be spending additional time on = this until we have their results. Thanks, * Editors / Martin Duke -- please clarify that ID2 will be using = bidirectional streams as necessary. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 25 03:05:00 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 05BEE12EACC for ; Tue, 25 Jul 2017 03:04:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=nokia.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 HW9cY_3BqKQN for ; Tue, 25 Jul 2017 03:04:55 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::71c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9A0126DEE for ; Tue, 25 Jul 2017 03:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UJkHIAKe3Akv0s/FoYV01hkb+SG/ae5PSxWl3Wh2S9c=; b=VEiQMsIjhjnV/lO+Y0dFg4d0nhvTJ5liBFSwjOQVv5UhuKgFLM10q4IvWwB9/cfOY+Bf9oOrhM1qmS8G6n/7xQ3Ts9lYL6jfKtdf6G+/rlXaAWAdtrtFYkUaVJLJ2ur5XbUEgdPqJWPnkwJ5T96ziYFCsDN9tVBWqUcttk4Bg/g= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB1063.eurprd07.prod.outlook.com (10.163.103.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Tue, 25 Jul 2017 10:04:53 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354%13]) with mapi id 15.01.1304.014; Tue, 25 Jul 2017 10:04:52 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Dmitri Tikhonov , =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= CC: Magnus Westerlund , IETF QUIC WG Subject: RE: Idea for packet numbers Thread-Topic: Idea for packet numbers Thread-Index: AQHTAT74Pm6HB4E+oUyHojrh9ct+26JcjwOAgAF4cgCAA8bLAA== Date: Tue, 25 Jul 2017 10:04:52 +0000 Message-ID: References: <20170721093732.GA31705@ubuntu-dmitri> In-Reply-To: <20170721093732.GA31705@ubuntu-dmitri> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; x-originating-ip: [82.69.101.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB1063; 7:N5OcyqfBaRKvzjDGJ26ml2C2WqQU4WW7IajfMvGFy342wN1TqoB/1O7MdajJnc7sFHnD8Sdu6uRsL3jOhJETbZityHF2KCWyyffOulp1LnkIxZi6MWW/s9VuMEMgqAHwwR6qLBux28o1Dzvy5DmI69o2Kp7uWLgtMZZnBRdqkMYfO6ipFEv1fWubGexMu/0FyKojcim7WkcCCzuYVInSAItgS1qP/lwngVul579z9gZmGWNQPAHiL2869dAspcflDMPGPhY/eOeTsx39TyD6CnQs0CZLa+iosH1R+HmPPjRg8DHmkm2F6UNhhoQZ+c7jEyq0Hxtv+/7k13DXZ/4QnpRqFkeZW8YMPYdp20G9Hm9W/V6tLeCvOj3upLrucBZURQ0ac58eVFcV0pkbWiFsrlSCAucYGiPqF7qv4uB9ue93gLiOoPkxGjUgUCfHWGJput8M3os4CyHE5Kc3KSRzAnL1q6Ly1wlQ3nTRWL1Qkx7wFNiRovPEStzeWhQ/Sas4Kfc9RuTDpZ9zL53NLCWB8eW7cUogLAhfDHTNsvBVs5ed+pSzEt6557w1YBnfx11yBMX8Skeko7dyOa6UKYYrTOq4wjEyjZ+5D4QTwvTqaNXvxUuxkzK/ojfK/kgh3W/8qlbx74ePnvvW+ptEN8Ie5+k2XUGJM5+JOQQwoY3nCmMwao1vuwptJZxWaYVsgXBdgyPv/BbUHhYkwZCgrjkkESMJmLi4mKLcbUSvt7dxp8+zfVyz+yim/yq3HFOV8HOUMXXlUlYVw+8OLLfcvymvsUgdtMoZ0KMAlDb/D5KpCP0= x-ms-office365-filtering-correlation-id: e2fab474-355b-4264-424d-08d4d344981e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB1063; x-ms-traffictypediagnostic: DB5PR07MB1063: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1063; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1063; x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39410400002)(39850400002)(39400400002)(39450400003)(199003)(13464003)(189002)(24454002)(53546010)(3480700004)(229853002)(8936002)(2950100002)(9686003)(5250100002)(5890100001)(39060400002)(68736007)(53936002)(478600001)(86362001)(38730400002)(6506006)(7736002)(305945005)(101416001)(14454004)(81156014)(81166006)(76176999)(50986999)(54356999)(6246003)(6436002)(54906002)(99286003)(55016002)(33656002)(8676002)(105586002)(189998001)(66066001)(106356001)(97736004)(74316002)(25786009)(5660300001)(6116002)(7696004)(3660700001)(102836003)(3280700002)(3846002)(2900100001)(4326008)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1063; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 10:04:52.7347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1063 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, 25 Jul 2017 10:04:59 -0000 I've been thinking about packet numbers and what it is safe to reason about= them. With regards to packet numbers the key parts of the spec appear to be: a) The packet number for sending MUST increase by at least one after sendi= ng any packet, unless otherwise specified b) A QUIC endpoint MUST NOT reuse a packet number within the same connectio= n c) The sender MUST use a packet number size able to represent more than twi= ce as large a range than the difference between the largest acknowledged pa= cket and packet number being sent. d) An endpoint SHOULD retain old keys for a short period to allow it to dec= rypt packets with smaller packet numbers than the packet that triggered the= key update. This allows an endpoint to consume packets that are reordered = around the transition between keys. Packets with higher packet numbers alwa= ys use the updated keys and MUST NOT be decrypted with old keys. >From a receivers point of view we actively ignore a and assume that there m= ay be packet reordering and packet loss in the network.=20 Packet reordering means that packet numbers won't appear in order. Packet l= oss and the subsequent retransmission with a new packet number means that (= retransmitted) lower offset stream data may arrive with a higher packet num= ber. The receiver is expected to deal with these as part of normal operatio= n. >From the senders perspective the process it goes through is: 1. Get data to send 2. Get packet number 3. encrypt packet 4. queue packet on NIC 5. NIC sends packet. On a single threaded single stream application an implementation written to= spec would sequentially create packets in order, encrypt them and the nic = should then send them out in order onto the network. However on a multi-cpu server sending multiple streams in the same connecti= ons things get much harder to reason about. We can assume that each stream = is likely being generated by a different application thread (to avoid serve= r side head of line blocking etc) and so be producing packets concurrently. One option is to serialise the sending, so that after step 1 the request en= ters a synchronized serialized process and proceeds with strict ordering al= lowing requirement a to be met. This option isn't however efficient or desirable for a performance optimize= d solution. On a multi-cpu system, for optimal performance you want to take advantage o= f data locality (it is expensive to shuffle data between CPU cores when you= don't have to). The obvious design would be to have an atomic counter for = the packet number and do steps 1-4 within the thread (or at least CPU) that= is generating the data. With multiple streams being generated on multiple = cpu cores there is no guarantee that the order the packet numbers are assig= ned for the packets will match the order that the packets are queued on the= NIC. The higher numbered packet may get encrypted quicker and so enqueued = and sent ahead of the earlier packet number. At the wire level this would g= ive an egress pattern where the packet numbers weren't increasing after eve= ry packet, only over the longer run. If the server has multiple NICS then the problem has potential of occurring= even if steps 1-4 had been serialized via a cross cpu semaphore/lock. Diff= erent NICS will be attached to different CPU cores and an efficient OS coul= d try to avoid cross CPU communication by queuing the packet on a NIC conne= cted to the same CPU as the thread that generated the packet. If different = threads are generating the packets on different cores then potentially the = packets could be queued on different NICS and therefore be sent out of orde= r even if they were queued in order. Obviously we have established that a receiver should be designed to expect = and handle packet re-ordering and it is unknown to the receiver whether it = is in the network or host where the re-ordering occurs. From an end to end = point of view a multi-threaded implementation would work. If the multi-thre= aded implementation strictly complies with a then I'm unsure, it depends wh= at part of the process is defined as 'sending' and where the measurement to= validate it should be taken (e.g. the point the packets appear on the netw= ork vs the point the intention to create a packet to send is actioned). To complicate matters further, an implementer may not want to allocated pac= ket numbers one by one. If they know they have 32 packets worth of data to = send then perhaps it is more efficient to request 32 packet numbers in a si= ngle atomic operation and then encrypt and enqueue the packets in turn. If = another thread on a less loaded cpu is also generating stream data then pac= ket number re-ordering may occur to an even greater extend. Again (within l= imits) the receiver should cope with this level of packet re-ordering - as = long as the packet number size constraints aren't violated and the packets = arrive in a timely manner. However it does break the assumption that you ca= n generally rely on the low order bits of packet numbers to be generally se= nt in order. The packet re-ordering issue also impact requirements around streams ids be= ing created sequentially in order as the same set of race conditions can oc= cur. I think it may be worthwhile clarifying what the packet number behaviour is= expected to look like from an external observers perspective. Is there act= ually a desire to attempt to force the sender to serialize packet sending? = That is, does quic require that the egress from the host is strictly in ord= er and only the network can introduce re-ordering? Whilst keeping within th= e constraints of b-d, is/should it be acceptable that an implementation all= ocates blocks of contiguous packet numbers for each stream? If probably wou= ld mean you end up with gaps in packet numbers when a stream doesn't use al= l of its allocation in time (e.g a key change requires it to move to a new = allocation). If it isn't acceptable then what are the constraints the sende= r should keep within? Thomas > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov > Sent: 21 July 2017 10:38 > To: Mikkel Fahn=F8e J=F8rgensen > Cc: Magnus Westerlund ; IETF QUIC WG > > Subject: Re: Idea for packet numbers >=20 > On Thu, Jul 20, 2017 at 07:10:11AM -0400, Mikkel Fahn=F8e J=F8rgensen wro= te: > > For other reasons I would like the packet numbers to be close, > > preferably without gaps except during connection migration. > > > > This relates to storing interval maps as groups of bitmaps instead of > > binary trees to track already received packets. This both provides are > > more efficient implementation, and it reduces some modes of DoS where > > an attacker can create a lot of small intervals which cause the data > > structure to inflate. >=20 > The receive history gets truncated automatically, and so the receiver doe= s not > have to worry about a lot of data to keep track of. From [draft-ietf-qui= c- > transport] 8.13: >=20 > " To limit ACK blocks to those that have not yet been received " by the > sender, the receiver SHOULD track which ACK frames " have been > acknowledged by its peer. Once an ACK frame has " been acknowledged, th= e > packets it acknowledges SHOULD not be " acknowledged again. >=20 > Send history is another matter. Ibid., 8.13: >=20 > " The sender SHOULD close the connection if an unsent packet " number i= s > acknowledged. >=20 > (Previous versions of the draft had a MUST instead of a SHOULD.) >=20 > Thus it is in the interest of the sender either to create few gaps or to = create > them in a manner that does not blow up its own send history data structur= es if > it wants to check whether an unsent packet is ACKed. >=20 > - Dmitri. From nobody Tue Jul 25 05:12: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 1355A129A92 for ; Tue, 25 Jul 2017 05:12:34 -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, 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 X5MAcWsXc5aZ for ; Tue, 25 Jul 2017 05:12: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 7FB9512EB9B for ; Tue, 25 Jul 2017 05:12:30 -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 v6PCBPWt028356 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jul 2017 14:11:25 +0200 Received: from [193.173.217.30] (helo=[100.124.166.161]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dZygF-0002iK-Vz; Tue, 25 Jul 2017 14:11:16 +0200 From: "Philipp S. Tiesel" Message-Id: <9914D466-6293-447C-B3FC-839CFFF9298B@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_75740E02-D204-4807-BF9E-186009D52212" Mime-Version: 1.0 (Mac OS X Mail 10.3 $3273$) Subject: Unreliable Stream (was: Re: HTTP requests on one stream #692) Date: Tue, 25 Jul 2017 14:11:23 +0200 In-Reply-To: Cc: Martin Thomson , "Swindells, Thomas (Nokia - GB)" , Ian Swett , Lucas Pardue , IETF QUIC WG To: Mike Bishop References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> 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, 25 Jul 2017 12:12:34 -0000 --Apple-Mail=_75740E02-D204-4807-BF9E-186009D52212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, as the discussion is still hot, here the basic ideas we wanted to push = for unreliable streams. > On 24. Jul 2017, at 07:18, Mike Bishop > wrote: >=20 > While I see the argument for saying that unreliable delivery is a = client choice, not a sender one, it seems like something we could = reasonable express at the application layer and then have the sender = actually perform. For the case of HTTP =E2=80=93 Full ACK. > =20 > Simplest options I see would be: > No retransmissions ever (local configuration to stack, RST_STREAM = after stream completion) > No retransmissions after a certain timeout (RST_STREAM on a timer, if = you assume the stream data all becomes available at once) > =20 > Slightly more complex would be something like =E2=80=9Conly retransmit = any given segment once=E2=80=9D or =E2=80=9Cgive up on retransmissions = after a segment is X ms old.=E2=80=9D In case of HTTP, all three options could be requested via an HTTP = request header.=20 Optional, in case the server does not support unreliable streams, = fallback to reliable transmission. An open question is question is how to present a stream with =E2=80=9Chole= s=E2=80=9D to the application. On the QUIC layer, as it is much easier to implement, unreliable = transmission is driven by the sender. Retransmissions can then be done = depending on the applications choice. Depending on other open discussion, the sender tells the receiver about=20= unreliable transmission by ether a flag bit in the stream frame or in the START_STREA frame. The receiver must set a RST_STREM, if it can=E2=80=99= t handle=20 unreliable streams. 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 = )----' --Apple-Mail=_75740E02-D204-4807-BF9E-186009D52212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

as = the discussion is still hot, here the basic ideas we wanted to push for = unreliable streams.

On 24. Jul 2017, at 07:18, Mike = Bishop <Michael.Bishop@microsoft.com> wrote:

While I see the argument for saying that unreliable delivery = is a client choice, not a sender one, it seems like something we could = reasonable express at the application layer and then have the sender = actually perform.

For the case of HTTP =E2=80=93 Full ACK.

Simplest options I see would be:
No = retransmissions ever (local configuration to stack, RST_STREAM after = stream completion)
No retransmissions after a = certain timeout (RST_STREAM on a timer, if you assume the stream data = all becomes available at once)

Slightly more complex would be = something like =E2=80=9Conly retransmit any given segment once=E2=80=9D = or =E2=80=9Cgive up on retransmissions after a segment is X ms = old.=E2=80=9D

In case of HTTP, all = three options could be requested via an HTTP request = header.
Optional, in case the server does not support = unreliable streams, fallback to reliable transmission.

An open question is question is how to present a = stream with =E2=80=9Choles=E2=80=9D to the application.

On the QUIC layer, as it = is much easier to implement, unreliable transmission is driven by the = sender. Retransmissions can then be done depending on the applications = choice.

Depending on other open = discussion, the sender tells the receiver = about
unreliable transmission by ether a flag bit in the = stream frame or in
the START_STREA frame. The receiver must = set a RST_STREM, if it can=E2=80=99t handle
unreliable = streams.

AVE!
Philipp S. Tiesel / phils=E2=80=A6--
{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)----'

= --Apple-Mail=_75740E02-D204-4807-BF9E-186009D52212-- From nobody Tue Jul 25 05:25: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 CAA53131C89 for ; Tue, 25 Jul 2017 05:25:11 -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, RP_MATCHES_RCVD=-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=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 IZaidkbfI3cR for ; Tue, 25 Jul 2017 05:25:08 -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 B2419120721 for ; Tue, 25 Jul 2017 05:25:08 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id x125so67760197ywa.0 for ; Tue, 25 Jul 2017 05:25: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=TAshmQKzU7AugubU3S5crw0gQAUevSFBImJ++saox1A=; b=eaLco0iMZctHt7wXnHheYlmar2DcA29x+L0e3EGRgH9YmtK9drMxVwV9woWj7EJ4Iy Efa9ccJFflh+/NihxfCOpBhjhu7pUpAe9qtcc028tYGqCKWoChs/qGQNNLMscGk8rBn1 XO2EO2y8+DwsmwDicKYW/3go5oFVXbyprH140/zl4gnqMEpc7qhKKr/nrYAW1tM6J8pE DvCIXgata9a9Zb6cNQTmiCSsuFbT3oJbMfgWMIg26VNSYsWJH1X/kGzf+isUEQrzQRGY 6Wa3J2BVNUwrPHYHni3xEc6SCeJMXWndAk+s9qTz9cIfSPFeL+o2l5nufEPrfP55xPr3 /05g== 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=TAshmQKzU7AugubU3S5crw0gQAUevSFBImJ++saox1A=; b=M5vNys2OW5RAm5kubeq+axl6giX3qe/17rEBEWgEBVlAnkLqxnwQ5mK2sZ4eG/fLDW QYsdS1BFF64v2s2ks9IfJJoO5Wy+AJq+zdQoj9tZ0LVUMVf4/ewRYZvOG2Jw0Rb1z0/L XB+ShfyyXjTynhhwo9Rk8g0r12AXT5gRSqOloBQb9/9oiynxzaQpdvD5bhCfmebkxDDB /bOe7SVovo5Lsn16+gC36CrD6Uam+uT48aEwvGpu6VGrJcuA1Q+ZiyzR8WR19+OTRhS+ QiiFxwCwEEaj9SsG6a8acEL2vnx+Uzt2c2qsqf3/uO1INlr/p2xW4c7eD1jSqz29yDAF 2NnQ== X-Gm-Message-State: AIVw112+APPQrijUVsy/YaRBA65O595TNMrYT5TOv4fPUafqp9XMaZUd JU1s0XviuQxxmVUYbQwzQYe6fQAxk9UW X-Received: by 10.129.51.67 with SMTP id z64mr16001817ywz.370.1500985507690; Tue, 25 Jul 2017 05:25:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.163.130 with HTTP; Tue, 25 Jul 2017 05:24:47 -0700 (PDT) In-Reply-To: References: <20170721093732.GA31705@ubuntu-dmitri> From: Ian Swett Date: Tue, 25 Jul 2017 08:24:47 -0400 Message-ID: Subject: Re: Idea for packet numbers To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" Cc: Dmitri Tikhonov , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Magnus Westerlund , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1141519600314c0555236c2e" 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, 25 Jul 2017 12:25:12 -0000 --001a1141519600314c0555236c2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Some thoughts. 1) Sending packet numbers in order is not required, but the farther out of order packets get, the more acks the receiver is going to send, the larger they'll be, and the more complex loss detection is. In particular, you won't be able to rely on QUIC's packet numbers being in time order. TLDR; It's easier to send packets in order than it is to correctly deal with the implications of sending them out of order. 2) I don't think there's a compelling reason to use multiple CPUs for a single QUIC connection in any circumstances I've encountered. And if it is necessary, it'd be much simpler and faster to avoid any locking and use multiple QUIC connections(or possibly multipath if it existed). This also has the benefit of sending the packet numbers sequentially for a given connection ID. 3) I'm happy to treat reordering in the NIC as a form of network reordering, since it's not something the QUIC implementation may be able to control. On Tue, Jul 25, 2017 at 6:04 AM, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: > I've been thinking about packet numbers and what it is safe to reason > about them. > > With regards to packet numbers the key parts of the spec appear to be: > a) The packet number for sending MUST increase by at least one after > sending any packet, unless otherwise specified > b) A QUIC endpoint MUST NOT reuse a packet number within the same > connection > c) The sender MUST use a packet number size able to represent more than > twice as large a range than the difference between the largest acknowledg= ed > packet and packet number being sent. > d) An endpoint SHOULD retain old keys for a short period to allow it to > decrypt packets with smaller packet numbers than the packet that triggere= d > the key update. This allows an endpoint to consume packets that are > reordered around the transition between keys. Packets with higher packet > numbers always use the updated keys and MUST NOT be decrypted with old ke= ys. > > >From a receivers point of view we actively ignore a and assume that ther= e > may be packet reordering and packet loss in the network. > Packet reordering means that packet numbers won't appear in order. Packet > loss and the subsequent retransmission with a new packet number means tha= t > (retransmitted) lower offset stream data may arrive with a higher packet > number. The receiver is expected to deal with these as part of normal > operation. > > >From the senders perspective the process it goes through is: > 1. Get data to send > 2. Get packet number > 3. encrypt packet > 4. queue packet on NIC > 5. NIC sends packet. > > On a single threaded single stream application an implementation written > to spec would sequentially create packets in order, encrypt them and the > nic should then send them out in order onto the network. > However on a multi-cpu server sending multiple streams in the same > connections things get much harder to reason about. We can assume that ea= ch > stream is likely being generated by a different application thread (to > avoid server side head of line blocking etc) and so be producing packets > concurrently. > One option is to serialise the sending, so that after step 1 the request > enters a synchronized serialized process and proceeds with strict orderin= g > allowing requirement a to be met. > This option isn't however efficient or desirable for a performance > optimized solution. > On a multi-cpu system, for optimal performance you want to take advantage > of data locality (it is expensive to shuffle data between CPU cores when > you don't have to). The obvious design would be to have an atomic counter > for the packet number and do steps 1-4 within the thread (or at least CPU= ) > that is generating the data. With multiple streams being generated on > multiple cpu cores there is no guarantee that the order the packet number= s > are assigned for the packets will match the order that the packets are > queued on the NIC. The higher numbered packet may get encrypted quicker a= nd > so enqueued and sent ahead of the earlier packet number. At the wire leve= l > this would give an egress pattern where the packet numbers weren't > increasing after every packet, only over the longer run. > If the server has multiple NICS then the problem has potential of > occurring even if steps 1-4 had been serialized via a cross cpu > semaphore/lock. Different NICS will be attached to different CPU cores an= d > an efficient OS could try to avoid cross CPU communication by queuing the > packet on a NIC connected to the same CPU as the thread that generated th= e > packet. If different threads are generating the packets on different core= s > then potentially the packets could be queued on different NICS and > therefore be sent out of order even if they were queued in order. > > Obviously we have established that a receiver should be designed to expec= t > and handle packet re-ordering and it is unknown to the receiver whether i= t > is in the network or host where the re-ordering occurs. From an end to en= d > point of view a multi-threaded implementation would work. If the > multi-threaded implementation strictly complies with a then I'm unsure, i= t > depends what part of the process is defined as 'sending' and where the > measurement to validate it should be taken (e.g. the point the packets > appear on the network vs the point the intention to create a packet to se= nd > is actioned). > > To complicate matters further, an implementer may not want to allocated > packet numbers one by one. If they know they have 32 packets worth of dat= a > to send then perhaps it is more efficient to request 32 packet numbers in= a > single atomic operation and then encrypt and enqueue the packets in turn. > If another thread on a less loaded cpu is also generating stream data the= n > packet number re-ordering may occur to an even greater extend. Again > (within limits) the receiver should cope with this level of packet > re-ordering - as long as the packet number size constraints aren't violat= ed > and the packets arrive in a timely manner. However it does break the > assumption that you can generally rely on the low order bits of packet > numbers to be generally sent in order. > > The packet re-ordering issue also impact requirements around streams ids > being created sequentially in order as the same set of race conditions ca= n > occur. > > I think it may be worthwhile clarifying what the packet number behaviour > is expected to look like from an external observers perspective. Is there > actually a desire to attempt to force the sender to serialize packet > sending? That is, does quic require that the egress from the host is > strictly in order and only the network can introduce re-ordering? Whilst > keeping within the constraints of b-d, is/should it be acceptable that an > implementation allocates blocks of contiguous packet numbers for each > stream? If probably would mean you end up with gaps in packet numbers whe= n > a stream doesn't use all of its allocation in time (e.g a key change > requires it to move to a new allocation). If it isn't acceptable then wha= t > are the constraints the sender should keep within? > > Thomas > > > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov > > Sent: 21 July 2017 10:38 > > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > > Cc: Magnus Westerlund ; IETF QUIC WG > > > > Subject: Re: Idea for packet numbers > > > > On Thu, Jul 20, 2017 at 07:10:11AM -0400, Mikkel Fahn=C3=B8e J=C3=B8rge= nsen wrote: > > > For other reasons I would like the packet numbers to be close, > > > preferably without gaps except during connection migration. > > > > > > This relates to storing interval maps as groups of bitmaps instead of > > > binary trees to track already received packets. This both provides ar= e > > > more efficient implementation, and it reduces some modes of DoS where > > > an attacker can create a lot of small intervals which cause the data > > > structure to inflate. > > > > The receive history gets truncated automatically, and so the receiver > does not > > have to worry about a lot of data to keep track of. From > [draft-ietf-quic- > > transport] 8.13: > > > > " To limit ACK blocks to those that have not yet been received " by t= he > > sender, the receiver SHOULD track which ACK frames " have been > > acknowledged by its peer. Once an ACK frame has " been acknowledged, > the > > packets it acknowledges SHOULD not be " acknowledged again. > > > > Send history is another matter. Ibid., 8.13: > > > > " The sender SHOULD close the connection if an unsent packet " number > is > > acknowledged. > > > > (Previous versions of the draft had a MUST instead of a SHOULD.) > > > > Thus it is in the interest of the sender either to create few gaps or t= o > create > > them in a manner that does not blow up its own send history data > structures if > > it wants to check whether an unsent packet is ACKed. > > > > - Dmitri. > > --001a1141519600314c0555236c2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some thoughts.

1) Sending packet number= s in order is not required, but the farther out of order packets get, the m= ore acks the receiver is going to send, the larger they'll be, and the = more complex loss detection is.=C2=A0 In particular, you won't be able = to rely on QUIC's packet numbers being in time order.=C2=A0 TLDR; It= 9;s easier to send packets in order than it is to correctly deal with the i= mplications of sending them out of order.=C2=A0=C2=A0

<= div>2) I don't think there's a compelling reason to use multiple CP= Us for a single QUIC connection in any circumstances I've encountered.= =C2=A0 And if it is necessary, it'd be much simpler and faster to avoid= any locking and use multiple QUIC connections(or possibly multipath if it = existed).=C2=A0 This also has the benefit of sending the packet numbers seq= uentially for a given connection ID.

3) I'm ha= ppy to treat reordering in the NIC as a form of network reordering, since i= t's not something the QUIC implementation may be able to control.
=

On Tue, Jul 25, 2017 at 6:04 AM, Swindells, Thomas (Nokia - GB/Cambridg= e, UK) <thomas.swindells@nokia.com> wrote:
I've been thinking about packet numbers and w= hat it is safe to reason about them.

With regards to packet numbers the key parts of the spec appear to be:
a)=C2=A0 The packet number for sending MUST increase by at least one after = sending any packet, unless otherwise specified
b) A QUIC endpoint MUST NOT reuse a packet number within the same connectio= n
c) The sender MUST use a packet number size able to represent more than twi= ce as large a range than the difference between the largest acknowledged pa= cket and packet number being sent.
d) An endpoint SHOULD retain old keys for a short period to allow it to dec= rypt packets with smaller packet numbers than the packet that triggered the= key update. This allows an endpoint to consume packets that are reordered = around the transition between keys. Packets with higher packet numbers alwa= ys use the updated keys and MUST NOT be decrypted with old keys.

>From a receivers point of view we actively ignore a and assume that the= re may be packet reordering and packet loss in the network.
Packet reordering means that packet numbers won't appear in order. Pack= et loss and the subsequent retransmission with a new packet number means th= at (retransmitted) lower offset stream data may arrive with a higher packet= number. The receiver is expected to deal with these as part of normal oper= ation.

>From the senders perspective the process it goes through is:
1. Get data to send
2. Get packet number
3. encrypt packet
4. queue packet on NIC
5. NIC sends packet.

On a single threaded single stream application an implementation written to= spec would sequentially create packets in order, encrypt them and the nic = should then send them out in order onto the network.
However on a multi-cpu server sending multiple streams in the same connecti= ons things get much harder to reason about. We can assume that each stream = is likely being generated by a different application thread (to avoid serve= r side head of line blocking etc) and so be producing packets concurrently.=
One option is to serialise the sending, so that after step 1 the request en= ters a synchronized serialized process and proceeds with strict ordering al= lowing requirement a to be met.
This option isn't however efficient or desirable for a performance opti= mized solution.
On a multi-cpu system, for optimal performance you want to take advantage o= f data locality (it is expensive to shuffle data between CPU cores when you= don't have to). The obvious design would be to have an atomic counter = for the packet number and do steps 1-4 within the thread (or at least CPU) = that is generating the data. With multiple streams being generated on multi= ple cpu cores there is no guarantee that the order the packet numbers are a= ssigned for the packets will match the order that the packets are queued on= the NIC. The higher numbered packet may get encrypted quicker and so enque= ued and sent ahead of the earlier packet number. At the wire level this wou= ld give an egress pattern where the packet numbers weren't increasing a= fter every packet, only over the longer run.
If the server has multiple NICS then the problem has potential of occurring= even if steps 1-4 had been serialized via a cross cpu semaphore/lock. Diff= erent NICS will be attached to different CPU cores and an efficient OS coul= d try to avoid cross CPU communication by queuing the packet on a NIC conne= cted to the same CPU as the thread that generated the packet. If different = threads are generating the packets on different cores then potentially the = packets could be queued on different NICS and therefore be sent out of orde= r even if they were queued in order.

Obviously we have established that a receiver should be designed to expect = and handle packet re-ordering and it is unknown to the receiver whether it = is in the network or host where the re-ordering occurs. From an end to end = point of view a multi-threaded implementation would work. If the multi-thre= aded implementation strictly complies with a then I'm unsure, it depend= s what part of the process is defined as 'sending' and where the me= asurement to validate it should be taken (e.g. the point the packets appear= on the network vs the point the intention to create a packet to send is ac= tioned).

To complicate matters further, an implementer may not want to allocated pac= ket numbers one by one. If they know they have 32 packets worth of data to = send then perhaps it is more efficient to request 32 packet numbers in a si= ngle atomic operation and then encrypt and enqueue the packets in turn. If = another thread on a less loaded cpu is also generating stream data then pac= ket number re-ordering may occur to an even greater extend. Again (within l= imits) the receiver should cope with this level of packet re-ordering - as = long as the packet number size constraints aren't violated and the pack= ets arrive in a timely manner. However it does break the assumption that yo= u can generally rely on the low order bits of packet numbers to be generall= y sent in order.

The packet re-ordering issue also impact requirements around streams ids be= ing created sequentially in order as the same set of race conditions can oc= cur.

I think it may be worthwhile clarifying what the packet number behaviour is= expected to look like from an external observers perspective. Is there act= ually a desire to attempt to force the sender to serialize packet sending? = That is, does quic require that the egress from the host is strictly in ord= er and only the network can introduce re-ordering? Whilst keeping within th= e constraints of b-d, is/should it be acceptable that an implementation all= ocates blocks of contiguous packet numbers for each stream? If probably wou= ld mean you end up with gaps in packet numbers when a stream doesn't us= e all of its allocation in time (e.g a key change requires it to move to a = new allocation). If it isn't acceptable then what are the constraints t= he sender should keep within?

Thomas

> -----Original Message-----
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Dmitri Tikhonov
> Sent: 21 July 2017 10:38
> To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>; IETF QUIC WG
> <quic@ietf.org>
> Subject: Re: Idea for packet numbers
>
> On Thu, Jul 20, 2017 at 07:10:11AM -0400, Mikkel Fahn=C3=B8e J=C3=B8rg= ensen wrote:
> > For other reasons I would like the packet numbers to be close, > > preferably without gaps except during connection migration.
> >
> > This relates to storing interval maps as groups of bitmaps instea= d of
> > binary trees to track already received packets. This both provide= s are
> > more efficient implementation, and it reduces some modes of DoS w= here
> > an attacker can create a lot of small intervals which cause the d= ata
> > structure to inflate.
>
> The receive history gets truncated automatically, and so the receiver = does not
> have to worry about a lot of data to keep track of.=C2=A0 From [draft-= ietf-quic-
> transport] 8.13:
>
>=C2=A0 " To limit ACK blocks to those that have not yet been recei= ved=C2=A0 " by the
> sender, the receiver SHOULD track which ACK frames=C2=A0 " have b= een
> acknowledged by its peer.=C2=A0 Once an ACK frame has=C2=A0 " bee= n acknowledged, the
> packets it acknowledges SHOULD not be=C2=A0 " acknowledged again.=
>
> Send history is another matter.=C2=A0 Ibid., 8.13:
>
>=C2=A0 " The sender SHOULD close the connection if an unsent packe= t=C2=A0 " number is
> acknowledged.
>
> (Previous versions of the draft had a MUST instead of a SHOULD.)
>
> Thus it is in the interest of the sender either to create few gaps or = to create
> them in a manner that does not blow up its own send history data struc= tures if
> it wants to check whether an unsent packet is ACKed.
>
>=C2=A0 =C2=A0- Dmitri.

--001a1141519600314c0555236c2e-- From nobody Tue Jul 25 05:34: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 E19E8129AB2 for ; Tue, 25 Jul 2017 05:34:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 aBxUJDUG-hV1 for ; Tue, 25 Jul 2017 05:34:50 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 C6C26131C96 for ; Tue, 25 Jul 2017 05:34:49 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 80so101490603uas.0 for ; Tue, 25 Jul 2017 05:34:49 -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=O8y1x9Ih7YM3bDwF2ntr2+oDz7LXhnOXS0JXptAYkWI=; b=XHihd87vXeTrl9XgaKH8HU5tiiFxFh/THdEcMBATkdvzhmeYD0AOUctxxowkYmaKos RBVpqEGgGz9b97VotBBQYruml53tZnBT8y1UpbsfkEK3eTQ1AZrOw0WYWtPDMbNvP7b3 TuUPhIQM1kWmIm6yddhXuh7smEaaC/P2OGNEN9mo8ZjNmNfL3KhBemmT8EFYgvkDD6iY nwx3umCapPR+SOYUHeMGm8vlxQsuXz1Q2WXwNIYcJ9/ZOWsnyOLKWeWZq0oMSlxTjNuX sMjq1ma3lgQEyZB+ehXz/cGMoKkutTljti84CAEJ6nD9kAGBEU1SmI2VI7rxxJzto920 qGdA== 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=O8y1x9Ih7YM3bDwF2ntr2+oDz7LXhnOXS0JXptAYkWI=; b=XjJxRUiAjg38EY6B2NZjVVTvHxgBFkjdYepHBIo3KXuyF2SL+07H+LnigEIwquFfKM MZ/N6BG637bwWTSICNTmB5PaC/TWwpTMqFgl4iWuMvs4tZLos5WlbpaGUq0hlAboNvUN Lm051NvNT2azrPssT2RfnovdEDd+KqOt9XykzscBObLG9wdCc/WvDTop//BC3rVltrGI a/GItIenVrxcjdcg9OZ9mrrxDkQ28CuBScFy32X7aBrxDP2i+7KCuGoia6EsG7fPA19L H2DudY5/nfyrZ6+nWvtuR06ysOt2f19Ddft38c9KDo/AVFzx/wwOTPj6LM1CXskJszMB txOg== X-Gm-Message-State: AIVw112aVDFxERn6N98l6bzdxGXHpIaI8F9TxXhkaGIBuGY61BLWuKzj HV87xC15UWC6QW17e6iUQeNRjx2T4A== X-Received: by 10.31.186.130 with SMTP id k124mr8686174vkf.124.1500986088853; Tue, 25 Jul 2017 05:34:48 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 25 Jul 2017 14:34:48 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20170721093732.GA31705@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 25 Jul 2017 14:34:48 +0200 Message-ID: Subject: Re: Idea for packet numbers To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Ian Swett Cc: Magnus Westerlund , IETF QUIC WG , Dmitri Tikhonov Content-Type: multipart/alternative; boundary="001a11441096a39f2f0555238eab" 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, 25 Jul 2017 12:34:54 -0000 --001a11441096a39f2f0555238eab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 3) I'm happy to treat reordering in the NIC as a form of network reordering, since it's not something the QUIC implementation may be able to control. Wrt. complexity of loss control, I don=E2=80=99t think reordering within sh= ort time intervals is a major concern because you would expect to fill the gaps eventually. If receiver side assumptions are not met, it could be assumed to be poor line quality or malicious intent, thus warranting dropping the connection, or at least a larger transmission block. The problem is when you don=E2=80=99t know if a packet gap is due to valid deliberate omission = or failure / delay. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 25 July 2017 at 14.25.08, Ian Swett (ianswett@google.com) wrote: Some thoughts. 1) Sending packet numbers in order is not required, but the farther out of order packets get, the more acks the receiver is going to send, the larger they'll be, and the more complex loss detection is. In particular, you won't be able to rely on QUIC's packet numbers being in time order. TLDR; It's easier to send packets in order than it is to correctly deal with the implications of sending them out of order. 2) I don't think there's a compelling reason to use multiple CPUs for a single QUIC connection in any circumstances I've encountered. And if it is necessary, it'd be much simpler and faster to avoid any locking and use multiple QUIC connections(or possibly multipath if it existed). This also has the benefit of sending the packet numbers sequentially for a given connection ID. 3) I'm happy to treat reordering in the NIC as a form of network reordering, since it's not something the QUIC implementation may be able to control. On Tue, Jul 25, 2017 at 6:04 AM, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: > I've been thinking about packet numbers and what it is safe to reason > about them. > > With regards to packet numbers the key parts of the spec appear to be: > a) The packet number for sending MUST increase by at least one after > sending any packet, unless otherwise specified > b) A QUIC endpoint MUST NOT reuse a packet number within the same > connection > c) The sender MUST use a packet number size able to represent more than > twice as large a range than the difference between the largest acknowledg= ed > packet and packet number being sent. > d) An endpoint SHOULD retain old keys for a short period to allow it to > decrypt packets with smaller packet numbers than the packet that triggere= d > the key update. This allows an endpoint to consume packets that are > reordered around the transition between keys. Packets with higher packet > numbers always use the updated keys and MUST NOT be decrypted with old ke= ys. > > >From a receivers point of view we actively ignore a and assume that ther= e > may be packet reordering and packet loss in the network. > Packet reordering means that packet numbers won't appear in order. Packet > loss and the subsequent retransmission with a new packet number means tha= t > (retransmitted) lower offset stream data may arrive with a higher packet > number. The receiver is expected to deal with these as part of normal > operation. > > >From the senders perspective the process it goes through is: > 1. Get data to send > 2. Get packet number > 3. encrypt packet > 4. queue packet on NIC > 5. NIC sends packet. > > On a single threaded single stream application an implementation written > to spec would sequentially create packets in order, encrypt them and the > nic should then send them out in order onto the network. > However on a multi-cpu server sending multiple streams in the same > connections things get much harder to reason about. We can assume that ea= ch > stream is likely being generated by a different application thread (to > avoid server side head of line blocking etc) and so be producing packets > concurrently. > One option is to serialise the sending, so that after step 1 the request > enters a synchronized serialized process and proceeds with strict orderin= g > allowing requirement a to be met. > This option isn't however efficient or desirable for a performance > optimized solution. > On a multi-cpu system, for optimal performance you want to take advantage > of data locality (it is expensive to shuffle data between CPU cores when > you don't have to). The obvious design would be to have an atomic counter > for the packet number and do steps 1-4 within the thread (or at least CPU= ) > that is generating the data. With multiple streams being generated on > multiple cpu cores there is no guarantee that the order the packet number= s > are assigned for the packets will match the order that the packets are > queued on the NIC. The higher numbered packet may get encrypted quicker a= nd > so enqueued and sent ahead of the earlier packet number. At the wire leve= l > this would give an egress pattern where the packet numbers weren't > increasing after every packet, only over the longer run. > If the server has multiple NICS then the problem has potential of > occurring even if steps 1-4 had been serialized via a cross cpu > semaphore/lock. Different NICS will be attached to different CPU cores an= d > an efficient OS could try to avoid cross CPU communication by queuing the > packet on a NIC connected to the same CPU as the thread that generated th= e > packet. If different threads are generating the packets on different core= s > then potentially the packets could be queued on different NICS and > therefore be sent out of order even if they were queued in order. > > Obviously we have established that a receiver should be designed to expec= t > and handle packet re-ordering and it is unknown to the receiver whether i= t > is in the network or host where the re-ordering occurs. From an end to en= d > point of view a multi-threaded implementation would work. If the > multi-threaded implementation strictly complies with a then I'm unsure, i= t > depends what part of the process is defined as 'sending' and where the > measurement to validate it should be taken (e.g. the point the packets > appear on the network vs the point the intention to create a packet to se= nd > is actioned). > > To complicate matters further, an implementer may not want to allocated > packet numbers one by one. If they know they have 32 packets worth of dat= a > to send then perhaps it is more efficient to request 32 packet numbers in= a > single atomic operation and then encrypt and enqueue the packets in turn. > If another thread on a less loaded cpu is also generating stream data the= n > packet number re-ordering may occur to an even greater extend. Again > (within limits) the receiver should cope with this level of packet > re-ordering - as long as the packet number size constraints aren't violat= ed > and the packets arrive in a timely manner. However it does break the > assumption that you can generally rely on the low order bits of packet > numbers to be generally sent in order. > > The packet re-ordering issue also impact requirements around streams ids > being created sequentially in order as the same set of race conditions ca= n > occur. > > I think it may be worthwhile clarifying what the packet number behaviour > is expected to look like from an external observers perspective. Is there > actually a desire to attempt to force the sender to serialize packet > sending? That is, does quic require that the egress from the host is > strictly in order and only the network can introduce re-ordering? Whilst > keeping within the constraints of b-d, is/should it be acceptable that an > implementation allocates blocks of contiguous packet numbers for each > stream? If probably would mean you end up with gaps in packet numbers whe= n > a stream doesn't use all of its allocation in time (e.g a key change > requires it to move to a new allocation). If it isn't acceptable then wha= t > are the constraints the sender should keep within? > > Thomas > > > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov > > Sent: 21 July 2017 10:38 > > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > > Cc: Magnus Westerlund ; IETF QUIC WG > > > > Subject: Re: Idea for packet numbers > > > > On Thu, Jul 20, 2017 at 07:10:11AM -0400, Mikkel Fahn=C3=B8e J=C3=B8rge= nsen wrote: > > > For other reasons I would like the packet numbers to be close, > > > preferably without gaps except during connection migration. > > > > > > This relates to storing interval maps as groups of bitmaps instead of > > > binary trees to track already received packets. This both provides ar= e > > > more efficient implementation, and it reduces some modes of DoS where > > > an attacker can create a lot of small intervals which cause the data > > > structure to inflate. > > > > The receive history gets truncated automatically, and so the receiver > does not > > have to worry about a lot of data to keep track of. From > [draft-ietf-quic- > > transport] 8.13: > > > > " To limit ACK blocks to those that have not yet been received " by t= he > > sender, the receiver SHOULD track which ACK frames " have been > > acknowledged by its peer. Once an ACK frame has " been acknowledged, > the > > packets it acknowledges SHOULD not be " acknowledged again. > > > > Send history is another matter. Ibid., 8.13: > > > > " The sender SHOULD close the connection if an unsent packet " number > is > > acknowledged. > > > > (Previous versions of the draft had a MUST instead of a SHOULD.) > > > > Thus it is in the interest of the sender either to create few gaps or t= o > create > > them in a manner that does not blow up its own send history data > structures if > > it wants to check whether an unsent packet is ACKed. > > > > - Dmitri. > > --001a11441096a39f2f0555238eab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

3) I'm happy to treat reordering in the NIC as a form of network r= eordering, since it's not something the QUIC implementation may be able= to control.

Wrt. complexity o= f loss control, I don=E2=80=99t think reordering within short time interval= s is a major concern because you would expect to fill the gaps eventually. = If receiver side assumptions are not met, it could be assumed to be poor li= ne quality or malicious intent, thus warranting dropping the connection, or= at least a larger transmission block. The problem is when you don=E2=80=99= t know if a packet gap is due to valid deliberate omission or failure / del= ay.

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

On 2= 5 July 2017 at 14.25.08, Ian Swett (= ianswett@google.com) wrote:

Some thoughts.

1) Sending packet numbers in order is not required, but the farther out of order packets get, the more acks the receiver is going to send, the larger they'll be, and the more complex loss detection is.=C2=A0 In particular, you won't be able to rely on QUIC's packet numbers being in time order.=C2=A0 TLDR; It's easier to send packets in order than it is to correctly deal with the implications of sending them out of order.=C2=A0=C2=A0

2) I don't think there's a compelling reason to use multiple CPUs for a single QUIC connection in any circumstances I've encountered.=C2=A0 And if it is necessary, it'd be much simpler and faster to avoid any locking and use multiple QUIC connections(or possibly multipath if it existed).=C2=A0 This also has the benefit of sending the packet numbers sequentially for a given connection ID.

3) I'm happy to treat reordering in the NIC as a form of network reordering, since it's not something the QUIC implementation may be able to control.

On Tue, Jul 25, 2017 at 6:04 AM, Swindells, Thomas (Nokia - GB/Cambridge, UK) <thomas.swindells@n= okia.com> wrote:

I've been thinking about packet numbers and what it is safe to reason about them.

With regards to packet numbers the key parts of the spec appear to be:
a)=C2=A0 The packet number for sending MUST increase by at least one after sending any packet, unless otherwise specified
b) A QUIC endpoint MUST NOT reuse a packet number within the same connection
c) The sender MUST use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent.
d) An endpoint SHOULD retain old keys for a short period to allow it to decrypt packets with smaller packet numbers than the packet that triggered the key update. This allows an endpoint to consume packets that are reordered around the transition between keys. Packets with higher packet numbers always use the updated keys and MUST NOT be decrypted with old keys.

>From a receivers point of view we actively ignore a and assume that there may be packet reordering and packet loss in the network.
Packet reordering means that packet numbers won't appear in order. Packet loss and the subsequent retransmission with a new packet number means that (retransmitted) lower offset stream data may arrive with a higher packet number. The receiver is expected to deal with these as part of normal operation.

>From the senders perspective the process it goes through is:
1. Get data to send
2. Get packet number
3. encrypt packet
4. queue packet on NIC
5. NIC sends packet.

On a single threaded single stream application an implementation written to spec would sequentially create packets in order, encrypt them and the nic should then send them out in order onto the network.
However on a multi-cpu server sending multiple streams in the same connections things get much harder to reason about. We can assume that each stream is likely being generated by a different application thread (to avoid server side head of line blocking etc) and so be producing packets concurrently.
One option is to serialise the sending, so that after step 1 the request enters a synchronized serialized process and proceeds with strict ordering allowing requirement a to be met.
This option isn't however efficient or desirable for a performance optimized solution.
On a multi-cpu system, for optimal performance you want to take advantage of data locality (it is expensive to shuffle data between CPU cores when you don't have to). The obvious design would be to have an atomic counter for the packet number and do steps 1-4 within the thread (or at least CPU) that is generating the data. With multiple streams being generated on multiple cpu cores there is no guarantee that the order the packet numbers are assigned for the packets will match the order that the packets are queued on the NIC. The higher numbered packet may get encrypted quicker and so enqueued and sent ahead of the earlier packet number. At the wire level this would give an egress pattern where the packet numbers weren't increasing after every packet, only over the longer run.
If the server has multiple NICS then the problem has potential of occurring even if steps 1-4 had been serialized via a cross cpu semaphore/lock. Different NICS will be attached to different CPU cores and an efficient OS could try to avoid cross CPU communication by queuing the packet on a NIC connected to the same CPU as the thread that generated the packet. If different threads are generating the packets on different cores then potentially the packets could be queued on different NICS and therefore be sent out of order even if they were queued in order.

Obviously we have established that a receiver should be designed to expect and handle packet re-ordering and it is unknown to the receiver whether it is in the network or host where the re-ordering occurs. From an end to end point of view a multi-threaded implementation would work. If the multi-threaded implementation strictly complies with a then I'm unsure, it depends what part of the process is defined as 'sending' and where the measurement to validate it should be taken (e.g. the point the packets appear on the network vs the point the intention to create a packet to send is actioned).

To complicate matters further, an implementer may not want to allocated packet numbers one by one. If they know they have 32 packets worth of data to send then perhaps it is more efficient to request 32 packet numbers in a single atomic operation and then encrypt and enqueue the packets in turn. If another thread on a less loaded cpu is also generating stream data then packet number re-ordering may occur to an even greater extend. Again (within limits) the receiver should cope with this level of packet re-ordering - as long as the packet number size constraints aren't violated and the packets arrive in a timely manner. However it does break the assumption that you can generally rely on the low order bits of packet numbers to be generally sent in order.

The packet re-ordering issue also impact requirements around streams ids being created sequentially in order as the same set of race conditions can occur.

I think it may be worthwhile clarifying what the packet number behaviour is expected to look like from an external observers perspective. Is there actually a desire to attempt to force the sender to serialize packet sending? That is, does quic require that the egress from the host is strictly in order and only the network can introduce re-ordering? Whilst keeping within the constraints of b-d, is/should it be acceptable that an implementation allocates blocks of contiguous packet numbers for each stream? If probably would mean you end up with gaps in packet numbers when a stream doesn't use all of its allocation in time (e.g a key change requires it to move to a new allocation). If it isn't acceptable then what are the constraints the sender should keep within?

Thomas

> -----Original Message-----
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Dmitri Tikhonov
> Sent: 21 July 2017 10:38
> To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>; IETF QUIC WG
> <quic@ietf.org>
> Subject: Re: Idea for packet numbers
>
> On Thu, Jul 20, 2017 at 07:10:11AM -0400, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> > For other reasons I would like the packet numbers to be close,
> > preferably without gaps except during connection migration.
> >
> > This relates to storing interval maps as groups of bitmaps instead of
> > binary trees to track already received packets. This both provides are
> > more efficient implementation, and it reduces some modes of DoS where
> > an attacker can create a lot of small intervals which cause the data
> > structure to inflate.
>
> The receive history gets truncated automatically, and so the receiver does not
> have to worry about a lot of data to keep track of.=C2=A0 From [draft-ietf-quic-
> transport] 8.13:
>
>=C2=A0 " To limit ACK blocks to those that have not yet been received=C2=A0 " by the
> sender, the receiver SHOULD track which ACK frames=C2=A0 " have been
> acknowledged by its peer.=C2=A0 Once an ACK frame has=C2=A0 " been acknowledged, the
> packets it acknowledges SHOULD not be=C2=A0 " acknowledged again.
>
> Send history is another matter.=C2=A0 Ibid., 8.13:
>
>=C2=A0 " The sender SHOULD close the connection if an unsent packet=C2=A0 " number is
> acknowledged.
>
> (Previous versions of the draft had a MUST instead of a SHOULD.)
>
> Thus it is in the interest of the sender either to create few gaps or to create
> them in a manner that does not blow up its own send history data structures if
> it wants to check whether an unsent packet is ACKed.
>
>=C2=A0 =C2=A0- Dmitri.

--001a11441096a39f2f0555238eab-- From nobody Tue Jul 25 05:36: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 3702A129AB2 for ; Tue, 25 Jul 2017 05:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=nokia.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 FQ49VBP1SNbP for ; Tue, 25 Jul 2017 05:36:18 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0113.outbound.protection.outlook.com [104.47.2.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14233131C39 for ; Tue, 25 Jul 2017 05:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=586pERe7/EF8r229EZ7NTsNHtmhWjUSorECJk6BrevQ=; b=PldyF1tC9/bQv7o1jXde1yE+ETXN5AtdgCX87Xbysr3BdtTZQNKcSdKnqwp6XoXV87qQuErBwvUjNL/6efloD+NgFFK+h25EjnfZ8Q9woboicyxxkgUt4GIOcJMdZfGX98wmFggHTvmsHGLdev4S4gdv1OStYznqB2wpGCBxcC8= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB0872.eurprd07.prod.outlook.com (10.161.196.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Tue, 25 Jul 2017 12:36:15 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354%13]) with mapi id 15.01.1304.014; Tue, 25 Jul 2017 12:36:15 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Ian Swett CC: Dmitri Tikhonov , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Magnus Westerlund" , IETF QUIC WG Subject: RE: Idea for packet numbers Thread-Topic: Idea for packet numbers Thread-Index: AQHTAT74Pm6HB4E+oUyHojrh9ct+26JcjwOAgAF4cgCAA8bLAIACsUOAgAAAb2A= Date: Tue, 25 Jul 2017 12:36:14 +0000 Message-ID: References: <20170721093732.GA31705@ubuntu-dmitri> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; x-originating-ip: [82.69.101.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB0872; 7:7jWbwboZhsJGFRYzdY6AyQPVD4lJx1E9xPzivY4bKiSgSMl2FthvXmySxNCr1mu4Fy7tmxciAyFC8MyCRtuzpGDxm/6TVDBTQJ2HtDjLOM3dMBLNJYHEoKMHV9pzHdOiBDHDhQyJeZ9zWMTIFuh9THiFA8Alo9jYqKckrogjQfgj6xIqBvZmCqI6S3B6M3m5SmM/j7/2EITYe26bX1eCv/jRz/3mEV3sWpoO/FSg3GtK/cRKEBRO6D4YHiyhEgP8hStuYFvhxFqK5wvYgkX5poPx2pa2fO3jwkUeTyhvuezhXjJ7br+i88jplZTlNkOe4W5d4u0mcurBBn4KQUhjBBNxXZCVT508Miyzp9gQjGK5PUiOm4JB7Jrvfq9pUE5bBaZllRK94+jfpU+RuwE1uY8nxAIShAI4f1lebmqDlLQibO1S8lpEHH1UMbul/Ie52F6yPdblnStNSBramtr5vus2xnwdk+UHzApm9kA2f/q1d3tD9Y8kM3++rCbBwmihKI172XKag3CrEtE5+fJEkZvHgLcIHzygJl8tKRgniWuTv3+bgnpWSOibPkSRsR2WljXXSyXWRuDqk2EHHqdcE7vfdr1XyzcEPZc3xtrpf+zMZxolYvBNF89B4ChNp1w6pnl2HjWLOw3Gynzken3SJY2XBxFtzk9k7NAhTdOlhguqPxOLBI8V01KaJpKHP5zLhR7jZD9DfwqcyO9n+4/3x3077sE9LPBmt/ouRCuDoFXAlwAOC7x4x3Xxw8NvUp3bxs26QSrdO9UoWzSFvsT+IpM2A1s5P8sif0yonqKTiow= x-ms-office365-filtering-correlation-id: 523d3331-4ed7-41d1-3d37-08d4d359bd80 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB0872; x-ms-traffictypediagnostic: DB5PR07MB0872: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(82608151540597)(211936372134217)(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)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(920507026)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0872; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0872; x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39410400002)(39400400002)(39860400002)(39850400002)(13464003)(24454002)(199003)(377454003)(189002)(6116002)(54356999)(54906002)(14454004)(6306002)(106356001)(25786009)(54896002)(9686003)(7696004)(99286003)(6506006)(229853002)(68736007)(66066001)(6246003)(478600001)(6436002)(38730400002)(39060400002)(2900100001)(5660300001)(105586002)(55016002)(50986999)(53936002)(236005)(110136004)(101416001)(74316002)(93886004)(8676002)(8936002)(34040400001)(81156014)(86362001)(3480700004)(189998001)(76176999)(53546010)(790700001)(102836003)(97736004)(2950100002)(5890100001)(6916009)(7736002)(2906002)(3280700002)(5250100002)(3846002)(81166006)(33656002)(4326008)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB0872; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB123729774C9302FA783031DC84B80DB5PR07MB1237eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 12:36:14.9849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0872 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, 25 Jul 2017 12:36:22 -0000 --_000_DB5PR07MB123729774C9302FA783031DC84B80DB5PR07MB1237eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb21dDQpTZW50OiAy NSBKdWx5IDIwMTcgMTM6MjUNClRvOiBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1i cmlkZ2UsIFVLKSA8dGhvbWFzLnN3aW5kZWxsc0Bub2tpYS5jb20+DQpDYzogRG1pdHJpIFRpa2hv bm92IDxkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuIDxtaWtrZWxmakBnbWFpbC5jb20+OyBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVj dDogUmU6IElkZWEgZm9yIHBhY2tldCBudW1iZXJzDQoNClNvbWUgdGhvdWdodHMuDQoNCjEpIFNl bmRpbmcgcGFja2V0IG51bWJlcnMgaW4gb3JkZXIgaXMgbm90IHJlcXVpcmVkLCBidXQgdGhlIGZh cnRoZXIgb3V0IG9mIG9yZGVyIHBhY2tldHMgZ2V0LCB0aGUgbW9yZSBhY2tzIHRoZSByZWNlaXZl ciBpcyBnb2luZyB0byBzZW5kLCB0aGUgbGFyZ2VyIHRoZXknbGwgYmUsIGFuZCB0aGUgbW9yZSBj b21wbGV4IGxvc3MgZGV0ZWN0aW9uIGlzLiAgSW4gcGFydGljdWxhciwgeW91IHdvbid0IGJlIGFi bGUgdG8gcmVseSBvbiBRVUlDJ3MgcGFja2V0IG51bWJlcnMgYmVpbmcgaW4gdGltZSBvcmRlci4g IFRMRFI7IEl0J3MgZWFzaWVyIHRvIHNlbmQgcGFja2V0cyBpbiBvcmRlciB0aGFuIGl0IGlzIHRv IGNvcnJlY3RseSBkZWFsIHdpdGggdGhlIGltcGxpY2F0aW9ucyBvZiBzZW5kaW5nIHRoZW0gb3V0 IG9mIG9yZGVyLg0KDQoyKSBJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYSBjb21wZWxsaW5nIHJlYXNv biB0byB1c2UgbXVsdGlwbGUgQ1BVcyBmb3IgYSBzaW5nbGUgUVVJQyBjb25uZWN0aW9uIGluIGFu eSBjaXJjdW1zdGFuY2VzIEkndmUgZW5jb3VudGVyZWQuICBBbmQgaWYgaXQgaXMgbmVjZXNzYXJ5 LCBpdCdkIGJlIG11Y2ggc2ltcGxlciBhbmQgZmFzdGVyIHRvIGF2b2lkIGFueSBsb2NraW5nIGFu ZCB1c2UgbXVsdGlwbGUgUVVJQyBjb25uZWN0aW9ucyhvciBwb3NzaWJseSBtdWx0aXBhdGggaWYg aXQgZXhpc3RlZCkuICBUaGlzIGFsc28gaGFzIHRoZSBiZW5lZml0IG9mIHNlbmRpbmcgdGhlIHBh Y2tldCBudW1iZXJzIHNlcXVlbnRpYWxseSBmb3IgYSBnaXZlbiBjb25uZWN0aW9uIElELg0KW1Ro b21hcyBTd2luZGVsbHNdIFBlcmZvcm1hbmNlIHNlZW1zIHRvIG1lIHRvIGJlIGEgY29tcGVsbGlu ZyByZWFzb24uIEZpcnN0bHkgaWYgeW91IGhhdmUgZGlmZmVyZW50IGFzc2V0cy9kYXRhIGluIG1l bW9yeSAocGFydGljdWxhcmx5IENQVSBjYWNoZSkgdG8gZ2V0IHRoZSBtb3N0IG91dCBvZiBhIHN5 c3RlbSB5b3Ugd2FudCB0byBrZWVwIHRoZSBkYXRhIHByb2Nlc3NpbmcgbG9jYWwgdG8gdGhlIGNw dS4gU2Vjb25kbHkgZW5jcnlwdGlvbiBpcyBzdGlsbCBhIHJlbGF0aXZlbHkgZXhwZW5zaXZlIG9w ZXJhdGlvbiwgQ1BVcyBoYXZlIGFjY2VsZXJhdGlvbiB0byBoZWxwIHNvIHlvdSBhcmUgZ29pbmcg dG8gd2FudCB0byBkbyB3b3JrIGluIHBhcmFsbGVsIOKAkyBwYXJ0aWN1bGFybHkgd2hlbiBkZWxp dmVyaW5nIG11bHRpcGxlIHN0cmVhbXMuIFRoZXNlIGNhbiBtYWtlIGEgc2lnbmlmaWNhbnQgaW1w YWN0IG9uIGEgc2VydmVyIGRlbGl2ZXJpbmcgODBHYnBzIG9mIGxpdmUgdmlkZW8gdHJhZmZpYy4g T25lIG9mIHRoZSBiaWcgYWR2ZXJ0aXNlZCBiZW5lZml0cyBvZiBRVUlDIGlzIGl0cyBzdXBwb3J0 IGZvciBzdHJlYW0gbXVsdGlwbGV4aW5nIGFuZCBpdCBpcyBtb3N0bHkgdXAgdG8gdGhlIGNsaWVu dCByYXRoZXIgdGhhbiB0aGUgc2VydmVyIGFib3V0IHdoZXRoZXIgdG8gdXNlIGl0LCBJIGRvbuKA mXQgdGhpbmsgaXRzIHZpYWJsZSB0byBzYXkganVzdCBkb27igJl0IHVzZSBpdD8NCg0KMykgSSdt IGhhcHB5IHRvIHRyZWF0IHJlb3JkZXJpbmcgaW4gdGhlIE5JQyBhcyBhIGZvcm0gb2YgbmV0d29y ayByZW9yZGVyaW5nLCBzaW5jZSBpdCdzIG5vdCBzb21ldGhpbmcgdGhlIFFVSUMgaW1wbGVtZW50 YXRpb24gbWF5IGJlIGFibGUgdG8gY29udHJvbC4NCg0KDQpPbiBUdWUsIEp1bCAyNSwgMjAxNyBh dCA2OjA0IEFNLCBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSA8 dGhvbWFzLnN3aW5kZWxsc0Bub2tpYS5jb208bWFpbHRvOnRob21hcy5zd2luZGVsbHNAbm9raWEu Y29tPj4gd3JvdGU6DQpJJ3ZlIGJlZW4gdGhpbmtpbmcgYWJvdXQgcGFja2V0IG51bWJlcnMgYW5k IHdoYXQgaXQgaXMgc2FmZSB0byByZWFzb24gYWJvdXQgdGhlbS4NCg0KV2l0aCByZWdhcmRzIHRv IHBhY2tldCBudW1iZXJzIHRoZSBrZXkgcGFydHMgb2YgdGhlIHNwZWMgYXBwZWFyIHRvIGJlOg0K YSkgIFRoZSBwYWNrZXQgbnVtYmVyIGZvciBzZW5kaW5nIE1VU1QgaW5jcmVhc2UgYnkgYXQgbGVh c3Qgb25lIGFmdGVyIHNlbmRpbmcgYW55IHBhY2tldCwgdW5sZXNzIG90aGVyd2lzZSBzcGVjaWZp ZWQNCmIpIEEgUVVJQyBlbmRwb2ludCBNVVNUIE5PVCByZXVzZSBhIHBhY2tldCBudW1iZXIgd2l0 aGluIHRoZSBzYW1lIGNvbm5lY3Rpb24NCmMpIFRoZSBzZW5kZXIgTVVTVCB1c2UgYSBwYWNrZXQg bnVtYmVyIHNpemUgYWJsZSB0byByZXByZXNlbnQgbW9yZSB0aGFuIHR3aWNlIGFzIGxhcmdlIGEg cmFuZ2UgdGhhbiB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBsYXJnZXN0IGFja25vd2xlZGdl ZCBwYWNrZXQgYW5kIHBhY2tldCBudW1iZXIgYmVpbmcgc2VudC4NCmQpIEFuIGVuZHBvaW50IFNI T1VMRCByZXRhaW4gb2xkIGtleXMgZm9yIGEgc2hvcnQgcGVyaW9kIHRvIGFsbG93IGl0IHRvIGRl Y3J5cHQgcGFja2V0cyB3aXRoIHNtYWxsZXIgcGFja2V0IG51bWJlcnMgdGhhbiB0aGUgcGFja2V0 IHRoYXQgdHJpZ2dlcmVkIHRoZSBrZXkgdXBkYXRlLiBUaGlzIGFsbG93cyBhbiBlbmRwb2ludCB0 byBjb25zdW1lIHBhY2tldHMgdGhhdCBhcmUgcmVvcmRlcmVkIGFyb3VuZCB0aGUgdHJhbnNpdGlv biBiZXR3ZWVuIGtleXMuIFBhY2tldHMgd2l0aCBoaWdoZXIgcGFja2V0IG51bWJlcnMgYWx3YXlz IHVzZSB0aGUgdXBkYXRlZCBrZXlzIGFuZCBNVVNUIE5PVCBiZSBkZWNyeXB0ZWQgd2l0aCBvbGQg a2V5cy4NCg0KPkZyb20gYSByZWNlaXZlcnMgcG9pbnQgb2YgdmlldyB3ZSBhY3RpdmVseSBpZ25v cmUgYSBhbmQgYXNzdW1lIHRoYXQgdGhlcmUgbWF5IGJlIHBhY2tldCByZW9yZGVyaW5nIGFuZCBw YWNrZXQgbG9zcyBpbiB0aGUgbmV0d29yay4NClBhY2tldCByZW9yZGVyaW5nIG1lYW5zIHRoYXQg cGFja2V0IG51bWJlcnMgd29uJ3QgYXBwZWFyIGluIG9yZGVyLiBQYWNrZXQgbG9zcyBhbmQgdGhl IHN1YnNlcXVlbnQgcmV0cmFuc21pc3Npb24gd2l0aCBhIG5ldyBwYWNrZXQgbnVtYmVyIG1lYW5z IHRoYXQgKHJldHJhbnNtaXR0ZWQpIGxvd2VyIG9mZnNldCBzdHJlYW0gZGF0YSBtYXkgYXJyaXZl IHdpdGggYSBoaWdoZXIgcGFja2V0IG51bWJlci4gVGhlIHJlY2VpdmVyIGlzIGV4cGVjdGVkIHRv IGRlYWwgd2l0aCB0aGVzZSBhcyBwYXJ0IG9mIG5vcm1hbCBvcGVyYXRpb24uDQoNCj5Gcm9tIHRo ZSBzZW5kZXJzIHBlcnNwZWN0aXZlIHRoZSBwcm9jZXNzIGl0IGdvZXMgdGhyb3VnaCBpczoNCjEu IEdldCBkYXRhIHRvIHNlbmQNCjIuIEdldCBwYWNrZXQgbnVtYmVyDQozLiBlbmNyeXB0IHBhY2tl dA0KNC4gcXVldWUgcGFja2V0IG9uIE5JQw0KNS4gTklDIHNlbmRzIHBhY2tldC4NCg0KT24gYSBz aW5nbGUgdGhyZWFkZWQgc2luZ2xlIHN0cmVhbSBhcHBsaWNhdGlvbiBhbiBpbXBsZW1lbnRhdGlv biB3cml0dGVuIHRvIHNwZWMgd291bGQgc2VxdWVudGlhbGx5IGNyZWF0ZSBwYWNrZXRzIGluIG9y ZGVyLCBlbmNyeXB0IHRoZW0gYW5kIHRoZSBuaWMgc2hvdWxkIHRoZW4gc2VuZCB0aGVtIG91dCBp biBvcmRlciBvbnRvIHRoZSBuZXR3b3JrLg0KSG93ZXZlciBvbiBhIG11bHRpLWNwdSBzZXJ2ZXIg c2VuZGluZyBtdWx0aXBsZSBzdHJlYW1zIGluIHRoZSBzYW1lIGNvbm5lY3Rpb25zIHRoaW5ncyBn ZXQgbXVjaCBoYXJkZXIgdG8gcmVhc29uIGFib3V0LiBXZSBjYW4gYXNzdW1lIHRoYXQgZWFjaCBz dHJlYW0gaXMgbGlrZWx5IGJlaW5nIGdlbmVyYXRlZCBieSBhIGRpZmZlcmVudCBhcHBsaWNhdGlv biB0aHJlYWQgKHRvIGF2b2lkIHNlcnZlciBzaWRlIGhlYWQgb2YgbGluZSBibG9ja2luZyBldGMp IGFuZCBzbyBiZSBwcm9kdWNpbmcgcGFja2V0cyBjb25jdXJyZW50bHkuDQpPbmUgb3B0aW9uIGlz IHRvIHNlcmlhbGlzZSB0aGUgc2VuZGluZywgc28gdGhhdCBhZnRlciBzdGVwIDEgdGhlIHJlcXVl c3QgZW50ZXJzIGEgc3luY2hyb25pemVkIHNlcmlhbGl6ZWQgcHJvY2VzcyBhbmQgcHJvY2VlZHMg d2l0aCBzdHJpY3Qgb3JkZXJpbmcgYWxsb3dpbmcgcmVxdWlyZW1lbnQgYSB0byBiZSBtZXQuDQpU aGlzIG9wdGlvbiBpc24ndCBob3dldmVyIGVmZmljaWVudCBvciBkZXNpcmFibGUgZm9yIGEgcGVy Zm9ybWFuY2Ugb3B0aW1pemVkIHNvbHV0aW9uLg0KT24gYSBtdWx0aS1jcHUgc3lzdGVtLCBmb3Ig b3B0aW1hbCBwZXJmb3JtYW5jZSB5b3Ugd2FudCB0byB0YWtlIGFkdmFudGFnZSBvZiBkYXRhIGxv Y2FsaXR5IChpdCBpcyBleHBlbnNpdmUgdG8gc2h1ZmZsZSBkYXRhIGJldHdlZW4gQ1BVIGNvcmVz IHdoZW4geW91IGRvbid0IGhhdmUgdG8pLiBUaGUgb2J2aW91cyBkZXNpZ24gd291bGQgYmUgdG8g aGF2ZSBhbiBhdG9taWMgY291bnRlciBmb3IgdGhlIHBhY2tldCBudW1iZXIgYW5kIGRvIHN0ZXBz IDEtNCB3aXRoaW4gdGhlIHRocmVhZCAob3IgYXQgbGVhc3QgQ1BVKSB0aGF0IGlzIGdlbmVyYXRp bmcgdGhlIGRhdGEuIFdpdGggbXVsdGlwbGUgc3RyZWFtcyBiZWluZyBnZW5lcmF0ZWQgb24gbXVs dGlwbGUgY3B1IGNvcmVzIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZSBvcmRlciB0aGUg cGFja2V0IG51bWJlcnMgYXJlIGFzc2lnbmVkIGZvciB0aGUgcGFja2V0cyB3aWxsIG1hdGNoIHRo ZSBvcmRlciB0aGF0IHRoZSBwYWNrZXRzIGFyZSBxdWV1ZWQgb24gdGhlIE5JQy4gVGhlIGhpZ2hl ciBudW1iZXJlZCBwYWNrZXQgbWF5IGdldCBlbmNyeXB0ZWQgcXVpY2tlciBhbmQgc28gZW5xdWV1 ZWQgYW5kIHNlbnQgYWhlYWQgb2YgdGhlIGVhcmxpZXIgcGFja2V0IG51bWJlci4gQXQgdGhlIHdp cmUgbGV2ZWwgdGhpcyB3b3VsZCBnaXZlIGFuIGVncmVzcyBwYXR0ZXJuIHdoZXJlIHRoZSBwYWNr ZXQgbnVtYmVycyB3ZXJlbid0IGluY3JlYXNpbmcgYWZ0ZXIgZXZlcnkgcGFja2V0LCBvbmx5IG92 ZXIgdGhlIGxvbmdlciBydW4uDQpJZiB0aGUgc2VydmVyIGhhcyBtdWx0aXBsZSBOSUNTIHRoZW4g dGhlIHByb2JsZW0gaGFzIHBvdGVudGlhbCBvZiBvY2N1cnJpbmcgZXZlbiBpZiBzdGVwcyAxLTQg aGFkIGJlZW4gc2VyaWFsaXplZCB2aWEgYSBjcm9zcyBjcHUgc2VtYXBob3JlL2xvY2suIERpZmZl cmVudCBOSUNTIHdpbGwgYmUgYXR0YWNoZWQgdG8gZGlmZmVyZW50IENQVSBjb3JlcyBhbmQgYW4g ZWZmaWNpZW50IE9TIGNvdWxkIHRyeSB0byBhdm9pZCBjcm9zcyBDUFUgY29tbXVuaWNhdGlvbiBi eSBxdWV1aW5nIHRoZSBwYWNrZXQgb24gYSBOSUMgY29ubmVjdGVkIHRvIHRoZSBzYW1lIENQVSBh cyB0aGUgdGhyZWFkIHRoYXQgZ2VuZXJhdGVkIHRoZSBwYWNrZXQuIElmIGRpZmZlcmVudCB0aHJl YWRzIGFyZSBnZW5lcmF0aW5nIHRoZSBwYWNrZXRzIG9uIGRpZmZlcmVudCBjb3JlcyB0aGVuIHBv dGVudGlhbGx5IHRoZSBwYWNrZXRzIGNvdWxkIGJlIHF1ZXVlZCBvbiBkaWZmZXJlbnQgTklDUyBh bmQgdGhlcmVmb3JlIGJlIHNlbnQgb3V0IG9mIG9yZGVyIGV2ZW4gaWYgdGhleSB3ZXJlIHF1ZXVl ZCBpbiBvcmRlci4NCg0KT2J2aW91c2x5IHdlIGhhdmUgZXN0YWJsaXNoZWQgdGhhdCBhIHJlY2Vp dmVyIHNob3VsZCBiZSBkZXNpZ25lZCB0byBleHBlY3QgYW5kIGhhbmRsZSBwYWNrZXQgcmUtb3Jk ZXJpbmcgYW5kIGl0IGlzIHVua25vd24gdG8gdGhlIHJlY2VpdmVyIHdoZXRoZXIgaXQgaXMgaW4g dGhlIG5ldHdvcmsgb3IgaG9zdCB3aGVyZSB0aGUgcmUtb3JkZXJpbmcgb2NjdXJzLiBGcm9tIGFu IGVuZCB0byBlbmQgcG9pbnQgb2YgdmlldyBhIG11bHRpLXRocmVhZGVkIGltcGxlbWVudGF0aW9u IHdvdWxkIHdvcmsuIElmIHRoZSBtdWx0aS10aHJlYWRlZCBpbXBsZW1lbnRhdGlvbiBzdHJpY3Rs eSBjb21wbGllcyB3aXRoIGEgdGhlbiBJJ20gdW5zdXJlLCBpdCBkZXBlbmRzIHdoYXQgcGFydCBv ZiB0aGUgcHJvY2VzcyBpcyBkZWZpbmVkIGFzICdzZW5kaW5nJyBhbmQgd2hlcmUgdGhlIG1lYXN1 cmVtZW50IHRvIHZhbGlkYXRlIGl0IHNob3VsZCBiZSB0YWtlbiAoZS5nLiB0aGUgcG9pbnQgdGhl IHBhY2tldHMgYXBwZWFyIG9uIHRoZSBuZXR3b3JrIHZzIHRoZSBwb2ludCB0aGUgaW50ZW50aW9u IHRvIGNyZWF0ZSBhIHBhY2tldCB0byBzZW5kIGlzIGFjdGlvbmVkKS4NCg0KVG8gY29tcGxpY2F0 ZSBtYXR0ZXJzIGZ1cnRoZXIsIGFuIGltcGxlbWVudGVyIG1heSBub3Qgd2FudCB0byBhbGxvY2F0 ZWQgcGFja2V0IG51bWJlcnMgb25lIGJ5IG9uZS4gSWYgdGhleSBrbm93IHRoZXkgaGF2ZSAzMiBw YWNrZXRzIHdvcnRoIG9mIGRhdGEgdG8gc2VuZCB0aGVuIHBlcmhhcHMgaXQgaXMgbW9yZSBlZmZp Y2llbnQgdG8gcmVxdWVzdCAzMiBwYWNrZXQgbnVtYmVycyBpbiBhIHNpbmdsZSBhdG9taWMgb3Bl cmF0aW9uIGFuZCB0aGVuIGVuY3J5cHQgYW5kIGVucXVldWUgdGhlIHBhY2tldHMgaW4gdHVybi4g SWYgYW5vdGhlciB0aHJlYWQgb24gYSBsZXNzIGxvYWRlZCBjcHUgaXMgYWxzbyBnZW5lcmF0aW5n IHN0cmVhbSBkYXRhIHRoZW4gcGFja2V0IG51bWJlciByZS1vcmRlcmluZyBtYXkgb2NjdXIgdG8g YW4gZXZlbiBncmVhdGVyIGV4dGVuZC4gQWdhaW4gKHdpdGhpbiBsaW1pdHMpIHRoZSByZWNlaXZl ciBzaG91bGQgY29wZSB3aXRoIHRoaXMgbGV2ZWwgb2YgcGFja2V0IHJlLW9yZGVyaW5nIC0gYXMg bG9uZyBhcyB0aGUgcGFja2V0IG51bWJlciBzaXplIGNvbnN0cmFpbnRzIGFyZW4ndCB2aW9sYXRl ZCBhbmQgdGhlIHBhY2tldHMgYXJyaXZlIGluIGEgdGltZWx5IG1hbm5lci4gSG93ZXZlciBpdCBk b2VzIGJyZWFrIHRoZSBhc3N1bXB0aW9uIHRoYXQgeW91IGNhbiBnZW5lcmFsbHkgcmVseSBvbiB0 aGUgbG93IG9yZGVyIGJpdHMgb2YgcGFja2V0IG51bWJlcnMgdG8gYmUgZ2VuZXJhbGx5IHNlbnQg aW4gb3JkZXIuDQoNClRoZSBwYWNrZXQgcmUtb3JkZXJpbmcgaXNzdWUgYWxzbyBpbXBhY3QgcmVx dWlyZW1lbnRzIGFyb3VuZCBzdHJlYW1zIGlkcyBiZWluZyBjcmVhdGVkIHNlcXVlbnRpYWxseSBp biBvcmRlciBhcyB0aGUgc2FtZSBzZXQgb2YgcmFjZSBjb25kaXRpb25zIGNhbiBvY2N1ci4NCg0K SSB0aGluayBpdCBtYXkgYmUgd29ydGh3aGlsZSBjbGFyaWZ5aW5nIHdoYXQgdGhlIHBhY2tldCBu dW1iZXIgYmVoYXZpb3VyIGlzIGV4cGVjdGVkIHRvIGxvb2sgbGlrZSBmcm9tIGFuIGV4dGVybmFs IG9ic2VydmVycyBwZXJzcGVjdGl2ZS4gSXMgdGhlcmUgYWN0dWFsbHkgYSBkZXNpcmUgdG8gYXR0 ZW1wdCB0byBmb3JjZSB0aGUgc2VuZGVyIHRvIHNlcmlhbGl6ZSBwYWNrZXQgc2VuZGluZz8gVGhh dCBpcywgZG9lcyBxdWljIHJlcXVpcmUgdGhhdCB0aGUgZWdyZXNzIGZyb20gdGhlIGhvc3QgaXMg c3RyaWN0bHkgaW4gb3JkZXIgYW5kIG9ubHkgdGhlIG5ldHdvcmsgY2FuIGludHJvZHVjZSByZS1v cmRlcmluZz8gV2hpbHN0IGtlZXBpbmcgd2l0aGluIHRoZSBjb25zdHJhaW50cyBvZiBiLWQsIGlz L3Nob3VsZCBpdCBiZSBhY2NlcHRhYmxlIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gYWxsb2NhdGVz IGJsb2NrcyBvZiBjb250aWd1b3VzIHBhY2tldCBudW1iZXJzIGZvciBlYWNoIHN0cmVhbT8gSWYg cHJvYmFibHkgd291bGQgbWVhbiB5b3UgZW5kIHVwIHdpdGggZ2FwcyBpbiBwYWNrZXQgbnVtYmVy cyB3aGVuIGEgc3RyZWFtIGRvZXNuJ3QgdXNlIGFsbCBvZiBpdHMgYWxsb2NhdGlvbiBpbiB0aW1l IChlLmcgYSBrZXkgY2hhbmdlIHJlcXVpcmVzIGl0IHRvIG1vdmUgdG8gYSBuZXcgYWxsb2NhdGlv bikuIElmIGl0IGlzbid0IGFjY2VwdGFibGUgdGhlbiB3aGF0IGFyZSB0aGUgY29uc3RyYWludHMg dGhlIHNlbmRlciBzaG91bGQga2VlcCB3aXRoaW4/DQoNClRob21hcw0KDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERtaXRyaSBU aWtob25vdg0KPiBTZW50OiAyMSBKdWx5IDIwMTcgMTA6MzgNCj4gVG86IE1pa2tlbCBGYWhuw7hl IErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29t Pj4NCj4gQ2M6IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5j b208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4+OyBJRVRGIFFVSUMgV0cN Cj4gPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSZTog SWRlYSBmb3IgcGFja2V0IG51bWJlcnMNCj4NCj4gT24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgMDc6 MTA6MTFBTSAtMDQwMCwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiB3cm90ZToNCj4gPiBGb3Ig b3RoZXIgcmVhc29ucyBJIHdvdWxkIGxpa2UgdGhlIHBhY2tldCBudW1iZXJzIHRvIGJlIGNsb3Nl LA0KPiA+IHByZWZlcmFibHkgd2l0aG91dCBnYXBzIGV4Y2VwdCBkdXJpbmcgY29ubmVjdGlvbiBt aWdyYXRpb24uDQo+ID4NCj4gPiBUaGlzIHJlbGF0ZXMgdG8gc3RvcmluZyBpbnRlcnZhbCBtYXBz IGFzIGdyb3VwcyBvZiBiaXRtYXBzIGluc3RlYWQgb2YNCj4gPiBiaW5hcnkgdHJlZXMgdG8gdHJh Y2sgYWxyZWFkeSByZWNlaXZlZCBwYWNrZXRzLiBUaGlzIGJvdGggcHJvdmlkZXMgYXJlDQo+ID4g bW9yZSBlZmZpY2llbnQgaW1wbGVtZW50YXRpb24sIGFuZCBpdCByZWR1Y2VzIHNvbWUgbW9kZXMg b2YgRG9TIHdoZXJlDQo+ID4gYW4gYXR0YWNrZXIgY2FuIGNyZWF0ZSBhIGxvdCBvZiBzbWFsbCBp bnRlcnZhbHMgd2hpY2ggY2F1c2UgdGhlIGRhdGENCj4gPiBzdHJ1Y3R1cmUgdG8gaW5mbGF0ZS4N Cj4NCj4gVGhlIHJlY2VpdmUgaGlzdG9yeSBnZXRzIHRydW5jYXRlZCBhdXRvbWF0aWNhbGx5LCBh bmQgc28gdGhlIHJlY2VpdmVyIGRvZXMgbm90DQo+IGhhdmUgdG8gd29ycnkgYWJvdXQgYSBsb3Qg b2YgZGF0YSB0byBrZWVwIHRyYWNrIG9mLiAgRnJvbSBbZHJhZnQtaWV0Zi1xdWljLQ0KPiB0cmFu c3BvcnRdIDguMTM6DQo+DQo+ICAiIFRvIGxpbWl0IEFDSyBibG9ja3MgdG8gdGhvc2UgdGhhdCBo YXZlIG5vdCB5ZXQgYmVlbiByZWNlaXZlZCAgIiBieSB0aGUNCj4gc2VuZGVyLCB0aGUgcmVjZWl2 ZXIgU0hPVUxEIHRyYWNrIHdoaWNoIEFDSyBmcmFtZXMgICIgaGF2ZSBiZWVuDQo+IGFja25vd2xl ZGdlZCBieSBpdHMgcGVlci4gIE9uY2UgYW4gQUNLIGZyYW1lIGhhcyAgIiBiZWVuIGFja25vd2xl ZGdlZCwgdGhlDQo+IHBhY2tldHMgaXQgYWNrbm93bGVkZ2VzIFNIT1VMRCBub3QgYmUgICIgYWNr bm93bGVkZ2VkIGFnYWluLg0KPg0KPiBTZW5kIGhpc3RvcnkgaXMgYW5vdGhlciBtYXR0ZXIuICBJ YmlkLiwgOC4xMzoNCj4NCj4gICIgVGhlIHNlbmRlciBTSE9VTEQgY2xvc2UgdGhlIGNvbm5lY3Rp b24gaWYgYW4gdW5zZW50IHBhY2tldCAgIiBudW1iZXIgaXMNCj4gYWNrbm93bGVkZ2VkLg0KPg0K PiAoUHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIGRyYWZ0IGhhZCBhIE1VU1QgaW5zdGVhZCBvZiBh IFNIT1VMRC4pDQo+DQo+IFRodXMgaXQgaXMgaW4gdGhlIGludGVyZXN0IG9mIHRoZSBzZW5kZXIg ZWl0aGVyIHRvIGNyZWF0ZSBmZXcgZ2FwcyBvciB0byBjcmVhdGUNCj4gdGhlbSBpbiBhIG1hbm5l ciB0aGF0IGRvZXMgbm90IGJsb3cgdXAgaXRzIG93biBzZW5kIGhpc3RvcnkgZGF0YSBzdHJ1Y3R1 cmVzIGlmDQo+IGl0IHdhbnRzIHRvIGNoZWNrIHdoZXRoZXIgYW4gdW5zZW50IHBhY2tldCBpcyBB Q0tlZC4NCj4NCj4gICAtIERtaXRyaS4NCg0K --_000_DB5PR07MB123729774C9302FA783031DC84B80DB5PR07MB1237eurp_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t R0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiAyNSBKdWx5IDIwMTcgMTM6MjU8YnI+DQo8Yj5Ubzo8L2I+IFN3aW5kZWxs cywgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwgVUspICZsdDt0aG9tYXMuc3dpbmRlbGxz QG5va2lhLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERtaXRyaSBUaWtob25vdiAmbHQ7ZHRpa2hv bm92QGxpdGVzcGVlZHRlY2guY29tJmd0OzsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7 bWlra2VsZmpAZ21haWwuY29tJmd0OzsgTWFnbnVzIFdlc3Rlcmx1bmQgJmx0O21hZ251cy53ZXN0 ZXJsdW5kQGVyaWNzc29uLmNvbSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IElkZWEgZm9yIHBhY2tldCBudW1iZXJzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgdGhv dWdodHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBT ZW5kaW5nIHBhY2tldCBudW1iZXJzIGluIG9yZGVyIGlzIG5vdCByZXF1aXJlZCwgYnV0IHRoZSBm YXJ0aGVyIG91dCBvZiBvcmRlciBwYWNrZXRzIGdldCwgdGhlIG1vcmUgYWNrcyB0aGUgcmVjZWl2 ZXIgaXMgZ29pbmcgdG8gc2VuZCwgdGhlIGxhcmdlciB0aGV5J2xsIGJlLCBhbmQgdGhlIG1vcmUg Y29tcGxleCBsb3NzIGRldGVjdGlvbiBpcy4mbmJzcDsgSW4gcGFydGljdWxhciwgeW91IHdvbid0 IGJlIGFibGUNCiB0byByZWx5IG9uIFFVSUMncyBwYWNrZXQgbnVtYmVycyBiZWluZyBpbiB0aW1l IG9yZGVyLiZuYnNwOyBUTERSOyBJdCdzIGVhc2llciB0byBzZW5kIHBhY2tldHMgaW4gb3JkZXIg dGhhbiBpdCBpcyB0byBjb3JyZWN0bHkgZGVhbCB3aXRoIHRoZSBpbXBsaWNhdGlvbnMgb2Ygc2Vu ZGluZyB0aGVtIG91dCBvZiBvcmRlci4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgSSBkb24ndCB0aGluayB0aGVyZSdz IGEgY29tcGVsbGluZyByZWFzb24gdG8gdXNlIG11bHRpcGxlIENQVXMgZm9yIGEgc2luZ2xlIFFV SUMgY29ubmVjdGlvbiBpbiBhbnkgY2lyY3Vtc3RhbmNlcyBJJ3ZlIGVuY291bnRlcmVkLiZuYnNw OyBBbmQgaWYgaXQgaXMgbmVjZXNzYXJ5LCBpdCdkIGJlIG11Y2ggc2ltcGxlciBhbmQgZmFzdGVy IHRvIGF2b2lkIGFueSBsb2NraW5nIGFuZCB1c2UgbXVsdGlwbGUgUVVJQyBjb25uZWN0aW9ucyhv cg0KIHBvc3NpYmx5IG11bHRpcGF0aCBpZiBpdCBleGlzdGVkKS4mbmJzcDsgVGhpcyBhbHNvIGhh cyB0aGUgYmVuZWZpdCBvZiBzZW5kaW5nIHRoZSBwYWNrZXQgbnVtYmVycyBzZXF1ZW50aWFsbHkg Zm9yIGEgZ2l2ZW4gY29ubmVjdGlvbiBJRC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1Rob21hcyBTd2luZGVsbHNdIFBlcmZvcm1h bmNlIHNlZW1zIHRvIG1lIHRvIGJlIGEgY29tcGVsbGluZyByZWFzb24uIEZpcnN0bHkgaWYgeW91 IGhhdmUgZGlmZmVyZW50IGFzc2V0cy9kYXRhIGluIG1lbW9yeSAocGFydGljdWxhcmx5IENQVSBj YWNoZSkgdG8gZ2V0IHRoZSBtb3N0IG91dA0KIG9mIGEgc3lzdGVtIHlvdSB3YW50IHRvIGtlZXAg dGhlIGRhdGEgcHJvY2Vzc2luZyBsb2NhbCB0byB0aGUgY3B1LiBTZWNvbmRseSBlbmNyeXB0aW9u IGlzIHN0aWxsIGEgcmVsYXRpdmVseSBleHBlbnNpdmUgb3BlcmF0aW9uLCBDUFVzIGhhdmUgYWNj ZWxlcmF0aW9uIHRvIGhlbHAgc28geW91IGFyZSBnb2luZyB0byB3YW50IHRvIGRvIHdvcmsgaW4g cGFyYWxsZWwg4oCTIHBhcnRpY3VsYXJseSB3aGVuIGRlbGl2ZXJpbmcgbXVsdGlwbGUgc3RyZWFt cy4NCiBUaGVzZSBjYW4gbWFrZSBhIHNpZ25pZmljYW50IGltcGFjdCBvbiBhIHNlcnZlciBkZWxp dmVyaW5nIDgwR2JwcyBvZiBsaXZlIHZpZGVvIHRyYWZmaWMuIE9uZSBvZiB0aGUgYmlnIGFkdmVy dGlzZWQgYmVuZWZpdHMgb2YgUVVJQyBpcyBpdHMgc3VwcG9ydCBmb3Igc3RyZWFtIG11bHRpcGxl eGluZyBhbmQgaXQgaXMgbW9zdGx5IHVwIHRvIHRoZSBjbGllbnQgcmF0aGVyIHRoYW4gdGhlIHNl cnZlciBhYm91dCB3aGV0aGVyIHRvIHVzZSBpdCwgSSBkb27igJl0DQogdGhpbmsgaXRzIHZpYWJs ZSB0byBzYXkganVzdCBkb27igJl0IHVzZSBpdD88L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MykgSSdtIGhhcHB5IHRvIHRyZWF0IHJlb3JkZXJpbmcgaW4gdGhlIE5JQyBhcyBh IGZvcm0gb2YgbmV0d29yayByZW9yZGVyaW5nLCBzaW5jZSBpdCdzIG5vdCBzb21ldGhpbmcgdGhl IFFVSUMgaW1wbGVtZW50YXRpb24gbWF5IGJlIGFibGUgdG8gY29udHJvbC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCAy NSwgMjAxNyBhdCA2OjA0IEFNLCBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlk Z2UsIFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5zd2luZGVsbHNAbm9raWEuY29tIiB0 YXJnZXQ9Il9ibGFuayI+dGhvbWFzLnN3aW5kZWxsc0Bub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ3ZlIGJl ZW4gdGhpbmtpbmcgYWJvdXQgcGFja2V0IG51bWJlcnMgYW5kIHdoYXQgaXQgaXMgc2FmZSB0byBy ZWFzb24gYWJvdXQgdGhlbS48YnI+DQo8YnI+DQpXaXRoIHJlZ2FyZHMgdG8gcGFja2V0IG51bWJl cnMgdGhlIGtleSBwYXJ0cyBvZiB0aGUgc3BlYyBhcHBlYXIgdG8gYmU6PGJyPg0KYSkmbmJzcDsg VGhlIHBhY2tldCBudW1iZXIgZm9yIHNlbmRpbmcgTVVTVCBpbmNyZWFzZSBieSBhdCBsZWFzdCBv bmUgYWZ0ZXIgc2VuZGluZyBhbnkgcGFja2V0LCB1bmxlc3Mgb3RoZXJ3aXNlIHNwZWNpZmllZDxi cj4NCmIpIEEgUVVJQyBlbmRwb2ludCBNVVNUIE5PVCByZXVzZSBhIHBhY2tldCBudW1iZXIgd2l0 aGluIHRoZSBzYW1lIGNvbm5lY3Rpb248YnI+DQpjKSBUaGUgc2VuZGVyIE1VU1QgdXNlIGEgcGFj a2V0IG51bWJlciBzaXplIGFibGUgdG8gcmVwcmVzZW50IG1vcmUgdGhhbiB0d2ljZSBhcyBsYXJn ZSBhIHJhbmdlIHRoYW4gdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbGFyZ2VzdCBhY2tub3ds ZWRnZWQgcGFja2V0IGFuZCBwYWNrZXQgbnVtYmVyIGJlaW5nIHNlbnQuPGJyPg0KZCkgQW4gZW5k cG9pbnQgU0hPVUxEIHJldGFpbiBvbGQga2V5cyBmb3IgYSBzaG9ydCBwZXJpb2QgdG8gYWxsb3cg aXQgdG8gZGVjcnlwdCBwYWNrZXRzIHdpdGggc21hbGxlciBwYWNrZXQgbnVtYmVycyB0aGFuIHRo ZSBwYWNrZXQgdGhhdCB0cmlnZ2VyZWQgdGhlIGtleSB1cGRhdGUuIFRoaXMgYWxsb3dzIGFuIGVu ZHBvaW50IHRvIGNvbnN1bWUgcGFja2V0cyB0aGF0IGFyZSByZW9yZGVyZWQgYXJvdW5kIHRoZSB0 cmFuc2l0aW9uIGJldHdlZW4ga2V5cy4NCiBQYWNrZXRzIHdpdGggaGlnaGVyIHBhY2tldCBudW1i ZXJzIGFsd2F5cyB1c2UgdGhlIHVwZGF0ZWQga2V5cyBhbmQgTVVTVCBOT1QgYmUgZGVjcnlwdGVk IHdpdGggb2xkIGtleXMuPGJyPg0KPGJyPg0KJmd0O0Zyb20gYSByZWNlaXZlcnMgcG9pbnQgb2Yg dmlldyB3ZSBhY3RpdmVseSBpZ25vcmUgYSBhbmQgYXNzdW1lIHRoYXQgdGhlcmUgbWF5IGJlIHBh Y2tldCByZW9yZGVyaW5nIGFuZCBwYWNrZXQgbG9zcyBpbiB0aGUgbmV0d29yay48YnI+DQpQYWNr ZXQgcmVvcmRlcmluZyBtZWFucyB0aGF0IHBhY2tldCBudW1iZXJzIHdvbid0IGFwcGVhciBpbiBv cmRlci4gUGFja2V0IGxvc3MgYW5kIHRoZSBzdWJzZXF1ZW50IHJldHJhbnNtaXNzaW9uIHdpdGgg YSBuZXcgcGFja2V0IG51bWJlciBtZWFucyB0aGF0IChyZXRyYW5zbWl0dGVkKSBsb3dlciBvZmZz ZXQgc3RyZWFtIGRhdGEgbWF5IGFycml2ZSB3aXRoIGEgaGlnaGVyIHBhY2tldCBudW1iZXIuIFRo ZSByZWNlaXZlciBpcyBleHBlY3RlZCB0bw0KIGRlYWwgd2l0aCB0aGVzZSBhcyBwYXJ0IG9mIG5v cm1hbCBvcGVyYXRpb24uPGJyPg0KPGJyPg0KJmd0O0Zyb20gdGhlIHNlbmRlcnMgcGVyc3BlY3Rp dmUgdGhlIHByb2Nlc3MgaXQgZ29lcyB0aHJvdWdoIGlzOjxicj4NCjEuIEdldCBkYXRhIHRvIHNl bmQ8YnI+DQoyLiBHZXQgcGFja2V0IG51bWJlcjxicj4NCjMuIGVuY3J5cHQgcGFja2V0PGJyPg0K NC4gcXVldWUgcGFja2V0IG9uIE5JQzxicj4NCjUuIE5JQyBzZW5kcyBwYWNrZXQuPGJyPg0KPGJy Pg0KT24gYSBzaW5nbGUgdGhyZWFkZWQgc2luZ2xlIHN0cmVhbSBhcHBsaWNhdGlvbiBhbiBpbXBs ZW1lbnRhdGlvbiB3cml0dGVuIHRvIHNwZWMgd291bGQgc2VxdWVudGlhbGx5IGNyZWF0ZSBwYWNr ZXRzIGluIG9yZGVyLCBlbmNyeXB0IHRoZW0gYW5kIHRoZSBuaWMgc2hvdWxkIHRoZW4gc2VuZCB0 aGVtIG91dCBpbiBvcmRlciBvbnRvIHRoZSBuZXR3b3JrLjxicj4NCkhvd2V2ZXIgb24gYSBtdWx0 aS1jcHUgc2VydmVyIHNlbmRpbmcgbXVsdGlwbGUgc3RyZWFtcyBpbiB0aGUgc2FtZSBjb25uZWN0 aW9ucyB0aGluZ3MgZ2V0IG11Y2ggaGFyZGVyIHRvIHJlYXNvbiBhYm91dC4gV2UgY2FuIGFzc3Vt ZSB0aGF0IGVhY2ggc3RyZWFtIGlzIGxpa2VseSBiZWluZyBnZW5lcmF0ZWQgYnkgYSBkaWZmZXJl bnQgYXBwbGljYXRpb24gdGhyZWFkICh0byBhdm9pZCBzZXJ2ZXIgc2lkZSBoZWFkIG9mIGxpbmUg YmxvY2tpbmcgZXRjKQ0KIGFuZCBzbyBiZSBwcm9kdWNpbmcgcGFja2V0cyBjb25jdXJyZW50bHku PGJyPg0KT25lIG9wdGlvbiBpcyB0byBzZXJpYWxpc2UgdGhlIHNlbmRpbmcsIHNvIHRoYXQgYWZ0 ZXIgc3RlcCAxIHRoZSByZXF1ZXN0IGVudGVycyBhIHN5bmNocm9uaXplZCBzZXJpYWxpemVkIHBy b2Nlc3MgYW5kIHByb2NlZWRzIHdpdGggc3RyaWN0IG9yZGVyaW5nIGFsbG93aW5nIHJlcXVpcmVt ZW50IGEgdG8gYmUgbWV0Ljxicj4NClRoaXMgb3B0aW9uIGlzbid0IGhvd2V2ZXIgZWZmaWNpZW50 IG9yIGRlc2lyYWJsZSBmb3IgYSBwZXJmb3JtYW5jZSBvcHRpbWl6ZWQgc29sdXRpb24uPGJyPg0K T24gYSBtdWx0aS1jcHUgc3lzdGVtLCBmb3Igb3B0aW1hbCBwZXJmb3JtYW5jZSB5b3Ugd2FudCB0 byB0YWtlIGFkdmFudGFnZSBvZiBkYXRhIGxvY2FsaXR5IChpdCBpcyBleHBlbnNpdmUgdG8gc2h1 ZmZsZSBkYXRhIGJldHdlZW4gQ1BVIGNvcmVzIHdoZW4geW91IGRvbid0IGhhdmUgdG8pLiBUaGUg b2J2aW91cyBkZXNpZ24gd291bGQgYmUgdG8gaGF2ZSBhbiBhdG9taWMgY291bnRlciBmb3IgdGhl IHBhY2tldCBudW1iZXIgYW5kIGRvIHN0ZXBzIDEtNA0KIHdpdGhpbiB0aGUgdGhyZWFkIChvciBh dCBsZWFzdCBDUFUpIHRoYXQgaXMgZ2VuZXJhdGluZyB0aGUgZGF0YS4gV2l0aCBtdWx0aXBsZSBz dHJlYW1zIGJlaW5nIGdlbmVyYXRlZCBvbiBtdWx0aXBsZSBjcHUgY29yZXMgdGhlcmUgaXMgbm8g Z3VhcmFudGVlIHRoYXQgdGhlIG9yZGVyIHRoZSBwYWNrZXQgbnVtYmVycyBhcmUgYXNzaWduZWQg Zm9yIHRoZSBwYWNrZXRzIHdpbGwgbWF0Y2ggdGhlIG9yZGVyIHRoYXQgdGhlIHBhY2tldHMgYXJl IHF1ZXVlZA0KIG9uIHRoZSBOSUMuIFRoZSBoaWdoZXIgbnVtYmVyZWQgcGFja2V0IG1heSBnZXQg ZW5jcnlwdGVkIHF1aWNrZXIgYW5kIHNvIGVucXVldWVkIGFuZCBzZW50IGFoZWFkIG9mIHRoZSBl YXJsaWVyIHBhY2tldCBudW1iZXIuIEF0IHRoZSB3aXJlIGxldmVsIHRoaXMgd291bGQgZ2l2ZSBh biBlZ3Jlc3MgcGF0dGVybiB3aGVyZSB0aGUgcGFja2V0IG51bWJlcnMgd2VyZW4ndCBpbmNyZWFz aW5nIGFmdGVyIGV2ZXJ5IHBhY2tldCwgb25seSBvdmVyIHRoZQ0KIGxvbmdlciBydW4uPGJyPg0K SWYgdGhlIHNlcnZlciBoYXMgbXVsdGlwbGUgTklDUyB0aGVuIHRoZSBwcm9ibGVtIGhhcyBwb3Rl bnRpYWwgb2Ygb2NjdXJyaW5nIGV2ZW4gaWYgc3RlcHMgMS00IGhhZCBiZWVuIHNlcmlhbGl6ZWQg dmlhIGEgY3Jvc3MgY3B1IHNlbWFwaG9yZS9sb2NrLiBEaWZmZXJlbnQgTklDUyB3aWxsIGJlIGF0 dGFjaGVkIHRvIGRpZmZlcmVudCBDUFUgY29yZXMgYW5kIGFuIGVmZmljaWVudCBPUyBjb3VsZCB0 cnkgdG8gYXZvaWQgY3Jvc3MgQ1BVIGNvbW11bmljYXRpb24NCiBieSBxdWV1aW5nIHRoZSBwYWNr ZXQgb24gYSBOSUMgY29ubmVjdGVkIHRvIHRoZSBzYW1lIENQVSBhcyB0aGUgdGhyZWFkIHRoYXQg Z2VuZXJhdGVkIHRoZSBwYWNrZXQuIElmIGRpZmZlcmVudCB0aHJlYWRzIGFyZSBnZW5lcmF0aW5n IHRoZSBwYWNrZXRzIG9uIGRpZmZlcmVudCBjb3JlcyB0aGVuIHBvdGVudGlhbGx5IHRoZSBwYWNr ZXRzIGNvdWxkIGJlIHF1ZXVlZCBvbiBkaWZmZXJlbnQgTklDUyBhbmQgdGhlcmVmb3JlIGJlIHNl bnQgb3V0IG9mDQogb3JkZXIgZXZlbiBpZiB0aGV5IHdlcmUgcXVldWVkIGluIG9yZGVyLjxicj4N Cjxicj4NCk9idmlvdXNseSB3ZSBoYXZlIGVzdGFibGlzaGVkIHRoYXQgYSByZWNlaXZlciBzaG91 bGQgYmUgZGVzaWduZWQgdG8gZXhwZWN0IGFuZCBoYW5kbGUgcGFja2V0IHJlLW9yZGVyaW5nIGFu ZCBpdCBpcyB1bmtub3duIHRvIHRoZSByZWNlaXZlciB3aGV0aGVyIGl0IGlzIGluIHRoZSBuZXR3 b3JrIG9yIGhvc3Qgd2hlcmUgdGhlIHJlLW9yZGVyaW5nIG9jY3Vycy4gRnJvbSBhbiBlbmQgdG8g ZW5kIHBvaW50IG9mIHZpZXcgYSBtdWx0aS10aHJlYWRlZCBpbXBsZW1lbnRhdGlvbg0KIHdvdWxk IHdvcmsuIElmIHRoZSBtdWx0aS10aHJlYWRlZCBpbXBsZW1lbnRhdGlvbiBzdHJpY3RseSBjb21w bGllcyB3aXRoIGEgdGhlbiBJJ20gdW5zdXJlLCBpdCBkZXBlbmRzIHdoYXQgcGFydCBvZiB0aGUg cHJvY2VzcyBpcyBkZWZpbmVkIGFzICdzZW5kaW5nJyBhbmQgd2hlcmUgdGhlIG1lYXN1cmVtZW50 IHRvIHZhbGlkYXRlIGl0IHNob3VsZCBiZSB0YWtlbiAoZS5nLiB0aGUgcG9pbnQgdGhlIHBhY2tl dHMgYXBwZWFyIG9uIHRoZSBuZXR3b3JrDQogdnMgdGhlIHBvaW50IHRoZSBpbnRlbnRpb24gdG8g Y3JlYXRlIGEgcGFja2V0IHRvIHNlbmQgaXMgYWN0aW9uZWQpLjxicj4NCjxicj4NClRvIGNvbXBs aWNhdGUgbWF0dGVycyBmdXJ0aGVyLCBhbiBpbXBsZW1lbnRlciBtYXkgbm90IHdhbnQgdG8gYWxs b2NhdGVkIHBhY2tldCBudW1iZXJzIG9uZSBieSBvbmUuIElmIHRoZXkga25vdyB0aGV5IGhhdmUg MzIgcGFja2V0cyB3b3J0aCBvZiBkYXRhIHRvIHNlbmQgdGhlbiBwZXJoYXBzIGl0IGlzIG1vcmUg ZWZmaWNpZW50IHRvIHJlcXVlc3QgMzIgcGFja2V0IG51bWJlcnMgaW4gYSBzaW5nbGUgYXRvbWlj IG9wZXJhdGlvbiBhbmQgdGhlbiBlbmNyeXB0DQogYW5kIGVucXVldWUgdGhlIHBhY2tldHMgaW4g dHVybi4gSWYgYW5vdGhlciB0aHJlYWQgb24gYSBsZXNzIGxvYWRlZCBjcHUgaXMgYWxzbyBnZW5l cmF0aW5nIHN0cmVhbSBkYXRhIHRoZW4gcGFja2V0IG51bWJlciByZS1vcmRlcmluZyBtYXkgb2Nj dXIgdG8gYW4gZXZlbiBncmVhdGVyIGV4dGVuZC4gQWdhaW4gKHdpdGhpbiBsaW1pdHMpIHRoZSBy ZWNlaXZlciBzaG91bGQgY29wZSB3aXRoIHRoaXMgbGV2ZWwgb2YgcGFja2V0IHJlLW9yZGVyaW5n DQogLSBhcyBsb25nIGFzIHRoZSBwYWNrZXQgbnVtYmVyIHNpemUgY29uc3RyYWludHMgYXJlbid0 IHZpb2xhdGVkIGFuZCB0aGUgcGFja2V0cyBhcnJpdmUgaW4gYSB0aW1lbHkgbWFubmVyLiBIb3dl dmVyIGl0IGRvZXMgYnJlYWsgdGhlIGFzc3VtcHRpb24gdGhhdCB5b3UgY2FuIGdlbmVyYWxseSBy ZWx5IG9uIHRoZSBsb3cgb3JkZXIgYml0cyBvZiBwYWNrZXQgbnVtYmVycyB0byBiZSBnZW5lcmFs bHkgc2VudCBpbiBvcmRlci48YnI+DQo8YnI+DQpUaGUgcGFja2V0IHJlLW9yZGVyaW5nIGlzc3Vl IGFsc28gaW1wYWN0IHJlcXVpcmVtZW50cyBhcm91bmQgc3RyZWFtcyBpZHMgYmVpbmcgY3JlYXRl ZCBzZXF1ZW50aWFsbHkgaW4gb3JkZXIgYXMgdGhlIHNhbWUgc2V0IG9mIHJhY2UgY29uZGl0aW9u cyBjYW4gb2NjdXIuPGJyPg0KPGJyPg0KSSB0aGluayBpdCBtYXkgYmUgd29ydGh3aGlsZSBjbGFy aWZ5aW5nIHdoYXQgdGhlIHBhY2tldCBudW1iZXIgYmVoYXZpb3VyIGlzIGV4cGVjdGVkIHRvIGxv b2sgbGlrZSBmcm9tIGFuIGV4dGVybmFsIG9ic2VydmVycyBwZXJzcGVjdGl2ZS4gSXMgdGhlcmUg YWN0dWFsbHkgYSBkZXNpcmUgdG8gYXR0ZW1wdCB0byBmb3JjZSB0aGUgc2VuZGVyIHRvIHNlcmlh bGl6ZSBwYWNrZXQgc2VuZGluZz8gVGhhdCBpcywgZG9lcyBxdWljIHJlcXVpcmUgdGhhdA0KIHRo ZSBlZ3Jlc3MgZnJvbSB0aGUgaG9zdCBpcyBzdHJpY3RseSBpbiBvcmRlciBhbmQgb25seSB0aGUg bmV0d29yayBjYW4gaW50cm9kdWNlIHJlLW9yZGVyaW5nPyBXaGlsc3Qga2VlcGluZyB3aXRoaW4g dGhlIGNvbnN0cmFpbnRzIG9mIGItZCwgaXMvc2hvdWxkIGl0IGJlIGFjY2VwdGFibGUgdGhhdCBh biBpbXBsZW1lbnRhdGlvbiBhbGxvY2F0ZXMgYmxvY2tzIG9mIGNvbnRpZ3VvdXMgcGFja2V0IG51 bWJlcnMgZm9yIGVhY2ggc3RyZWFtPyBJZg0KIHByb2JhYmx5IHdvdWxkIG1lYW4geW91IGVuZCB1 cCB3aXRoIGdhcHMgaW4gcGFja2V0IG51bWJlcnMgd2hlbiBhIHN0cmVhbSBkb2Vzbid0IHVzZSBh bGwgb2YgaXRzIGFsbG9jYXRpb24gaW4gdGltZSAoZS5nIGEga2V5IGNoYW5nZSByZXF1aXJlcyBp dCB0byBtb3ZlIHRvIGEgbmV3IGFsbG9jYXRpb24pLiBJZiBpdCBpc24ndCBhY2NlcHRhYmxlIHRo ZW4gd2hhdCBhcmUgdGhlIGNvbnN0cmFpbnRzIHRoZSBzZW5kZXIgc2hvdWxkIGtlZXAgd2l0aGlu Pzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9l bnpiIj5UaG9tYXM8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxi cj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFFVSUMg W21haWx0bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRG1pdHJpIFRpa2hvbm92PGJyPg0KJmd0OyBT ZW50OiAyMSBKdWx5IDIwMTcgMTA6Mzg8YnI+DQomZ3Q7IFRvOiBNaWtrZWwgRmFobsO4ZSBKw7hy Z2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIj5taWtrZWxmakBn bWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IE1hZ251cyBXZXN0ZXJsdW5kICZsdDs8YSBo cmVmPSJtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIj5tYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb208L2E+Jmd0OzsgSUVURiBRVUlDIFdHPGJyPg0KJmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZn dDsgU3ViamVjdDogUmU6IElkZWEgZm9yIHBhY2tldCBudW1iZXJzPGJyPg0KJmd0Ozxicj4NCiZn dDsgT24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgMDc6MTA6MTFBTSAtMDQwMCwgTWlra2VsIEZhaG7D uGUgSsO4cmdlbnNlbiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgRm9yIG90aGVyIHJlYXNvbnMgSSB3 b3VsZCBsaWtlIHRoZSBwYWNrZXQgbnVtYmVycyB0byBiZSBjbG9zZSw8YnI+DQomZ3Q7ICZndDsg cHJlZmVyYWJseSB3aXRob3V0IGdhcHMgZXhjZXB0IGR1cmluZyBjb25uZWN0aW9uIG1pZ3JhdGlv bi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhpcyByZWxhdGVzIHRvIHN0b3Jpbmcg aW50ZXJ2YWwgbWFwcyBhcyBncm91cHMgb2YgYml0bWFwcyBpbnN0ZWFkIG9mPGJyPg0KJmd0OyAm Z3Q7IGJpbmFyeSB0cmVlcyB0byB0cmFjayBhbHJlYWR5IHJlY2VpdmVkIHBhY2tldHMuIFRoaXMg Ym90aCBwcm92aWRlcyBhcmU8YnI+DQomZ3Q7ICZndDsgbW9yZSBlZmZpY2llbnQgaW1wbGVtZW50 YXRpb24sIGFuZCBpdCByZWR1Y2VzIHNvbWUgbW9kZXMgb2YgRG9TIHdoZXJlPGJyPg0KJmd0OyAm Z3Q7IGFuIGF0dGFja2VyIGNhbiBjcmVhdGUgYSBsb3Qgb2Ygc21hbGwgaW50ZXJ2YWxzIHdoaWNo IGNhdXNlIHRoZSBkYXRhPGJyPg0KJmd0OyAmZ3Q7IHN0cnVjdHVyZSB0byBpbmZsYXRlLjxicj4N CiZndDs8YnI+DQomZ3Q7IFRoZSByZWNlaXZlIGhpc3RvcnkgZ2V0cyB0cnVuY2F0ZWQgYXV0b21h dGljYWxseSwgYW5kIHNvIHRoZSByZWNlaXZlciBkb2VzIG5vdDxicj4NCiZndDsgaGF2ZSB0byB3 b3JyeSBhYm91dCBhIGxvdCBvZiBkYXRhIHRvIGtlZXAgdHJhY2sgb2YuJm5ic3A7IEZyb20gW2Ry YWZ0LWlldGYtcXVpYy08YnI+DQomZ3Q7IHRyYW5zcG9ydF0gOC4xMzo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmcXVvdDsgVG8gbGltaXQgQUNLIGJsb2NrcyB0byB0aG9zZSB0aGF0IGhhdmUg bm90IHlldCBiZWVuIHJlY2VpdmVkJm5ic3A7ICZxdW90OyBieSB0aGU8YnI+DQomZ3Q7IHNlbmRl ciwgdGhlIHJlY2VpdmVyIFNIT1VMRCB0cmFjayB3aGljaCBBQ0sgZnJhbWVzJm5ic3A7ICZxdW90 OyBoYXZlIGJlZW48YnI+DQomZ3Q7IGFja25vd2xlZGdlZCBieSBpdHMgcGVlci4mbmJzcDsgT25j ZSBhbiBBQ0sgZnJhbWUgaGFzJm5ic3A7ICZxdW90OyBiZWVuIGFja25vd2xlZGdlZCwgdGhlPGJy Pg0KJmd0OyBwYWNrZXRzIGl0IGFja25vd2xlZGdlcyBTSE9VTEQgbm90IGJlJm5ic3A7ICZxdW90 OyBhY2tub3dsZWRnZWQgYWdhaW4uPGJyPg0KJmd0Ozxicj4NCiZndDsgU2VuZCBoaXN0b3J5IGlz IGFub3RoZXIgbWF0dGVyLiZuYnNwOyBJYmlkLiwgOC4xMzo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmcXVvdDsgVGhlIHNlbmRlciBTSE9VTEQgY2xvc2UgdGhlIGNvbm5lY3Rpb24gaWYgYW4g dW5zZW50IHBhY2tldCZuYnNwOyAmcXVvdDsgbnVtYmVyIGlzPGJyPg0KJmd0OyBhY2tub3dsZWRn ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgKFByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBkcmFmdCBo YWQgYSBNVVNUIGluc3RlYWQgb2YgYSBTSE9VTEQuKTxicj4NCiZndDs8YnI+DQomZ3Q7IFRodXMg aXQgaXMgaW4gdGhlIGludGVyZXN0IG9mIHRoZSBzZW5kZXIgZWl0aGVyIHRvIGNyZWF0ZSBmZXcg Z2FwcyBvciB0byBjcmVhdGU8YnI+DQomZ3Q7IHRoZW0gaW4gYSBtYW5uZXIgdGhhdCBkb2VzIG5v dCBibG93IHVwIGl0cyBvd24gc2VuZCBoaXN0b3J5IGRhdGEgc3RydWN0dXJlcyBpZjxicj4NCiZn dDsgaXQgd2FudHMgdG8gY2hlY2sgd2hldGhlciBhbiB1bnNlbnQgcGFja2V0IGlzIEFDS2VkLjxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOy0gRG1pdHJpLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_DB5PR07MB123729774C9302FA783031DC84B80DB5PR07MB1237eurp_-- From nobody Tue Jul 25 05:41: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 4E30C129B35 for ; Tue, 25 Jul 2017 05:41:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 yB_GlHiSEmBJ for ; Tue, 25 Jul 2017 05:41:19 -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 BC13F129AAD for ; Tue, 25 Jul 2017 05:41:19 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id p3so25482560qtg.2 for ; Tue, 25 Jul 2017 05:41:19 -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:in-reply-to:user-agent; bh=aTCPb/ON6quwCBCckIKO9mGJbb7wH1norPWEEZOiI2Y=; b=m8Ix5Io6NvqCbK2/owWiRG8yKXaasZt91otvZPO7CrtZdgkzogkHvg1XSTLDimNhJ5 cXmmfk+897XTbWMI1yywD06QWEY84xFlCNB4xxV9d5nypK/DrVj1HMnrXUA0BQgsgEts mLHITs5xj2wr/ziiARuWfaiXtnWJ6r1D0IgXdziuomYSUPVaRj8eAa5TXcKzeZCe+xvF J6nwlCJTAQm2BOF0buqolYg+ASNo4bGEqJnsT1OLFH3Pel2nxsmln54FllFvFNV5eAqD 14fkklHI7MvInFO99elAHW1YwHWULlv99VdqY7HrdQ1WPzYBhB82RigjV0X53qkNoq94 AxxQ== 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:in-reply-to:user-agent; bh=aTCPb/ON6quwCBCckIKO9mGJbb7wH1norPWEEZOiI2Y=; b=aXaCmLURyOqbifk0289ZQVicoJe06vnqd23C1unqab/hXAhk1uJNCgXKMUZ6whyrsM 7xYjSRDmbHMdMeZwiQKikKOkHkfoiEj3t/SjlSFp5MpZ/AEFWH9YaK+IsxPJEE86+mEp V5v6QUU+72V7JCaSht9pOXbqcJPRbnHmfjYzM4RXeBIC4KR9GMcj1ict25tp1db7hggE +3WTGYPNRbm03GTE87QcHYp55A99YXwtSdpx0KbpQrlyfhm5C2hvouN9p6bylTUb+MQX ObhKqmzaKEDrNWeJg56KTA67efwN6Vh/Z8cOx0cmVNrZDRzDqAZceipqzveZ1wzJj3Yn MsyQ== X-Gm-Message-State: AIVw112LHHRb7luFGKHLZjA4C3Q3BH5XyUclfziudQZqWuNPvHx95mwq mFcoCncu4sVyuPQW X-Received: by 10.200.48.105 with SMTP id g38mr15800862qte.125.1500986478776; Tue, 25 Jul 2017 05:41:18 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id o20sm10489662qtc.23.2017.07.25.05.41.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 05:41:18 -0700 (PDT) Date: Tue, 25 Jul 2017 08:41:09 -0400 From: Dmitri Tikhonov To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Magnus Westerlund , IETF QUIC WG Subject: Re: Idea for packet numbers Message-ID: <20170725124109.GA1764@ubuntu-dmitri> References: <20170721093732.GA31705@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Tue, 25 Jul 2017 12:41:21 -0000 On Tue, Jul 25, 2017 at 10:04:52AM +0000, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: > From the senders perspective the process it goes through is: > 1. Get data to send > 2. Get packet number > 3. encrypt packet > 4. queue packet on NIC > 5. NIC sends packet. I think this model needs to account for the OS. A normal application does not write to NIC directly: it goes through the kernel. A socket's send buffer may get full and queueing a packet may fail. Let's assume that happens and the application waits to queue a packet. (If instead you just throw this packet out and pretend that you queued it, then it is conceptually the same as the "write to NIC directly" model above, but I don't think many people are ready to take that route.) While the application waits for the socket to become writeable, an ACK alarm may go off or new packets may arrive for this connection: generating and sending an ACK is in order. Since we want to send the ACK first, the buffered, not-yet-sent packet may need to be renumbered, have its contents changed, or both: - Either the packet does not contain an ACK, in which case the new ACK frame is put into a new packet and the buffered packet gets a new packet number; or - The packet contains an ACK which can be replaced with the new ACK (if there is room), in which case the packet gets to keep the number, but the packet contents change. Another scenario where butchering unsent packets is required is when RST_STREAM comes in: application must then drop outgoing STREAM frames for that stream. The process is, then: 1. Get data to send 2. Get packet number 3. Encrypt packet 4. Try enqueuing packet a) If successful, "commit" packet number and go to (1) b) If unsuccessful, wait and do something smart later, depending on circumstances Just my $.02, - Dmitri. From nobody Tue Jul 25 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 9A563129789 for ; Tue, 25 Jul 2017 06:26:17 -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 (1024-bit key) header.d=krose.org 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 bnr4MGeuKnjO for ; Tue, 25 Jul 2017 06:26:13 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 2DA9B131C33 for ; Tue, 25 Jul 2017 06:26:13 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id q130so27761333qka.4 for ; Tue, 25 Jul 2017 06:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pKAzWkpZIEarTLsK6NSSsO6Ev5X6vjR8nJZQTpsN/PU=; b=geX+1q4x1a/s6AwYUC4vI/GpycGt2onpRnabAWk/l6mC0HRQhZsvWVWxRV/i2xHjh4 0yTTr/PV4v1fsRICOuTJCR4HrXwuLeAQZarE8A9WhE1eqbM/4pfPcJBblID3Zq/cECgC jRwhaR5vrTSOTZt5TrWmQLp1tkd/e2HEn0/7w= 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=pKAzWkpZIEarTLsK6NSSsO6Ev5X6vjR8nJZQTpsN/PU=; b=mIZ1S3hBO7Jm3vCFQzENUjHr0dQHUrdjoBHNiajKl4kVBC4SNFDgXU0p6QoSO/kH// mwFaOvsqvQzb5CeAi9h7Yy1zJIvQm4CwS1zDmfAp7fZLxrHmoScFbDcFLpIJx3P/Cwio 2n7eL6ivCV6UqF6w64TjGp4G6Uih0ppKpou6+qHqu8baXbzOve6YaOzN9sSJIxfMAfnB 0VZ41ucf4VZXryKxj1WaeedCxFOr0vOHGcemb5u5kYgXB2LpQEt8WernosKGehsP8WgD ztybUas1NMyRAeTZBL6IMVSoPm05GfR16qCzTMBt1T0ViTMutso26IBzU2eoDAQH6h/k j7MA== X-Gm-Message-State: AIVw111W7NSIX+n0fYOyJ+NdoyGdhJGPbYOG19r2ipvsyuFrAriqqh3B bX0NkzxxmUna/EnvsuTRvap2YZcAED4z X-Received: by 10.55.131.65 with SMTP id f62mr22990538qkd.290.1500989172047; Tue, 25 Jul 2017 06:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Tue, 25 Jul 2017 06:26:11 -0700 (PDT) X-Originating-IP: [2607:fb90:edd:e418:74a8:300a:fb36:b806] Received: by 10.55.128.194 with HTTP; Tue, 25 Jul 2017 06:26:11 -0700 (PDT) In-Reply-To: References: <20170721093732.GA31705@ubuntu-dmitri> From: Kyle Rose Date: Tue, 25 Jul 2017 09:26:11 -0400 Message-ID: Subject: RE: Idea for packet numbers To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" Cc: Ian Swett , Dmitri Tikhonov , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Magnus Westerlund Content-Type: multipart/alternative; boundary="94eb2c0702726999e1055524460f" 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, 25 Jul 2017 13:26:18 -0000 --94eb2c0702726999e1055524460f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Jul 25, 2017 8:36 AM, "Swindells, Thomas (Nokia - GB/Cambridge, UK)" < thomas.swindells@nokia.com> wrote: * encryption is still a relatively expensive operation, CPUs have acceleration to help so you are going to want to do work in parallel =E2=80= =93 particularly when delivering multiple streams. These can make a significant impact on a server delivering 80Gbps of live video traffic. One of the big advertised benefits of QUIC is its support for stream multiplexing and it is mostly up to the client rather than the server about whether to use it, I don=E2=80=99t think its viable to say just don=E2=80=99t use it?* Are you planning to serve 80 Gb/s on a single connection? If yes, then I assume that's an infrastructure connection (e.g., cache to cache). I'm skeptical of the comparative advantage of one connection vs. N for N CPUs when compared to the complexity/cost of supporting parallel senders that need to share at least some state. Kyle --94eb2c0702726999e1055524460f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jul 25, 2017 8:36 AM, "Swindells, Thomas (Nokia - GB/Cambridge, U= K)" <thomas.swindells= @nokia.com> wrote:
=C2=A0encr= yption is still a relatively expensive operation, CPUs have acceleration to= help so you are going to want to do work in parallel =E2=80=93 particularl= y when delivering multiple streams. These can make a significant impact on a server delivering 80Gbps of live = video traffic. One of the big advertised benefits of QUIC is its support fo= r stream multiplexing and it is mostly up to the client rather than the ser= ver about whether to use it, I don=E2=80=99t think its viable to say just don=E2=80=99t use it?
A= re you planning to serve 80 Gb/s on a single connection? If yes, then I ass= ume that's an infrastructure connection (e.g., cache to cache). I'm= skeptical of the comparative advantage of one connection vs. N for N CPUs = when compared to the complexity/cost of supporting parallel senders that ne= ed to share at least some state.

Kyle
--94eb2c0702726999e1055524460f-- From nobody Tue Jul 25 07:29:00 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 8794F12EB5D for ; Tue, 25 Jul 2017 07:28:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=nokia.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 vNlj-FlLCaAk for ; Tue, 25 Jul 2017 07:28:56 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC061131CD0 for ; Tue, 25 Jul 2017 07:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EsdaG7RokIkJW0iICIkx5Rh+Ue6+Vz/AnvVgrVdT9CY=; b=cWPjnK/R3dYPGypOAq6wz45v6d8HlQ47vw54Lk4oNUk02k2iR7+B69nqMLaJBzGXPJjvm1f4QcU2aoUM8AqmRGAqUjFmT/D23oDNVcMHlvbpOfUMX78+fCh+zjH/u7exNds805+Xt1CSj3r6LhBsY70zMAPr2q+ej2KFvXFG9pM= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB1271.eurprd07.prod.outlook.com (10.164.41.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Tue, 25 Jul 2017 14:28:52 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354%13]) with mapi id 15.01.1304.014; Tue, 25 Jul 2017 14:28:52 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Dmitri Tikhonov CC: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , "Magnus Westerlund" , IETF QUIC WG Subject: RE: Idea for packet numbers Thread-Topic: Idea for packet numbers Thread-Index: AQHTAT74Pm6HB4E+oUyHojrh9ct+26JcjwOAgAF4cgCAA8bLAIACtdaAgAAAveA= Date: Tue, 25 Jul 2017 14:28:52 +0000 Message-ID: References: <20170721093732.GA31705@ubuntu-dmitri> <20170725124109.GA1764@ubuntu-dmitri> In-Reply-To: <20170725124109.GA1764@ubuntu-dmitri> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; x-originating-ip: [82.69.101.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB1271; 7:VB18DC48AExXBF267lDaRApLaY4N+gVsYGW/awdiTV9amI7gy1NASTgrlD6GHlr3fb64J4RB6gTITgu7D/n07PSfPHVokQX7XCHJe/nWQC3gQw+bKzzRUqxWXdAWVuWx8CYxmgiVtZZ2yg1Q8ctBWjsY8qNgZF5X9gXu4HXiw/8fBY7JZB5fBoU7xlKhNnHKdOzi4g4By93JMf2Q+/WNqhReJr1DWwRQE8eNtcP//9Cdw/6giv1SeO9pN2aKftpsxWO3TYFg54R7rMQbJEzcVdSMbx5oEGQJI8FrEQuaIp6v9e1Q/zJOALfhLnSmf7hN0cB6ui7y6erP3Lp8MakY5Yx6fNtyrC3cZmhdGqXD/PdC/x1c9gqKzYiJl6Y2Jj/NNGDIVjp4viFXMEgRb9LjkansoM+pmygIrap8BF3D6W1bhn3zgYBRb3hQ5VctB/VjKsKrLU1715NqPdM7zCuoOnKI+H9ZcIR3fFaaN6WIQq62nnlBFGHxdeyUirDRjDWBsP2lIVVwpNBrcItkw9qb1CYmy4s3AVmxpL3mL9n1eVY8UIVI5sNZvvP5/k+7G0yVT+TrBfUfflFBD5n7rvLUJrq0qDM5or2VK0gMAAIiL/yiRNGBDR3Qi0diCG6bgz6x20bkNWYtPEUDq2oBlPMZIbx+xeXUn7PHDn0lY+W1Ay2Pcsk65w0qZ3vPkgOnd1ujhTvYl8OgPG1RbME8REP4M+uX5aDhLTRIJu1O8b+864nc8HAvF32HIEhI8Xz19y0TFeVN+VO3df5hPmFJm5O/guvuVfXIGpCAy7/DAbamF/w= x-ms-office365-filtering-correlation-id: 1e8f37e9-64dd-48c0-2e69-08d4d369796b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB1271; x-ms-traffictypediagnostic: DB5PR07MB1271: x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597); 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)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1271; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1271; x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39450400003)(39840400002)(39400400002)(39850400002)(13464003)(189002)(24454002)(199003)(99286003)(7696004)(305945005)(5660300001)(54906002)(6246003)(55016002)(106356001)(3280700002)(8936002)(53936002)(110136004)(101416001)(3660700001)(74316002)(38730400002)(9686003)(54356999)(105586002)(25786009)(14454004)(3480700004)(68736007)(93886004)(86362001)(5250100002)(76176999)(50986999)(6506006)(33656002)(189998001)(66066001)(4326008)(53546010)(8676002)(7736002)(2900100001)(6436002)(229853002)(81166006)(81156014)(2950100002)(478600001)(6916009)(102836003)(2906002)(3846002)(6116002)(39060400002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1271; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 14:28:52.6204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1271 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, 25 Jul 2017 14:28:58 -0000 4 wasn't meant to imply how you queue the packet on the NIC - I was assumin= g via a kernel API call into normal udp send buffers, but both methods are = valid. You are right though there is the potential for the queuing operation to be= blocked/rejected. As I understand it the packet number is used in the encryption process, so = changing a packets number is a non-trivial operation.=20 A fast path route for queuing acks makes sense, again however the only real= way to do that would be to give the ack packet a higher packet number but = then send it before lower marked packets - even potentially if they do also= contain ack frames. For RST_STREAM I think it is permitted that currently queued packets are st= ill sent, but if they only contain that streams packets then it is a benefi= cial optimization if they weren't sent (leaving packet number gaps). Thomas > -----Original Message----- > From: Dmitri Tikhonov [mailto:dtikhonov@litespeedtech.com] > Sent: 25 July 2017 13:41 > To: Swindells, Thomas (Nokia - GB/Cambridge, UK) > > Cc: Mikkel Fahn=F8e J=F8rgensen ; Magnus Westerlund > ; IETF QUIC WG > Subject: Re: Idea for packet numbers >=20 > On Tue, Jul 25, 2017 at 10:04:52AM +0000, Swindells, Thomas (Nokia - > GB/Cambridge, UK) wrote: > > From the senders perspective the process it goes through is: > > 1. Get data to send > > 2. Get packet number > > 3. encrypt packet > > 4. queue packet on NIC > > 5. NIC sends packet. >=20 > I think this model needs to account for the OS. >=20 > A normal application does not write to NIC directly: it goes through the = kernel. > A socket's send buffer may get full and queueing a packet may fail. Let'= s > assume that happens and the application waits to queue a packet. (If ins= tead > you just throw this packet out and pretend that you queued it, then it is > conceptually the same as the "write to NIC directly" model above, but I d= on't > think many people are ready to take that route.) While the application w= aits > for the socket to become writeable, an ACK alarm may go off or new packet= s > may arrive for this > connection: generating and sending an ACK is in order. Since we want to > send the ACK first, the buffered, not-yet-sent packet may need to be > renumbered, have its contents changed, or both: >=20 > - Either the packet does not contain an ACK, in which case the > new ACK frame is put into a new packet and the buffered packet > gets a new packet number; or > - The packet contains an ACK which can be replaced with the new > ACK (if there is room), in which case the packet gets to keep > the number, but the packet contents change. >=20 > Another scenario where butchering unsent packets is required is when > RST_STREAM comes in: application must then drop outgoing STREAM frames > for that stream. >=20 > The process is, then: >=20 > 1. Get data to send > 2. Get packet number > 3. Encrypt packet > 4. Try enqueuing packet > a) If successful, "commit" packet number and go to (1) > b) If unsuccessful, wait and do something smart later, > depending on circumstances >=20 > Just my $.02, >=20 > - Dmitri. From nobody Tue Jul 25 07:34: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 29FE1131CDC for ; Tue, 25 Jul 2017 07:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 3jqE9CKADLcd for ; Tue, 25 Jul 2017 07:34:23 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 A667E131CD4 for ; Tue, 25 Jul 2017 07:34:23 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6PEPq8f047362; Tue, 25 Jul 2017 10:34:17 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049297.ppops.net-00191d01. with ESMTP id 2bx7959553-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jul 2017 10:34:17 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v6PEYGTN011977; Tue, 25 Jul 2017 09:34:16 -0500 Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v6PEY7Ke011882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jul 2017 09:34:08 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint02.pst.cso.att.com (RSA Interceptor); Tue, 25 Jul 2017 14:33:54 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v6PEXsqM011731; Tue, 25 Jul 2017 09:33:54 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v6PEXhcD010847; Tue, 25 Jul 2017 09:33:43 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id DDDA6F05B9; Tue, 25 Jul 2017 10:33:42 -0400 (EDT) Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Tue, 25 Jul 2017 10:33:42 -0400 From: "MORTON, ALFRED C (AL)" To: Ian Swett , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" CC: Magnus Westerlund , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "IETF QUIC WG" , Dmitri Tikhonov Subject: RE: Idea for packet numbers Thread-Topic: Idea for packet numbers Thread-Index: AQHTAT74Pm6HB4E+oUyHojrh9ct+26JcjwOAgAF4cgCAA8bLAIAC9FKA///aNiA= Date: Tue, 25 Jul 2017 14:33:42 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF46BC67BC@njmtexg4.research.att.com> References: <20170721093732.GA31705@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.251.241] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF46BC67BCnjmtexg4researc_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-25_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 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-1706020000 definitions=main-1707250229 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, 25 Jul 2017 14:34:26 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CF46BC67BCnjmtexg4researc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSWFuLCBUaG9tYXMsDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjUsIDIwMTcg ODoyNSBBTQ0KVG86IFN3aW5kZWxscywgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwgVUsp DQpDYzogTWFnbnVzIFdlc3Rlcmx1bmQ7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW47IElFVEYg UVVJQyBXRzsgRG1pdHJpIFRpa2hvbm92DQpTdWJqZWN0OiBSZTogSWRlYSBmb3IgcGFja2V0IG51 bWJlcnMNCg0KU29tZSB0aG91Z2h0cy4NCg0KMSkgU2VuZGluZyBwYWNrZXQgbnVtYmVycyBpbiBv cmRlciBpcyBub3QgcmVxdWlyZWQsIGJ1dCB0aGUgZmFydGhlciBvdXQgb2Ygb3JkZXIgcGFja2V0 cyBnZXQsIHRoZSBtb3JlIGFja3MgdGhlIHJlY2VpdmVyIGlzIGdvaW5nIHRvIHNlbmQsIHRoZSBs YXJnZXIgdGhleSdsbCBiZSwgYW5kIHRoZSBtb3JlIGNvbXBsZXggbG9zcyBkZXRlY3Rpb24gaXMu ICBJbiBwYXJ0aWN1bGFyLCB5b3Ugd29uJ3QgYmUgYWJsZSB0byByZWx5IG9uIFFVSUMncyBwYWNr ZXQgbnVtYmVycyBiZWluZyBpbiB0aW1lIG9yZGVyLiAgVExEUjsgSXQncyBlYXNpZXIgdG8gc2Vu ZCBwYWNrZXRzIGluIG9yZGVyIHRoYW4gaXQgaXMgdG8gY29ycmVjdGx5IGRlYWwgd2l0aCB0aGUg aW1wbGljYXRpb25zIG9mIHNlbmRpbmcgdGhlbSBvdXQgb2Ygb3JkZXIuDQo8c25pcD4NCltBQ01d DQpBbHRob3VnaCB0aGlzIHRocmVhZCBpcyBvbiBsb25nZXIgcGFja2V0IG51bWJlcnMsDQpJIHRo aW5rIGl04oCZcyB3b3J0aCBwb2ludGluZyBvdXQgdGhhdA0Kcm91dGluZSByZW9yZGVyaW5nIGF0 IHRoZSBTZW5kZXIgd291bGQgaGF2ZQ0KaW1wbGljYXRpb25zIGZvciB0aGUgc2luZ2xlLWJpdCBh bHRlcm5hdGUgbWFya2luZw0KKFNwaW4tYml0KSBhcHByb2FjaC4gVGhlIGJvdW5kYXJ5IGJldHdl ZW4NCnBhY2tldHMgbWFya2VkIOKAnDDigJ0gYW5kIOKAnDHigJ0gd291bGQgbm90IGJlIHJlbGlh YmxlOw0KdGhlcmUgd291bGQgYXBwZWFyIHRvIGJlIHZlcnkgc2hvcnQgUlRUcyBhbG9uZyB3aXRo IGxvbmdlciBSVFRzOg0KDQogIC4uLiAwIDAgMCAxIDEgMCAxIDEgMSAxIDEgLi4uDQogICAgICAg ICAgICBeIF4NCiAgIF4gPSByZW9yZGVyZWQNClRoZSBzaW5nbGUgYml0IGRvZXNu4oCZdCBoYXZl IGVub3VnaCBpbmZvIHRvDQpyZXN0b3JlIG9yZGVyLiBBdm9pZCByZW9yZGVyaW5nIGlmIHBvc3Np YmxlLg0KDQpBbA0KDQoNCg== --_000_4D7F4AD313D3FC43A053B309F97543CF46BC67BCnjmtexg4researc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjsNCgljb2xvcjpi bGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkhpIElhbiwgVGhvbWFzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5JYW4gU3dldHQ8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg SnVseSAyNSwgMjAxNyA4OjI1IEFNPGJyPg0KPGI+VG86PC9iPiBTd2luZGVsbHMsIFRob21hcyAo Tm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKTxicj4NCjxiPkNjOjwvYj4gTWFnbnVzIFdlc3Rlcmx1 bmQ7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW47IElFVEYgUVVJQyBXRzsgRG1pdHJpIFRpa2hv bm92PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJZGVhIGZvciBwYWNrZXQgbnVtYmVyczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIHRo b3VnaHRzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkg U2VuZGluZyBwYWNrZXQgbnVtYmVycyBpbiBvcmRlciBpcyBub3QgcmVxdWlyZWQsIGJ1dCB0aGUg ZmFydGhlciBvdXQgb2Ygb3JkZXIgcGFja2V0cyBnZXQsIHRoZSBtb3JlIGFja3MgdGhlIHJlY2Vp dmVyIGlzIGdvaW5nIHRvIHNlbmQsIHRoZSBsYXJnZXIgdGhleSdsbCBiZSwgYW5kIHRoZSBtb3Jl IGNvbXBsZXggbG9zcyBkZXRlY3Rpb24gaXMuJm5ic3A7IEluIHBhcnRpY3VsYXIsIHlvdSB3b24n dCBiZSBhYmxlDQogdG8gcmVseSBvbiBRVUlDJ3MgcGFja2V0IG51bWJlcnMgYmVpbmcgaW4gdGlt ZSBvcmRlci4mbmJzcDsgVExEUjsgSXQncyBlYXNpZXIgdG8gc2VuZCBwYWNrZXRzIGluIG9yZGVy IHRoYW4gaXQgaXMgdG8gY29ycmVjdGx5IGRlYWwgd2l0aCB0aGUgaW1wbGljYXRpb25zIG9mIHNl bmRpbmcgdGhlbSBvdXQgb2Ygb3JkZXIuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvaT48L2I+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbHQ7c25pcCZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltBQ01d PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFsdGhvdWdoIHRoaXMgdGhyZWFkIGlzIG9uIGxv bmdlciBwYWNrZXQgbnVtYmVycywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHRoaW5r IGl04oCZcyB3b3J0aCBwb2ludGluZyBvdXQgdGhhdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPnJvdXRpbmUgcmVvcmRlcmluZyBhdCB0aGUgU2VuZGVyIHdvdWxkIGhhdmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+aW1wbGljYXRpb25zIGZvciB0aGUgc2luZ2xlLWJpdCBhbHRlcm5h dGUgbWFya2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4oU3Bpbi1iaXQpIGFwcHJvYWNo LiBUaGUgYm91bmRhcnkgYmV0d2Vlbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnBhY2tl dHMgbWFya2VkIOKAnDDigJ0gYW5kIOKAnDHigJ0gd291bGQgbm90IGJlIHJlbGlhYmxlOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj50aGVyZSB3b3VsZCBhcHBlYXIgdG8gYmUgdmVyeSBzaG9y dCBSVFRzIGFsb25nIHdpdGggbG9uZ2VyIFJUVHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgLi4uIDAgMCAwIDEgMSAw IDEgMSAxIDEgMSAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO14gXjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgXiA9IHJlb3JkZXJlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgc2luZ2xlIGJpdCBkb2VzbuKAmXQgaGF2ZSBlbm91 Z2ggaW5mbyB0bw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnJlc3RvcmUgb3JkZXIuIEF2 b2lkIHJlb3JkZXJpbmcgaWYgcG9zc2libGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4D7F4AD313D3FC43A053B309F97543CF46BC67BCnjmtexg4researc_-- From nobody Tue Jul 25 07:40: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 3CA2C131CDC for ; Tue, 25 Jul 2017 07:40: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, RP_MATCHES_RCVD=-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=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 WmYeW4cO2O2R for ; Tue, 25 Jul 2017 07:40:21 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 83A46131CF2 for ; Tue, 25 Jul 2017 07:40:18 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i6so36543835ywb.1 for ; Tue, 25 Jul 2017 07:40:18 -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=ioMgzWWbTe+68Z7OxEEN+Qe1WJVoZP4Kky6UvLmwyNA=; b=vlmTMiLY7sT9V2c5Pvh3T6cccvcriKGMhq3hBKVD5ukJY2U4csTXEK19KBwgSf/ipL oRmLzcuqp7sgT1dKI34BEM3gamotlevRZ87FL7LGI02VAyYS49sTAM2dkBVktp/SZEYY JgWwIzqZzqOJ9jes6ilUvmmfaSgUyRUZVwDQEq5LVKI+OjHac5BVjcXK3ZYqegxN8txe uayQrGThZUoLO3zgWbLjN4UqgpshAoYaf5H0jj/duJ9mEcAcqZkuau1eDdHazwHVWEao jLLC67HxfK+pXHVvwLHrK6XpoIvpf/Khw/Bu3hBIzfMoWvQfxHvvLD5ceMrnz3U8FNsK GMYw== 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=ioMgzWWbTe+68Z7OxEEN+Qe1WJVoZP4Kky6UvLmwyNA=; b=OQy6Nfo1P+4hl2maAZpyaBKqHwicBOtEYLKMR9oguuABPWb1FxKYv6qpgtu9XEwqwd GhaFSzl0x1tPXeAPBaiTpNNluySO33ej8EeTYOaNOn+brC2bj7qVhaXv6Mzo4fIL4Qf8 yWIAV4ZLvu+kxJIMRrCIPDO36Coo0RiqqN3MI5d/yImAO0QTkc1tAAJVvwMjby9PWmWb WsUU6nfXseJpnK7CY24K7Q9tIOJvGFMdqTKQlLeBQmASjTihhtSf67YBTLpiGtE53knD 9FQKPZXOUO+0uFNJXuBDgzYpHwV8a0sMQL69y6/tVVSGMbb8YYdezI07mw+BRa3ojawD Evrg== X-Gm-Message-State: AIVw113I+43lRRmftWp/h/DD72QGODr8io7Uj4rn+T2xvR6nlxn3Iz9H ZsrH6Mq6lntRjN6kZIkc8gYufCePIdSw X-Received: by 10.129.92.3 with SMTP id q3mr16273699ywb.298.1500993616565; Tue, 25 Jul 2017 07:40:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Tue, 25 Jul 2017 07:39:55 -0700 (PDT) In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF46BC67BC@njmtexg4.research.att.com> References: <20170721093732.GA31705@ubuntu-dmitri> <4D7F4AD313D3FC43A053B309F97543CF46BC67BC@njmtexg4.research.att.com> From: Ian Swett Date: Tue, 25 Jul 2017 10:39:55 -0400 Message-ID: Subject: Re: Idea for packet numbers To: "MORTON, ALFRED C (AL)" Cc: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Magnus Westerlund , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Dmitri Tikhonov Content-Type: multipart/alternative; boundary="001a114d6f0254b0070555254fe4" 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, 25 Jul 2017 14:40:23 -0000 --001a114d6f0254b0070555254fe4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed Al, but as long as the packet number(or a portion of it) is exposed, the middlebox can easily detect the reordering and realize where the real edge is. If it wasn't exposed, it has to use some heuristics and do some filtering(ie: it seems unlikely the RTT decreased from 40 milliseconds to 100 microseconds) to filter out false edges. On Tue, Jul 25, 2017 at 10:33 AM, MORTON, ALFRED C (AL) wrote: > Hi Ian, Thomas, > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Tuesday, July 25, 2017 8:25 AM > *To:* Swindells, Thomas (Nokia - GB/Cambridge, UK) > *Cc:* Magnus Westerlund; Mikkel Fahn=C3=B8e J=C3=B8rgensen; IETF QUIC WG;= Dmitri > Tikhonov > *Subject:* Re: Idea for packet numbers > > > > Some thoughts. > > > > 1) Sending packet numbers in order is not required, but the farther out o= f > order packets get, the more acks the receiver is going to send, the large= r > they'll be, and the more complex loss detection is. In particular, you > won't be able to rely on QUIC's packet numbers being in time order. TLDR= ; > It's easier to send packets in order than it is to correctly deal with th= e > implications of sending them out of order. > > > > [ACM] > > Although this thread is on longer packet numbers, > > I think it=E2=80=99s worth pointing out that > > routine reordering at the Sender would have > > implications for the single-bit alternate marking > > (Spin-bit) approach. The boundary between > > packets marked =E2=80=9C0=E2=80=9D and =E2=80=9C1=E2=80=9D would not be r= eliable; > > there would appear to be very short RTTs along with longer RTTs: > > > > ... 0 0 0 1 1 0 1 1 1 1 1 ... > > ^ ^ > > ^ =3D reordered > > The single bit doesn=E2=80=99t have enough info to > > restore order. Avoid reordering if possible. > > > > Al > > > > > --001a114d6f0254b0070555254fe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed Al, but as long as the packet number(or a portion o= f it) is exposed, the middlebox can easily detect the reordering and realiz= e where the real edge is.=C2=A0 If it wasn't exposed, it has to use som= e heuristics and do some filtering(ie: it seems unlikely the RTT decreased = from 40 milliseconds to 100 microseconds) to filter out false edges.
<= div class=3D"gmail_extra">
On Tue, Jul 25, 20= 17 at 10:33 AM, MORTON, ALFRED C (AL) <acmorton@att.com> wrot= e:

Hi Ian, Thomas,

=C2=A0<= /p>

From: QUIC [ma= ilto:quic-bounce= s@ietf.org] On Behalf Of Ian Swett
Sent: Tuesday, July 25, 2017 8:25 AM
To: Swindells, Thomas (Nokia - GB/Cambridge, UK)
Cc: Magnus Westerlund; Mikkel Fahn=C3=B8e J=C3=B8rgensen; IETF QUIC = WG; Dmitri Tikhonov
Subject: Re: Idea for packet numbers

=C2=A0

Some thoughts.

=C2=A0

1) Sending packet numbers in order is not required, = but the farther out of order packets get, the more acks the receiver is goi= ng to send, the larger they'll be, and the more complex loss detection = is.=C2=A0 In particular, you won't be able to rely on QUIC's packet numbers being in time order.=C2=A0 TLDR; It&#= 39;s easier to send packets in order than it is to correctly deal with the = implications of sending them out of order.=C2=A0=C2=A0

<snip>

[ACM]
Although this thread is on l= onger packet numbers,

I think it=E2=80=99s worth p= ointing out that

routine reordering at the Se= nder would have

implications for the single-= bit alternate marking

(Spin-bit) approach. The bou= ndary between

packets marked =E2=80=9C0=E2= =80=9D and =E2=80=9C1=E2=80=9D would not be reliable;<= /p>
there would appear to be ver= y short RTTs along with longer RTTs:

=C2=A0<= /p>
=C2=A0 ... 0 0 0 1 1 0 1 1 1= 1 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 ^ =3D reordered=

The single bit doesn=E2=80= =99t have enough info to

restore order. Avoid reorder= ing if possible.

=C2=A0<= /p>
Al

=C2=A0<= /p>
=C2=A0

--001a114d6f0254b0070555254fe4-- From nobody Tue Jul 25 07:46: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 8CC71131CE7 for ; Tue, 25 Jul 2017 07:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=nokia.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 X0340vNEyvgB for ; Tue, 25 Jul 2017 07:46:31 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0133.outbound.protection.outlook.com [104.47.1.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3DD131CD0 for ; Tue, 25 Jul 2017 07:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hgDcT95fozCTTC5aBxsdDvhDZylxqfyWdfQK0B5h128=; b=RZA2Q6+N72abYbseCwmdj5US40smedI+DuVbvyiEKfnMgFApzsGjgANn7EATLV4sw7/MiwxlazfD3Ko/PNZ3lXvetqRWL9teGFQe3Jws+Hw8pYyd3OzXM9fFQ0sOuN3KYG2Y7JfRk2IboEM+5u7PJc9zJnUe7Oe/e3woe1AuM3A= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB0997.eurprd07.prod.outlook.com (10.161.200.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Tue, 25 Jul 2017 14:46:27 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354%13]) with mapi id 15.01.1304.014; Tue, 25 Jul 2017 14:46:27 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: "MORTON, ALFRED C (AL)" , Ian Swett CC: Magnus Westerlund , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "IETF QUIC WG" , Dmitri Tikhonov Subject: RE: Idea for packet numbers Thread-Topic: Idea for packet numbers Thread-Index: AQHTAT74Pm6HB4E+oUyHojrh9ct+26JcjwOAgAF4cgCAA8bLAIACsUOAgAAkBQCAAABhMA== Date: Tue, 25 Jul 2017 14:46:27 +0000 Message-ID: References: <20170721093732.GA31705@ubuntu-dmitri> <4D7F4AD313D3FC43A053B309F97543CF46BC67BC@njmtexg4.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF46BC67BC@njmtexg4.research.att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; x-originating-ip: [82.69.101.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB0997; 7:B3jrv/WYTWEZAnLnK8wYHapR/rcH1uWnjQiSLtn5XD7Cw2jOYjg/OZqr40uk5mreKqbdAMtE4PHAXF9F9U486LFyHmCvs1YBP9w2STMh5BzPT/33rIm1fcEFFiQXz2Ku0nfYKlJcUpAGvV2uO1WeygQsabTi7q3BfmTehHLQVEXX6xarwp3iVfU/xFsUdNpwXLKaSnX/BdOCuOYlD+JBcfo6BMuBqS2QwSlKcsszn/YH3XEqnSQ5STcfI+6pS/I/N22V8DNCg3gxfOZoDyX7wgiBIiMfqlbTk4LrcbpMAcW7OGDzE5R/T8fNIrqj0DV1HQEqaI7Qsk+n8Iz9hYSZUb3tgJvusmw0gCUm/Xxwyc6HtVE93xUkpqvX7rMEX4TpAD8VmR0YvpyNyN+uwj+fNB17k2u0h+gQS0WJ+IWjojBK0BxdkiK83Lp0HY2yApiPfeJJLa0qIM7r68xC4PqovJLeSCkSMzGhRevMWsA42IeH6WG1vPG2EoQ+05WVIRSFGBmSy5WrhMDTjIOnkdmYwoWd79hz5Ncx8lZod4uJq1pXP+Mou0v0uWYG1WyTuzdbqrrwHOy58u8uN3r5IFYiHkONXXRcbGf77+xZkODoqtyFQV2OkgPSJZwQ88W6xgl6ZtnxkFsk9QBeD59Z5Qom/qjMjmaLLSU+IjclWfl94jNDX7TYxNHZvwEbFq9FZA7TIztElk4hm3Z/oQMbYbpSbg0emBkMcAHlK2fu3iEeGsuX2f+sskv+AUJcRBCcoJ23lTKYSfDVtCRlYc3jfJ8V4RBZYeRXGJ93OTUqLOGh6sQ= x-ms-office365-filtering-correlation-id: 6d2e2bb5-0ad7-4ddc-cda6-08d4d36bedf6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB0997; x-ms-traffictypediagnostic: DB5PR07MB0997: x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597)(97927398514766)(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)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(920507026)(6055026)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0997; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0997; x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39410400002)(39860400002)(39850400002)(39400400002)(377454003)(199003)(189002)(6436002)(53936002)(3480700004)(8936002)(93886004)(39060400002)(66066001)(33656002)(55016002)(81156014)(99286003)(68736007)(86362001)(81166006)(236005)(6246003)(478600001)(2950100002)(14454004)(54896002)(38730400002)(4326008)(54906002)(9686003)(97736004)(2906002)(3280700002)(3660700001)(25786009)(53546010)(105586002)(5250100002)(6506006)(74316002)(2900100001)(7736002)(34040400001)(101416001)(229853002)(106356001)(76176999)(189998001)(5660300001)(50986999)(8676002)(790700001)(6306002)(6116002)(102836003)(3846002)(7696004)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB0997; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB1237AD0D4933D12BC04749CB84B80DB5PR07MB1237eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 14:46:27.1446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0997 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, 25 Jul 2017 14:46:35 -0000 --_000_DB5PR07MB1237AD0D4933D12BC04749CB84B80DB5PR07MB1237eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBpcyBwYXJ0bHkgbXkgY29uY2VybiwgaWYgaW1wbGVtZW50YXRpb25zL21lY2hhbmlzbXMg YXJlIGFzc3VtaW5nIGEgbG93IGxldmVsIG9mIHJlb3JkZXJpbmcgKHN1Y2ggYXMgbWlkZGxlIGJv eGVzIHVzaW5nIGEgc3BpbiBiaXQpIGhvdyBjb25maWRlbnQgYXJlIHdlIHRoYXQgdGhvc2UgYXNz dW1wdGlvbnMgYXJlIGFjY3VyYXRlIGFuZCBhIGdvb2QgdGhpbmcgdG8gb3NzaWZ5Pw0KV2l0aCBh IG11bHRpLXRocmVhZGVkIG11bHRpLW5pYyBzeXN0ZW0gSeKAmW0gbm90IGNlcnRhaW4gaXQgaXMg YWN0dWFsbHkgdGhhdCBpdCBpcyBuZWNlc3NhcmlseSBlYXN5IHRvIChwZXJmb3JtYW50bHkpIGF2 b2lkIHJlLW9yZGVyaW5nIC0gZXZlbiBpZiB0aGUgaW1wbGVtZW50YXRpb24gZG9lc27igJl0IGRl bGliZXJhdGVseSBpbnRlbmQgdG8gaW50cm9kdWNlIGl0Lg0KDQpPbmUgc29sdXRpb24gaXMgdG8g ZGVjaWRlIHRoYXQgc3BpbiBiaXQgYW5kIGxlc3MgY29tcGxleCBsb3N0IHBhY2tldCB0cmFja2lu ZyAoYW5kIHdoYXRldmVyIGVsc2UgYmVuZWZpdHMgZnJvbSBsb3cgYW1vdW50cyBvZiBwYWNrZXQg cmVvcmRlcmluZykgYXJlIHdvcnRod2hpbGUgcHJvcGVydGllcyBhbmQgc28gbWFuZGF0ZSBjbGVh cmx5IHRoYXQgcGFja2V0IGdlbmVyYXRpb24gbXVzdCBiZSBzZXJpYWxpc2VkIGFuZCB0aGUgZWdy ZXNzIG9mIHRoZSBwYWNrZXRzIHN0cmljdGx5IG9yZGVyZWQgYXMgbXVjaCBhcyBwb3NzaWJsZSAo ZS5nLiBlYWNoIGNvbm5lY3Rpb24gaXMgbG9ja2VkIHRvIGEgbmljIHdpdGggdGhlIHBhY2tldHMg c2VudCBpbiB0aGUgY29ycmVjdCBvcmRlcikuIEnigJl2ZSBubyBpZGVhIGlmIHRoaXMgaXMgYSBw cm9wZXJ0eSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBhY3R1YWxseSBoYXZlIHRvZGF5IG9yIGlm IG11bHRpcGxlIHN0cmVhbXMgYXJlIGVuY3J5cHRlZCBvbiBkaWZmZXJlbnQgdGhyZWFkcyB3aXRo IGp1c3QgdGhlIGltcGxpY2l0IGFzc3VtcHRpb24gdGhlIG91dHB1dCB3aWxsIGVuZCB1cCBpbiB0 aGUgcmlnaHQgb3JkZXIuDQoNClRob21hcw0KDQpGcm9tOiBNT1JUT04sIEFMRlJFRCBDIChBTCkg W21haWx0bzphY21vcnRvbkBhdHQuY29tXQ0KU2VudDogMjUgSnVseSAyMDE3IDE1OjM0DQpUbzog SWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lh IC0gR0IvQ2FtYnJpZGdlLCBVSykgPHRob21hcy5zd2luZGVsbHNAbm9raWEuY29tPg0KQ2M6IE1h Z251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+OyBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc+OyBEbWl0cmkgVGlraG9ub3YgPGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNv bT4NClN1YmplY3Q6IFJFOiBJZGVhIGZvciBwYWNrZXQgbnVtYmVycw0KDQpIaSBJYW4sIFRob21h cywNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIElhbiBTd2V0dA0KU2VudDogVHVlc2RheSwgSnVseSAyNSwgMjAxNyA4OjI1IEFNDQpUbzog U3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSykNCkNjOiBNYWdudXMg V2VzdGVybHVuZDsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjsgSUVURiBRVUlDIFdHOyBEbWl0 cmkgVGlraG9ub3YNClN1YmplY3Q6IFJlOiBJZGVhIGZvciBwYWNrZXQgbnVtYmVycw0KDQpTb21l IHRob3VnaHRzLg0KDQoxKSBTZW5kaW5nIHBhY2tldCBudW1iZXJzIGluIG9yZGVyIGlzIG5vdCBy ZXF1aXJlZCwgYnV0IHRoZSBmYXJ0aGVyIG91dCBvZiBvcmRlciBwYWNrZXRzIGdldCwgdGhlIG1v cmUgYWNrcyB0aGUgcmVjZWl2ZXIgaXMgZ29pbmcgdG8gc2VuZCwgdGhlIGxhcmdlciB0aGV5J2xs IGJlLCBhbmQgdGhlIG1vcmUgY29tcGxleCBsb3NzIGRldGVjdGlvbiBpcy4gIEluIHBhcnRpY3Vs YXIsIHlvdSB3b24ndCBiZSBhYmxlIHRvIHJlbHkgb24gUVVJQydzIHBhY2tldCBudW1iZXJzIGJl aW5nIGluIHRpbWUgb3JkZXIuICBUTERSOyBJdCdzIGVhc2llciB0byBzZW5kIHBhY2tldHMgaW4g b3JkZXIgdGhhbiBpdCBpcyB0byBjb3JyZWN0bHkgZGVhbCB3aXRoIHRoZSBpbXBsaWNhdGlvbnMg b2Ygc2VuZGluZyB0aGVtIG91dCBvZiBvcmRlci4NCjxzbmlwPg0KW0FDTV0NCkFsdGhvdWdoIHRo aXMgdGhyZWFkIGlzIG9uIGxvbmdlciBwYWNrZXQgbnVtYmVycywNCkkgdGhpbmsgaXTigJlzIHdv cnRoIHBvaW50aW5nIG91dCB0aGF0DQpyb3V0aW5lIHJlb3JkZXJpbmcgYXQgdGhlIFNlbmRlciB3 b3VsZCBoYXZlDQppbXBsaWNhdGlvbnMgZm9yIHRoZSBzaW5nbGUtYml0IGFsdGVybmF0ZSBtYXJr aW5nDQooU3Bpbi1iaXQpIGFwcHJvYWNoLiBUaGUgYm91bmRhcnkgYmV0d2Vlbg0KcGFja2V0cyBt YXJrZWQg4oCcMOKAnSBhbmQg4oCcMeKAnSB3b3VsZCBub3QgYmUgcmVsaWFibGU7DQp0aGVyZSB3 b3VsZCBhcHBlYXIgdG8gYmUgdmVyeSBzaG9ydCBSVFRzIGFsb25nIHdpdGggbG9uZ2VyIFJUVHM6 DQoNCiAgLi4uIDAgMCAwIDEgMSAwIDEgMSAxIDEgMSAuLi4NCiAgICAgICAgICAgIF4gXg0KICAg XiA9IHJlb3JkZXJlZA0KVGhlIHNpbmdsZSBiaXQgZG9lc27igJl0IGhhdmUgZW5vdWdoIGluZm8g dG8NCnJlc3RvcmUgb3JkZXIuIEF2b2lkIHJlb3JkZXJpbmcgaWYgcG9zc2libGUuDQoNCkFsDQoN Cg0K --_000_DB5PR07MB1237AD0D4933D12BC04749CB84B80DB5PR07MB1237eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRoYXQgaXMgcGFydGx5IG15IGNvbmNlcm4sIGlmIGltcGxlbWVudGF0aW9u cy9tZWNoYW5pc21zIGFyZSBhc3N1bWluZyBhIGxvdyBsZXZlbCBvZiByZW9yZGVyaW5nIChzdWNo IGFzIG1pZGRsZSBib3hlcyB1c2luZyBhIHNwaW4gYml0KSBob3cgY29uZmlkZW50DQogYXJlIHdl IHRoYXQgdGhvc2UgYXNzdW1wdGlvbnMgYXJlIGFjY3VyYXRlIGFuZCBhIGdvb2QgdGhpbmcgdG8g b3NzaWZ5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2l0aCBhIG11bHRpLXRocmVh ZGVkIG11bHRpLW5pYyBzeXN0ZW0gSeKAmW0gbm90IGNlcnRhaW4gaXQgaXMgYWN0dWFsbHkgdGhh dCBpdCBpcyBuZWNlc3NhcmlseSBlYXN5IHRvIChwZXJmb3JtYW50bHkpIGF2b2lkIHJlLW9yZGVy aW5nIC0gZXZlbiBpZiB0aGUNCiBpbXBsZW1lbnRhdGlvbiBkb2VzbuKAmXQgZGVsaWJlcmF0ZWx5 IGludGVuZCB0byBpbnRyb2R1Y2UgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk9uZSBzb2x1dGlvbiBpcyB0byBk ZWNpZGUgdGhhdCBzcGluIGJpdCBhbmQgbGVzcyBjb21wbGV4IGxvc3QgcGFja2V0IHRyYWNraW5n IChhbmQgd2hhdGV2ZXIgZWxzZSBiZW5lZml0cyBmcm9tIGxvdyBhbW91bnRzIG9mIHBhY2tldCBy ZW9yZGVyaW5nKQ0KIGFyZSB3b3J0aHdoaWxlIHByb3BlcnRpZXMgYW5kIHNvIG1hbmRhdGUgY2xl YXJseSB0aGF0IHBhY2tldCBnZW5lcmF0aW9uIG11c3QgYmUgc2VyaWFsaXNlZCBhbmQgdGhlIGVn cmVzcyBvZiB0aGUgcGFja2V0cyBzdHJpY3RseSBvcmRlcmVkIGFzIG11Y2ggYXMgcG9zc2libGUg KGUuZy4gZWFjaCBjb25uZWN0aW9uIGlzIGxvY2tlZCB0byBhIG5pYyB3aXRoIHRoZSBwYWNrZXRz IHNlbnQgaW4gdGhlIGNvcnJlY3Qgb3JkZXIpLiBJ4oCZdmUgbm8gaWRlYQ0KIGlmIHRoaXMgaXMg YSBwcm9wZXJ0eSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBhY3R1YWxseSBoYXZlIHRvZGF5IG9y IGlmIG11bHRpcGxlIHN0cmVhbXMgYXJlIGVuY3J5cHRlZCBvbiBkaWZmZXJlbnQgdGhyZWFkcyB3 aXRoIGp1c3QgdGhlIGltcGxpY2l0IGFzc3VtcHRpb24gdGhlIG91dHB1dCB3aWxsIGVuZCB1cCBp biB0aGUgcmlnaHQgb3JkZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRob21hczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSBbbWFp bHRvOmFjbW9ydG9uQGF0dC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjUgSnVseSAyMDE3IDE1 OjM0PGJyPg0KPGI+VG86PC9iPiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7 OyBTd2luZGVsbHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSAmbHQ7dGhvbWFz LnN3aW5kZWxsc0Bub2tpYS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYWdudXMgV2VzdGVybHVu ZCAmbHQ7bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tJmd0OzsgTWlra2VsIEZhaG7DuGUg SsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtx dWljQGlldGYub3JnJmd0OzsgRG1pdHJpIFRpa2hvbm92ICZsdDtkdGlraG9ub3ZAbGl0ZXNwZWVk dGVjaC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBJZGVhIGZvciBwYWNrZXQgbnVt YmVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgSWFuLCBUaG9tYXMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5JYW4gU3dldHQ8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAy NSwgMjAxNyA4OjI1IEFNPGJyPg0KPGI+VG86PC9iPiBTd2luZGVsbHMsIFRob21hcyAoTm9raWEg LSBHQi9DYW1icmlkZ2UsIFVLKTxicj4NCjxiPkNjOjwvYj4gTWFnbnVzIFdlc3Rlcmx1bmQ7IE1p a2tlbCBGYWhuw7hlIErDuHJnZW5zZW47IElFVEYgUVVJQyBXRzsgRG1pdHJpIFRpa2hvbm92PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJZGVhIGZvciBwYWNrZXQgbnVtYmVyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Tb21lIHRob3VnaHRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjEpIFNlbmRpbmcgcGFja2V0IG51bWJlcnMg aW4gb3JkZXIgaXMgbm90IHJlcXVpcmVkLCBidXQgdGhlIGZhcnRoZXIgb3V0IG9mIG9yZGVyIHBh Y2tldHMgZ2V0LCB0aGUgbW9yZSBhY2tzIHRoZSByZWNlaXZlciBpcyBnb2luZyB0byBzZW5kLCB0 aGUgbGFyZ2VyIHRoZXknbGwgYmUsIGFuZCB0aGUgbW9yZSBjb21wbGV4IGxvc3MgZGV0ZWN0aW9u IGlzLiZuYnNwOyBJbiBwYXJ0aWN1bGFyLA0KIHlvdSB3b24ndCBiZSBhYmxlIHRvIHJlbHkgb24g UVVJQydzIHBhY2tldCBudW1iZXJzIGJlaW5nIGluIHRpbWUgb3JkZXIuJm5ic3A7IFRMRFI7IEl0 J3MgZWFzaWVyIHRvIHNlbmQgcGFja2V0cyBpbiBvcmRlciB0aGFuIGl0IGlzIHRvIGNvcnJlY3Rs eSBkZWFsIHdpdGggdGhlIGltcGxpY2F0aW9ucyBvZiBzZW5kaW5nIHRoZW0gb3V0IG9mIG9yZGVy LiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jmx0O3NuaXAmZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltBQ01dPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbHRob3VnaCB0aGlzIHRocmVhZCBpcyBvbiBsb25nZXIgcGFj a2V0IG51bWJlcnMsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgdGhpbmsgaXTigJlzIHdvcnRo IHBvaW50aW5nIG91dCB0aGF0DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnJvdXRpbmUgcmVvcmRl cmluZyBhdCB0aGUgU2VuZGVyIHdvdWxkIGhhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmltcGxp Y2F0aW9ucyBmb3IgdGhlIHNpbmdsZS1iaXQgYWx0ZXJuYXRlIG1hcmtpbmc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPihTcGluLWJpdCkgYXBwcm9hY2guIFRoZSBib3VuZGFyeSBiZXR3ZWVuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPnBhY2tldHMgbWFya2VkIOKAnDDigJ0gYW5kIOKAnDHigJ0gd291 bGQgbm90IGJlIHJlbGlhYmxlOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+dGhlcmUgd291bGQgYXBw ZWFyIHRvIGJlIHZlcnkgc2hvcnQgUlRUcyBhbG9uZyB3aXRoIGxvbmdlciBSVFRzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgLi4uIDAg MCAwIDEgMSAwIDEgMSAxIDEgMSAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDte IF48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBeID0gcmVvcmRlcmVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5UaGUgc2luZ2xlIGJpdCBkb2VzbuKAmXQgaGF2ZSBlbm91Z2ggaW5m byB0bw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5yZXN0b3JlIG9yZGVyLiBBdm9pZCByZW9yZGVy aW5nIGlmIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB5PR07MB1237AD0D4933D12BC04749CB84B80DB5PR07MB1237eurp_-- From nobody Tue Jul 25 09:27: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 36FC5131D1D for ; Tue, 25 Jul 2017 09:27:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 P2d66jHxYayK for ; Tue, 25 Jul 2017 09:27:12 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 684D9131D18 for ; Tue, 25 Jul 2017 09:27:12 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id d145so65246085qkc.2 for ; Tue, 25 Jul 2017 09:27:12 -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:in-reply-to:user-agent; bh=aHegjIQx5ijg32UUzKx+uFq1Ti7v2y1IeEDlbCMpqUQ=; b=2IlQussujDdAm2xroikslTokm/Rzj+28J0kd6GWYhAqLSqIoXUuA9uuqxGJrS4zq9g Yj3kPbZiv+kcdC+GH12fV+VOLYUWFccJhhts5Xxi/s4iXWEWbASd8UCGSf2fDDvB3fXY CXWWidZN3SaeICVLk1onRKfPBgeCqjiMleiOq72V4YpVQcry93n8JRvE6v/Lr+ShZYys GUto4iML6RI7yTN2n8qwJramM7zxER2WQPGRFfT+kPbDBFCQwdnvkrntBF7ELlyvlEwv FlnCqnijAHjn8SxlT8M1jSnc0ep90FWi2/CUJPtjguN3iim84MU5hwAMbBHBl3w8RKd3 06/A== 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:in-reply-to:user-agent; bh=aHegjIQx5ijg32UUzKx+uFq1Ti7v2y1IeEDlbCMpqUQ=; b=U8oXSR9RBgBN4PLgdZj4uMkNYxHapg9Kv4NnG+FvlIGDrS271x9buqfrdK9K45u2tH QjhRLdJ3O0sCNifs8pBy9fD7zymhdWYXovcSdYO7MxsZ0AWa25d/9ITp5GFdRnKDGhJA +JKl+7E2ooUMbfOM+tBtE1TuFyv9MDtigK36AhrZbnM7pjncCH8RcviHGlICfkbsnK7P FYRrvexlZOY41JSK4Q1efLu/hRGhlWEHOkqYkKSA3wGwb1Km8kxm/kWhhvCNOvtIw4hh RC6OXcnmG65Rb+m6z/lpUU1ZYFQo1w1S93D9vprBk7vUAOyeC4mJTYV2trHHPUNIX3Q3 gY1g== X-Gm-Message-State: AIVw111CZxEeQaMmAT1Wr45Mi/JwoQy0doCUtPqqHriUGD7bV752Y0vP JmwHnmRUIk/NxVsz X-Received: by 10.55.33.195 with SMTP id f64mr26421802qki.208.1501000031477; Tue, 25 Jul 2017 09:27:11 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id e32sm10115263qtb.63.2017.07.25.09.27.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 09:27:10 -0700 (PDT) Date: Tue, 25 Jul 2017 12:27:01 -0400 From: Dmitri Tikhonov To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Magnus Westerlund , IETF QUIC WG Subject: Re: Idea for packet numbers Message-ID: <20170725162701.GA4414@ubuntu-dmitri> References: <20170721093732.GA31705@ubuntu-dmitri> <20170725124109.GA1764@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Tue, 25 Jul 2017 16:27:14 -0000 On Tue, Jul 25, 2017 at 02:28:52PM +0000, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: > 4 wasn't meant to imply how you queue the packet on the NIC - I was > assuming via a kernel API call into normal udp send buffers, but both > methods are valid. You are right though there is the potential for the > queuing operation to be blocked/rejected. Since we were talking about implementation, I wanted to point out that packet number allocation is more complicated in practice. I realize this is not what you meant. :) > As I understand it the packet number is used in the encryption process, > so changing a packets number is a non-trivial operation. A fast path > route for queuing acks makes sense, again however the only real way ^^^^^^^^^^^^^ By this, do you mean "without encrypting data twice?" > to do that would be to give the ack packet a higher packet number but > then send it before lower marked packets - even potentially if they > do also contain ack frames. That is a good approach if it does not break packet number derivation. I am not sure whether it can... The draft says: " A packet number is decoded by finding the packet number " value that is closest to the next expected packet. Thus, after receiving ACK packet with large gap, which is the next expected packet number from the point of view of the peer? > For RST_STREAM I think it is permitted that currently queued packets > are still sent, but if they only contain that streams packets then > it is a beneficial optimization if they weren't sent (leaving packet > number gaps). Current draft says: " An endpoint that receives a RST_STREAM frame (and which " has not sent a FIN or a RST_STREAM) MUST immediately " respond with a RST_STREAM frame, and MUST NOT send any " more data on the stream. I suppose one could interpret "send" to mean "enqueue," but I would err on the side of caution. - Dmitri. From nobody Tue Jul 25 11:17: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 03C22131E88 for ; Tue, 25 Jul 2017 11:17:27 -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, RP_MATCHES_RCVD=-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=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 DEvuvgdYd9Ad for ; Tue, 25 Jul 2017 11:17:25 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 CA0E312EC13 for ; Tue, 25 Jul 2017 11:17:24 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id s6so43579037qtc.1 for ; Tue, 25 Jul 2017 11:17:24 -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=G5sDPFsMt17NbtwxobMTdSj1vTSNbf+d6r4N+m8YdIE=; b=XtTG4m4wtRxLxGmDwkdARTGkTrUKPF2hU21d5r/Cuye3Nj4Ec2idhlAkFHmQueRVW3 BH2u6Fm4bWayFx7N03MvBTnuM2silCirO4M8JsvkPd1m+hA5GdtjTqz6gdvGAkhbKUMi rKQwKFBLmPebs5MakQzt5p5HCt5C302QFpd69CUJsFH2L4hyh+oHAlwCHixAvtbBUA5V A9kWkzhp99E/VeyHQaXuHSPsdznJqCignIoqdC4hpqr/WBj8i+Ugq+dqn2JGOVB2jeUt NuQnuDdu+mWZsb8PSDT/I5wSWGKmc/UAwjb81UQPRYb48/43lw3cp81Ri8RSXpwnHzzM pR7Q== 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=G5sDPFsMt17NbtwxobMTdSj1vTSNbf+d6r4N+m8YdIE=; b=OMlz685ojEDnwQa+vOeXepPI3JvZ0naaRVKwFHVCCOO/yQkTq8v9mL+Y/71Q6nHl/v tploYnj3RVtmi4pPI80ArMkEkqP/WSHnpq0kGMpebqDn5tWjNVXY9b0a3LW1JFO22Xj5 Q+8GYvA5mt7wNJ/n39Ng3tLmgZwAly8GI8WKJJpr7YM25LBxyKs/xDxbIhLaJIM3nlty EtasbGBMdtjZ0tIKCWY7DBoLTpdZ+pntpSVEpBtR7cSfo9fa+usALNFtoMQtBDZlpDdS dWbhSom4usExAXDZsd1hZEvvNaJgXbMdSEG0iZrAJCL+5/ENdq9OyBaW9XM9L44P2isY cB9w== X-Gm-Message-State: AIVw112xfFenID8xULNo+HGES8ZPv1ePM/353RUiSvqx9PFkafVYSbqA 9CNAbYtDk93pUBZ10hM+y4Fk4gXKpErP X-Received: by 10.237.37.45 with SMTP id v42mr28569932qtc.333.1501006643765; Tue, 25 Jul 2017 11:17:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.117 with HTTP; Tue, 25 Jul 2017 11:17:03 -0700 (PDT) In-Reply-To: <9914D466-6293-447C-B3FC-839CFFF9298B@in-panik.de> References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> <9914D466-6293-447C-B3FC-839CFFF9298B@in-panik.de> From: Frank Kastenholz Date: Tue, 25 Jul 2017 14:17:03 -0400 Message-ID: Subject: Re: Unreliable Stream (was: Re: HTTP requests on one stream #692) To: "Philipp S. Tiesel" Cc: Mike Bishop , Lucas Pardue , "Swindells, Thomas (Nokia - GB)" , IETF QUIC WG , Martin Thomson , Ian Swett Content-Type: multipart/alternative; boundary="001a113e5f16cf46eb0555285788" 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, 25 Jul 2017 18:17:27 -0000 --001a113e5f16cf46eb0555285788 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 25, 2017 at 8:11 AM, Philipp S. Tiesel wrote: ... > In case of HTTP, all three options could be requested via an HTTP request > header. > Optional, in case the server does not support unreliable streams, fallbac= k > to reliable transmission. > > An open question is question is how to present a stream with =E2=80=9Chol= es=E2=80=9D to > the application. > Hi At a previous job I implemented a protocol that had some similarities to QUIC and one of the protocol's features was that a stream could be declared to be unreliable. We had two not-incompatible views. First is the simple approach --- a part of the API included the QUIC sequence number -- the app can then use this to make the needed decisions. The assumption here is that the sequence numbers increase by a knowable amount. Alternatively, we felt that such streams tended to consist of fairly small (fit in one packet) independent messages that contained their own identification (or didn't need it). In this case, the application could figure out the holes, etc, on its own. An example might be something like a periodic status report from some kind of sensor that contains a time stamp. The time stamp tells the app all it needs to know. Neither of these are protocol issues --- presenting the seq. num. is an API matter, and assuming that the app and its protocol can sort it out is, well, an app matter. On the QUIC layer, as it is much easier to implement, unreliable > transmission is driven by the sender. Retransmissions can then be done > depending on the applications choice. > In the work I did previously, we found instances where either sender or receiver might wish to assert reliability (or unreliability). Continuing with the sensor I mentioned above, a receiver that is a logger may want every sensor reading. A receiver that just is showing the current value will not need reliability. So the sender (the node with the sensor) might wish to assert one mode, the receiver however wants the other -- and vice versa. This ignores the question of what to do when the receiver wants one mode and the sender the other ... I don't have a quick answer ... we didn't have funding at the previous gig to go into these levels of protocol development... Probably would have done some kind of negotiation, with the connection failing if the parties can't agree (maybe ala the old Telnet will/wont/do/dont technique). Thanks Frank Kastenholz --001a113e5f16cf46eb0555285788 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jul 25, 2017 at 8:11 AM, Philipp S. Tiesel &l= t;phils@in-panik.de<= /a>> wrote:
...=C2=A0
In case of HTTP, all three = options could be requested via an HTTP request header.=C2=A0
Opti= onal, in case the server does not support unreliable streams, fallback to r= eliable transmission.

An open question is question= is how to present a stream with =E2=80=9Choles=E2=80=9D to the application= .

Hi

=
At a previous job I implemented a protocol that had some similar= ities to QUIC and=C2=A0
one of the protocol's features was th= at a stream could be declared to be unreliable.
We had two not-in= compatible views. First is the simple approach --- a part of the API
<= div>included the QUIC sequence number -- the app can then use this to make = the needed
decisions.=C2=A0 The assumption here is that the seque= nce numbers increase by a knowable
amount. Alternatively, we felt= that such streams tended to consist of fairly small (fit in one
= packet) independent messages that contained their own identification (or di= dn't need it).=C2=A0 In=C2=A0
this case, the application coul= d figure out the holes, etc, on its own.=C2=A0 An example might be
something like a periodic status report from some kind of sensor that con= tains a time stamp.
The time stamp tells the app all it needs to = know.

Neither of these are protocol issues --- pre= senting the seq. num. is an API matter, and assuming
that the app= and its protocol can sort it out is, well, an app matter.

On the QUIC layer, as it is much easier to implement, unreliable tran= smission is driven by the sender. Retransmissions can then be done dependin= g on the applications choice.

In the work I did previously, we found instances where either send= er or receiver might wish
to assert reliability (or unreliability= ).=C2=A0 Continuing with the sensor I mentioned above, a
receiver= that is a logger may want every sensor reading. A receiver that just is sh= owing
the current value will not need reliability. So the sender = (the node with the sensor) might
wish to assert one mode, the rec= eiver however wants the other -- and vice versa.=C2=A0

=
This ignores the question of what to do when the receiver wants one mo= de and the sender the other ... I don't have a quick answer ... we didn= 't have funding at the previous gig to go into these levels of protocol= development...=C2=A0 Probably would have done some kind of negotiation,
with the connection failing if the parties can't agree (maybe a= la the old Telnet will/wont/do/dont
technique).

Thanks
Frank Kastenholz

<= /div> --001a113e5f16cf46eb0555285788-- From nobody Tue Jul 25 12:11: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 9F381131CB4 for ; Tue, 25 Jul 2017 12:11:35 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jB-EFroaYYTc for ; Tue, 25 Jul 2017 12:11:33 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 93D14131714 for ; Tue, 25 Jul 2017 12:11:33 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id w45so108749316uac.5 for ; Tue, 25 Jul 2017 12:11:33 -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=clIWrAGnz/92lyIjHA/QtLmUN+BZKCNMzbaOAsElxmo=; b=c5h89UN/9kmBoKpgzZXDZgkLq+2iRMQHJFwk8Cw5267wEnurFtFv9sPFOpxiKkSTeS 5+KazPSHxtmk4rLMAImk/XP6bD4OqZIdRjsZMKDKit/C5lWdsv3/TLd6FzRclPePoj2W ArqYrB4wwy7pSEwSPlRkkSxkvTdsP3qKNxCxEY8XU4z8C1Vid/tgeECD/UoaTWNoMDXp MQiAoAkEnUYOC98dKXwMM/Nn1O2+xVs5Z16VBUwIgo5icGK7qMIU7QiAowojZn4pl1WB iKLFaHYLvAMcjpWIIspdqfs9upJYodU89M5N3jAPbIdlRQKQvY9URwDdtTQGSNQhcuJf W8rg== 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=clIWrAGnz/92lyIjHA/QtLmUN+BZKCNMzbaOAsElxmo=; b=HYvdZO+rNmiijUff7+AueG7rYxuQVI6XrI+jaIHlsCQIdAXEpzNcbCnnaw3n9bI6B+ b1urbINsOiJLizdtsCUSj49hp+fXdINB2X4fwSk+K6J8JpGJiqI+ZhW2DouUw0DqFfYa EXTvQQwo+WpamxAKVTKLqrs6Zx17O8XvBkK+C9T81Q2T/8df6e0i19S4++UImKFWFRGh dAm/d9NV6Deg9RXktXaffLec31vmRBpre73Y0fm/ycKW08d1mkNQMafVUN1JYXEtZhRy 4sfl2HnQDlt4tXoEnKGh2WT7N9Zv7GrCDwiEMMIqk0lz7OKLBUHpB6lfJlCgsNq3XSdt tKZA== X-Gm-Message-State: AIVw112n6xIyyz1iDCq0LSl86qd5R9jgJ31QLaMgRHAvxPhlGL3lQK68 gHbclPn01A7nZ+Gjmu/mp8jlfFl5PQ== X-Received: by 10.176.91.19 with SMTP id u19mr13497492uae.152.1501009892717; Tue, 25 Jul 2017 12:11:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 25 Jul 2017 21:11:31 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> <9914D466-6293-447C-B3FC-839CFFF9298B@in-panik.de> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 25 Jul 2017 21:11:31 +0200 Message-ID: Subject: Re: Unreliable Stream (was: Re: HTTP requests on one stream #692) To: "Philipp S. Tiesel" , Frank Kastenholz Cc: Lucas Pardue , Mike Bishop , IETF QUIC WG , Martin Thomson , Ian Swett , "Swindells, Thomas (Nokia - GB)" Content-Type: multipart/alternative; boundary="f403045f8b7475b9820555291922" 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, 25 Jul 2017 19:11:35 -0000 --f403045f8b7475b9820555291922 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe Franks description suits the view if unreliable streams being very small unidirectional streams. As to Phillips question: An open question is question is how to present a stream with =E2=80=9Choles= =E2=80=9D to the application. The size of holes may be tricky unless, but presenting logical streams with holes is easy: For reliable (logical) streams you have one transport stream with many messages and no holes. These messages must be on the stream to ensure ordering, and you therefore need an application level message frame. For unreliable (logical) streams you only send one message in each QUIC transport stream. Instead of a message frame you store a logical stream id. The transport stream id will always increase so even if unreliable, you still know about ordering. An internal sequence number could be added if more details are needed. Unreliable streams may be short so there can be many in a single UDP packet. This can drain the stream ID space. A sending application can easily tell QUIC transport to not retransmit frames of unreliable streams (or have some timeout etc.). The receiving QUIC transport might struggle with seeing only the second half of an unreliable stream. The receiving application has not easy way to tell transport to stop waiting even if both sending and receiving applications have negotiated what they want. To solve this problem, QUIC transport could have a flag on frames that mark them as unreliable - perhaps two bits for different classes / timeouts etc. The application can the tell transport how to manage such streams. By and large, reliable and unreliable streams work exactly the same at the transport layer. Note that if streams are not unidirectional there is more overhead in keeping stream state and terminating streams. With a uni-directional stream a sender can immediately close all stream state after sending a single frame message. At a deeper level there may be frame retransmission, but this is much more lightweight. Then if frames are marked unreliable they can also bypass the retransmission queue. So I would like unidirectional streams with a flag to mark frames as unreliable, and longer stream identifiers (possibly compressed). How this works at the HTTP level I have no clue because I am still not up to speed on this part. But I can easily imagine that a single stream per HTTP transaction will fall short of some of those can be unreliable. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 25 July 2017 at 20.17.34, Frank Kastenholz (fkastenholz@google.com) wrote: An open question is question is how to present a stream with =E2=80=9Choles= =E2=80=9D to the application. --f403045f8b7475b9820555291922 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I believe Franks description suits the view if un= reliable streams being very small unidirectional streams.

As to Phillips question:
An open question is question is how to present a stream wi= th =E2=80=9Choles=E2=80=9D to the application.
= The size of holes may be tricky unless, but presenting logical streams with= holes is easy:
For reliable (logical) streams you have one transport= stream with many messages and no holes. These messages must be on the stre= am to ensure ordering, and you therefore need an application level message = frame.
For unreliable (logical) streams you only send one message in = each QUIC transport stream. Instead of a message frame you store a logical = stream id. The transport stream id will always increase so even if unreliab= le, you still know about ordering. An internal sequence number could be add= ed if more details are needed.
Unreliable streams may be short so the= re can be many in a single UDP packet. This can drain the stream ID space.<= /p>
A sending application can easily tell QUIC transport to not retransmi= t frames of unreliable streams (or have some timeout etc.).
The recei= ving QUIC transport might struggle with seeing only the second half of an u= nreliable stream. The receiving application has not easy way to tell transp= ort to stop waiting even if both sending and receiving applications have ne= gotiated what they want. To solve this problem, QUIC transport could have a= flag on frames that mark them as unreliable - perhaps two bits for differe= nt classes / timeouts etc. The application can the tell transport how to ma= nage such streams.
By and large, reliable and unreliable streams work= exactly the same at the transport layer.

Note that if str= eams are not unidirectional there is more overhead in keeping stream state = and terminating streams. With a uni-directional stream a sender can immedia= tely close all stream state after sending a single frame message. At a deep= er level there =C2=A0may be frame retransmission, but this is much more lig= htweight. Then if frames are marked unreliable they can also bypass the ret= ransmission queue.
So I would like unidirectional streams with a flag= to mark frames as unreliable, and longer stream identifiers (possibly comp= ressed).
How this works at the HTTP level I have no clue because I am= still not up to speed on this part. But I can easily imagine that a single= stream per HTTP transaction will fall short of some of those can be unreli= able.

K= ind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

On 25 July 2017 at 20.17.34, Frank Kastenholz (fkastenholz@google.com) wrote:

An open question is question is how to present a stream with = =E2=80=9Choles=E2=80=9D to the application.
--f403045f8b7475b9820555291922-- From nobody Tue Jul 25 13:03: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 B2DC8131D0B for ; Tue, 25 Jul 2017 13:03:28 -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_HELO_PASS=-0.001, 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 H1VMF1uJeqJS for ; Tue, 25 Jul 2017 13:03:25 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0134.outbound.protection.outlook.com [104.47.36.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DD31317A4 for ; Tue, 25 Jul 2017 13:03:25 -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=AfcQFjj/cJo7ffZfxh08fNCXQqTon8zRyL0KklIkp98=; b=CBcMRhhSU9timb0EWNuyl+Kd8XamHpljz/Lq/HE6eyUFC8C3/oStVloMcULMaLIXriApHbmaHX3CG7nyOPY5hNLg8V66oVjsAz+bEhXSntMZg9+DVvBAZ2U5g7/T3O6Cpmltaf2K0E96Jq0h8JlsVhB8K23q6WEvXWw0T/B7n80= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0192.namprd21.prod.outlook.com (10.173.52.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Tue, 25 Jul 2017 20:03:23 +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.01.1282.008; Tue, 25 Jul 2017 20:03:23 +0000 From: Mike Bishop To: Mike Bishop , Patrick McManus , Eric Rescorla CC: Lucas Pardue , IETF QUIC WG , Martin Thomson , Martin Duke Subject: RE: New Second Implementation Draft Thread-Topic: New Second Implementation Draft Thread-Index: AQHTAYMPsVZ1kdsT/kGX6kMckMKBMaJdcN8AgAB7CgCAABgsgIAAFmUAgAABiICABFnMUIACiRtg Date: Tue, 25 Jul 2017 20:03:23 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A37748A01@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A37748A51@bgb01xud1012> 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:5::6d4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0192; 7:TFnnUabDqoipiuj/xXDt2pdhfVIZM/paAHfXFXmG32058MfvgDFziX0N/9b128FlGQisDCd6/nXkei71bc632mkIQ3L53/Fgtiu6KM3e+f5MTXooClwBPyyXQyo/zD3OewxzgsWHN32tFcHq+HNRYKeMY3sWuYKhvQzdvCXKWzjqsaXOQdLumho6SKkYzE9lY4m4U7gBhYwoZtqswcg9xRMuUWppGse+dzJRn2A0gZw8oOVROCpNIl4730WGvSgm1E0shQQ0BwKgWIawyubqZgbQVdLkPjp6cHD3JvhHmE6v2ABvt0xfRjCtFivYIGqEbLzEfA5sD/IQOOG/yowKe8sH5+W74baPmJ4lgGvtVjuOudkufxdV88Yx+VxggCb2JY4mvBMvK95S+W32Ar5fvagMjREFUowKml4CfgPznA73eIsYK0EgAUdx3bYMLZc4RF9GHO/ucTsKpzZOkE7O24ygDoSCdUJIKrvgiee6BAu7dW0J/lOW2VEzrW4t96nNDqJG3m4Yx+rta/fDXhzKMi00de/IFfG6r6IGQE+vegwS/MtmEUNH3pa3zX3oZrMGNCCmkJtFpczTJTKJOl/6Rn5ROPQbWAcxnzz4fMFXeLNzPhPA7XIEvAVYpFfbproe1lyub8gTe6XnHV2IivEjovRBiY4/5j6Yw/CJRPsQYnClO4mLhg2BFa3gnbioWzDVW07MlcJZyQkp2F9MiBZxQ0bKW1ep1ql1Qt7GQKoVkET3aaVM0FOebbV1B1yXtcC9ePX13k7jrnURRt3h4/KlKya1OXr/QoOikP5iTRbQ6jdqesbhhrsHGHGzUCNplwBo x-ms-office365-filtering-correlation-id: e23d0a62-2f65-4be6-a1b5-08d4d3983484 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254087)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0192; x-ms-traffictypediagnostic: MWHPR21MB0192: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(127952516941037)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0192; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0192; x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39850400002)(39400400002)(39860400002)(39410400002)(47760400005)(189002)(199003)(57704003)(377454003)(24454002)(3280700002)(53546010)(25786009)(74316002)(5660300001)(106356001)(19609705001)(4326008)(7696004)(86612001)(2906002)(10090500001)(105586002)(3660700001)(478600001)(10290500003)(68736007)(86362001)(14454004)(72206003)(81156014)(7736002)(81166006)(33656002)(39060400002)(54356999)(101416001)(50986999)(3480700004)(2900100001)(5005710100001)(8990500004)(102836003)(76176999)(6116002)(8676002)(790700001)(2561002)(8936002)(1511001)(38730400002)(561944003)(236005)(6246003)(97736004)(2950100002)(2421001)(99286003)(54896002)(55016002)(93886004)(229853002)(6306002)(6506006)(53936002)(77096006)(54906002)(9686003)(189998001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0192; 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: multipart/alternative; boundary="_000_MWHPR21MB01412439AD2FA29B1E9F648C87B80MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 20:03:23.4429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0192 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, 25 Jul 2017 20:03:29 -0000 --_000_MWHPR21MB01412439AD2FA29B1E9F648C87B80MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBzbyB3ZeKAmXJlIG9uIHRoZSBzYW1lIHBhZ2Ug4oCTIHRoaXMgc2V0IG9mIOKAnFNlY29u ZCBJbXBsZW1lbnRhdGlvbiBEcmFmdOKAnSB0YXJnZXRzIGlzIGZvciBTZWF0dGxlPyAgT3Igc29t ZSBmdXR1cmUgZGF0ZT8NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1pa2UgQmlzaG9wDQpTZW50OiBTdW5kYXksIEp1bHkgMjMsIDIwMTcg MTA6MjEgUE0NClRvOiBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPjsgRXJp YyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0KQ2M6IEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVl QGJiYy5jby51az47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29u IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBn bWFpbC5jb20+DQpTdWJqZWN0OiBSRTogTmV3IFNlY29uZCBJbXBsZW1lbnRhdGlvbiBEcmFmdA0K DQpJ4oCZZCBmb2xsb3cgcHJlY2VkZW50IOKAkyBodHRwLzEuMSBpcyBhbHJlYWR5IGRlZmluZWQs IHNvIHdoeSBub3QgaHR0cC8wLjk/DQoNCknigJlkIGFsc28gbGlrZSB0byBtZW50aW9uIHRoYXQg bXkgd2lmZSBpcyBwYXJ0aWN1bGFybHkgZm9uZCBvZiB0aGUgcGFpbnQgY29sb3Ig4oCcUmhpbm/i gJ0gZm9yIHRoZSBhc3NvY2lhdGVkIGJpa2VzaGVkLiAg8J+YiQ0KDQpGcm9tOiBRVUlDIFttYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF0cmljayBNY01hbnVzDQpT ZW50OiBGcmlkYXksIEp1bHkgMjEsIDIwMTcgMzo1MyBBTQ0KVG86IEVyaWMgUmVzY29ybGEgPGVr ckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4NCkNjOiBMdWNhcyBQYXJkdWUgPEx1Y2Fz LlBhcmR1ZUBiYmMuY28udWs8bWFpbHRvOkx1Y2FzLlBhcmR1ZUBiYmMuY28udWs+PjsgSUVURiBR VUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IE1hcnRpbiBUaG9t c29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbT4+OyBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFpbHRvOm1hcnRp bi5oLmR1a2VAZ21haWwuY29tPj4NClN1YmplY3Q6IFJlOiBOZXcgU2Vjb25kIEltcGxlbWVudGF0 aW9uIERyYWZ0DQoNCml0cyBhIGdvb2QgaWRlYSB0aGF0IG5lZWRzIGEgYmlrZXNoZWQuIGhxLW5v cCB3b3VsZCBiZSBteSBwcmVmZXJlbmNlIChzdGF5IGluIHRoZSBocSBuYW1lc3BhY2UpLi4NCg0K T24gRnJpLCBKdWwgMjEsIDIwMTcgYXQgMTI6NDcgUE0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZt LmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpoMDlxLTA1PyA6KQ0KDQpPbiBGcmks IEp1bCAyMSwgMjAxNyBhdCAyOjI3IEFNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25A Z21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCkRvIHdl IG5lZWQgYSBwZXJtYW5lbnQgQUxQTiB0b2tlbiBmb3IgdGhpcz8gIEl0IHNlZW1zIGxpa2UgYSB1 c2VmdWwNCmZhY2lsaXR5IHRvIGJ1aWxkIGludG8gc3RhY2tzIHRoYXQgYXJlIHRyYW5zcG9ydC1v bmx5LiAgTWF5YmUgImgwOXEiLg0KDQpPbiAyMSBKdWx5IDIwMTcgYXQgMTA6MDAsIEx1Y2FzIFBh cmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5jby51azxtYWlsdG86THVjYXMuUGFyZHVlQGJiYy5jby51 az4+IHdyb3RlOg0KPiBJIGFwcHJlY2lhdGUgdGhlIGZsZXhpYmlsaXR5IGJ1dCBoYXZlIGRpZmZp Y3VsdHkgaW4gc2VlaW5nIGhvdyB0aGlzIHdvdWxkDQo+IGZsb3cgdGhyb3VnaCB0byBpbnRlcm9w IHRlc3RpbmcsIGhvdyBkbyB3ZSBtZWFzdXJlIHN1Y2Nlc3M/IE9uZSBwb3NzaWJsZQ0KPiBvdXRj b21lIGlzIGludGVyb3AgbGltaXRlZCB0byBzZWxmLXRlc3Qgb2Yg4oCcYmVzcG9rZS1zaW1wbGUt YXBw4oCdIG92ZXIgUVVJQywNCj4gaXMgdGhhdCBnb29kIGVub3VnaD8gTXkgcHJlZmVyZW5jZSBp cyB0byBwaWNrIGEgbWluaW1hbCBiYXNlbGluZSAo4oCcZWNobyBhbmQNCj4gYW1wbGlmeeKAnSBv ciB3aGF0ZXZlciBlbHNlKSBhbmQgdGhlbiBhZGRpdGlvbmFscyBhcmUgYSBib251cyB0aGF0IGlz IHVwIHRvDQo+IGV4dGVybmFsIGNvb3JkaW5hdGlvbi4gSSB0aGluayB0aGlzIGNvbW1vbiBiYXNl bGluZSBjb3VsZCBhbHNvIGhlbHAgdG93YXJkcw0KPiBvbmdvaW5nIGNvbnNpZGVyYXRpb24gZm9y IHBlcmZvcm1hbmNlIG9yIGJlbmNobWFya2luZywgb3ZlciBkaXNwYXJhdGUNCj4gaW1wbGVtZW50 YXRpb25zLCBhcyBhc3BlY3RzIG9mIHRoZSBwcm90b2NvbCBldm9sdmUgb3IgY2hhbmdlLg0KPg0K Pg0KPg0KPiBUaGUgcHJvcG9zYWwgdG8gZG8gSFRUUCAwLjkgR0VULCBkaXNjdXNzZWQgaW4gUHJh Z3VlLCBhZGRyZXNzZXMgbXkgY29uY2VybnMuDQo+DQo+DQo+DQo+IEx1Y2FzDQo+DQo+DQoNCg0K --_000_MWHPR21MB01412439AD2FA29B1E9F648C87B80MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z ZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3Qg c28gd2XigJlyZSBvbiB0aGUgc2FtZSBwYWdlIOKAkyB0aGlzIHNldCBvZiDigJxTZWNvbmQgSW1w bGVtZW50YXRpb24gRHJhZnTigJ0gdGFyZ2V0cyBpcyBmb3IgU2VhdHRsZT8mbmJzcDsgT3Igc29t ZSBmdXR1cmUgZGF0ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5NaWtlIEJpc2hvcDxicj4NCjxiPlNlbnQ6PC9i PiBTdW5kYXksIEp1bHkgMjMsIDIwMTcgMTA6MjEgUE08YnI+DQo8Yj5Ubzo8L2I+IFBhdHJpY2sg TWNNYW51cyAmbHQ7cG1jbWFudXNAbW96aWxsYS5jb20mZ3Q7OyBFcmljIFJlc2NvcmxhICZsdDtl a3JAcnRmbS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWNhcyBQYXJkdWUgJmx0O0x1Y2FzLlBh cmR1ZUBiYmMuY28udWsmZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBN YXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgTWFydGluIER1 a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS RTogTmV3IFNlY29uZCBJbXBsZW1lbnRhdGlvbiBEcmFmdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SeKAmWQgZm9sbG93IHByZWNlZGVudCDigJMgaHR0cC8xLjEgaXMg YWxyZWFkeSBkZWZpbmVkLCBzbyB3aHkgbm90IGh0dHAvMC45PzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5J4oCZZCBhbHNvIGxpa2UgdG8gbWVudGlvbiB0aGF0IG15IHdpZmUgaXMgcGFydGljdWxh cmx5IGZvbmQgb2YgdGhlIHBhaW50IGNvbG9yIOKAnFJoaW5v4oCdIGZvciB0aGUgYXNzb2NpYXRl ZCBiaWtlc2hlZC4mbmJzcDsNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4mIzEyODUyMTs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+UGF0cmljayBNY01hbnVzPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAy MSwgMjAxNyAzOjUzIEFNPGJyPg0KPGI+VG86PC9iPiBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVm PSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gTHVjYXMgUGFyZHVlICZsdDs8YSBocmVmPSJtYWlsdG86THVjYXMuUGFyZHVlQGJiYy5jby51 ayI+THVjYXMuUGFyZHVlQGJiYy5jby51azwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhy ZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs7IE1hcnRpbiBU aG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsgTWFydGluIER1a2UNCiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tIj5tYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBOZXcgU2Vjb25kIEltcGxlbWVudGF0aW9u IERyYWZ0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdHMgYSBnb29kIGlkZWEgdGhh dCBuZWVkcyBhIGJpa2VzaGVkLiBocS1ub3Agd291bGQgYmUgbXkgcHJlZmVyZW5jZSAoc3RheSBp biB0aGUgaHEgbmFtZXNwYWNlKS4uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVsIDIxLCAyMDE3IGF0IDEyOjQ3IFBNLCBFcmljIFJlc2Nv cmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWty QHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5oMDlxLTA1PyA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1bCAyMSwgMjAxNyBhdCAyOjI3IEFNLCBNYXJ0 aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB3ZSBuZWVkIGEgcGVybWFuZW50IEFMUE4g dG9rZW4gZm9yIHRoaXM/Jm5ic3A7IEl0IHNlZW1zIGxpa2UgYSB1c2VmdWw8YnI+DQpmYWNpbGl0 eSB0byBidWlsZCBpbnRvIHN0YWNrcyB0aGF0IGFyZSB0cmFuc3BvcnQtb25seS4mbmJzcDsgTWF5 YmUgJnF1b3Q7aDA5cSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAyMSBK dWx5IDIwMTcgYXQgMTA6MDAsIEx1Y2FzIFBhcmR1ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkx1Y2Fz LlBhcmR1ZUBiYmMuY28udWsiIHRhcmdldD0iX2JsYW5rIj5MdWNhcy5QYXJkdWVAYmJjLmNvLnVr PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBJIGFwcHJlY2lhdGUgdGhlIGZsZXhpYmlsaXR5IGJ1 dCBoYXZlIGRpZmZpY3VsdHkgaW4gc2VlaW5nIGhvdyB0aGlzIHdvdWxkPGJyPg0KJmd0OyBmbG93 IHRocm91Z2ggdG8gaW50ZXJvcCB0ZXN0aW5nLCBob3cgZG8gd2UgbWVhc3VyZSBzdWNjZXNzPyBP bmUgcG9zc2libGU8YnI+DQomZ3Q7IG91dGNvbWUgaXMgaW50ZXJvcCBsaW1pdGVkIHRvIHNlbGYt dGVzdCBvZiDigJxiZXNwb2tlLXNpbXBsZS1hcHDigJ0gb3ZlciBRVUlDLDxicj4NCiZndDsgaXMg dGhhdCBnb29kIGVub3VnaD8gTXkgcHJlZmVyZW5jZSBpcyB0byBwaWNrIGEgbWluaW1hbCBiYXNl bGluZSAo4oCcZWNobyBhbmQ8YnI+DQomZ3Q7IGFtcGxpZnnigJ0gb3Igd2hhdGV2ZXIgZWxzZSkg YW5kIHRoZW4gYWRkaXRpb25hbHMgYXJlIGEgYm9udXMgdGhhdCBpcyB1cCB0bzxicj4NCiZndDsg ZXh0ZXJuYWwgY29vcmRpbmF0aW9uLiBJIHRoaW5rIHRoaXMgY29tbW9uIGJhc2VsaW5lIGNvdWxk IGFsc28gaGVscCB0b3dhcmRzPGJyPg0KJmd0OyBvbmdvaW5nIGNvbnNpZGVyYXRpb24gZm9yIHBl cmZvcm1hbmNlIG9yIGJlbmNobWFya2luZywgb3ZlciBkaXNwYXJhdGU8YnI+DQomZ3Q7IGltcGxl bWVudGF0aW9ucywgYXMgYXNwZWN0cyBvZiB0aGUgcHJvdG9jb2wgZXZvbHZlIG9yIGNoYW5nZS48 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBwcm9wb3NhbCB0byBk byBIVFRQIDAuOSBHRVQsIGRpc2N1c3NlZCBpbiBQcmFndWUsIGFkZHJlc3NlcyBteSBjb25jZXJu cy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEx1Y2FzPGJyPg0KJmd0 Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_MWHPR21MB01412439AD2FA29B1E9F648C87B80MWHPR21MB0141namp_-- From nobody Tue Jul 25 13:35: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 8CEB512420B for ; Tue, 25 Jul 2017 13:35:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 kp8j-8n9Yfxw for ; Tue, 25 Jul 2017 13:35:22 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 22DCA1317AD for ; Tue, 25 Jul 2017 13:35:22 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id l82so17640689ywc.2 for ; Tue, 25 Jul 2017 13:35:22 -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=DkwjOHU3X3IZk+YxTw+6qdq24nIXOT5sSHAWCXYgnd0=; b=bw03R0KCCXlCsPgexxUmE31uV7JnB+dBvmU6aUo7qVwuSP4HRO/EgvRq1iLiOzvcci PU0fHWg3ymlYRdIltCNd1HLemy+X9KUVmAcTDQxypDFZyF00nOp/bdjrlL995P6sXlY+ E7l2YgQjtI0HxSGmrWIzGzHuzgsh0fOJ0j7V+GONkYbkJMFGCumiNw5qBuBLiQ30jy+o 8RLolcjuvp7cWvUnbm6szUdK2fUW7KRZNkmboU5iM0pOBRtpA0efWBsEA9Pg8yyc3tUW Hb8X2Q8N6dmhwoeK86o3VZGwcVYAohy6ZaFj4Eqd8lOB1XlBNVgwFTzN0CXmYKeUrwZQ WS6g== 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=DkwjOHU3X3IZk+YxTw+6qdq24nIXOT5sSHAWCXYgnd0=; b=hOIvVFOJQD7rzcrsHwMF0IFL2f6faS261N37MSIqzRVwNf6V2noitbgzVhvmAnv3ft z8ImPrYGGKexu4RwJnFM5uZs2rZK1Ud1q/6w+Q8yOrlwDFiPOZJK6PwcKRA7wPvatvl8 MU5QjSFPPDpljv9e5n5ghpe5FQnDfbOJ9Ev1HMdJtpFVagpVK9vTQzHDUinx0SR0LJH4 Kb4DuqvKWT3i8ng8mbBaZzYlNdGkNc1F5Dese0tiX2xwVR2pCn6gU2dllRiaEPaINtEC RGJYSSXRFDofWpY0eHM8npMu17Lhqvaijg4xbjCN2nGQndPI7pX6nsYauhW5st0peOrK OdSg== X-Gm-Message-State: AIVw112uaxVieFEfHgBoPVAsW801nXLPCxhSGmw+QQ+rDN0NSb+p26s7 ZKbF7rtdcY3UGWLM0HQmSfYZRKhpNWs6 X-Received: by 10.37.160.41 with SMTP id x38mr17003837ybh.339.1501014920381; Tue, 25 Jul 2017 13:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Tue, 25 Jul 2017 13:34:39 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37748A01@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A37748A51@bgb01xud1012> From: Eric Rescorla Date: Tue, 25 Jul 2017 13:34:39 -0700 Message-ID: Subject: Re: New Second Implementation Draft To: Mike Bishop Cc: Patrick McManus , Lucas Pardue , IETF QUIC WG , Martin Thomson , Martin Duke Content-Type: multipart/alternative; boundary="94eb2c1a0650220e9205552a4511" 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, 25 Jul 2017 20:35:25 -0000 --94eb2c1a0650220e9205552a4511 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 25, 2017 at 1:03 PM, Mike Bishop wrote: > Just so we=E2=80=99re on the same page =E2=80=93 this set of =E2=80=9CSec= ond Implementation Draft=E2=80=9D > targets is for Seattle? Or some future date? > I had previously understood ID2 to be for Singapore. Given the somewhat rickety state of the implementations I saw in PRG, I think it might be better to get them solid in SEA rather than rickety but more full featured... -Ekr > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mike Bishop > *Sent:* Sunday, July 23, 2017 10:21 PM > *To:* Patrick McManus ; Eric Rescorla > *Cc:* Lucas Pardue ; IETF QUIC WG = ; > Martin Thomson ; Martin Duke < > martin.h.duke@gmail.com> > *Subject:* RE: New Second Implementation Draft > > > > I=E2=80=99d follow precedent =E2=80=93 http/1.1 is already defined, so wh= y not http/0.9? > > > > I=E2=80=99d also like to mention that my wife is particularly fond of the= paint > color =E2=80=9CRhino=E2=80=9D for the associated bikeshed. =F0=9F=98=89 > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Patrick McManus > *Sent:* Friday, July 21, 2017 3:53 AM > *To:* Eric Rescorla > *Cc:* Lucas Pardue ; IETF QUIC WG = ; > Martin Thomson ; Martin Duke < > martin.h.duke@gmail.com> > *Subject:* Re: New Second Implementation Draft > > > > its a good idea that needs a bikeshed. hq-nop would be my preference (sta= y > in the hq namespace).. > > > > On Fri, Jul 21, 2017 at 12:47 PM, Eric Rescorla wrote: > > h09q-05? :) > > > > On Fri, Jul 21, 2017 at 2:27 AM, Martin Thomson > wrote: > > Do we need a permanent ALPN token for this? It seems like a useful > facility to build into stacks that are transport-only. Maybe "h09q". > > > On 21 July 2017 at 10:00, Lucas Pardue wrote: > > I appreciate the flexibility but have difficulty in seeing how this wou= ld > > flow through to interop testing, how do we measure success? One possibl= e > > outcome is interop limited to self-test of =E2=80=9Cbespoke-simple-app= =E2=80=9D over > QUIC, > > is that good enough? My preference is to pick a minimal baseline (=E2= =80=9Cecho > and > > amplify=E2=80=9D or whatever else) and then additionals are a bonus tha= t is up to > > external coordination. I think this common baseline could also help > towards > > ongoing consideration for performance or benchmarking, over disparate > > implementations, as aspects of the protocol evolve or change. > > > > > > > > The proposal to do HTTP 0.9 GET, discussed in Prague, addresses my > concerns. > > > > > > > > Lucas > > > > > > > > > --94eb2c1a0650220e9205552a4511 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Jul 25, 2017 at 1:03 PM, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

Just so we=E2=80=99re on the same page =E2=80=93 thi= s set of =E2=80=9CSecond Implementation Draft=E2=80=9D targets is for Seatt= le?=C2=A0 Or some future date?

<= div>I had previously understood ID2 to be for Singapore. Given the somewhat= rickety state of the implementations I saw in PRG, I think it might be bet= ter to get them solid in SEA rather than rickety but more full featured...<= /div>

-Ekr

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mike Bishop
Sent: Sunday, July 23, 2017 10:21 PM
To: Patrick McManus <pmcmanus@mozilla.com>; Eric Rescorla <ekr@rtfm.com><= br> Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf.org>; Martin Thomson= <martin.t= homson@gmail.com>; Martin Duke <martin.h.duke@gmail.com>
Subject: RE: New Second Implementation Draft

=C2=A0

I=E2=80=99d follow precedent =E2=80=93 http/1.1 is a= lready defined, so why not http/0.9?

=C2=A0

I=E2=80=99d also like to mention that my wife is par= ticularly fond of the paint color =E2=80=9CRhino=E2=80=9D for the associate= d bikeshed.=C2=A0 =F0=9F=98= =89

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Patrick McManus
Sent: Friday, July 21, 2017 3:53 AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf.org>; Martin Thomson= <martin.t= homson@gmail.com>; Martin Duke <martin.h.= duke@gmail.com>
Subject: Re: New Second Implementation Draft

=C2=A0

its a good idea that needs a bikeshed. hq-nop would = be my preference (stay in the hq namespace)..

=C2=A0

On Fri, Jul 21, 2017 at 12:47 PM, Eric Rescorla <= ekr@rtfm.com> wrot= e:

h09q-05? :)

=C2=A0

On Fri, Jul 21, 2017 at 2:27 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

Do we need a permanent ALPN token for this?=C2=A0 It= seems like a useful
facility to build into stacks that are transport-only.=C2=A0 Maybe "h0= 9q".

On 21 July 2017 at 10:00, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
> I appreciate the flexibility but have difficulty in seeing how this wo= uld
> flow through to interop testing, how do we measure success? One possib= le
> outcome is interop limited to self-test of =E2=80=9Cbespoke-simple-app= =E2=80=9D over QUIC,
> is that good enough? My preference is to pick a minimal baseline (=E2= =80=9Cecho and
> amplify=E2=80=9D or whatever else) and then additionals are a bonus th= at is up to
> external coordination. I think this common baseline could also help to= wards
> ongoing consideration for performance or benchmarking, over disparate<= br> > implementations, as aspects of the protocol evolve or change.
>
>
>
> The proposal to do HTTP 0.9 GET, discussed in Prague, addresses my con= cerns.
>
>
>
> Lucas
>
>

=C2=A0

=C2=A0

--94eb2c1a0650220e9205552a4511-- From nobody Tue Jul 25 15:39: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 75810131FB9 for ; Tue, 25 Jul 2017 15:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 zIybSniHMKCx for ; Tue, 25 Jul 2017 15:39:11 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 E2F31131F36 for ; Tue, 25 Jul 2017 15:39:09 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id t201so57644423wmt.1 for ; Tue, 25 Jul 2017 15:39:09 -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=ELSGvpixSZbcr2foZFyUu6yIRQGdsW8xswfBOVJ6stc=; b=d1xVrVxbCBcHGBwHI7bMEunXnwwjm6pPgE3rhQp1nrR6HFc2OKW8JN6l3ft4tyhuvz Ywsw12tXpbmS6d6ZSg6N7cWAb2BsEJxmJcd5EQvVNzRiwiXRBgu7R20Y2RtQAuLd1d8L HoQ6GFQy2EStRZjM0Z5Z3v1o2Tm2KOCxJa/mHuXhPmjo7sxbDf2ZJ51KFF9nX/elNiAJ CiAQFPXPK1R1yrNZCP7yrgSGEDvEV4wugxBnuG4FScVlSyY5d9K+wApfcwbVwm0VFe27 97BKRpFNqBxVvqippZ3ztUqO2YLUtQRjtze/MU3tpk2dYalBQ3BhzB4PzQRN+rAZLBH8 2E+g== 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=ELSGvpixSZbcr2foZFyUu6yIRQGdsW8xswfBOVJ6stc=; b=XdwPrCu67AtpXefSfWGqYw+/s9g9564vFvCuZqHQAMOanFs6EVohTiB9NKSTQUAIeI G9Sp2VimT70/8U+JeX8nl7pN1VvyJafNkXH46LhVNyWC5i/kA8BZm5G971IaKi6K7V8L Q7GKMKb6UqV0yZLkHFWliYVBURfjwe58essrnvcvnmR1/oRaA4V7dNQW/RcJuuD021CY EmwfB+fZS0aDg8aInT6zBUIzzZslp6FTYCxRtRHAKk2lTDQWr2mvMBDl29QJNqmwFfTN 7LhBFCBUcY2EEZb8RuXs1uNWFkFo+1ZMXZHaEc8ifklAFgwN8FSeXayDe+hi5B0foyDw cPig== X-Gm-Message-State: AIVw110SBC9aHe1oXqXUibv/ISWcQJSGu4jyMua7tcDY9F6PkSghM5FA Xj1xIQ9PqdMRo429HtSRQ1E1b2XVGFtC X-Received: by 10.28.11.212 with SMTP id 203mr9840381wml.105.1501022348400; Tue, 25 Jul 2017 15:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.119 with HTTP; Tue, 25 Jul 2017 15:39:07 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37748A01@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A37748A51@bgb01xud1012> From: Martin Duke Date: Tue, 25 Jul 2017 15:39:07 -0700 Message-ID: Subject: Re: New Second Implementation Draft To: Eric Rescorla Cc: Mike Bishop , Patrick McManus , Lucas Pardue , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="001a114450cee061eb05552bffd5" 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, 25 Jul 2017 22:39:13 -0000 --001a114450cee061eb05552bffd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the ID1 group has to reach consensus they are at the point of diminishing returns, whenever that may be. If anyone wants to get ahead, this is the stuff to tackle. On Tue, Jul 25, 2017 at 1:34 PM, Eric Rescorla wrote: > > On Tue, Jul 25, 2017 at 1:03 PM, Mike Bishop > wrote: > >> Just so we=E2=80=99re on the same page =E2=80=93 this set of =E2=80=9CSe= cond Implementation >> Draft=E2=80=9D targets is for Seattle? Or some future date? >> > > I had previously understood ID2 to be for Singapore. Given the somewhat > rickety state of the implementations I saw in PRG, I think it might be > better to get them solid in SEA rather than rickety but more full > featured... > > -Ekr > > >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mike Bishop >> *Sent:* Sunday, July 23, 2017 10:21 PM >> *To:* Patrick McManus ; Eric Rescorla > > >> *Cc:* Lucas Pardue ; IETF QUIC WG ; >> Martin Thomson ; Martin Duke < >> martin.h.duke@gmail.com> >> *Subject:* RE: New Second Implementation Draft >> >> >> >> I=E2=80=99d follow precedent =E2=80=93 http/1.1 is already defined, so w= hy not http/0.9? >> >> >> >> I=E2=80=99d also like to mention that my wife is particularly fond of th= e paint >> color =E2=80=9CRhino=E2=80=9D for the associated bikeshed. =F0=9F=98=89 >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org ] *On >> Behalf Of *Patrick McManus >> *Sent:* Friday, July 21, 2017 3:53 AM >> *To:* Eric Rescorla >> *Cc:* Lucas Pardue ; IETF QUIC WG ; >> Martin Thomson ; Martin Duke < >> martin.h.duke@gmail.com> >> *Subject:* Re: New Second Implementation Draft >> >> >> >> its a good idea that needs a bikeshed. hq-nop would be my preference >> (stay in the hq namespace).. >> >> >> >> On Fri, Jul 21, 2017 at 12:47 PM, Eric Rescorla wrote: >> >> h09q-05? :) >> >> >> >> On Fri, Jul 21, 2017 at 2:27 AM, Martin Thomson >> wrote: >> >> Do we need a permanent ALPN token for this? It seems like a useful >> facility to build into stacks that are transport-only. Maybe "h09q". >> >> >> On 21 July 2017 at 10:00, Lucas Pardue wrote: >> > I appreciate the flexibility but have difficulty in seeing how this >> would >> > flow through to interop testing, how do we measure success? One possib= le >> > outcome is interop limited to self-test of =E2=80=9Cbespoke-simple-app= =E2=80=9D over >> QUIC, >> > is that good enough? My preference is to pick a minimal baseline (=E2= =80=9Cecho >> and >> > amplify=E2=80=9D or whatever else) and then additionals are a bonus th= at is up >> to >> > external coordination. I think this common baseline could also help >> towards >> > ongoing consideration for performance or benchmarking, over disparate >> > implementations, as aspects of the protocol evolve or change. >> > >> > >> > >> > The proposal to do HTTP 0.9 GET, discussed in Prague, addresses my >> concerns. >> > >> > >> > >> > Lucas >> > >> > >> >> >> >> >> > > --001a114450cee061eb05552bffd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the ID1 group has to reach consensus they are at t= he point of diminishing returns, whenever that may be. If anyone wants to g= et ahead, this is the stuff to tackle.

=
On Tue, Jul 25, 2017 at 1:34 PM, Eric Rescorla <= span dir=3D"ltr"><ekr@= rtfm.com> wrote:

On Tue, Jul 25, 2017 at 1:03 PM, Mike Bishop <= ;Michael.= Bishop@microsoft.com> wrote:

Just so we=E2=80=99re on the same page =E2=80=93 thi= s set of =E2=80=9CSecond Implementation Draft=E2=80=9D targets is for Seatt= le?=C2=A0 Or some future date?

<= /span>
I had previously understood ID2 to be for Singapore. Given the s= omewhat rickety state of the implementations I saw in PRG, I think it might= be better to get them solid in SEA rather than rickety but more full featu= red...

-Ekr

<= /div>

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mike Bishop
Sent: Sunday, July 23, 2017 10:21 PM
To: Patrick McManus <pmcmanus@mozilla.com>; Eric Rescorla <ekr@rtfm.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf.org>; Martin Thomson= <martin.t= homson@gmail.com>; Martin Duke <martin.h.duke@gmail.com>
Subject: RE: New Second Implementation Draft

=C2=A0

I=E2=80=99d follow precedent =E2=80=93 http/1.1 is a= lready defined, so why not http/0.9?

=C2=A0

I=E2=80=99d also like to mention that my wife is par= ticularly fond of the paint color =E2=80=9CRhino=E2=80=9D for the associate= d bikeshed.=C2=A0 =F0=9F=98= =89

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Patrick McManus
Sent: Friday, July 21, 2017 3:53 AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf.org>; Martin Thomson= <martin.t= homson@gmail.com>; Martin Duke <martin.h.= duke@gmail.com>
Subject: Re: New Second Implementation Draft

=C2=A0

its a good idea that needs a bikeshed. hq-nop would = be my preference (stay in the hq namespace)..

=C2=A0

On Fri, Jul 21, 2017 at 12:47 PM, Eric Rescorla <= ekr@rtfm.com> wrot= e:

h09q-05? :)

=C2=A0

On Fri, Jul 21, 2017 at 2:27 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

Do we need a permanent ALPN token for this?=C2=A0 It= seems like a useful
facility to build into stacks that are transport-only.=C2=A0 Maybe "h0= 9q".

On 21 July 2017 at 10:00, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
> I appreciate the flexibility but have difficulty in seeing how this wo= uld
> flow through to interop testing, how do we measure success? One possib= le
> outcome is interop limited to self-test of =E2=80=9Cbespoke-simple-app= =E2=80=9D over QUIC,
> is that good enough? My preference is to pick a minimal baseline (=E2= =80=9Cecho and
> amplify=E2=80=9D or whatever else) and then additionals are a bonus th= at is up to
> external coordination. I think this common baseline could also help to= wards
> ongoing consideration for performance or benchmarking, over disparate<= br> > implementations, as aspects of the protocol evolve or change.
>
>
>
> The proposal to do HTTP 0.9 GET, discussed in Prague, addresses my con= cerns.
>
>
>
> Lucas
>
>

=C2=A0

=C2=A0

--001a114450cee061eb05552bffd5-- From nobody Tue Jul 25 15:41: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 176DA131FC8 for ; Tue, 25 Jul 2017 15:41:25 -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, FREEMAIL_FROM=0.001, 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=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 Xb8uwnfMeCfc for ; Tue, 25 Jul 2017 15:41:23 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 AABEA131FBE for ; Tue, 25 Jul 2017 15:41:22 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id k71so71112363wrc.2 for ; Tue, 25 Jul 2017 15:41:22 -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=bZMKWomhlCPZyibG0ugIuL8sIIQeAbc+ydmfY6Z/u2k=; b=QVwsN8hvIWd8tBfagNoEHjJ3bA2JwHcic6HF+QlNXZNyJyrpzcX+z3QBCL+ITqfa0A MWo2S/TjvyoJmaeX9bQOMvu7LWeQfwHZDNEwyNkbYGgtciZEGqNM/UxunLiRHMhIgfx3 tcDS6fJraAJEdRJofuLCcjtAYsFyfVCTdeHJpZ70kd2vVgQPI73aX8/PuhtXcOomiJH+ 7RNOjoi5P4pw0piNu3LcaMqKnlJQVrOnwQdey891uyBrejphU5zuqGtc33rJIseAMV2t RnDzShhXigtb/PQHmcZafaEevd6UFqwjm4Ffqj0XRVn8PX0NacRjoos+mWTRPvLjCLDA +yMg== 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=bZMKWomhlCPZyibG0ugIuL8sIIQeAbc+ydmfY6Z/u2k=; b=YTq0k9AJfMzUeMPh14x3iHCzl6qIWN2JZy6l75GAbWgVEizW7HEbmFB4XNSlw3HFvH /3858daSj92e4FRCbHuYPe4f57KWS3NTn52EH0N4G4whO+mWFeAlolq5fzkCGQH7d3Fj n805jYJ3pEGtjj38xSM0uqKnKpurowGZ+kpTdBYa4yoVSmTRrfgc/tnzlhKFfY4CUKSE NEvIhCKmmWcOnma6BrNNH1IwdYUwN45/zX9hl+PNmAwt7jQQNtP3EuACPgqHpEs/+g4m I/uDPX72ivdmF7ZPd98KUkCPW5ktpaUzuO/pc3gWkZ1apOYNuD1947Q35I1QBndrZwLY jgIg== X-Gm-Message-State: AIVw110yPokiKtNugFezpPbANGFOBxVjPKuB5PsTJLVdTCbAbPGnNrj1 S0YBX/MnhjHWJitHElU/vQurLyFXQyZ8 X-Received: by 10.223.171.79 with SMTP id r15mr15153510wrc.57.1501022481211; Tue, 25 Jul 2017 15:41:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.119 with HTTP; Tue, 25 Jul 2017 15:41:20 -0700 (PDT) In-Reply-To: References: From: Martin Duke Date: Tue, 25 Jul 2017 15:41:20 -0700 Message-ID: Subject: Re: Unidirectional Streams discussion To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="94eb2c1cb818caf29e05552c07f6" 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, 25 Jul 2017 22:41:25 -0000 --94eb2c1cb818caf29e05552c07f6 Content-Type: text/plain; charset="UTF-8" clarification added. On Tue, Jul 25, 2017 at 12:36 AM, Mark Nottingham wrote: > Everyone, > > In Prague, we discussed Unidirectional Streams. > > Issue: https://github.com/quicwg/base-drafts/issues/175 > Draft minutes: https://github.com/quicwg/wg- > materials/blob/master/ietf99/minutes.md#unidirectional-streams > > The outcome of that discussion was that Martin would continue to work on > his proposal, and EKR would experiment with unidirectional streams in a > branch of his implementation, to gain experience with them and help judge > the amount of complexity they save or add. > > We'll take a look at their work at the October interim meeting. > > In the meantime, our approach remains bidirectional streams (including for > the purposes of Implementation Draft 2)*. > > Please refrain from discussing unidirectional streams on-list; if Martin > and EKR have questions to help guide their exploration, they should ask the > group, but otherwise we shouldn't be spending additional time on this until > we have their results. > > Thanks, > > > * Editors / Martin Duke -- please clarify that ID2 will be using > bidirectional streams as necessary. > > -- > Mark Nottingham https://www.mnot.net/ > > --94eb2c1cb818caf29e05552c07f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
clarification added.

<= div class=3D"gmail_quote">On Tue, Jul 25, 2017 at 12:36 AM, Mark Nottingham= <m= not@mnot.net> wrote:
Everyo= ne,

In Prague, we discussed Unidirectional Streams.

=C2=A0 Issue: https://github.com/quicwg/base-dr= afts/issues/175
=C2=A0 Draft minutes: https://github.com/quicwg/wg-materials/blob/master/ietf99= /minutes.md#unidirectional-streams

The outcome of that discussion was that Martin would continue to work on hi= s proposal, and EKR would experiment with unidirectional streams in a branc= h of his implementation, to gain experience with them and help judge the am= ount of complexity they save or add.

We'll take a look at their work at the October interim meeting.

In the meantime, our approach remains bidirectional streams (including for = the purposes of Implementation Draft 2)*.

Please refrain from discussing unidirectional streams on-list; if Martin an= d EKR have questions to help guide their exploration, they should ask the g= roup, but otherwise we shouldn't be spending additional time on this un= til we have their results.

Thanks,

* Editors / Martin Duke -- please clarify that ID2 will be using bidirectio= nal streams as necessary.

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--94eb2c1cb818caf29e05552c07f6-- From nobody Tue Jul 25 17:05: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 1A72E132127 for ; Tue, 25 Jul 2017 17:05:51 -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, 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 (2048-bit key) header.d=mnot.net header.b=LBSaoJrz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kkIfG4oe 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 akPOGcgK5U4x for ; Tue, 25 Jul 2017 17:05:49 -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 0A0D613212B for ; Tue, 25 Jul 2017 17:05:49 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 65C6C20A64; Tue, 25 Jul 2017 20:05:48 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 25 Jul 2017 20:05:48 -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=i18YPKNqVskrZf2iSdoFOLfUsh+hzVxexPlBL3Aoh sU=; b=LBSaoJrzMEJIUUJ7pQAS/5ggHBdquEviN2zvpaGTnEoIv5YSsEw12k16Q tGR93gub/HldlUaDc7zfw+5lVvm8vRbfwUauy+sbOuHmAZNbBFvr+26K3l1FLmZb VTFb947PiBGuGYE7OdGU/Eov94AfgOlqX7YoiU8hby3s0rMree+up1G/78h/2uo/ 0PMDjVzzdC15KxtlOWW5FfWzV+RKXxLh9cveWK7xsiTQuXP/9rIQr+skDDXKn9TP S/nVDvlANrRAvxxsXSPeR1QzLrIDn5lgkuvm/PbLC3SNvwJ1L4bNMb+nbHCiYE2Q XVW6R7cXPYeY4izq4TULxelGBIcgQ== 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=i18YPKNqVskrZf2iSd oFOLfUsh+hzVxexPlBL3AohsU=; b=kkIfG4oeQohW1bVflDwevvLrLsTa5w58xn zaG1PTZloIS2rBERZABgLKnB/j3L6bq66xjB9jpMLeB8b+lZmmdRlHI7zel3BM1Q e4QjCZO0aSSIYQMXhb74ZPY61ofjkzt2LIKnWVXlWbWu2BMI/wkFZT9tyjjYH5YK b8BUAcCSUWagUQQ+eGIpTIgA2IB2mi7nnix/UW/L5ES7Lsk9MKlFy/0oHEKDNiG9 +RLDH0KGKMoflPZcYZ3YrRhr/Yp45EzhjEt7faXAIIV793vCXyoi5T04M0W3bj7V fSAzmeierJzAQFis09ELXsABM0SzK/stuCOjWl3jD/eZjIu3XEvA== X-ME-Sender: X-Sasl-enc: +4jbpF3q6ZM0Qomky9I8LF2S9Jv8tvEClmWiB6QspBRO 1501027547 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 761AB7E12E; Tue, 25 Jul 2017 20:05:47 -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 10.3 $3273$) Subject: Passive RTT Measurement / Middlebox discussion Message-Id: Date: Wed, 26 Jul 2017 10:05:43 +1000 Cc: Lars Eggert To: IETF 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: Wed, 26 Jul 2017 00:05:51 -0000 In Prague, we discussed passive RTT measurement. Issue: https://github.com/quicwg/base-drafts/issues/631 Draft minutes: = https://github.com/quicwg/wg-materials/blob/master/ietf99/minutes.md#passi= ve-rtt-measurement-in-quic---ian-swett The outcome of that discussion was the formation of a Design Team, led = by Ted Hardie, to review what privacy risks would be eliminated if this = information is not available and to ascertain what network measurement = and management options would be available if this information is not. We expect them to report back in the Singapore meeting. In the meantime, please refrain from discussing passive RTT measurement = on-list. We'd also appreciate it if related issues (e.g., #632, on-path = calculation of loss and congestion) was also deferred until we see those = results. We believe that the design team's membership is representative of both = operators' needs and privacy concerns. If you'd like to contribute, = please contact Ted, but please understand that to be successful, the = team's size needs to be limited. Ted will post the team's membership to = the list shortly. See for more = information about Design Teams in the IETF. Thanks, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jul 26 02:27: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 66FA3131FE5 for ; Wed, 26 Jul 2017 02:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 TPgCHm7T41Ca for ; Wed, 26 Jul 2017 02:27:25 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30117.outbound.protection.outlook.com [40.107.3.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAED131FDC for ; Wed, 26 Jul 2017 02:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fRhY2IX934tVczhzrdRANgw3uQ7/wjBmp0L0osVG3Bw=; b=KabihteXdwtqEdm5fn7mgzN6DjsvVzjku0mn3l9HxWUe1az9neq/GVZr0HiCryEJnVLw4bRClyD3pFLBTDIm8szgOiz32n+AWbsCc1q6MU1/drMZpt3jxuAMvX+ZLCY2c+DNoW6bI5PtAX59+3P1A8QMmKYEiI5eQEJSG/xeauQ= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB0935.eurprd07.prod.outlook.com (10.161.200.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Wed, 26 Jul 2017 09:27:20 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::400b:454d:9821:a354%13]) with mapi id 15.01.1304.014; Wed, 26 Jul 2017 09:27:20 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Dmitri Tikhonov CC: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , "Magnus Westerlund" , IETF QUIC WG Subject: RE: Idea for packet numbers Thread-Topic: Idea for packet numbers Thread-Index: AQHTAT74Pm6HB4E+oUyHojrh9ct+26JcjwOAgAF4cgCAA8bLAIACtdaAgAAAveCAAD5egIAAAIvg Date: Wed, 26 Jul 2017 09:27:19 +0000 Message-ID: References: <20170721093732.GA31705@ubuntu-dmitri> <20170725124109.GA1764@ubuntu-dmitri> <20170725162701.GA4414@ubuntu-dmitri> In-Reply-To: <20170725162701.GA4414@ubuntu-dmitri> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB0935; 7:Xvk2Xve+8SvzA9yad4fIjvUiDlJy/pHLFgNEruvnq93L5tqPU9z1oEf4MbaAbEZfikX7e81AIIq0a2HewcSxkDXJhBq1/2B6ZB2pkA4UYfHLUNfGNqx+LhdGLnBpEVh6+F4E1yz5J7KFlHF3b7zNygyNQuj1dKd+1VTF0pA3oCcHLEd3i0s3L14laPLSbyVdlgsRhSfHQl6c1Ja2szolNkMj4KyGhRtoPjzds9kaGrOhYKRdUxPDXmcCf+orSXoje+UVJAkNiN14+YbO5DIz09ECCclJ30kR1NKoTb9Ic0L0rutuFHK08dY61dI4AUAWHUx+Qbj6inWbmYEZK4q9nlXuvR5aAQ81Eqpvw6XbW1c+nx1fbm9brop0FYhXLw7OHLi31J+ah3eumbYGByG1mfiSFnv9uhsv0wkbZYNL6Jb5dR5xeh9GMFfi7dCuKt+5/q6Pms/V7gR96fOgd/5QxtNhEUKfJ0rMUYkoipu1KjXvZ19+ZZkfYjr9Yjtm9rDqbju7PEse11KqtUyXQY2mZl+ecbeSmfhNI2DHDuN2Akov7UPbZW9VJawGW7xdKi0f3WzZgWwN8w34NzXVb5dAaG9gIaMsgInWXs4NyZWMAMYQU5dsWJ1EIWuQqK8beq5FObhL20FOlE0IytLZUlBrTD0ylJFVHNZsfFeTAAi7jK3rYTgo3epXHtqgMgBsarOCUuC4KQ1gE2F7euY20TTtuRAIqLxNTxUs6qDbP+yybXEQxsTFMqGKOYfzYdYs2DIP3VVTIifYnsqtO5SqXgffFWqZzOnilxdroUhVqTkMa1c= x-ms-office365-filtering-correlation-id: 5f4376a8-75af-494e-68bf-08d4d40883c1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB0935; x-ms-traffictypediagnostic: DB5PR07MB0935: x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0935; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0935; x-forefront-prvs: 038002787A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39400400002)(39410400002)(39850400002)(24454002)(199003)(13464003)(189002)(305945005)(53546010)(86362001)(189998001)(66066001)(97736004)(2900100001)(8676002)(4326008)(81166006)(81156014)(25786009)(68736007)(101416001)(33656002)(99286003)(8936002)(53936002)(6506006)(3480700004)(110136004)(7696004)(6246003)(54906002)(229853002)(74316002)(6436002)(93886004)(38730400002)(478600001)(106356001)(14454004)(105586002)(55016002)(39060400002)(5660300001)(2950100002)(5250100002)(50986999)(7736002)(6916009)(6116002)(54356999)(76176999)(102836003)(3846002)(3280700002)(2906002)(9686003)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB0935; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2017 09:27:19.9067 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0935 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, 26 Jul 2017 09:27:27 -0000 > -----Original Message----- > From: Dmitri Tikhonov [mailto:dtikhonov@litespeedtech.com] > Sent: 25 July 2017 17:27 > To: Swindells, Thomas (Nokia - GB/Cambridge, UK) > > Cc: Mikkel Fahn=F8e J=F8rgensen ; Magnus Westerlund > ; IETF QUIC WG > Subject: Re: Idea for packet numbers >=20 > On Tue, Jul 25, 2017 at 02:28:52PM +0000, Swindells, Thomas (Nokia - > GB/Cambridge, UK) wrote: > > 4 wasn't meant to imply how you queue the packet on the NIC - I was > > assuming via a kernel API call into normal udp send buffers, but both > > methods are valid. You are right though there is the potential for > > the queuing operation to be blocked/rejected. >=20 > Since we were talking about implementation, I wanted to point out that pa= cket > number allocation is more complicated in practice. I realize this is not= what > you meant. :) >=20 > > As I understand it the packet number is used in the encryption > > process, so changing a packets number is a non-trivial operation. A > > fast path route for queuing acks makes sense, again however the only > > real way > ^^^^^^^^^^^^^ >=20 > By this, do you mean "without encrypting data twice?" Yes - re-encrypting can't really be considered a 'trivial' operation =20 > > to do that would be to give the ack packet a higher packet number but > > then send it before lower marked packets - even potentially if they do > > also contain ack frames. >=20 > That is a good approach if it does not break packet number derivation. > I am not sure whether it can... The draft says: >=20 > " A packet number is decoded by finding the packet number > " value that is closest to the next expected packet. >=20 > Thus, after receiving ACK packet with large gap, which is the next expect= ed > packet number from the point of view of the peer? The spec says that you should give plenty of room in the number space, so a= s long as you haven't reached half your number space across that period thi= s should be extremely rare or perhaps impossible.=20 The worst case is that if you do violate it then either you may be requeste= d to retransmit some packets, or you just send the original packets first a= nd then the ack. =20 > > For RST_STREAM I think it is permitted that currently queued packets > > are still sent, but if they only contain that streams packets then it > > is a beneficial optimization if they weren't sent (leaving packet > > number gaps). >=20 > Current draft says: >=20 > " An endpoint that receives a RST_STREAM frame (and which > " has not sent a FIN or a RST_STREAM) MUST immediately > " respond with a RST_STREAM frame, and MUST NOT send any > " more data on the stream. >=20 > I suppose one could interpret "send" to mean "enqueue," but I would err o= n > the side of caution. With a basic integration between an application and quic stack the api woul= d likely just be the application writing a load of data onto a stream which= then gets multiplexed into a quic connection. In this case the application view would be once it has written it to the st= ream it is being 'sent' - in the same way the assumption is held for TCP tr= ansmission.=20 Packetization and enqueuing for transmission would therefore be considered = part of the sending process and with that API it would seem to be fair to s= end queued data but not allow new writes from the application. Assuming no re-encryption/packetization, that is pretty much all you can do= if packets contain data from multiple stream frames anyway.=20 The "immediately respond with a RST_STREAM" perhaps then needs to be read a= s: "immediately, after any pending packets have been transmitted, such that= no new packets with data from that stream are generated with a higher pack= et number than the RST_STREAM response frame."? Thomas From nobody Wed Jul 26 04:05: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 1C02B131FE9 for ; Wed, 26 Jul 2017 04:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 mj-RDryUa11q for ; Wed, 26 Jul 2017 04:05:15 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71D2126DEE for ; Wed, 26 Jul 2017 04:05:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3xHXMF4NZ6z15MQD; Wed, 26 Jul 2017 13:05:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4awx1nUqicU; Wed, 26 Jul 2017 13:05:12 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11F24.dip0.t-ipconnect.de [217.225.31.36]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 26 Jul 2017 13:05:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 $3273$) Subject: Re: Unreliable Stream (was: Re: HTTP requests on one stream #692) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 26 Jul 2017 13:05:10 +0200 Cc: "Philipp S. Tiesel" , Frank Kastenholz , Mike Bishop , Ian Swett , Lucas Pardue , IETF QUIC WG , Martin Thomson , "Swindells, Thomas (Nokia - GB)" Content-Transfer-Encoding: quoted-printable Message-Id: <9EA010C1-A283-4C21-B257-5D7BA68B20E8@tik.ee.ethz.ch> References: <7CF7F94CB496BF4FAB1676F375F9666A37748B7A@bgb01xud1012> <2B5E3522-750C-4697-A308-D8452E800D9F@in-panik.de> <9914D466-6293-447C-B3FC-839CFFF9298B@in-panik.de> 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: Wed, 26 Jul 2017 11:05:18 -0000 Hi all, in the taps working group we are working on a new socket API, our = current proposal is called post sockets. This API is message-based and = reliability is realized by assigning a deadline to a message. This = approach is based on the assumption that a message is only as a whole = useful for the application, and only if delivered within a certain time = frame (where for full reliability this time frame in infinite). As = message is a data segment defined by the application which can be a = frame in a video stream or a sensor report and can span one or multiple = transport packets. I thinks this matches what Mikkel describes below. The deadline is set by the sender because only the sender side can = =E2=80=9Ameasure=E2=80=98 correctly when the deadline is passed. For me = any signal from the client side about what the right value for this = deadline is, is probably an application question and should be done in = the application layer. Mirja > Am 25.07.2017 um 21:11 schrieb Mikkel Fahn=C3=B8e J=C3=B8rgensen = : >=20 > I believe Franks description suits the view if unreliable streams = being very small unidirectional streams. >=20 > As to Phillips question: >> An open question is question is how to present a stream with = =E2=80=9Choles=E2=80=9D to the application. > The size of holes may be tricky unless, but presenting logical streams = with holes is easy: >=20 > For reliable (logical) streams you have one transport stream with many = messages and no holes. These messages must be on the stream to ensure = ordering, and you therefore need an application level message frame. >=20 > For unreliable (logical) streams you only send one message in each = QUIC transport stream. Instead of a message frame you store a logical = stream id. The transport stream id will always increase so even if = unreliable, you still know about ordering. An internal sequence number = could be added if more details are needed. >=20 > Unreliable streams may be short so there can be many in a single UDP = packet. This can drain the stream ID space. >=20 > A sending application can easily tell QUIC transport to not retransmit = frames of unreliable streams (or have some timeout etc.). >=20 > The receiving QUIC transport might struggle with seeing only the = second half of an unreliable stream. The receiving application has not = easy way to tell transport to stop waiting even if both sending and = receiving applications have negotiated what they want. To solve this = problem, QUIC transport could have a flag on frames that mark them as = unreliable - perhaps two bits for different classes / timeouts etc. The = application can the tell transport how to manage such streams. >=20 > By and large, reliable and unreliable streams work exactly the same at = the transport layer. >=20 >=20 >=20 > Note that if streams are not unidirectional there is more overhead in = keeping stream state and terminating streams. With a uni-directional = stream a sender can immediately close all stream state after sending a = single frame message. At a deeper level there may be frame = retransmission, but this is much more lightweight. Then if frames are = marked unreliable they can also bypass the retransmission queue. >=20 > So I would like unidirectional streams with a flag to mark frames as = unreliable, and longer stream identifiers (possibly compressed). >=20 > How this works at the HTTP level I have no clue because I am still not = up to speed on this part. But I can easily imagine that a single stream = per HTTP transaction will fall short of some of those can be unreliable. >=20 >=20 >=20 > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen >=20 >=20 > On 25 July 2017 at 20.17.34, Frank Kastenholz (fkastenholz@google.com) = wrote: >=20 >> An open question is question is how to present a stream with = =E2=80=9Choles=E2=80=9D to the application. From nobody Wed Jul 26 07:16: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 BBD37132044 for ; Wed, 26 Jul 2017 07:16:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 kgjfxLSPSXeI for ; Wed, 26 Jul 2017 07:16:39 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e: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 F0C07132040 for ; Wed, 26 Jul 2017 07:16:38 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id b8so8281898pgn.0 for ; Wed, 26 Jul 2017 07:16: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=G9GpGNIf7IdyO8IhUwRdjsXyD0tm8qBXGjRzpXQt5WM=; b=ho+shzcC2OVDbA+OMuYXnJ1FLWC1OPsLlX8FgYqY8aHvglvS28Qeoq+fS3CYjc4cI5 4906oj1gfSjYfFmkhCW6qLtvvlKweL3ATs60NUzq41UyGxLPkqwiT+aN9B8PxkdlvMln riJ4OjR/BXNptyLNltM85hMn8s9dGBc5SpDzPuZrFkJw+SygJWiZ5+V2Rjp1G8S/rBbt F8ORNh+6Q3JKNlAeDDZi91azcCHwX1eIumoh/KX5XjvjffFkLKZKXkxRnCoOcIINJT4Q OiB5JJQoRfD/4/niFnXp2Oh7oSTOoyX9yhM42F1O2KBsSZKC7FrIq4eOA/IYlfMc7HLh Z5eA== 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=G9GpGNIf7IdyO8IhUwRdjsXyD0tm8qBXGjRzpXQt5WM=; b=OjXLuwA5CjlptJ5HwLwnxIX8dX9cAFxDF0eoO55WAnfvZUh++Hpi7RZgFbvSDZMFQE MBl9Kp9m4t/9+MxDPewvyo5sgpF0+qioE6jRmADHZNahPHui6wuZ1E1sSJx/yro367gK 6uZe6tPLXAZFGo6qMxxYjFkFowGpGO8j4fiAUebSFG4ekgimL9ZZlxUIRla9U78Sd84P 9lfKTrO/xNRipmC5PlmIY4FHbPLM9MV1Mmh20/aXm8eWy757ocr6yGzVqfyp43Wntz1P AGssVP837VtvECHUC1P3WfqP9SB1WtryyszGmo/d+uinwGtkXXaMoTOSQIxOwaMjy+nW G5lw== X-Gm-Message-State: AIVw113JNHSAx+KHJN9VrcfjPm5rkmEx0snh+rDeUjavmSWCOzmQGMYm up3YNeO9vEcKzZ0AOu0vVJAr2SjykeOf X-Received: by 10.84.216.81 with SMTP id f17mr1101670plj.117.1501078598291; Wed, 26 Jul 2017 07:16:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.153.19 with HTTP; Wed, 26 Jul 2017 07:16:37 -0700 (PDT) Received: by 10.100.153.19 with HTTP; Wed, 26 Jul 2017 07:16:37 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 26 Jul 2017 14:16:37 +0000 Message-ID: Subject: Re: Idea for packet numbers To: Magnus Westerlund Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c19a6a8a2026705553918e1" 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, 26 Jul 2017 14:16:41 -0000 --94eb2c19a6a8a2026705553918e1 Content-Type: text/plain; charset="UTF-8" (Going back to the original discussion) Magnus, IIUC, you are asking for a network device to be able to observe packets within a flow. don't understand what the value of encrypting the high order bits is if there are enough low order bits to allow linkability across packets within a flow. After all, the point of encyptimg packet number is to avoid linkability, isn't it? - jana On Jul 20, 2017 3:00 AM, "Magnus Westerlund" wrote: > Hi, > > There has been some discussion around packet numbers. For passive > detection of packet loss in measurements and network management, it would > be really good if the packet numbers where continuous and not only > monotonically increasing. As this enables one to determine losses upstream > of the measurement point. At the same time I understand there are benefits > with being able to introduce gaps into the packet number to test the > receiver's behaviour. > > To enable both of these capabilities I would propose that the N least > significant bits of the packet number are strictly increased by one. Then > one can introduce gaps in the bits above the N ones. Yes, that will burn > through the packet number space faster as the gaps may become larger than > was the case without this. However, I don't see that this will have > significant effect unless the sender introduce gaps very frequently so that > the length of the packet number field needs to be much larger due to the > outstanding sequence number space is much larger. > > The value of N can clearly be discussed but it should be selected so that > reordering and common burst durations are shorter than the time to wrap the > strictly increase amount of bits. If the higher bits are available to > measurement node, some possibility to infer gaps will also be possible. It > might be that N needs to be scaled with throughput with a minimal value. > N=8 would mean 256 packets between wraps. I think that is a reasonable > minimal value. However, that will wrap in 28 ms at 100 mbps of payload > (assuming 1400 bytes of payload per packet). > > So what people think about this idea? > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > --94eb2c19a6a8a2026705553918e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Going back to the original discussion)
=
Magnus,

IIUC, you are asking for a network device to be able to observe= packets within a flow. =C2=A0don't understand what the value of encryp= ting the high order bits is if there are enough low order bits to allow lin= kability across packets within a flow. After all, the point of encyptimg pa= cket number is to avoid linkability, isn't it?
<= br>
- jana
On Jul 20, 2017 3:00 AM, "Magnus Westerlun= d" <magnus.wester= lund@ericsson.com> wrote:
Hi,

There has been some discussion around packet numbers. For passive detection= of packet loss in measurements and network management, it would be really = good if the packet numbers where continuous and not only monotonically incr= easing. As this enables one to determine losses upstream of the measurement= point. At the same time I understand there are benefits with being able to= introduce gaps into the packet number to test the receiver's behaviour= .

To enable both of these capabilities I would propose that the N least signi= ficant bits of the packet number are strictly increased by one. Then one ca= n introduce gaps in the bits above the N ones. Yes, that will burn through = the packet number space faster as the gaps may become larger than was the c= ase without this. However, I don't see that this will have significant = effect unless the sender introduce gaps very frequently so that the length = of the packet number field needs to be much larger due to the outstanding s= equence number space is much larger.

The value of N can clearly be discussed but it should be selected so that r= eordering and common burst durations are shorter than the time to wrap the = strictly increase amount of bits. If the higher bits are available to measu= rement node, some possibility to infer gaps will also be possible. It might= be that N needs to be scaled with throughput with a minimal value. N=3D8 w= ould mean 256 packets between wraps. I think that is a reasonable minimal v= alue. However, that will wrap in 28 ms at 100 mbps of payload (assuming 140= 0 bytes of payload per packet).

So what people think about this idea?

Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Media Technologies, Ericsson Research
-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 = 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----

--94eb2c19a6a8a2026705553918e1-- From nobody Thu Jul 27 06:48: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 AE8EA13201F for ; Thu, 27 Jul 2017 06:48:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 v6y53ZwwEdkL for ; Thu, 27 Jul 2017 06:47:58 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 BD9B8120721 for ; Thu, 27 Jul 2017 06:47:58 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id u207so45049230ywc.3 for ; Thu, 27 Jul 2017 06:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ZZyY3yWcLXrvnNN5QE5oACP3RqNegU+oYtp04dm3AuM=; b=fccaR1/+6gBtGGCjEfBuoNaWqzERULD1mcd5+AQcMzUs6mG9K65AwJ65KSUsNp8ddd VE+Z1jh2eGdYjs+Nh/YCe++ekMqZjyrtrPFm7DTnbVSq1XlrU+JAwLy5q6HkiFeTLZk3 ExWQyOSnTgwutcyQtbU9uPoJLo6TWdTuDzDckPLibp6JVOLtcLg+PFw3tVo0pb6GAsro VqO8XMQqZB846iILYmWVQFPaYhHvg/t7ZhLZAQuFIKbb7k5h/2LEczFk7dxae65aSsO1 D/CtS70FmojZw+QjTumCn8go/iuyxzsTCQf7RBWS7Wk80PybZhaBwPcF+r5ODve31HPy Ba/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:from:date:message-id:subject:to; bh=ZZyY3yWcLXrvnNN5QE5oACP3RqNegU+oYtp04dm3AuM=; b=Ip4ulsZSokMLp/Osw73f/zUxaMouL6aVcoRRaPhitv89kkkCiIr+bKxhm4tKZ0qEXk d+FtWxelrmfVUap4vDrVJshqZccYvr3QvifiP6TaRduEnmPkv9J+jk+VwYt7SxvH2MBo UxWZUbGlauB10lQJBeKNgHtuaF95xgBpItOUT0e0OCr+yzU1DuEm2PsZNDIpx0XSer/z tf98+TbrRXdUEBrwAeAYYvwgLAPjbwRy0dyMwDNgzgY3T3PKz5aAYlrj79U1ZHksLqDf iS204+XdQM1RRj9YePEwjmBtld6rcDcC+rQt1vawBA8pL4RPEK/YtBz5YZKee4FB/HoC KtHA== X-Gm-Message-State: AIVw112Ko1u4sOCcZSqZIi++4beefNYPLAKKyp29acuuFRY6/GDNE6xA NWsuBxMu8t9dz5zdvZGOaCxvuPhlALKirxY= X-Received: by 10.37.212.140 with SMTP id m134mr3608266ybf.256.1501163277705; Thu, 27 Jul 2017 06:47:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Thu, 27 Jul 2017 06:47:17 -0700 (PDT) From: Eric Rescorla Date: Thu, 27 Jul 2017 06:47:17 -0700 Message-ID: Subject: Closing on CONNECTION_CLOSE To: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c07d966eb0ccf05554ccfd1" 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, 27 Jul 2017 13:48:01 -0000 --94eb2c07d966eb0ccf05554ccfd1 Content-Type: text/plain; charset="UTF-8" There have been a number of issues raised about the exact semantics of CONNECTION_CLOSE [0], but we have never really closed on them. As Ryan says, one might have think that CONNECTION_CLOSE is like TCP FIN or like TCP RST. In the FIN-like model: - The closing side sends a CONNECTION_CLOSE - The non-closing side ACKs it - The closing side keeps retransmitting until it gets an ACK or it times out. In the RST-like model: - The closing side sends a CONNECTION_CLOSE - The non-closing side just terminates the connection - The closing side responds to new packets from the non-closing side with a retransmitted CONNECTION_CLOSE (perhaps just a stored packet) for some time. The specification seems kind of vague on this point (there is a big TODO for TIME_WAIT) and in places suggests retransmission [1] I had previously assumed the FIN-like model but after talking to Ian this morning I think the RST-like model is better. It's easier to implement because you don't need to manage a post-close state machine on either side. The only downside I'm really aware of is that the closing side has to keep state for something like 2MSL (so that it can properly respond to late packets), rather than being able to clean up on receiving an ACK. However, this isn't that big a deal, because as noted above, you can throw away the connection and just send a stored packet, or alternately, just send public reset (or just go silent). Given that ID1 does include CONNECTION_CLOSE, albeit with limited semantics, it would be good to resolve this soon. Are there people who want to argue in favor of the FIN-like model? -Ekr [0] https://github.com/quicwg/base-drafts/issues/330 https://github.com/quicwg/base-drafts/issues/328 [1] See also the spec for ID1 which says: "The packet containing a connection close does not need to be retransmitted." --94eb2c07d966eb0ccf05554ccfd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There have been a number of issues raised about the e= xact semantics of
CONNECTION_CLOSE [0], but we have never really = closed on them. As Ryan
says, one might have think that CONNECTIO= N_CLOSE is like TCP FIN or
like TCP RST.=C2=A0

In the FIN-like model:
- The closing side s= ends a CONNECTION_CLOSE
- The non-closing side ACKs it
= - The closing side keeps retransmitting until it gets an ACK or it
=C2=A0 times out.

In the RST-like= model:
- The closing side sends a CONNECTION_CLOSE
- T= he non-closing side just terminates the connection
- The closing = side responds to new packets from the non-closing side
=C2=A0 wit= h a retransmitted CONNECTION_CLOSE (perhaps just a stored packet)
=C2=A0 for some time.

The specification seems kin= d of vague on this point (there is a big
TODO for TIME_WAIT) and = in places suggests retransmission [1] I had
previously assumed th= e FIN-like model but after talking to Ian this
morning I think th= e RST-like model is better. It's easier to implement
because = you don't need to manage a post-close state machine on either
side. The only downside I'm really aware of is that the closing side
has to keep state for something like 2MSL (so that it can properly=
respond to late packets), rather than being able to clean up on<= /div>
receiving an ACK. However, this isn't that big a deal, becaus= e as
noted above, you can throw away the connection and just send= a stored
packet, or alternately, just send public reset (or just= go silent).

Given that ID1 does include CONNECTIO= N_CLOSE, albeit with limited
semantics, it would be good to resol= ve this soon. Are there people who
want to argue in favor of the = FIN-like model?

-Ekr

=
[0] https://github.com/quicwg/base-drafts/issues/330
https://github.com/quicwg/base-drafts/issues/328

[1] See also the spec for ID1 which says:
"The packet containing a connection close does not need to be retrans= mitted."

--94eb2c07d966eb0ccf05554ccfd1-- From nobody Thu Jul 27 06:58: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 E6245131C8F for ; Thu, 27 Jul 2017 06:58:38 -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, RP_MATCHES_RCVD=-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=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 lbqJbTKHrmJf for ; Thu, 27 Jul 2017 06:58:36 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 2BFE7131FF1 for ; Thu, 27 Jul 2017 06:58:36 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id x125so106728299ywa.0 for ; Thu, 27 Jul 2017 06:58:36 -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=caVkbHUZ3ZC+M4VesukI3muXjeOCD+iZbB+UEcb3kdY=; b=HL4VzqkIXhxISc9nibqCwBnkO8hp0HaeT+W//tvhVWAY2xC5tAinvRxaZeBMSWnhDA NoBK9oaCCMFl57JBlim1Q4YK6b8Pcu1BsUeU1HO2p/m/oZYTAeJJfU8YJdjICYpQuUqH yjFlu7R6BzRLnXKNaplaOLe8IPtBBvl7wosdD12qGEVZRpAMVhojw3yE4ash3Vu9aUxd d5DQwSPda9C2A4bfymIIuZMaaBmivvojMzGzlJ37FWyzhmnxCmoIF/J06Db51pn+GqkI 0CZ+cOgj9Ems8KTRq9Utxli2ke1D/aUa2F2RkDlGPha7U/GXwTqgJloA0bzQUasLxJlR 62YA== 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=caVkbHUZ3ZC+M4VesukI3muXjeOCD+iZbB+UEcb3kdY=; b=DEVFtyxIAuyElyrCzlnPZPzw6lhncw+IAJtqMRBXw0zw16T/NGc+dBXVvxXH4wYLH8 FZX69YlSpcKZjbwWczvjIsy8v4WwK9MMrjZrjIXBtVSUx+75oTL73OJp5tGoeFqdxngh XO5jxRnAt+8XKhlTgZ+PxF5qJYEKaKDgds2Ci4KIqPuMx6NyDsbxAn/19h1pnaI39qsx xPg2qVTCBc5ly5+RMApA/odxQyf9/tuKTEpDYtLkGACh9OPJnxX0+fv25NhF+8HWeKRp SlkFhtj8DoGR1F0rLlENXuE8hQ8kOQPUNgWIAuGGo0ya+mR8CXdihOpeGdylTvCK907t gDmA== X-Gm-Message-State: AIVw110peXt9VFFMQ9XRc5o1QZqe1E6xmsZ+Pc6geBeeM9lTzI9uDhAg fwsQ5DQDNr9zsZqebtjYOAi0fsIampgC X-Received: by 10.129.92.3 with SMTP id q3mr3615053ywb.298.1501163915246; Thu, 27 Jul 2017 06:58:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Thu, 27 Jul 2017 06:58:14 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Thu, 27 Jul 2017 09:58:14 -0400 Message-ID: Subject: Re: Closing on CONNECTION_CLOSE To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114d6f02eb9d1105554cf58a" 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, 27 Jul 2017 13:58:39 -0000 --001a114d6f02eb9d1105554cf58a Content-Type: text/plain; charset="UTF-8" Nice summary. As you implied, I favor the RST-like model. And as you stated, it'd be very helpful to specify something soon, since it's about to become an implementation blocker. On Thu, Jul 27, 2017 at 9:47 AM, Eric Rescorla wrote: > There have been a number of issues raised about the exact semantics of > CONNECTION_CLOSE [0], but we have never really closed on them. As Ryan > says, one might have think that CONNECTION_CLOSE is like TCP FIN or > like TCP RST. > > > In the FIN-like model: > - The closing side sends a CONNECTION_CLOSE > - The non-closing side ACKs it > - The closing side keeps retransmitting until it gets an ACK or it > times out. > > > In the RST-like model: > - The closing side sends a CONNECTION_CLOSE > - The non-closing side just terminates the connection > - The closing side responds to new packets from the non-closing side > with a retransmitted CONNECTION_CLOSE (perhaps just a stored packet) > for some time. > > The specification seems kind of vague on this point (there is a big > TODO for TIME_WAIT) and in places suggests retransmission [1] I had > previously assumed the FIN-like model but after talking to Ian this > morning I think the RST-like model is better. It's easier to implement > because you don't need to manage a post-close state machine on either > side. The only downside I'm really aware of is that the closing side > has to keep state for something like 2MSL (so that it can properly > respond to late packets), rather than being able to clean up on > receiving an ACK. However, this isn't that big a deal, because as > noted above, you can throw away the connection and just send a stored > packet, or alternately, just send public reset (or just go silent). > > Given that ID1 does include CONNECTION_CLOSE, albeit with limited > semantics, it would be good to resolve this soon. Are there people who > want to argue in favor of the FIN-like model? > > -Ekr > > > [0] https://github.com/quicwg/base-drafts/issues/330 > https://github.com/quicwg/base-drafts/issues/328 > > [1] See also the spec for ID1 which says: > "The packet containing a connection close does not need to be > retransmitted." > > --001a114d6f02eb9d1105554cf58a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nice summary.=C2=A0 As you implied, I favor the RST-like m= odel.=C2=A0=C2=A0

And as you stated, it'd be very he= lpful to specify something soon, since it's about to become an implemen= tation blocker.

On Thu, Jul 27, 2017 at 9:47 AM, Eric Rescorla = <ekr@rtfm.com><= /span> wrote:
There= have been a number of issues raised about the exact semantics of
CONNECTION_CLOSE [0], but we have never really closed on them. As Ryan
says, one might have think that CONNECTION_CLOSE is like TCP FIN or<= /div>
like TCP RST.=C2=A0

In th= e FIN-like model:
- The closing side sends a CONNECTION_CLOSE
- The non-closing side ACKs it
- The closing side keeps re= transmitting until it gets an ACK or it
=C2=A0 times out.

In the RST-like model:
- The clo= sing side sends a CONNECTION_CLOSE
- The non-closing side just te= rminates the connection
- The closing side responds to new packet= s from the non-closing side
=C2=A0 with a retransmitted CONNECTIO= N_CLOSE (perhaps just a stored packet)
=C2=A0 for some time.

The specification seems kind of vague on this point (t= here is a big
TODO for TIME_WAIT) and in places suggests retransm= ission [1] I had
previously assumed the FIN-like model but after = talking to Ian this
morning I think the RST-like model is better.= It's easier to implement
because you don't need to manag= e a post-close state machine on either
side. The only downside I&= #39;m really aware of is that the closing side
has to keep state = for something like 2MSL (so that it can properly
respond to late = packets), rather than being able to clean up on
receiving an ACK.= However, this isn't that big a deal, because as
noted above,= you can throw away the connection and just send a stored
packet,= or alternately, just send public reset (or just go silent).

=
Given that ID1 does include CONNECTION_CLOSE, albeit with limite= d
semantics, it would be good to resolve this soon. Are there peo= ple who
want to argue in favor of the FIN-like model?
<= br>
-Ekr

[0] https://= github.com/quicwg/base-drafts/issues/330
https://git= hub.com/quicwg/base-drafts/issues/328

[1]= See also the spec for ID1 which says:
"The packet containin= g a connection close does not need to be retransmitted."

--001a114d6f02eb9d1105554cf58a-- From nobody Thu Jul 27 07:03: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 53CA9131C84 for ; Thu, 27 Jul 2017 07:03:01 -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 ykkNbf11aQXu for ; Thu, 27 Jul 2017 07:02:54 -0700 (PDT) Received: from mx3.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.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 9A1E6129AAD for ; Thu, 27 Jul 2017 07:02:54 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dajNL-0003Bq-WC for quic@ietf.org; Thu, 27 Jul 2017 16:02:52 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dajNA-0005l4-Ar for quic@ietf.org; Thu, 27 Jul 2017 10:02:48 -0400 Received: (qmail 15003 invoked from network); 27 Jul 2017 14:02:38 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Jul 2017 14:02:38 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: Date: Thu, 27 Jul 2017 07:02:33 -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: 7bit Subject: Re: Closing on CONNECTION_CLOSE 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.13) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA230RZZs4/9QcLi/nb/GoFpMYHT3azp2ACbWz9H GkpW4x2Rhg1jI9Z2IBQudfbmwAKvYOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyUbiNBtPa+nnaSOBS8xTQyHeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj237jnExji3pN9ZwHGBHd3j58WezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6+ln3SmdyWNNJvR4I+Hp8ZTqmtKYOlQxywq7X9AiLTGhCJj2HZv393lVD HgpaAy7e7ySyMjvCXUn/XipQj8shABklgDtVC2Xqa4QCRhTuoCmXPUJkXUk8tGhJsBnmMDbaKcNO SCytRyeT1c4b6jF7f/DKzfOCXnJQjcl9DhaIFtyqmgfXlC5BKKIliXyEzbMHRIbZK0lCbLYw/2Y2 Z+15FA== 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, 27 Jul 2017 14:03:01 -0000 On 7/27/2017 6:47 AM, Eric Rescorla wrote: > The specification seems kind of vague on this point (there is a big > TODO for TIME_WAIT) and in places suggests retransmission [1] I had > previously assumed the FIN-like model but after talking to Ian this > morning I think the RST-like model is better. It's easier to implement > because you don't need to manage a post-close state machine on either > side. The only downside I'm really aware of is that the closing side > has to keep state for something like 2MSL (so that it can properly > respond to late packets), rather than being able to clean up on > receiving an ACK. However, this isn't that big a deal, because as > noted above, you can throw away the connection and just send a stored > packet, or alternately, just send public reset (or just go silent). > > Given that ID1 does include CONNECTION_CLOSE, albeit with limited > semantics, it would be good to resolve this soon. Are there people who > want to argue in favor of the FIN-like model? Yes the text is vague. My ID1 code implements the RST behavior -- immediate close on receipt, no ACK. It seemed natural. I have yet to implement a proper zombie state, but that would be needed whether we want the RST or FIN semantic, since FIN packets can be lost. RST behavior is cleaner there: repeat the RST frame if packets are still received after some timeout. -- Christian Huitema From nobody Thu Jul 27 07:09: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 D919B131A4F for ; Thu, 27 Jul 2017 07:09:03 -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=Zo7jikaE; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iX+62w5W 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 ZU77tiObUdYA for ; Thu, 27 Jul 2017 07:09:02 -0700 (PDT) Received: from mx0b-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 30E12131C3C for ; Thu, 27 Jul 2017 07:09:02 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6RE8oYL021194; Thu, 27 Jul 2017 07:08:55 -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=97zpydG5fy06goRxynS7qqK/9UJvh49EgV0g4iLfQe8=; b=Zo7jikaEq1p85XjiJ+4wfYO/REQeaTF3/SBLqFUNhwYyHSDTS9RLtnshGPh1h5PoFu5u nGVEiwezAduHSKcMUjuohJ8GDp0fTUx7tt1Zts38ADurASbczj2oeWsxH1kta3MXmvdx HjFNmrGjn8FddTSU7uW03uhIzS29xF/uqyM= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2bydmerph9-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jul 2017 07:08:55 -0700 Received: from NAM01-BY2-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, 27 Jul 2017 10:08:54 -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=97zpydG5fy06goRxynS7qqK/9UJvh49EgV0g4iLfQe8=; b=iX+62w5WE3hKa8AE98/rZwbgt/UexOsMGNzcouIOHhjuAVCo0dNqtzjmbEuun4seDduFxqZJvnoEQmx8x2PFeYGGbM+/iK+GR8HRbAvbUfHt4LYxkthunDwmH6ytqFQ7vHsh6hwreCGPaZe8lMIH3yDKWhCSbqpxZDVgH5hZFU8= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Thu, 27 Jul 2017 14:08:33 +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.01.1282.021; Thu, 27 Jul 2017 14:08:33 +0000 From: Subodh Iyengar To: Christian Huitema , "quic@ietf.org" Subject: Re: Closing on CONNECTION_CLOSE Thread-Topic: Closing on CONNECTION_CLOSE Thread-Index: AQHTBt8BY44EN83ZV0KhVSU38MiR6aJntD6AgAAAgeM= Date: Thu, 27 Jul 2017 14:08:33 +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: [2620:10d:c091:200::ba12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 20:wvkQfN6GVdPpQrsgyyH5QnzbL4/KlXwV4HRBJZEVNPVM3iI/2DhbN6aWujlMgfCRi2DpmHvMO5G594i2EjG8Sm8qO1UehRZxQAKMY5BHT2lBUCU+apDThXrWGewx6IMWIs8m76yKfxpTSwis7KU2Sa1lXgkG68w1PNxYahEjQt8= x-ms-office365-filtering-correlation-id: a2186885-4978-42f5-fe71-08d4d4f8f761 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1456; x-ms-traffictypediagnostic: MWHPR15MB1456: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1456; x-forefront-prvs: 03818C953D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39400400002)(39850400002)(39410400002)(24454002)(199003)(189002)(377454003)(53546010)(3660700001)(8676002)(8936002)(2906002)(81166006)(81156014)(5660300001)(6436002)(9686003)(7696004)(25786009)(54896002)(99286003)(55016002)(6246003)(53936002)(86362001)(102836003)(7116003)(3280700002)(6116002)(189998001)(7736002)(97736004)(2950100002)(2900100001)(478600001)(14454004)(229853002)(38730400002)(77096006)(2501003)(101416001)(68736007)(6506006)(105586002)(76176999)(54356999)(33656002)(50986999)(106356001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.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_MWHPR15MB14558B64A6166EB2C3E66F03B6BE0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2017 14:08:33.1423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 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-07-27_07:, , 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, 27 Jul 2017 14:09:04 -0000 --_000_MWHPR15MB14558B64A6166EB2C3E66F03B6BE0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The only downside I'm really aware of is that the closing side has to keep state for something like 2MSL (so that it can properly respond to late packets), rather than being able to clean up on receiving an ACK I favor the RST model as well. You'll end up having to keep a loss timeout even in the FIN model because of ACKs being lost / the remote side shutting for unrelated reasons / silen= tly closing their connection. However what is the right response to late packets? The only response I can= think of is to resend the connection close if you still have the connection state. I= s there anything else that could be sent that I'm missing? As an aside on the topic of TIME_WAIT itself: The reason I'm aware that TIME_WAIT exists in TCP is to protect us from the= local port being re-bound to another connection and the data from the old connection i= nterfering with the new connection. With QUIC this seems less of an issue though because a combination of (connection id + packet type + packet encryption) can be use= d to determine whether or not the packet was valid to be received in the context of a new connection.= Going with the philosophy of dropping packets on the floor that are malformed that martin = proposed during the last WG meeting, do we even need a TIME_WAIT state in QUIC? The advantage of TIME_WAIT that I see is this ability to send the CONNECTIO= N_CLOSE in a timely manner to prevent the client from needing to retry till the RTO limit and r= ealize the connection needs to be closed. However if we go with the close model of graceful close= always driven by the app, then this won't be a common case and we might deliver a PUBLIC RESET instead of = a CLOSE. Subodh ________________________________ From: QUIC on behalf of Christian Huitema Sent: Thursday, July 27, 2017 7:02:33 AM To: quic@ietf.org Subject: Re: Closing on CONNECTION_CLOSE On 7/27/2017 6:47 AM, Eric Rescorla wrote: > The specification seems kind of vague on this point (there is a big > TODO for TIME_WAIT) and in places suggests retransmission [1] I had > previously assumed the FIN-like model but after talking to Ian this > morning I think the RST-like model is better. It's easier to implement > because you don't need to manage a post-close state machine on either > side. The only downside I'm really aware of is that the closing side > has to keep state for something like 2MSL (so that it can properly > respond to late packets), rather than being able to clean up on > receiving an ACK. However, this isn't that big a deal, because as > noted above, you can throw away the connection and just send a stored > packet, or alternately, just send public reset (or just go silent). > > Given that ID1 does include CONNECTION_CLOSE, albeit with limited > semantics, it would be good to resolve this soon. Are there people who > want to argue in favor of the FIN-like model? Yes the text is vague. My ID1 code implements the RST behavior -- immediate close on receipt, no ACK. It seemed natural. I have yet to implement a proper zombie state, but that would be needed whether we want the RST or FIN semantic, since FIN packets can be lost. RST behavior is cleaner there: repeat the RST frame if packets are still received after some timeout. -- Christian Huitema --_000_MWHPR15MB14558B64A6166EB2C3E66F03B6BE0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

--_000_MWHPR15MB14558B64A6166EB2C3E66F03B6BE0MWHPR15MB1455namp_-- From nobody Thu Jul 27 07: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 16060131C96 for ; Thu, 27 Jul 2017 07:13:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 qs-IvUgQdYz6 for

--94eb2c19a6a8b84b9105554e517f-- From nobody Thu Jul 27 08:48: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 DC298131CB3 for ; Thu, 27 Jul 2017 08:48:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 paSOXOB3XmUA for ; Thu, 27 Jul 2017 08:48:39 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 326E412EC4B for ; Thu, 27 Jul 2017 08:48:39 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id x125so108799862ywa.0 for ; Thu, 27 Jul 2017 08:48:39 -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=7+StB1fMeY2nj3u4pYODy+luhZisRjikUpZkA/pnzLA=; b=pzAFnO1POGHZiz6pcfe6qR+vASU0SKaIZISmyUAkuIa/syTlT8gOH3f6yHHMK3hAwM msBs64Nz9T1ry42mTXOzIAIGQHG3UEvOn7zGKg1pHJnz1jM9XrJFFJZH5ndjMDWyu6R8 SUJcm1p5oIQommqabnC0nXO+VCuBzoSPtVu/KUXLL6k+EmwzVD7oJxxti1QnRFdUIh7R kWxsbWaFH9bbD0oigwjSNTDLkQ6RjNV3xcl6T1qyVkY7ueQuf97wJVoX92VChPR9JIZ7 2REYWzxiHybspW3A2QRCAlkZazEjBxBWVktF1u1BAzgvMvSfFk8+oAKuxd4VJ+77nDSV +k/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=7+StB1fMeY2nj3u4pYODy+luhZisRjikUpZkA/pnzLA=; b=sFg+RatTQwJqa3oxGZUskamT/1xTQ0Puu99rvVLht0PKKbdP0kV2cksZoentHfMzvR JnRT2pwQaq9c55ErvktayqChhH3/Vsog4h7dQLGLdmhfRMnAcGjaBNYaeIuVElStlDGX u35oP7N/pQVYT4mVPTkD/v4agwW/EzRfXyDLLljqn7MP4mrSujgUV9ihVKhd2coJnrDQ pLJs3BmdXyLm4q7gBpbyLxZISCNl0eESoJQWa+ER52mklCmtrdk28Lhx7Yy1TnMOQJ/M se690sCFVDwNVrXkMhp4DI8GvWYN4HwfZuQmeJlgV8HJT3cpqYYV9MEaTsug8OBInjS4 rnzQ== X-Gm-Message-State: AIVw110MXx05bW54sWT3EHeCk8kTTLArLWLLf/bgHNtmpKUgpV/l8c4j bYT4WuzUkR+K1FVVutSObUNTbe2yGBrx X-Received: by 10.37.248.12 with SMTP id u12mr4049489ybd.248.1501170518297; Thu, 27 Jul 2017 08:48:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Thu, 27 Jul 2017 08:47:57 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 27 Jul 2017 08:47:57 -0700 Message-ID: Subject: Re: Closing on CONNECTION_CLOSE To: Jana Iyengar Cc: IETF QUIC WG , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Ian Swett , Christian Huitema Content-Type: multipart/alternative; boundary="f403045db8667dc44005554e7f81" 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, 27 Jul 2017 15:48:42 -0000 --f403045db8667dc44005554e7f81 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 27, 2017 at 8:35 AM, Jana Iyengar wrote: > I'm also in favor of the RST model. Subodh -- to your point about > time_wait, this dovetails with a timeout we need to have in place for > regular connection close, where we must allow for retransmissions to be > sent and for responses to peer's retransmissions. (It's what I call > DRAIN_TIME). > > So basically, once a connection close is sent, the sender waits for > DRAIN_TIME and then discards state. The receivers sends an ack and > immediately discards state on receipt. > Jana, I'm finding myself a bit confused. Can you perhaps draw me a diagram of what you mean when you say "allow for retransmissions to be sent"...? -Ekr > As ekr notes, receipt of this ack could circumvent the DRAIN_TIME timeout. > TCP time wait accounts for network lifetime of packets, which we don't have > to handle, since once both sides are torn down, there's no danger of an old > connection interfering with a new one. That said, I'm still thinking about > if it's possible for an old packet circling the network to create > connection state when received after all state is torn down... If we want > to ensure that doesn't happen, we'd want to account for network lifetime (2 > msl). > > On Jul 27, 2017 7:59 AM, "Eric Rescorla" wrote: > >> I just filed a PR for this at: >> https://github.com/quicwg/base-drafts/pull/705 >> >> It explicitly permits duplication. >> >> -Ekr >> >> >> On Thu, Jul 27, 2017 at 7:51 AM, Ian Swett wrote: >> >>> I would recommend sending an identical packet every time, since there's >>> no value to encrypting a new one with a new packet number, but it increases >>> the amount of state you have to keep and the CPU to respond to spurious >>> packets. >>> >>> On Thu, Jul 27, 2017 at 10:47 AM, Swindells, Thomas (Nokia - >>> GB/Cambridge, UK) wrote: >>> >>>> > > However, this isn't that big a deal, because as >>>> > > noted above, you can throw away the connection and just send a >>>> stored >>>> > > packet, or alternately, just send public reset (or just go silent). >>>> Should/would you have to generate a newly encrypted packet with a new >>>> packet number each time (as per other retransmissions)? >>>> Or is this a special case because it is the final packet and so doesn't >>>> matter if it is duplicated? >>>> >>>> >>> >> --f403045db8667dc44005554e7f81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jul 27, 2017 at 8:35 AM, Jana Iyengar <jri@google.com> wrote:
I'm also= in favor of the RST model. Subodh -- to your point about time_wait, this d= ovetails with a timeout we need to have in place for regular connection clo= se, where we must allow for retransmissions to be sent and for responses to= peer's retransmissions. (It's what I call DRAIN_TIME).

So basically, once a connection close is = sent, the sender waits for DRAIN_TIME and then discards state. The receiver= s sends an ack and immediately discards state on receipt.

Jana,

I'm finding m= yself a bit confused. Can you perhaps draw me a diagram of what you mean wh= en
you say "allow for retransmissions to be sent"...?

-Ekr

As ekr= notes, receipt of this ack could circumvent the DRAIN_TIME timeout. TCP ti= me wait accounts for network lifetime of packets, which we don't have t= o handle, since once both sides are torn down, there's no danger of an = old connection interfering with a new one. That said, I'm still thinkin= g about if it's possible for an old packet circling the network to crea= te connection state when received after all state is torn down... If we wan= t to ensure that doesn't happen, we'd want to account for network l= ifetime (2 msl).

On Jul 27, 2017 7:59 AM,= "Eric Rescorla" <ekr@rtfm.com> wrote:
I just filed a PR for this at:
https= ://github.com/quicwg/base-drafts/pull/705

=
It explicitly permits duplication.

-Ekr
=

On Thu, Jul 27, 2017 at 7:51 AM, Ian Swett <ianswett@google.com&= gt; wrote:
I woul= d recommend sending an identical packet every time, since there's no va= lue to encrypting a new one with a new packet number, but it increases the = amount of state you have to keep and the CPU to respond to spurious packets= .

On Thu, Jul 27, 2017 at 10:47 AM, = Swindells, Thomas (Nokia - GB/Cambridge, UK) <thomas.swindells@n= okia.com> wrote:
&g= t; > However, this isn't that big a deal, because as
> > noted above, you can throw away the connection and just send a st= ored
> > packet, or alternately, just send public reset (or just go silent= ).
Should/would you have to generate a newly encrypted packet with a ne= w packet number each time (as per other retransmissions)?
Or is this a special case because it is the final packet and so doesn't= matter if it is duplicated?

--f403045db8667dc44005554e7f81-- From nobody Thu Jul 27 12:49:12 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 7D7A7129B2A for ; Thu, 27 Jul 2017 12:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, 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 H1OhSimK8XnL for ; Thu, 27 Jul 2017 12:49:08 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 33D5E126CD6 for ; Thu, 27 Jul 2017 12:49:08 -0700 (PDT) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) by linode64.ducksong.com (Postfix) with ESMTPSA id A27F73A01B for ; Thu, 27 Jul 2017 15:49:06 -0400 (EDT) Received: by mail-qt0-f179.google.com with SMTP id 16so29058805qtz.4 for ; Thu, 27 Jul 2017 12:49:06 -0700 (PDT) X-Gm-Message-State: AIVw110QMqNR+QSJDqEw5hSvYrZfeUDSslrNFexKjtwI2THJ6jKrHoM6 bmHZh3uA0l+yWFHJBWAIc7MrR55auw== X-Received: by 10.237.49.194 with SMTP id 60mr7137543qth.73.1501184946436; Thu, 27 Jul 2017 12:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.182.17 with HTTP; Thu, 27 Jul 2017 12:49:05 -0700 (PDT) From: Patrick McManus Date: Thu, 27 Jul 2017 15:49:05 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Issue push id To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114f6764797fce055551dbd5" 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, 27 Jul 2017 19:49:11 -0000 --001a114f6764797fce055551dbd5 Content-Type: text/plain; charset="UTF-8" re https://github.com/quicwg/base-drafts/pull/701/ which is meant to close issues 281 and 702. Basically a big thumbs up - but they're all marked design issues so I wanted to make sure to make a list comment about the PR. In general I think when QUIC transport stream IDs show up as copied information into http level frames (or worse - applications using quic) we've probably made a mistake. So this push-id-label is great. -P --001a114f6764797fce055551dbd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
re https://github.com/quicwg/base-drafts/pull/701/ which is mean= t to close issues 281 and 702.

Basically a big thu= mbs up - but they're all marked design issues so I wanted to make sure = to make a list comment about the PR. In general I think when QUIC transport= stream IDs show up as copied information into http level frames (or worse = - applications using quic) we've probably made a mistake. So this push-= id-label is great.

-P
=C2=A0
--001a114f6764797fce055551dbd5-- From nobody Thu Jul 27 16:22: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 9D14C129AA0 for ; Thu, 27 Jul 2017 16:22:18 -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 zhTi-ODQnoXN for ; Thu, 27 Jul 2017 16:22:16 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 8235C12ECBD for ; Thu, 27 Jul 2017 16:22:16 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v205so3776737itf.1 for ; Thu, 27 Jul 2017 16:22:16 -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=VH7nsgTPJOoacWtqPHUF4rExGq600WFycEOptnCrZ3s=; b=oiRqfZTC57F4NNPIVqX3JVFGZt4Q2PPk1dzrWUuaZvUyzrNZVf8kG9onC9xtP6pvfN IkSOQN4e4anGXNaYb/qBdEUQfEFtH2jxSErBm1tlWvpxO0fHjf0Rg2Fd5+k/3v8hXLnn hzlENJiWFD6FFafVuDMjuPCBsZwajEBOYCQooCHjmSbWNxLwpRoFLGlfRcGKSfJSnElw kraWHvZEFs9UXrczOCY0LIXh59cug5uD3R3gBjZk6w1te+oiZVx4iz+6zp5y7viuXJV9 A/skmufd4rxnPjeHXU5IKDuqzvDkwL6RaLqj9pFySJSbhtym5YJRMlXunQZCdGlNRwap Hc/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=VH7nsgTPJOoacWtqPHUF4rExGq600WFycEOptnCrZ3s=; b=C0sz+A0qfswJ/drKCpXp+JeEhPZS2YRorkYqL6S7WnZz7WIk0ksl7mby8Qfq0SyPB8 6hPAwdYs6+tN5puEvAZTw7mu91UBkHtADVXOcc9vcZBJUUvkCpzbsVhzkEWhPYcEFJe4 U/PRPg5VyIArbVma6tdQqZ3Ostr0/ZZaIFef5nO/bt2R4jXds2uROejKgewS4vex/OL9 X5JKv/1JaIObRRmvGszgtTvvweXuS4Pe/VT8arU8Jlvshr7ydWzAFbhktpvG/7he9WjB EGlJJe+tX/D1gDW1fSCjabpyU619JeP+KvqRWpPIBsGAH3BC/Zyz8ubC8E5+lpbjw11V LGLA== X-Gm-Message-State: AIVw1104+58Jl2jmWOU89RYWfbA6bJm1VSwVuGsQ75o1WEj9PD7g7ydW 6nBFauFCFb9aco9e2W6dA7971FLZw2aD X-Received: by 10.36.5.68 with SMTP id 65mr7246585itl.140.1501197735877; Thu, 27 Jul 2017 16:22:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 27 Jul 2017 16:22:15 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 28 Jul 2017 09:22:15 +1000 Message-ID: Subject: Re: Issue push id To: Patrick McManus Cc: 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, 27 Jul 2017 23:22:19 -0000 Ahh, you beat me to it. I ran out of time yesterday to do the list announcement. Yes, we discussed this briefly in Prague and the feedback I got was that people wanted to see a PR for describing how to identify pushes other than by stream ID. This is that PR. In the write-up I did, I point out that this allows you to promise the same thing multiple times and fulfill all those promises just once. This is somewhat novel. I'd like to understand if people are willing to accept this particular trade-off. On 28 July 2017 at 05:49, Patrick McManus wrote: > re https://github.com/quicwg/base-drafts/pull/701/ which is meant to close > issues 281 and 702. > > Basically a big thumbs up - but they're all marked design issues so I wanted > to make sure to make a list comment about the PR. In general I think when > QUIC transport stream IDs show up as copied information into http level > frames (or worse - applications using quic) we've probably made a mistake. > So this push-id-label is great. > > -P > From nobody Fri Jul 28 05:32: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 83C3A131FF0 for ; Fri, 28 Jul 2017 05:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] 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 gxP841FPVQag for ; Fri, 28 Jul 2017 05:32:16 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 8E664131C28 for ; Fri, 28 Jul 2017 05:32:16 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id p3so76104107qtg.2 for ; Fri, 28 Jul 2017 05:32:16 -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:in-reply-to:user-agent; bh=EYXPCGxURtoU019aAo9a3nsydQNHha2HytP0C1Z9L7w=; b=xqb4b7ehDngUyXh1qFI1kuCyavNFNTFo/AKW82QJq8dO/a4N+Tbt9fKgPJ4SQzAZo8 sh2WITMmtrgJR55zhewlFdxND5nm5Hoy+G58zjIWJ6thAgcH2D0wGkBsTtbCAcHzslrx Xnr3a83Mu2f8UqrS0Mz/Rd1ep98HX2mBl6WMXHBMZjdifgtAJtiDfa+d/ZxtqeRIpdud ILCXIbsILLMxYD2QwD9ZKI50l3I1tgHEdSWvnvZCNJEOVFsVuXpEl0dwm6Sb/rAIiH6W EbFhrCHuFvbPwbzwEgoXhTgHFc/9S8KOuBm1lqlhB6Rh8mmezZb8FCw+zFY+Bwa6yFHe 46cg== 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:in-reply-to:user-agent; bh=EYXPCGxURtoU019aAo9a3nsydQNHha2HytP0C1Z9L7w=; b=C3Q136goSu8M0mBGXD0OHqukiazXwjvOLNqaFe+PENiUVxWEEo81h95R7GQSM8mLsI 9nmb2hXebWdnjpd0J/xFVDPUG022DyL6gKj3LFIQIDpu/MQF984Rmk4gEaI9hQilxlHW LnbzJ6iT6947uJv1i4nhg2THgMr8rpAnGjJF9L2/VFhzlaD/xUT+tjY+irHXP486hjYR OvKFcmzv4AiJt2gx7Gyh4riRPDMwxlRN/o+wRav7GUTP9aXb5F/Axct2czqZICXTDX4i NtiNF5D+RvgTXgbtBeIXTmreF84oGqJc6dflwOlcGjyY2boU8qFyqCkH9Gq5oDJODm/Q fGAQ== X-Gm-Message-State: AIVw113dqI2jPeqMgOCfk2dk/RWhO/S1pkrkIZa9P1nf2KoeLFm7yW5R /8n2yHWACuALwRt8 X-Received: by 10.200.13.130 with SMTP id s2mr10017737qti.287.1501245135595; Fri, 28 Jul 2017 05:32:15 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id u3sm15956031qth.95.2017.07.28.05.32.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 05:32:15 -0700 (PDT) Date: Fri, 28 Jul 2017 08:32:08 -0400 From: Dmitri Tikhonov To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Magnus Westerlund , IETF QUIC WG Subject: Re: Idea for packet numbers Message-ID: <20170728123208.GA2686@ubuntu-dmitri> References: <20170721093732.GA31705@ubuntu-dmitri> <20170725124109.GA1764@ubuntu-dmitri> <20170725162701.GA4414@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Fri, 28 Jul 2017 12:32:18 -0000 On Wed, Jul 26, 2017 at 09:27:19AM +0000, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: > > > to do that would be to give the ack packet a higher packet number but > > > then send it before lower marked packets - even potentially if they do > > > also contain ack frames. > > > > That is a good approach if it does not break packet number derivation. > > I am not sure whether it can... The draft says: > > > > " A packet number is decoded by finding the packet number > > " value that is closest to the next expected packet. > > > > Thus, after receiving ACK packet with large gap, which is the next expected > > packet number from the point of view of the peer? > > The spec says that you should give plenty of room in the number space, > so as long as you haven't reached half your number space across that > period this should be extremely rare or perhaps impossible. The worst > case is that if you do violate it then either you may be requested to > retransmit some packets, or you just send the original packets first > and then the ack. OK -- this should work. I'd have to work out the math to prove it to myself, though. :) > > > For RST_STREAM I think it is permitted that currently queued packets > > > are still sent, but if they only contain that streams packets then it > > > is a beneficial optimization if they weren't sent (leaving packet > > > number gaps). > > > > Current draft says: > > > > " An endpoint that receives a RST_STREAM frame (and which > > " has not sent a FIN or a RST_STREAM) MUST immediately > > " respond with a RST_STREAM frame, and MUST NOT send any > > " more data on the stream. > > > > I suppose one could interpret "send" to mean "enqueue," but I would err on > > the side of caution. > > With a basic integration between an application and quic stack the > api would likely just be the application writing a load of data onto > a stream which then gets multiplexed into a quic connection. In this > case the application view would be once it has written it to the > stream it is being 'sent' - in the same way the assumption is held for > TCP transmission. Packetization and enqueuing for transmission would > therefore be considered part of the sending process and with that API > it would seem to be fair to send queued data but not allow new writes > from the application. Sure, I agree -- I was not talking about the application level at all, just the QUIC layer. The application should not be in the business of sending RST_STREAM frames. > Assuming no re-encryption/packetization, that is pretty much all you > can do if packets contain data from multiple stream frames anyway. If one assumes that, then yes. > The "immediately respond with a RST_STREAM" perhaps then needs to be > read as: "immediately, after any pending packets have been transmitted, > such that no new packets with data from that stream are generated with > a higher packet number than the RST_STREAM response frame."? Not unless the "MUST NOT" in the quoted draft paragraph above be changed to "SHOULD NOT:" An eager implementation may check whether its peer has sent stream data after receiving RST_STREAM (which it would know by the] ACK frame) and terminate the connection. - Dmitri. From nobody Fri Jul 28 05:50: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 18652132133 for ; Fri, 28 Jul 2017 05:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] 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 wTe5xIaUZM9z for ; Fri, 28 Jul 2017 05:49:54 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 6B27113212A for ; Fri, 28 Jul 2017 05:49:54 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id u139so56498341qka.1 for ; Fri, 28 Jul 2017 05:49:54 -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:in-reply-to:user-agent; bh=W4nO6/3aw7YCTu6bTw0mnPjfLHMwHCe1LF1ZN2Vqb7o=; b=ROee5jTC7peFWwxtl7KSfUpLJ7n8nHVvlojboUsgmRbTTh74XGMQHiXKkHNTeDpORW 5kP026LHiV9oTJBLfp48vi4zpf1pX/uC3flIQzkLnHERyGsRB4gbqBg2QT/cfOCrXALi oqWQMkBzF8flzF3FMHbzFIolw00p6gxleqYzigQN5pBpTSBM9yoYMIsdCPbaeuH7d8OM yvBe7WjzRZRg/PgXP+N+9FhDdSONuXq47bRIfctu8P2XrncTfVz/7Cw1cUNK29BLAJAT YCttFuKFs3eCDZs1s+dbOLCh6uiIR+gH7wKF1BrmPgWsUzWsOGmtDVyTNv6VHAzbwsgx 7RvQ== 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:in-reply-to:user-agent; bh=W4nO6/3aw7YCTu6bTw0mnPjfLHMwHCe1LF1ZN2Vqb7o=; b=fvWhSHQgLaAltiIW9JVK4HzY3GObjMQPMXKdMrpU9bWx2i0fmbXaWndwfd68JkAdYd GA02IMHuFAwDl02hMwsNN9ov3ilBGzcxr3lEcNbNN3dyH8u55l8yZLq8UW0hAV9MsBGD Be/qBX2CCn0RIk39Q8TOP0s18VszZ/w5uFCjC91/2QR60J235pF166uHuG39P53q6TlA NQ4Ds9HH2/+Fbd1eLeXbhozX21JKDRa9ti8g7CE71RYP0nZpNA30BU8TgBZeJd7Itw02 K0rcaXTy5NjglQHm5y/WJrNKRHpxXJ+/+mDTWdqLdXEtLxFacwrdLQPcxZlBVV+R1mPp JIUg== X-Gm-Message-State: AIVw113nT8/ayLROpkGUNUO/vvgN1HYeL6qEv/TWdywZwjbCLEE8omAP ZHEh+iSSosqipOZh X-Received: by 10.55.179.4 with SMTP id c4mr10404267qkf.7.1501246193609; Fri, 28 Jul 2017 05:49:53 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id c3sm6788367qtc.65.2017.07.28.05.49.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 05:49:52 -0700 (PDT) Date: Fri, 28 Jul 2017 08:49:51 -0400 From: Dmitri Tikhonov To: Jana Iyengar Cc: Eric Rescorla , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , IETF QUIC WG , Christian Huitema , Ian Swett Subject: Re: Closing on CONNECTION_CLOSE Message-ID: <20170728124951.GB2686@ubuntu-dmitri> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Fri, 28 Jul 2017 12:49:56 -0000 On Thu, Jul 27, 2017 at 03:35:49PM +0000, Jana Iyengar wrote: > That said, I'm still thinking about if it's possible for an old packet > circling the network to create connection state when received after > all state is torn down... If we want to ensure that doesn't happen, > we'd want to account for network lifetime (2 > msl). Unlikely, because version negotiation occurs when new connection is established and thus first few incoming packets would have to have the VERSION bit set: " A QUIC connection begins with a client sending a handshake packet. The " details of the handshake mechanisms are described in {{handshake}}, " but all of the initial packets sent from the client to the server " MUST use the long header format and MUST specify the version of the " protocol being used. - Dmitri. From nobody Fri Jul 28 08:19: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 8B64B131D9F for ; Fri, 28 Jul 2017 08:19:00 -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_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=fb.com header.b=BY2jGT0I; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ZKlQp8QE 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 OGAyalt2ewpv for ; Fri, 28 Jul 2017 08:18:59 -0700 (PDT) Received: from mx0b-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 DA1F3129AB2 for ; Fri, 28 Jul 2017 08:18:58 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6SFEetD009793 for ; Fri, 28 Jul 2017 08:18:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=RZa1NRoFVfTWAAyySFzzF+ZJM9sXb+imd4puPstbbNs=; b=BY2jGT0IbZmbEkxAK3NG2Xv0gJUYyiCwFpBOxe1VVLAQV5tyvmTskrOTKGbEg4HB5peX t/dJjYoUPJ6yPVtiF8guKYIpYjGui5v+RwjiByG203uqgfCnAmPtCjo8+CeAsJ/p80Nc ubz1fWG4p4egBGs9+AjrNxZQBvzcK5B7f0c= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2bywfvj6da-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Jul 2017 08:18:56 -0700 Received: from PRN-CHUB02.TheFacebook.com (192.168.16.12) by PRN-CHUB11.TheFacebook.com (192.168.16.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Jul 2017 08:18:55 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Jul 2017 08:18:54 -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=RZa1NRoFVfTWAAyySFzzF+ZJM9sXb+imd4puPstbbNs=; b=ZKlQp8QEO53gvq7unVPNGXjHOeOMksiFxn6wEkJYt2QSRSWU2C4ddoL0DJhUy0V6HENtzE9Y7EhzME8BwKYR/rvyczBj56YjvO/Oy91eirMXYYJFlatfaf/gL25nHRo0v6PV1kYZS1m+94IDnqhnwQHV1n8gJvyCZksdCFlE66Q= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1453.namprd15.prod.outlook.com (10.173.234.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Fri, 28 Jul 2017 15:18:52 +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.01.1282.023; Fri, 28 Jul 2017 15:18:51 +0000 From: Subodh Iyengar To: "quic@ietf.org" Subject: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFg== Date: Fri, 28 Jul 2017 15:18:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c091:200::3:b081] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1453; 20:4NU5Kgd9bFYn0jpVFHglJdUK6LBsqxPzs6vHKs38qYIIzK/V8A13wR2F1j1nqm99ASj+S6kjYu8x6qgZH/+fEi4UWlULES1JTcsTDqyDXvYYPFdg5zGRu7RUXAKJTnTWFVAZtiXVp/7RYwl++t/UhKd106l+0FCpL6KlRdz0h5s= x-ms-office365-filtering-correlation-id: 03709b1d-18b0-4911-fcd5-08d4d5cbf3fc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254127)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1453; x-ms-traffictypediagnostic: MWHPR15MB1453: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1453; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1453; x-forefront-prvs: 03827AF76E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39840400002)(39400400002)(39850400002)(189002)(51444003)(199003)(6506006)(5640700003)(97736004)(54356999)(50986999)(54896002)(6436002)(9686003)(478600001)(2501003)(77096006)(19627405001)(53936002)(2351001)(5660300001)(110136004)(189998001)(7696004)(55016002)(99286003)(38730400002)(106356001)(14454004)(105586002)(102836003)(7736002)(1730700003)(101416001)(81156014)(81166006)(8676002)(68736007)(74316002)(86362001)(2906002)(8936002)(3280700002)(6116002)(25786009)(6916009)(6606003)(3660700001)(33656002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1453; 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_MWHPR15MB1455F1F87FEFB41796F76C6AB6BF0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2017 15:18:51.2415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1453 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-07-28_07:, , 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: Fri, 28 Jul 2017 15:19:00 -0000 --_000_MWHPR15MB1455F1F87FEFB41796F76C6AB6BF0MWHPR15MB1455namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The flow control language in the draft is a bit confusing right now, and I = could use a bit more clarity on the intention For example in MAX_DATA and MAX_STREAM_DATA the data is defined as "A 64-bit unsigned integer indicating the maximum amount of data that can b= e sent on the entire connection, in units of 1024 octets. That is, the upda= ted connection-level data limit is determined by multiplying the encoded va= lue by 1024." This seems like it means that flow control is advertised in terms of number= of bytes that you can send from that moment. However from the Flow control section: "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to adver= tise additional credit by sending the absolute byte offset in the connectio= n or stream which it is willing to receive." I think that we definitely mean offset here in both cases, i.e. MAX_DATA =3D sum of max offset of all streams that are allowed MAX_STREAM_DATA =3D max offset on a stream Let's say the conn flow control limit of the receiver is 50. All units in m= ultiples of 1024. initial state of receiver stream1 --> [0, 10] stream2 --> [0, 20] stream3 --> [0, 20] So the sender has consumed his entire flow control window. Then the receive= r consumes 10 (*1024) bytes from stream1: stream1 ---> (10, 10) stream2 ---> [0, 20] stream3 ---> [0, 20] so now the conn window has 10 (*1024) bytes remaining, what does the receiv= er send in their update: MAX_DATA =3D 10 or MAX_DATA =3D 60 I think we mean 60 here. It makes it much easier to maintain the flow contr= ol in that case. Subodh --_000_MWHPR15MB1455F1F87FEFB41796F76C6AB6BF0MWHPR15MB1455namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The flow control language in the draft is a bit confusing right now, and= I could use a bit more clarity on the intention

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

"A 64-bit unsigned integer indicating the maximum amount of data= that can be sent on the entire connection, in units of 1024 octets. That i= s, the updated connection-level data limit is determined by multiplying the= encoded value by 1024."

This seems like it means that flow control is advertised in terms of number= of bytes that you can send from that moment.

However from the Flow control section:

"A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to = advertise additional credit by sending the absolute byte offset in the conn= ection or stream which it is willing to receive."

I think that we definitely mean offset here in both cases, i.e.

MAX_DATA =3D sum of max offset of all streams that are allowed

MAX_STREAM_DATA =3D max offset on a stream

Let's say the conn flow control limit of the receiver is 50. All units in m= ultiples of 1024.

initial state of receiver
stream1 --> [0, 10]
stream2 --> [0, 20]

stream3 --> [0, 20]

So the sender has consumed his entire flow control window. Then the receive= r consumes 10 (*1024) bytes from stream1:

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

so now the conn window has 10 (*1024) bytes remaining, what does the rec= eiver send in their update:

MAX_DATA =3D 10

or

MAX_DATA =3D 60

I think we mean 60 here. It makes it much easier to maintain the flow co= ntrol in that case.

Subodh

--_000_MWHPR15MB1455F1F87FEFB41796F76C6AB6BF0MWHPR15MB1455namp_-- From nobody Fri Jul 28 09:57:47 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 9650E131748 for ; Fri, 28 Jul 2017 09:57:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 jwVrjGgn9PS7 for ; Fri, 28 Jul 2017 09:57:44 -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 84D7012EB5D for ; Fri, 28 Jul 2017 09:57:44 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l82so68797543ywc.2 for ; Fri, 28 Jul 2017 09:57:44 -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=2M2lxC7i691+RLAlYyWRSP2oGvEbadzcmWxjUTavZZc=; b=VO8NUZd12llPdFQ53oKlMjxZPTiRDdeW4TclpZwwpS2jRstpzXYmcBdJRH3U4S8QWU +Tk3kz+EnebY6i0PmGa49jNLwGGd+9jwB5yY7I3uPigcZ7gSBBUSF8vXwG4qmhzZFLcY 3aa3QgEp0h7RX8+mG3HSGThesEdBxX3IjMfXr+AIuEYTKtzhFrnZqs9d9fGfcQi0QAT4 jWw93ZYVBE1CzZj6aB50H1bbHs8jHNp6u5qlpWSRGbzWYLPKYPHo2Qj9TZ+ZhfT8kyGg HJ5ckGOHpE1tUH6ph1tcjl0xhdngbFMQlQO+mMVP/0fQA89zg7mdHpEwMIGBDkRr6udH CpQA== 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=2M2lxC7i691+RLAlYyWRSP2oGvEbadzcmWxjUTavZZc=; b=LinqBkCh4HJZ4ZJS2EgUQ2wZIjMXBdVVq2Ig6x6EiXh+b9J8Z/AXF/FiPEzVTwdgVm SPFL6RWbJB2TdGIEw/FJCTBnLXz/UTBGLWQXqSAQ86wUhtbXpnAQpXNcxqIM4BQ1jlAH q5SOPT0sBfYaj5nhDNfr7h0oxDO5+TAeudv6dJHdi+PzzOpe4S2cNVTF+sGh9EwxKAZP h7Wz0pXRYMSujq6vh/GKpbvitZ9Su02k8p/GWMNP6Z2+wYjdFYHR7SZ/R59h7JWrymjl gThAbFK/UBCz4nhwQ4ahX8tvJ+157SR0p+YEGuI1xM4nFldSxciJs8ikqLs+Jv9Jh/ad tU2A== X-Gm-Message-State: AIVw110JUnUM0xxN1Ci96Pw/XJr7lPLKFgooXCxKK/n7zXcgfE/jpNc5 8dI8M3XcHTcPfSDD1H+OfXg0tkMrDZgu X-Received: by 10.129.121.86 with SMTP id u83mr7624708ywc.397.1501261063762; Fri, 28 Jul 2017 09:57:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Fri, 28 Jul 2017 09:57:23 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Fri, 28 Jul 2017 12:57:23 -0400 Message-ID: Subject: Re: flow control description in draft To: Subodh Iyengar Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0a8b326c33ee055563943c" 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, 28 Jul 2017 16:57:47 -0000 --94eb2c0a8b326c33ee055563943c Content-Type: text/plain; charset="UTF-8" On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar wrote: > The flow control language in the draft is a bit confusing right now, and I > could use a bit more clarity on the intention > > For example in MAX_DATA and MAX_STREAM_DATA the data is defined as > > "A 64-bit unsigned integer indicating the maximum amount of data that can > be sent on the entire connection, in units of 1024 octets. That is, the > updated connection-level data limit is determined by multiplying the > encoded value by 1024." > > This seems like it means that flow control is advertised in terms of > number of bytes that you can send from that moment. > > However from the Flow control section: > > "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to > advertise additional credit by sending the absolute byte offset in the > connection or stream which it is willing to receive." > > I think that we definitely mean offset here in both cases, i.e. > > MAX_DATA = sum of max offset of all streams that are allowed > > MAX_STREAM_DATA = max offset on a stream > > > Yes, that's what the spec means. I thought it was fairly clear, but if you think it's confusing, a PR to improve the wording would be appreciated. > Let's say the conn flow control limit of the receiver is 50. All units in > multiples of 1024. > > initial state of receiver > stream1 --> [0, 10] > stream2 --> [0, 20] > > stream3 --> [0, 20] > > > So the sender has consumed his entire flow control window. Then the > receiver consumes 10 (*1024) bytes from stream1: > > stream1 ---> (10, 10) > > stream2 ---> [0, 20] > > stream3 ---> [0, 20] > > > so now the conn window has 10 (*1024) bytes remaining, what does the > receiver send in their update: > > > MAX_DATA = 10 > > or > > MAX_DATA = 60 > > > I think we mean 60 here. It makes it much easier to maintain the flow > control in that case. > > > Subodh > > > --94eb2c0a8b326c33ee055563943c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar <= subodh@fb.com> wrote:

The flow control language in the draft is a bit confusing right now, and= I could use a bit more clarity on the intention

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

"A 64-bit unsigned integer indicating the maximum amount of data= that can be sent on the entire connection, in units of 1024 octets. That i= s, the updated connection-level data limit is determined by multiplying the= encoded value by 1024."

This seems like it means that flow control is advertised in terms of number= of bytes that you can send from that moment.
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

However from the Flow control section:

"A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to = advertise additional credit by sending the absolute byte offset in the conn= ection or stream which it is willing to receive."

I think that we definitely mean offset here in both cases, i.e.

MAX_DATA =3D sum of max offset of all streams that are allowed

MAX_STREAM_DATA =3D max offset on a stream

Yes, that's what the spec mean= s.=C2=A0 I thought it was fairly clear, but if you think it's confusing= , a PR to improve the wording would be appreciated.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Let's say the conn flow control limit of the receiver is 50. All units = in multiples of 1024.

initial state of receiver
stream1 -->=C2=A0 [0, 10]
stream2 -->=C2=A0 [0, 20]

stream3 -->=C2=A0 [0, 20]

So the sender has consumed his entire flow control window. Then the receive= r consumes 10 (*1024) bytes from stream1:

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

so now the conn window has 10 (*1024) bytes remaining, what does the rec= eiver send in their update:

MAX_DATA =3D 10

or

MAX_DATA =3D 60

I think we mean 60 here. It makes it much easier to maintain the flow co= ntrol in that case.

Subodh

--94eb2c0a8b326c33ee055563943c-- From nobody Fri Jul 28 10:15:17 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 1AAD9131F5A for ; Fri, 28 Jul 2017 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 rs2i99RFZXaG for ; Fri, 28 Jul 2017 10:15:13 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 63CF0131CED for ; Fri, 28 Jul 2017 10:15:13 -0700 (PDT) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by linode64.ducksong.com (Postfix) with ESMTPSA id E95DA3A021 for ; Fri, 28 Jul 2017 13:15:11 -0400 (EDT) Received: by mail-qk0-f170.google.com with SMTP id d136so126451954qkg.3 for ; Fri, 28 Jul 2017 10:15:11 -0700 (PDT) X-Gm-Message-State: AIVw113qkQF5ICVBAuDKmPthQwHu2JkbabjIJA7vfCGR2xmYnWOwH2Kj HY//fIH+aAgr4KYbCsjeolAhCkUzbg== X-Received: by 10.55.26.94 with SMTP id a91mr6544050qka.174.1501262111744; Fri, 28 Jul 2017 10:15:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.182.17 with HTTP; Fri, 28 Jul 2017 10:15:11 -0700 (PDT) In-Reply-To: <20170728124951.GB2686@ubuntu-dmitri> References: <20170728124951.GB2686@ubuntu-dmitri> From: Patrick McManus Date: Fri, 28 Jul 2017 13:15:11 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Closing on CONNECTION_CLOSE To: Dmitri Tikhonov Cc: Jana Iyengar , Eric Rescorla , IETF QUIC WG , Christian Huitema , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Ian Swett Content-Type: multipart/alternative; boundary="001a1146eb62e2af93055563d2d6" 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, 28 Jul 2017 17:15:16 -0000 --001a1146eb62e2af93055563d2d6 Content-Type: text/plain; charset="UTF-8" I agree that the rst-like semantic in the pull request is sensible here. Some more language around expecting applications to do graceful shutdown before this happens would be helpful - especially with the definition of GOAWAY migrating out of the transport document. This works well with the silent close concept so that makes me happy. I would like the text to say that the receiver should not discard data that it has acknowledged before receipt of the CLOSE (discarding it is the TCP receiver RST behavior). Are there objections to adding that? I disagree a little bit with (I think) Subodh and Wily regarding what to send when you recv data after you have sent a CLOSE. I want to strongly encourage implementations to have a TIME_WAIT like period of being able to a fully protected CLOSE (it can be a memcpy retransmit). public reset ought to be left as a last resort. --001a1146eb62e2af93055563d2d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that the rst-like semantic in the pull reques= t is sensible here. Some more language around expecting applications to do = graceful shutdown before this happens would be helpful - especially with th= e definition of GOAWAY migrating out of the transport document. This works = well with the silent close concept so that makes me happy.
I would like the text to say that the receiver should not disc= ard data that it has acknowledged before receipt of the CLOSE (discarding i= t is the TCP receiver RST behavior). Are there objections to adding that?

I disagree a little bit with (I think) Subodh a= nd Wily regarding what to send when you recv data after you have sent a CLO= SE. I want to strongly encourage implementations to have a TIME_WAIT like p= eriod of being able to a fully protected CLOSE (it can be a memcpy retransm= it). public reset ought to be left as a last resort.

--001a1146eb62e2af93055563d2d6-- From nobody Fri Jul 28 11:49: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 D085F131C99 for ; Fri, 28 Jul 2017 11:49:22 -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 PtVAZJZ53pqv for ; Fri, 28 Jul 2017 11:49:20 -0700 (PDT) Received: from mx44.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 A1932131E0D for ; Fri, 28 Jul 2017 11:49:20 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx44.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1dbAK6-0005zA-9o for quic@ietf.org; Fri, 28 Jul 2017 20:49:18 +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 1dbAK3-0000Xw-At for quic@ietf.org; Fri, 28 Jul 2017 14:49:16 -0400 Received: (qmail 6975 invoked from network); 28 Jul 2017 18:49:13 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Jul 2017 18:49:13 -0000 To: Patrick McManus , Dmitri Tikhonov References: <20170728124951.GB2686@ubuntu-dmitri> Cc: Jana Iyengar , Eric Rescorla , IETF QUIC WG , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Ian Swett From: Christian Huitema Message-ID: Date: Fri, 28 Jul 2017 11:49:09 -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="------------6120020CBC5E82DDF6903A3C" Subject: Re: Closing on CONNECTION_CLOSE 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: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbMzHFUa97P3bfY1LzB69ykND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23Q5hd1fTq7VCTCYFGtegiwHLOSWf0iLpjmOrL d+JDt7tL1nlQs5YvH9FEfKO0+WwCYOEkjsX7F8KmpUaZQHV+SaoNpL7PRmmTib7l1mO88Em2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpCbsjdvAic40+cHi4LtB9yD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyfFtN22Lr2qS6oeGUxSJ/EjeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj2357kOoTgosukdyElz7rBwHENdSMuNhZC3X/nGdDKYyg+xII1yJ8udUSd8siDlV+9cBL pGLKbiMLMKI7KIsgfDrl6J1fhOzjF0b4LXcjJZ5lolwe4FDighPMMafsmwOoT6zTQwxc1Dks8jy3 XjHlpiYKxzCPlkGqIuWmcZPQhnpX0M0yU2LI0GQUDn3k/srNlrrRG8CNIo3Sx0BJZHAPrCs7tyb7 Rrgi3wKcZ6DOEZP9h2AocVYAMa9P02RGLBmw4yqe0W5l+akx4yHjJyULwyVMTRpUChnn7dZMk3sz 8NLrGw== 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: Fri, 28 Jul 2017 18:49:23 -0000 This is a multi-part message in MIME format. --------------6120020CBC5E82DDF6903A3C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/28/2017 10:15 AM, Patrick McManus wrote: > I disagree a little bit with (I think) Subodh and Wily regarding what > to send when you recv data after you have sent a CLOSE. I want to > strongly encourage implementations to have a TIME_WAIT like period of > being able to a fully protected CLOSE (it can be a memcpy retransmit). > public reset ought to be left as a last resort. As Subodh pointed out, "TIME_WAIT exists in TCP is to protect us from the local port being re-bound to another connection and the data from the old connection interfering with the new connection." We don't have that constraint of old packets resurfacing 30 seconds later and interfering with a new data flow. Encryption protects against that. The "waiting" or "draining" period would mostly be a courtesy to the peer, to ensure that the CLOSE frame is well received, and that the peer actually stops sending. The normal duration of the draining period would be "sufficiently more than 1 RTT". With the current spec, the closer knows that the CLOSE has not been received yet if it keeps receiving packets from the peer. This should normally last for 1 RTT after sending the CLOSE frame. If it receives any packets more than 1 RTT after sending the CLOSE, it can assume that the CLOSE frame was not received. It would make sense to resend it then. Of course, there is a question of how long to wait after 1 RTT. Probably "some time depending on the application". We could be tempted to specify acknowledgements, etc. But then we have to remember the two generals... --=20 Christian Huitema --------------6120020CBC5E82DDF6903A3C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 7/28/2017 10:15 AM, Patrick McManus wrote:

I disagree a little bit with (I think) Subodh and Wily regarding what to send when you recv data after you have sent a CLOSE. I want to strongly encourage implementations to have a TIME_WAIT like period of being able to a fully protected CLOSE (it can be a memcpy retransmit). public reset ought to be left as a last resort.

As Subodh pointed out, "TIME_WAIT exists in TCP is to protect us from the local port being re-bound to another connection and the data from the old connection interfering with the new connection." We don't have that constraint of old packets resurfacing 30 seconds later and interfering with a new data flow. Encryption protects against that. The "waiting" or "draining" period would mostly be a courtesy to the peer, to ensure that the CLOSE frame is well received, and that the peer actually stops sending.

The normal duration of the draining period would be "sufficiently more than 1 RTT". With the current spec, the closer knows that the CLOSE has not been received yet if it keeps receiving packets from the peer. This should normally last for 1 RTT after sending the CLOSE frame. If it receives any packets more than 1 RTT after sending the CLOSE, it can assume that the CLOSE frame was not received. It would make sense to resend it then.

Of course, there is a question of how long to wait after 1 RTT. Probably "some time depending on the application".

We could be tempted to specify acknowledgements, etc. But then we have to remember the two generals...

-- Christian Huitema
--------------6120020CBC5E82DDF6903A3C-- From nobody Fri Jul 28 13:32: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 8C0EA129562 for ; Fri, 28 Jul 2017 13:32:00 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mFa_lLC0Ux8E for ; Fri, 28 Jul 2017 13:31:58 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 4AF81126CD6 for ; Fri, 28 Jul 2017 13:31:58 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 80so171410200uas.0 for ; Fri, 28 Jul 2017 13:31:58 -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=Xjs9+UOWu6i+GC4MrYr+t/ZQRQaw7gIpNKZxJoanRy0=; b=Dv/dpBdLxw6+kH57HLCcxodZpkpK9q3OEK3PqFe+LKXrBHdBeufzN+3WGHmcwONo1F Mc01hUZoF2o1B8h0sofDA10zeKGDISWnplp/RsRp6woxZUdwfJLZqFE1FpPsE0Eteft0 QFK0rjpJTxKL+VevEHs/DURzX7EzzijeAy1zhuHxE0dZbQkjNgbYOAp52M31MumCbj8t A1qTgojsWFqIvcErBfbvUYxKicIghKNLINAIj8ZXJ08XVdkyEsnfVt+Hw25+visap2MP e8owm3wDKU3AbbjSxwXDR/CyuqWpAmmTQXfp9HqGuVXrUd9eOiGiaLXiIwjb9MrOTTY8 WGbQ== 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=Xjs9+UOWu6i+GC4MrYr+t/ZQRQaw7gIpNKZxJoanRy0=; b=KH4+t1hQY8t5YjMVau651JnO39b/zaES/M9fvUOrI/VrwI3IevdVX2+A+XJPtzENTL 7+K4QNNcARuQl2yu2hmyoVd5TTJrltHJ/8VDQP0n/cD27vO2fPZLJm8lMmEP3f15akzB cP0LRO0zKRIzdbQjf/Yg/tRUD/fsrk8q/obLZ9XE50uEvgIK0PpyxjU5NDg5CfavNHVH najk36rniMFputxil8iv0tVKQU3Slz1dImqvQgzRw8q/ezq7DmhvKBSwki10PWgZqi+p yI5kT/kTUlc4XiPBNoW2rBL5n3zMLcCldpj50X09iM3WsorrIwewwCKZVkSPwOIVL3i4 DpIg== X-Gm-Message-State: AIVw1134k7zaBylKAQsVoa6qFYrE6XzeoN4WyV2aZDmfmhOx5ecaQo/L D8L23I9Q6VjyJBLGKrcq1uteukRqzw== X-Received: by 10.31.53.3 with SMTP id c3mr4996230vka.78.1501273917463; Fri, 28 Jul 2017 13:31:57 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 28 Jul 2017 16:31:56 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20170728124951.GB2686@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 28 Jul 2017 16:31:56 -0400 Message-ID: Subject: Re: Closing on CONNECTION_CLOSE To: Dmitri Tikhonov , Christian Huitema , Patrick McManus Cc: Eric Rescorla , Jana Iyengar , IETF QUIC WG , Ian Swett , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" Content-Type: multipart/alternative; boundary="001a11447e9a8fa45a055566926a" 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, 28 Jul 2017 20:32:01 -0000 --001a11447e9a8fa45a055566926a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As Subodh pointed out, "TIME_WAIT exists in TCP is to protect us from the local port being re-bound to another connection and the data from the old connection interfering with the new connection." That would be another argument for making the connection independent of 5-tuple. It would also simplify error handling during early handshake and decouple protocol for from lower layer. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 28 July 2017 at 20.49.25, Christian Huitema (huitema@huitema.net) wrote: On 7/28/2017 10:15 AM, Patrick McManus wrote: I disagree a little bit with (I think) Subodh and Wily regarding what to send when you recv data after you have sent a CLOSE. I want to strongly encourage implementations to have a TIME_WAIT like period of being able to a fully protected CLOSE (it can be a memcpy retransmit). public reset ought to be left as a last resort. As Subodh pointed out, "TIME_WAIT exists in TCP is to protect us from the local port being re-bound to another connection and the data from the old connection interfering with the new connection." We don't have that constraint of old packets resurfacing 30 seconds later and interfering with a new data flow. Encryption protects against that. The "waiting" or "draining" period would mostly be a courtesy to the peer, to ensure that the CLOSE frame is well received, and that the peer actually stops sending. The normal duration of the draining period would be "sufficiently more than 1 RTT". With the current spec, the closer knows that the CLOSE has not been received yet if it keeps receiving packets from the peer. This should normally last for 1 RTT after sending the CLOSE frame. If it receives any packets more than 1 RTT after sending the CLOSE, it can assume that the CLOSE frame was not received. It would make sense to resend it then. Of course, there is a question of how long to wait after 1 RTT. Probably "some time depending on the application". We could be tempted to specify acknowledgements, etc. But then we have to remember the two generals... -- Christian Huitema --001a11447e9a8fa45a055566926a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

As Subodh pointed = out, "TIME_WAIT exists in TCP is to protect us from the local port bei= ng re-bound to another connection and the data from the old connection inte= rfering with the new connection."
That woul= d be another argument for making the connection independent of 5-tuple. It = would also simplify error handling during early handshake and decouple prot= ocol for from lower layer.

=

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

On 28 July 2= 017 at 20.49.25, Christian Huitema (= huitema@huitema.net) wrote:

On 7/28/2017 10:15 AM, Patrick McManus wrote:

I disagree a little bit with (I think) Sub= odh and Wily regarding what to send when you recv data after you have sent a CLOSE. I want to strongly encourage implementations to have a TIME_WAIT like period of being able to a fully protected CLOSE (it can be a memcpy retransmit). public reset ought to be left as a last resort.

As Subodh pointed out, "TIME_WAIT exists in TCP is to protect us from the local port being re-bound to another connection and the data from the old connection interfering with the new connection." We don't have that constraint of old packets resurfacing 30 seconds later and interfering with a new data flow. Encryption protects against that. The "waiting" or "draining= " period would mostly be a courtesy to the peer, to ensure that the CLOSE frame is well received, and that the peer actually stops sending.

The normal duration of the draining period would be "sufficiently more than 1 RTT". With the current spec, the closer knows that the CLOSE has not been received yet if it keeps receiving packets from the peer. This should normally last for 1 RTT after sending the CLOSE frame. If it receives any packets more than 1 RTT after sending the CLOSE, it can assume that the CLOSE frame was not received. It would make sense to resend it then.

Of course, there is a question of how long to wait after 1 RTT. Probably "some time depending on the application".

We could be tempted to specify acknowledgements, etc. But then we have to remember the two generals...

-- =20 Christian Huitema

--001a11447e9a8fa45a055566926a-- From nobody Sun Jul 30 17:11: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 DF24A131CF2 for ; Sun, 30 Jul 2017 17:11: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, FREEMAIL_FROM=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=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 S7qyAiJ5GYn6 for ; Sun, 30 Jul 2017 17:11:00 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 7E170131467 for ; Sun, 30 Jul 2017 17:11:00 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id l7so105900896iof.1 for ; Sun, 30 Jul 2017 17:11:00 -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=mk1L761E6vJM0pkostKxpgrBEFUx0NhOZTnB0lLpjOM=; b=DpDDGpekVLrAJPWFBmgJPpVf1oLaGmsuhPISyMCKzqs0kNAVsBfGOX3zQ1ahelMmEg 1RsmzOPqvUsnCaFZaN2oBxOiBDozuvv+G/VPQWIFB1ANX9CdxetLH7rzQHhNDUp9t5Rh b/jssqIvzB8DPmTdCUhSVyTK6sEHjue6U4lX7Kgc7PMMTqAxbfJtYxuA0mAiLpU3PUQD BtdgRj+Ozkb/XobfsX51tuVgMCt2efIQ07bH+ZfDU8DGyhIymsn+AH9DNixpUnZrxHvo u3ZOeYX0xsM9hw8qc2W5zmjcFYz1yjmGxPRu9XoDP46BCMdWKqa8BkSUH4gSMiSBn1m/ wRPg== 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=mk1L761E6vJM0pkostKxpgrBEFUx0NhOZTnB0lLpjOM=; b=WYt5C2R9YD7pJ5jY/jNzbkmJd7ix/Y+vrngQcXdRnTbwlGZAHun4M75Izxqp0KFt7I c4BCJES0MFLBDJyCaD8QsUJqgqAqV1rVlNaPf7ZwxMBiPv109XVPkqr9yY1VB60zx2rD 8b9XEiB6qdDL52WewDJKmEbAroAJnzQ6mpaNhf+DA5F+XzunOISRh4FSxMi6pGzOBkva zWgB75yYbHg/14mnHhAiQgmZZ8SOrn55XeUTNTU7F2XozRuPcFNYNAcpLvow5MrGEUtk PXnoZtUPJUz2fAZHNvOH22XSVw/mDVSWZsHYfYo8S/w9+BQmI0465Az0XjVhExBi5ReM S7Cg== X-Gm-Message-State: AIVw113Mm/7UVnIso36fzX2TJByeXh3HbwE5H9E4whMXP9gUm6J3gfIQ F7RStNOIjqYpDvJ/38r50S6FNaa+tPx68xw= X-Received: by 10.107.201.65 with SMTP id z62mr15634018iof.74.1501459859617; Sun, 30 Jul 2017 17:10:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Sun, 30 Jul 2017 17:10:59 -0700 (PDT) From: Martin Thomson Date: Mon, 31 Jul 2017 10:10:59 +1000 Message-ID: Subject: STOP_SENDING 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, 31 Jul 2017 00:11:02 -0000 https://github.com/quicwg/base-drafts/pull/171 As mentioned in Prague, I want to merge the PR formerly known as DISINTEREST. Mike has updated it and it is now ready to do. I plan to merge this in 48 hours, absent any substantial objections. From nobody Mon Jul 31 13:25:12 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 DD1B9132543 for ; Mon, 31 Jul 2017 13:25:10 -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=[AC_DIV_BONANZA=0.001, 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 0tNlxw4439FV for ; Mon, 31 Jul 2017 13:25:09 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 B16A41318A2 for ; Mon, 31 Jul 2017 13:25:09 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id s6so124817127qtc.1 for ; Mon, 31 Jul 2017 13:25:09 -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=GRK5G4e95OihCIr7xUxZnc97i9wdCkvj5H9Pal5PJLM=; b=s4+w39hZZZbaKRlRaC5bbPestslPVkB8mmf/dzVYWPQ83my6bmwkK10gO7l4h/r6rL BweVkJFVVTYLvP008bftPfI7+V/wilbv19bv3FNVUUg4qz1/BskouaguVFC0ZHru03Vv VoFFxhdk6PdzdzZTMJA9bE8pppJglJlJ3iN+MpTpKLRoqKNOaQOEO0ijBhm302yj+7Cd ZuWn/uV+lkkDogH+TrgWjoJ8xPLWnxcZGqeTNl5mWWWMe+dnHfudjzV6hVVy3zVIKGX5 Wz8wwavK5sPi4xRD6oBb4nsXckBVuMgV5T8QeZCaqjPiRy/N0l15tLqK2hP8SunltoYB wb3g== 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=GRK5G4e95OihCIr7xUxZnc97i9wdCkvj5H9Pal5PJLM=; b=qxurEXHAo/Hw013mgGZiZFKPP8mBxOHxKvuWFwXxQU6UYV0C8b4EAh68q5WXrCbu9p mB0/w9NLA2IQoSj2Y5IzxAxAFjbGnWXejFDTPxpD1ZJMPuYd6HeOv/jNLPFie+dMf6bd QkpSk3eNCSXWuACaroByOAuJaHA6sIUd+4+C0qUMDvdcTiB7+XMmfwEEFUW2lb46gFPJ 05bn41KmseZmGBIoBGAT4vy2ynlZUnqVehukVWSeUngwrpM9S9diz5J+aIvdEsQKw2/R ilKId9qeF+mTIJd+TzpmFhUPv59DA6t1SII7coLQFudLLQfObAkHnSU2ALON1YmRm+vM l28w== X-Gm-Message-State: AIVw113dcj23qmAsy/iWPe+HhwNwNLMl23U9hgqRT8MLqOv8TpmJ0wCL hmLyg7RjLmWvWzQTUwnC6bq6NX8hjQ== X-Received: by 10.237.60.80 with SMTP id u16mr22763190qte.100.1501532708461; Mon, 31 Jul 2017 13:25:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.59.248 with HTTP; Mon, 31 Jul 2017 13:24:38 -0700 (PDT) From: Ted Hardie Date: Mon, 31 Jul 2017 13:24:38 -0700 Message-ID: Subject: Design team membership for RTT measurement issue To: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c190dc0b4df850555a2d37b" 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, 31 Jul 2017 20:25:11 -0000 --94eb2c190dc0b4df850555a2d37b Content-Type: text/plain; charset="UTF-8" My apologies for the delay in putting this out. Christian Huitema Eric Rescorla Al Morton Christopher Wood Marcus Ihlar Daniel Kahn Gillmor Andrew Mcgregor Emile Stephan Ted Hardie regards, Ted --94eb2c190dc0b4df850555a2d37b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My = apologies for the delay in putting this out.

Christian Huitema=
Eric Rescorla
Al Morton
Christopher Wood
Marcus Ihlar
Daniel Kahn Gillmor
Andrew Mcgregor
Emile Stephan
Ted Hardie

regards,

Te= d

--94eb2c190dc0b4df850555a2d37b-- From nobody Mon Jul 31 16:57: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 9E85E12EB8C for ; Mon, 31 Jul 2017 16:57:40 -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=Vny2yxhl; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=G4wI6MZH 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 Kzs0amLH6yiJ for ; Mon, 31 Jul 2017 16:57:38 -0700 (PDT) Received: from mx0b-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 ACA1E129A96 for ; Mon, 31 Jul 2017 16:57:38 -0700 (PDT) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6VNrAfp013241; Mon, 31 Jul 2017 16:57:36 -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=S4xH7tDo7f2wOOU7mx4ry3mGMBU6i5kSvEH5Zqmdvdo=; b=Vny2yxhluEci88c32iS0RfM45NpZXypD+WCBc5n2CO+NB7VcLYFPcdMBOcbKvF7RoQRY lIjRdWAJxmHhYb8iCHPNAr/8TZrVo4OoQw5rZuyKjdflexROeS6KKUzDwjgrn1/czrt5 ls/asYKIjw1EKpyGsrOpxL5zW0zH4WCZ4+o= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2c282b9shh-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Jul 2017 16:57:36 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 31 Jul 2017 19:57:35 -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=S4xH7tDo7f2wOOU7mx4ry3mGMBU6i5kSvEH5Zqmdvdo=; b=G4wI6MZHkbM0BMkAvr2CW6jj/0VQuvv8aTPKHUY8MNqu+n/jyr1AVnujfWC2wbV2F0P6JDfiqJhDp9mqHNsZ6icvig9yhO4FLBTGekgZz+kCq+EnFwiGx104GjZ8wNHMQO1DHLa8py27g5tVf+e8jqttv1ttJVVVFhZaogT5bZs= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Mon, 31 Jul 2017 23:57:34 +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.01.1304.023; Mon, 31 Jul 2017 23:57:34 +0000 From: Subodh Iyengar To: Martin Thomson , QUIC WG Subject: Re: STOP_SENDING Thread-Topic: STOP_SENDING Thread-Index: AQHTCZGIY51TFpy/zEi+0IsMXc5nPKJumE+/ Date: Mon, 31 Jul 2017 23:57:34 +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: [2620:10d:c090:200::5:78a6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 20:MMS0AfHCzgP8MNJlGAysXwzN+vEh3yVhNRgYnKcPUbejPMWRMmtJoXNiGh87iIUj1GsEiMfuUAfDd8NtRG6NVx6W7WnNuyK0lSHX3zMYaKfLl5jALDFah0q1fMD30RUffeaPUzoX/Acp/7zNof4q8aSDN8jq98wWFP7tEs4yccE= x-ms-office365-filtering-correlation-id: 7ba87cbc-68be-461c-d3a3-08d4d86fea12 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1455; x-ms-traffictypediagnostic: MWHPR15MB1455: x-exchange-antispam-report-test: UriScan:(166708455590820); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1455; x-forefront-prvs: 03853D523D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(52314003)(377454003)(199003)(189002)(6606003)(2950100002)(478600001)(8676002)(99286003)(55016002)(81166006)(81156014)(3280700002)(3660700001)(6436002)(53936002)(8936002)(229853002)(77096006)(2900100001)(97736004)(6246003)(7116003)(38730400002)(5660300001)(189998001)(39060400002)(50986999)(6506006)(76176999)(54356999)(74316002)(68736007)(606006)(53546010)(33656002)(25786009)(966005)(14454004)(105586002)(106356001)(86362001)(2906002)(54896002)(236005)(7696004)(9686003)(6306002)(102836003)(6116002)(101416001)(7736002)(19627405001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.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_MWHPR15MB1455C9C91344082BD1EF4CAAB6B20MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2017 23:57:34.4123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 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-07-31_10:, , 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, 31 Jul 2017 23:57:41 -0000 --_000_MWHPR15MB1455C9C91344082BD1EF4CAAB6B20MWHPR15MB1455namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I commented on the PR, but had a design comment Sending one more frame type has the added burden of needing to retransmit i= t before we go to closed state unless we make STOP_SENDING non retransmitta= ble. Since this frame type is advisory anyway, does it really need to be re= transmittable? Also it doesn't make sense to send this if we have received = the peers RST. A peer's RST might have raced with our STOP_SENDING and the = peer might have got rid of state for the stream. Thus any retransmitted STO= P_SENDING frames might just be ignored. Previously we had a bidirectional RST. With this change, it makes me a bit = nervous for an endpoint to rely on a peer following advisory behavior for t= hem to be able to close their stream, for example what would we do about a = client that chooses not to send a RST on STOP_SENDING, do we rely on stream= limits only? close the connection? It would be much more comfortable with = a client MUST send a RST when getting a STOP_SENDING. Subodh ________________________________ From: QUIC on behalf of Martin Thomson Sent: Sunday, July 30, 2017 5:10 PM To: QUIC WG Subject: STOP_SENDING https://github.com/quicwg/base-drafts/pull/171 As mentioned in Prague, I want to merge the PR formerly known as DISINTEREST. Mike has updated it and it is now ready to do. I plan to merge this in 48 hours, absent any substantial objections. --_000_MWHPR15MB1455C9C91344082BD1EF4CAAB6B20MWHPR15MB1455namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I commented on the PR, but had a design comment

Sending one more frame type has the added burden of needing to retransmit i= t before we go to closed state unless we make STOP_SENDING non retransmitta= ble. Since this frame type is advisory anyway, does it really need to be re= transmittable? Also it doesn't make sense to send this if we have received the peers RST. A peer's RST might h= ave raced with our STOP_SENDING and the peer might have got rid of state fo= r the stream. Thus any retransmitted STOP_SENDING frames might just be igno= red.

Previously we had a bidirectional RST. With this change, it makes me a b= it nervous for an endpoint to rely on a peer following advisory behavior fo= r them to be able to close their stream, for example what would we do about= a client that chooses not to send a RST on STOP_SENDING, do we rely on stream limits only? close the connect= ion? It would be much more comfortable with a client MUST send a RST when g= etting a STOP_SENDING.

Subodh

From: QUIC <quic-bounc= es@ietf.org> on behalf of Martin Thomson <martin.thomson@gmail.com>= ;
Sent: Sunday, July 30, 2017 5:10 PM
To: QUIC WG
Subject: STOP_SENDING

https://github.com/quic= wg/base-drafts/pull/171

As mentioned in Prague, I want to merge the PR formerly known as
DISINTEREST. Mike has updated it and it is now ready to do. I p= lan
to merge this in 48 hours, absent any substantial objections.

--_000_MWHPR15MB1455C9C91344082BD1EF4CAAB6B20MWHPR15MB1455namp_-- From nobody Mon Jul 31 17:29: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 85E591322D6 for ; Mon, 31 Jul 2017 17:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 pkTh2fOHy7zK for ; Mon, 31 Jul 2017 17:29:05 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0094.outbound.protection.outlook.com [104.47.40.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CCB13253B for ; Mon, 31 Jul 2017 17:29:05 -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=NZs6cXuXrmtQ8er+kuY/Yh1Y+rO09b2DFEEoBFXe/qc=; b=fuXKU6sO8vdsyEXjSBK7FVHheADZt+cnF5iiR0a9c9GuobpvKs7ggacItKwWf3xGNCjv0ucDzDZAfLhgQQTXcfJN9GnH8YnoH+P77Loq5aTDksfjI2m8ML042AM5fTmPjGDFRVxQbLV61Wfaq3zib0q/OH2myBuLJrahtXIsyys= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.0; Tue, 1 Aug 2017 00:29:04 +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.01.1341.000; Tue, 1 Aug 2017 00:29:04 +0000 From: Mike Bishop To: Subodh Iyengar , Martin Thomson , QUIC WG Subject: RE: STOP_SENDING Thread-Topic: STOP_SENDING Thread-Index: AQHTCZGFwh/s1ctV8UmjTeq6nd+wlKJunmsAgAADa7A= Date: Tue, 1 Aug 2017 00:29:03 +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:e::224] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0125; 6:I8TkrLlLIZ13zETPYlbtPcew3mAp2Hch+gPl2kZVJ88IDmy+UaWsNMWQaFWfYfMmzYZBKF3URwTr+gxHSCEgEbDf83xEYL8c3nM6e0vGNqKThiWEK4QKfx1BMe4P3pTiRXp0ZKsihHEURgiOO+WH9VvhWpl2Kparw+q7nDSR5eyrdm2rAM7bzRIoSDHrS7bTjFi3IAaHOj0Eba9OYqyytoG8kN+bCyZsb9mg87lK8xcZb36YthQvJpZz2a+PBN7EPm0kYEtpV6IspdywEoUBJ0SEnY4rwQHq60I3SdiE8Mh4rDtE5sslpA5MKGhMMQ6sBe1nAj+HCIKxzN0JGEUIdg==; 5:cOuf4/VBQG0YsOkrxp3OYy5oR4PUGE6n4egHJzmZ6fKna2qFpfn6L6eOeqZw6Sk2g5rEFDNzDjvR9lfV30IHNegvgeAkEJUB1UQtmK13eHolaByCQqskLflFDo4yS4aSUo5SChRbCQPiacPwsCNodA==; 24:SLDi9vKPza5doqWQKFcRlont/9nu7829GG11/6l9koAoTh5DMI+PKonAzzDLoWcm1RsxPPyEyzhsFJNBqG5O5isUoCs/eOVpxtIQaxBJf/4=; 7:3wq+sAU24Bx2T050qjZQ50+/CCVgpf4rbdk/07XyY8BcFE1J7zC3t0P8omJKKmPmw2CrxeWoaRy2a8XwzwnlaLEgaCrGtqITdlcfXRzJp6XIvHRbprxj1EMPGxWuBtCkItpkfSsKKRYaOjpPDHlujy2CGMGYyfLIIRnlp1tsAh3283oQ3U9D6LSnffANj7D7QzdIDQHmyLzMLCVncMH9Ott9ImlPV4nMdaWMDNu5wLY= x-ms-office365-filtering-correlation-id: 68c844cd-c491-49c1-da85-08d4d874505a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0125; x-ms-traffictypediagnostic: MWHPR21MB0125: x-exchange-antispam-report-test: UriScan:(166708455590820)(189930954265078)(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)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0125; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0125; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(47760400005)(377454003)(199003)(189002)(52314003)(229853002)(6116002)(102836003)(790700001)(2906002)(86362001)(5660300001)(7116003)(81156014)(3280700002)(8936002)(3660700001)(7696004)(81166006)(8676002)(6436002)(86612001)(25786009)(68736007)(7736002)(77096006)(478600001)(19609705001)(74316002)(6506006)(10090500001)(10290500003)(99286003)(55016002)(50986999)(6246003)(53936002)(6306002)(54896002)(236005)(9686003)(76176999)(189998001)(54356999)(2950100002)(97736004)(38730400002)(53546010)(606006)(39060400002)(101416001)(72206003)(8990500004)(14454004)(106356001)(105586002)(33656002)(966005)(5005710100001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0125; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01417568E2E1C6ECEA56334987B30MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2017 00:29:03.9988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0125 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, 01 Aug 2017 00:29:08 -0000 --_000_MWHPR21MB01417568E2E1C6ECEA56334987B30MWHPR21MB0141namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yeah, the retransmission piece of it is interesting. I can see an argument= for making it non-retransmittable, but having guidance to periodically res= end it if you continue to receive data. (Kind of like ACKs - you don't bli= ndly re-send the frame, you re-evaluate what needs to be sent.) However, t= hat seems heavier-weight than simply sending it reliably. Note that only S= TREAM frames block the transition to "closed," and even there the transitio= n happens when you have "completed sending," which I don't read as everythi= ng having been ACK'd unless we added that definition somewhere else. The previous RST was only somewhat bidirectional - when you sent a RST_STRE= AM, you didn't know the other side's final offset, so you couldn't wind dow= n their side of the stream until they also sent a RST_STREAM. That's still= the case, but now it's more honest - the stream continues to be open in th= e other direction until they actually send the RST_STREAM. Conceptually, I'd be okay with a "MUST send RST_STREAM unless the stream is= already closed," but this is almost impossible to verify, even if you star= t tracking what streams show up in packet numbers after the ACK of the pack= et that contained the STOP_SENDING frame. My general rule is that if the o= ther party can't be certain whether you violated a MUST, it needs to be a S= HOULD. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar Sent: Monday, July 31, 2017 4:58 PM To: Martin Thomson ; QUIC WG Subject: Re: STOP_SENDING I commented on the PR, but had a design comment Sending one more frame type has the added burden of needing to retransmit i= t before we go to closed state unless we make STOP_SENDING non retransmitta= ble. Since this frame type is advisory anyway, does it really need to be re= transmittable? Also it doesn't make sense to send this if we have received = the peers RST. A peer's RST might have raced with our STOP_SENDING and the = peer might have got rid of state for the stream. Thus any retransmitted STO= P_SENDING frames might just be ignored. Previously we had a bidirectional RST. With this change, it makes me a bit = nervous for an endpoint to rely on a peer following advisory behavior for t= hem to be able to close their stream, for example what would we do about a = client that chooses not to send a RST on STOP_SENDING, do we rely on stream= limits only? close the connection? It would be much more comfortable with = a client MUST send a RST when getting a STOP_SENDING. Subodh ________________________________ From: QUIC > on behalf = of Martin Thomson > Sent: Sunday, July 30, 2017 5:10 PM To: QUIC WG Subject: STOP_SENDING https://github.com/quicwg/base-drafts/pull/171 As mentioned in Prague, I want to merge the PR formerly known as DISINTEREST. Mike has updated it and it is now ready to do. I plan to merge this in 48 hours, absent any substantial objections. --_000_MWHPR21MB01417568E2E1C6ECEA56334987B30MWHPR21MB0141namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yeah, the retransmission piece of it is interesting.= I can see an argument for making it non-retransmittable, but having = guidance to periodically resend it if you continue to receive data. (= Kind of like ACKs – you don’t blindly re-send the frame, you re-evaluate what needs to be sent.) However, that see= ms heavier-weight than simply sending it reliably. Note that only STR= EAM frames block the transition to “closed,” and even there the= transition happens when you have “completed sending,” which I don’t read as everything having been ACK’d unless we a= dded that definition somewhere else.

The previous RST was only somewhat bidirectional = 211; when you sent a RST_STREAM, you didn’t know the other side’= ;s final offset, so you couldn’t wind down their side of the stream u= ntil they also sent a RST_STREAM. That’s still the case, but now it’s more honest – the stream continues to be open in = the other direction until they actually send the RST_STREAM.

Conceptually, I’d be okay with a “MUST s= end RST_STREAM unless the stream is already closed,” but this is almo= st impossible to verify, even if you start tracking what streams show up in= packet numbers after the ACK of the packet that contained the STOP_SENDING frame. My general rule is that if the other party c= an’t be certain whether you violated a MUST, it needs to be a SHOULD.=

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Subodh Iyengar
Sent: Monday, July 31, 2017 4:58 PM
To: Martin Thomson <martin.thomson@gmail.com>; QUIC WG <qui= c@ietf.org>
Subject: Re: STOP_SENDING

I commented on the PR, but = had a design comment

Sending one more frame type has the added burden of needing to retransmit i= t before we go to closed state unless we make STOP_SENDING non retransmitta= ble. Since this frame type is advisory anyway, does it really need to be re= transmittable? Also it doesn't make sense to send this if we have received the peers RST. A peer's RST might h= ave raced with our STOP_SENDING and the peer might have got rid of state fo= r the stream. Thus any retransmitted STOP_SENDING frames might just be igno= red.

Previously we had a bidirec= tional RST. With this change, it makes me a bit nervous for an endpoint to = rely on a peer following advisory behavior for them to be able to close the= ir stream, for example what would we do about a client that chooses not to send a RST on STOP_SENDING, do we= rely on stream limits only? close the connection? It would be much more co= mfortable with a client MUST send a RST when getting a STOP_SENDING.

Subodh

From: QUIC <q= uic-bounces@ietf.org> on behalf of Martin Thomson <martin.thomson@gmail.com>
Sent: Sunday, July 30, 2017 5:10 PM
To: QUIC WG
Subject: STOP_SENDING

<= o:p>

https://github.com/quicwg/base-drafts/pull/171
As mentioned in Prague, I want to merge the PR formerly known as
DISINTEREST. Mike has updated it and it is now ready to do. I p= lan
to merge this in 48 hours, absent any substantial objections.

--_000_MWHPR21MB01417568E2E1C6ECEA56334987B30MWHPR21MB0141namp_-- From nobody Mon Jul 31 17:53: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 78352131467 for ; Mon, 31 Jul 2017 17:53:34 -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 2MXOSyyN0FrK for ; Mon, 31 Jul 2017 17:53:32 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 302B7127058 for ; Mon, 31 Jul 2017 17:53:32 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id h199so384007ith.1 for ; Mon, 31 Jul 2017 17:53:32 -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=d/380tYDilzT7aXPmkWhFD9bQ/HeeyUKgpICo5bzB/4=; b=fhFwRSzskiuaL0mrlf0GzjRJ4pt4TcRKrmFgXMhJEzPCuzEVPxTY6WwQ8Tq2rQEsk4 ib9a3EPYgvkS0JqcWt3CHLSbgQZy+c+p3cLnFefXRgLkdbPv6qhOGtlvGCd9ySHbrXTw 2dFl+nOp0uHs6jFvoEqfoBl0A4gpzFJBMZLibRfXN3IM14Zuhw4u3UZ2gYNUkpH7Nwgt 8xqDpfr/ZqTPbL9WYb7dNQa9S7wmchJhp9oT9FqwogVc8DbMR8w2bBIipSqnpsPQ6giJ RDrWmiZLALGnazwuLOWLwdZvj8DPuXau7zmyOdSu08V7m096jvOgKH0R3l96yii7VE+8 mBMw== 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=d/380tYDilzT7aXPmkWhFD9bQ/HeeyUKgpICo5bzB/4=; b=NLhwL/gMtNSWLuxQo4YQArcuVIqaDzrO4+kXA0hIR43woenQmM2xjnEpHrIIG8YMak 6MG4hqFW8yRLUPxe0fP5jf+M6NfJHZggXtmFHcs/df7/uMuFlKSdfe5BfypE0W8zBj7T EnelpM+qrJa1N8o6e/VOBEOl/4pVUnoshmka3XSO2KxHYdnUU02xUudVvlWG99tDO04Q HUn3WWMmVV8iZLYlbpVqczda8br6JalvDmriFwNY1mo6kuaBAWrkmHpHY/rJl4IB8LE1 w31w5SXHvH3MsYUwfFo26obIuuw8rsZPW9LvFFMxWgdNBSkQbG74WLTF0g9n9dJoc18c /dSA== X-Gm-Message-State: AIVw111iFeZrnKYuNI3AoH4qncQzfyesGqmlEX31TvU9fZxBf4ZqiBYQ WArIlIEJt4Bwv5e7oHhk0qlmlWcoZg== X-Received: by 10.36.5.68 with SMTP id 65mr75709itl.140.1501548811422; Mon, 31 Jul 2017 17:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Mon, 31 Jul 2017 17:53:30 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 1 Aug 2017 10:53:30 +1000 Message-ID: Subject: Re: STOP_SENDING To: Mike Bishop Cc: Subodh 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: Tue, 01 Aug 2017 00:53:34 -0000 Wow, nice catch Subodh, that's somewhat subtle. This is a frame that affects stream state that isn't caught up in the state machine. Mike is right that you can make the retransmission logic for STOP_SENDING independent of the stream state, but I think that could be more cumbersome to manage in implementation than is ideal. I think that the simple fix here is as Subodh suggests: mandate the sending of RST_STREAM in response to STOP_SENDING unless the stream is already closed. We can then note the optimization that this enables: you can stop sending STOP_SENDING when the stream is closed. Regarding MUST - I recognize that we fall back to the halting problem, but I can still construct a test that will in most cases detect misbehaviour: have someone send an infinitely long stream, send STOP_SENDING in every packet, if they acknowledge packets for some time without sending RST_STREAM, something is badly wrong. It's not deterministic, but it's still worth mandating. Mike, The relationship between retransmissions and stream states is something that remains open in my mind. What we have appears to be largely driven by some design choices in the Google implementation. I don't know if we have an open issue that tracks that, we've flip-flopped on our position over time and I don't think that we have a firm consensus on this. That said, it matters much less now that we have MAX_STREAM_ID. On 1 August 2017 at 10:29, Mike Bishop wrote= : > Yeah, the retransmission piece of it is interesting. I can see an argume= nt > for making it non-retransmittable, but having guidance to periodically > resend it if you continue to receive data. (Kind of like ACKs =E2=80=93 = you don=E2=80=99t > blindly re-send the frame, you re-evaluate what needs to be sent.) Howev= er, > that seems heavier-weight than simply sending it reliably. Note that onl= y > STREAM frames block the transition to =E2=80=9Cclosed,=E2=80=9D and even = there the > transition happens when you have =E2=80=9Ccompleted sending,=E2=80=9D whi= ch I don=E2=80=99t read as > everything having been ACK=E2=80=99d unless we added that definition some= where else. > > > > The previous RST was only somewhat bidirectional =E2=80=93 when you sent = a > RST_STREAM, you didn=E2=80=99t know the other side=E2=80=99s final offset= , so you couldn=E2=80=99t > wind down their side of the stream until they also sent a RST_STREAM. > That=E2=80=99s still the case, but now it=E2=80=99s more honest =E2=80=93= the stream continues to be > open in the other direction until they actually send the RST_STREAM. > > > > Conceptually, I=E2=80=99d be okay with a =E2=80=9CMUST send RST_STREAM un= less the stream is > already closed,=E2=80=9D but this is almost impossible to verify, even if= you start > tracking what streams show up in packet numbers after the ACK of the pack= et > that contained the STOP_SENDING frame. My general rule is that if the ot= her > party can=E2=80=99t be certain whether you violated a MUST, it needs to b= e a SHOULD. > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar > Sent: Monday, July 31, 2017 4:58 PM > To: Martin Thomson ; QUIC WG > Subject: Re: STOP_SENDING > > > > I commented on the PR, but had a design comment > > Sending one more frame type has the added burden of needing to retransmit= it > before we go to closed state unless we make STOP_SENDING non > retransmittable. Since this frame type is advisory anyway, does it really > need to be retransmittable? Also it doesn't make sense to send this if we > have received the peers RST. A peer's RST might have raced with our > STOP_SENDING and the peer might have got rid of state for the stream. Thu= s > any retransmitted STOP_SENDING frames might just be ignored. > > > > Previously we had a bidirectional RST. With this change, it makes me a bi= t > nervous for an endpoint to rely on a peer following advisory behavior for > them to be able to close their stream, for example what would we do about= a > client that chooses not to send a RST on STOP_SENDING, do we rely on stre= am > limits only? close the connection? It would be much more comfortable with= a > client MUST send a RST when getting a STOP_SENDING. > > Subodh > > > > ________________________________ > > From: QUIC on behalf of Martin Thomson > > Sent: Sunday, July 30, 2017 5:10 PM > To: QUIC WG > Subject: STOP_SENDING > > > > https://github.com/quicwg/base-drafts/pull/171 > > As mentioned in Prague, I want to merge the PR formerly known as > DISINTEREST. Mike has updated it and it is now ready to do. I plan > to merge this in 48 hours, absent any substantial objections. From nobody Mon Jul 31 20:25: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 2CFF0127ABE for ; Mon, 31 Jul 2017 20:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] 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 FyUaeFoVZPFd for ; Mon, 31 Jul 2017 20:25:12 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 AF320131CE3 for ; Mon, 31 Jul 2017 20:25:12 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id p3so2363778qtg.2 for ; Mon, 31 Jul 2017 20:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=as4kom+tWH6igHeA5AE4SxrxQRq8bwIKN+OHCP5z12s=; b=nvu7yztofyRTYLvNFcJZqRSzUgKMviFeVCmJnGzvd/Q2dEX7YlGxzx5pROC8bESRaP tUplVdIzY3xXE2tE4RdHry6vnLl4YEl06yCiF3vuchXOVXyY+s+eKnFMrnUIklm9bmUJ SALd/3BhVu/4H/TgviwOMTIF1CbHh++t0mAl07mHimCk4D8GLBtp1ltVRDJcMy+lXNHI /tYAv2PZQW6/2Lj/XLiZoojoR3Fktipf5t+fXphrN8LTW58FK3+yjfw73E34CsDZn16I WWhaPoKIK2zl7jlPY+Ep024Pd4TqXCLCvo+96/OvSh5YuMs1RGfvVlsBfXErfj4hyLNd JGWw== 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:subject:message-id:mime-version :content-disposition:user-agent; bh=as4kom+tWH6igHeA5AE4SxrxQRq8bwIKN+OHCP5z12s=; b=EBW4G7stK8zZAOMKIhRqy7Aq9rp4yAnLFS+JQ9ncPvTXEkSb2t+I4i0oelyyiN+a1D HDkJe8fLF11R3GsGx4vBCT6Mqnzjf1lqam4OP+oQs8BuAJq2uJr6n0VxrlVGjl5KgNCe lTt4dNVslOZcKE4ItumeY5K0ihUg7k1kAq3CpO92WP8YsYhChQ+eHJK3PNf++YEOjYhH Jaenn08upvdsLG1t3UcgCkOtIBRB83luQxfg4VryVvWtWoYPDm445u8UF+UgnmGG2bsh 8ITA4TZ2fDKAFug890pF/ylnLnRH4gcSo9tLZdI8+hleCdmgcax2Rx4kqqjxvHBO08Ux KWTg== X-Gm-Message-State: AIVw1133rysRm9F370bPxKyewhVAj5DUXgKM7WMciO2rQy6RDujEB+Ny t3l6g7yMo21Fmf6xZIA= X-Received: by 10.237.60.57 with SMTP id t54mr26596938qte.281.1501557911594; Mon, 31 Jul 2017 20:25:11 -0700 (PDT) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id 94sm17164267qte.55.2017.07.31.20.25.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 20:25:10 -0700 (PDT) Date: Mon, 31 Jul 2017 23:25:02 -0400 From: Dmitri Tikhonov To: quic@ietf.org Subject: Differentiate between GQUIC and QUIC packets Message-ID: <20170801032502.GA28788@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Tue, 01 Aug 2017 03:25:14 -0000 Hello, I wonder whether supporting both GQUIC and QUIC on the same host and port has been discussed. I searched on GitHub and this mailing list, but could not find anything. Suppose an implementation wants to serve both GQUIC and QUIC. How is it to differentiate between GQUIC and QUIC packets? There are two cases to consider: 1) GQUIC vs QUIC long-header format packet This is straightforward: the first byte in GQUIC must be zero, whereas in QUIC's long-header format packet it is set to one. 2) GQUIC vs QUIC short-header format packet Now it gets more involved. From [draft-ietf-quic-transport]: " 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 " +-+-+-+-+-+-+-+-+ " |0|C|K| Type (5)| " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " | | " + [Connection ID (64)] + " | | " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " | Packet Number (8/16/32) ... " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " | Protected Payload (*) ... " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " " Figure 2: Short Header Format and " The packet type in a short header currently determines only the size " of the packet number field. Additional types can be used to signal " the presence of other fields. " " +------+--------------------+ " | Type | Packet Number Size | " +------+--------------------+ " | 0x01 | 1 octet | " | | | " | 0x02 | 2 octets | " | | | " | 0x03 | 4 octets | " +------+--------------------+ " " Table 2: Short Header Packet Types GQUIC's interpretation of the first byte is: 0x80 unused, must be set to 0 0x40 reserved for multipath use 0x30 packet number size 0x08 connection ID 0x04 diversification nonce 0x02 public reset 0x01 version Here is an ambguity: First QUIC GQUIC byte meaning meaning 0x01 No connection ID, No connection ID, 1-byte packet 1-byte packet number, number. version bit set. (A variation: OR 0x20 for Key Phrase Bit / 4-byte packet number confusion). One could use logic like this: "it does not make sense for a packet to have a version bit set and not have a connection ID: therefore, it must not be GQUIC." Is this the recommended approach? Note that the ambiguities may get worse if QUIC decides to start using bits 0x1B for its short-header format first byte. - Dmitri. From nobody Mon Jul 31 20:28: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 02C61131CEF for ; Mon, 31 Jul 2017 20:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] 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 BdoPbzv8ok_x for ; Mon, 31 Jul 2017 20:28:14 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 0B33B131CE4 for ; Mon, 31 Jul 2017 20:28:14 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id u139so2421372qka.1 for ; Mon, 31 Jul 2017 20:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZxyUja4jvwDJ+Sd9vBfO/1dWPq3Epi6AgpHzgFwgUHs=; b=vn1JwJ6Fkii2UTL+f5dxl1cKPPGgTewwKUEl51Y7YPuFK+J9o9bug1+/wzv1dCDtcZ 8TSg2AwZC2lEghESQ9iO4yQtwhcuOn83x2fwGTWIlwwYmRSWrNzxQf96AcDHcuEMMMLq GvZj9dtuKi4oXFVgZbVDBn1rywFWH8UDo+H9NMmDiolNJ9loIc1NVXJV4r4zPI2XiCjq hiS3IBPT4YYw7eV6Lj+525T0MR+vi4hvkwGOvuaR4ONUVpI1gqXYRar6iOzBLRvp7qpW sx7/1w5OvccJeVVmLR5HRWGwGM7DxujBV8XCzlIkOjggqjLLc7PGKAN6FhJ+pTBw/Tfx vA4g== 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:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZxyUja4jvwDJ+Sd9vBfO/1dWPq3Epi6AgpHzgFwgUHs=; b=U8Med9jBoBzPT2LbRyxv4B/4VZoEEsge08GltKZpAwN5JkygoGu16/ez5UQ/Q4Pu8O zB9MPUr9s9O2tCdRguzDr165paAuF7BV6QbeQ6WFwtfmilXMf2hc+yklcs9LctLjcxd6 52R8FBT5cBGcUdOGSlc9Eep8ENOfKIUSPNalocMgfnPa8zkPafOQ6zliEiFF8GSaquXg NXcx6ZvymIlO7hfsmD/2m/jErDOQrHle/5hPSpraHTsL27fEJMOQZqymcirfZcqDspeg JJpgV4hDUD6tIHNyU5UMFjb6eTTLZY5CyGiKOPeY5s7VbzvSW0jPMf074SKMjROIpmuY FhQw== X-Gm-Message-State: AIVw113L2qH9xGjys1TtEZnAHN+jgaw2+9KuM8DQjOGPFCCoFU8AqkJS 8sCpoqNT/HN19o4Tfhc= X-Received: by 10.55.27.154 with SMTP id m26mr22106204qkh.135.1501558092928; Mon, 31 Jul 2017 20:28:12 -0700 (PDT) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id 131sm20851150qki.23.2017.07.31.20.28.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 20:28:12 -0700 (PDT) Date: Mon, 31 Jul 2017 23:28:05 -0400 From: Dmitri Tikhonov To: quic@ietf.org Subject: Re: Differentiate between GQUIC and QUIC packets Message-ID: <20170801032805.GA29894@ubuntu-dmitri> References: <20170801032502.GA28788@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170801032502.GA28788@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: Tue, 01 Aug 2017 03:28:15 -0000 On Mon, Jul 31, 2017 at 11:25:02PM -0400, Dmitri Tikhonov wrote: > 1) GQUIC vs QUIC long-header format packet > > This is straightforward: the first byte in GQUIC must be zero, ^^^^^^^^^^^^^^ > whereas in QUIC's long-header format packet it is set to one. This should read "the high bit of the first byte" -- sorry about that. - Dmitri.