From nobody Thu Jun 1 00:48: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 872ED12E045 for ; Thu, 1 Jun 2017 00:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 uh_rtEqghECT for ; Thu, 1 Jun 2017 00:47:58 -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 9FDC312E03C for ; Thu, 1 Jun 2017 00:47:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3wdfb06nnZz15PN9; Thu, 1 Jun 2017 09:47:56 +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 K0RjR3cstRc8; Thu, 1 Jun 2017 09:47:56 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 1 Jun 2017 09:47:56 +0200 (CEST) Subject: Re: enumerate packets not to ack? To: Martin Thomson , Jana Iyengar References: Cc: IETF QUIC WG , Patrick McManus From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <89f91631-063f-706c-b132-c24b72cab10e@tik.ee.ethz.ch> Date: Thu, 1 Jun 2017 09:47:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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, 01 Jun 2017 07:48:00 -0000 These are actually to different things. One is that you should not send/generate an ack frame just because you received an ack frame but no other data. The other point is that you actually can't really ack server retry or version negotiation because they don't have a valid packet number. On 01.06.2017 03:21, Martin Thomson wrote: > On 1 June 2017 at 04:57, Jana Iyengar wrote: >> Section 9 says acks must not generate acks, but this is a gap. We should >> enumerate the packet types (and perhaps frame types too) that must not >> generate acks. I've filed #563. > > What's the taxonomy? Can we split this based on frame type? > > PADDING and ACK alone don't generate the need for an ACK. However, a > packet with any other frame type does. Except when they are carried > in Server Stateless Retry packets, which never generates > acknowledgments. > > Version Negotiation packets don't contain frames so they don't cause > acknowledgments to be needed. Here's a thought: maybe they should. > From nobody Thu Jun 1 01:08: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 19E6F127B31 for ; Thu, 1 Jun 2017 01:08:46 -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 3ffLa_tTdzfY for ; Thu, 1 Jun 2017 01:08:44 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77E912E04D for ; Thu, 1 Jun 2017 01:08:43 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F079E340E3D; Thu, 1 Jun 2017 10:08:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.1084); Thu, 1 Jun 2017 10:08:41 +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; Thu, 1 Jun 2017 10:08:41 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19349125; Thu, 01 Jun 2017 10:08:41 +0200 Subject: Re: Should QUIC have a path-verifiable proof of source address? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CB3F2B11-E298-46D0-A161-CDD6DF9CC35F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell (IETF) In-Reply-To: <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> Date: Thu, 1 Jun 2017 10:08:40 +0200 Cc: quic@ietf.org Message-Id: <87D64B45-4B8D-4434-984C-A65399E53225@trammell.ch> References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> To: Christian Huitema 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: Thu, 01 Jun 2017 08:08:46 -0000 --Apple-Mail=_CB3F2B11-E298-46D0-A161-CDD6DF9CC35F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Christian, > On 31 May 2017, at 22:09, Christian Huitema = wrote: >=20 >=20 >=20 > On 5/31/2017 4:53 AM, Brian Trammell (IETF) wrote: >> "Shoud QUIC allow devices on path to distinguish QUIC traffic with = valid source addresses from traffic with spoofed source addresses?" >=20 > Brian, I am not sure I understand your requirement. Do you mean > something like the reachability verification implicit in the three = ways > handshake of TCP? Or do you mean some kind of cryptographic proof that > the device is allowed to use the source address? Excellent question. I left this intentionally vague, since I didn't want = to prejudice a selection of technique, just discuss the utility of the = property. (Also, by "a cryptographic proof that the device is allowed to = use the source address", I understand "a cryptographic proof that the = device can receive packets sent to the source address it uses", since = the notion of permission to use here beyond "gets packets routed to it" = would require a degree of integration between the control plane and the = data plane that would put us in future Internet territory.) As I see it, this is a question of degree: TCP provides a few bits of = entropy (by comparing SEQ/ACK), a cryptographic proof provides many = more. The tradeoffs are also different: the former requires a few extra = bits in the long header (during initial handshake) and possibly the = short header (for resumption and/or continuous proof during a = connection), but doesn't provide a very strong proof. The latter = provides a very strong proof, but has higher overhead requires sharing a = key with the device doing the verification. Thanks, cheers, Brian --Apple-Mail=_CB3F2B11-E298-46D0-A161-CDD6DF9CC35F 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 iQIcBAEBCgAGBQJZL8uJAAoJEIoSt78L6kajFaYQAMIpgpUUyUqesAYVLbu7zWix Y0PxN0is/8ypicc4k/8HRXlf7Na4HFUSZevFKmndLvx2zyvbP2dL2Aqoj0vu2DLi okAG2l4j8u2YE2jrXtpcF69aMp3G6Vt+IAMTIxYAqyR2hd7Xe6PX/adarr6rqpZA wmk3h5Mu85VwNdirR8j4w015TttK5wuxK8D7/uUKPtggYfy77DReJNoorVH9ysIj a+saS5AW4T4TvxAyFams91A6IfOZMXpg9Zy8aerEkPn94lEm+SRqEkA+qJ8DIEED pbVVM6TeLbSsYl99cLv6aWKsIFEQURpLly5H96w/GdUZ2ZQ26bafY7/JmMi1ENzT owRTsLf5dkwJMsgVIi5Clck7nwpzCmaNsxGeLIpYeBlCTjJpJHgCYElaA2Cv2xXS 38JY8rIl1H8RZrgCulaL3vKHyB7vacv9Jp/6Y54rdMJ3/jo41OsdKtqhIQGVT2xn XTWOvKuzS87hJX8vpGt05acmUxK2ao/a5NKlCxgXygttG1dPq1v2sclTrxbgcE0W VJkBiIvPqoW2wA1RHA4+aRA4zd/bxpLTim0JMJPS/MNWRavfqGKPXJ/JKqQReJuv N8GV1uW02MEOwGe/8lpQxRPfTeZC+dcdBGnNsZXr2k2r6IWGDPCuZ7NmwE3hDp6n kEERb1z8vo9vQyX+HTlD =KFUh -----END PGP SIGNATURE----- --Apple-Mail=_CB3F2B11-E298-46D0-A161-CDD6DF9CC35F-- From nobody Thu Jun 1 01:37:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D948E127136 for ; Thu, 1 Jun 2017 01:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 9Yy7pVEZLloW for ; Thu, 1 Jun 2017 01:37:52 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53BF12706D for ; Thu, 1 Jun 2017 01:37:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3wdghZ1994zMpcm; Thu, 1 Jun 2017 10:37:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkSpduWDJXm3; Thu, 1 Jun 2017 10:37:49 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 1 Jun 2017 10:37:49 +0200 (CEST) Subject: Re: Should QUIC have a path-verifiable proof of source address? To: Martin Thomson , Christian Huitema References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> Cc: QUIC WG From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> Date: Thu, 1 Jun 2017 10:37:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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, 01 Jun 2017 08:37:54 -0000 Hi all, On 01.06.2017 03:29, Martin Thomson wrote: > On 1 June 2017 at 06:09, Christian Huitema wrote: >> Brian, I am not sure I understand your requirement. Do you mean >> something like the reachability verification implicit in the three ways >> handshake of TCP? Or do you mean some kind of cryptographic proof that >> the device is allowed to use the source address? > > At risk of speaking for Brian, I think that this is intended to cover > the simple reachability verification implicit in TCP. That is, proof > that the endpoint was able to see a packet that was sent to their > claimed address. I just would like to note that TCP has a three-way handshake for this purpose but also during the connection you have the ack number that is visible to the network and also provides some proof that the sender is able to receive packets at the indicated source address. Mirja > > The verification provided by ICE also works. There, it's not a > three-way handshake, but two independent request/response validations. > > (I think that I see a companion to Brian's "what is an endpoint?" doc: > "what is a path?") > From nobody Thu Jun 1 02:24: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 DDC7A1200F1 for ; Thu, 1 Jun 2017 02:24:54 -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 3Om2WMIIs_FR for ; Thu, 1 Jun 2017 02:24:53 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 6101C12EB55 for ; Thu, 1 Jun 2017 02:24:53 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id c184so18167299lfe.2 for ; Thu, 01 Jun 2017 02:24:53 -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=+8LlCh4R5ybh3bTr4lnn0DXKD2oT+qArQ5x5gaHopCQ=; b=HMsX2WoWCkmOluX03mdLnnNDWL0XE+/FwG5CRW+csnR8llcxWvAchvyFGFS+4Ojb8K BLlgwnSx2DeJpCuGDYTGQ8OHVJZkgdcwfOVXNIYgp0S7EvFy1egFcMEV5T8c9rOQ2He2 6448RNBpC85/HQOJbPS39m1+5DwUdbu2BL72R3kLxt6TYIpjGCmLxSrKzQABvFYohtZb SgPlsUvdx/rXl1eT/RmfR9r0fHUkMhWTOP9Akb2oXvtMVdtPjzk4D390+SCl4/lDp8uh sQJ/udqKNHuwWLu/gpq5B+X7+cv2WVIUx60VW3wMQz19LSpcH6x7wvtYVHTsYr863Wt3 SXiw== 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=+8LlCh4R5ybh3bTr4lnn0DXKD2oT+qArQ5x5gaHopCQ=; b=NhHK5e9WPlG0ceFsVqH8+yVBR0MU7puLlpyNjsIwQQwSDweRcMpXCly7ksgRyfDclw 2yCoWsvu8biQBaVEw11VKYHPWaXEmYhvTPH990XBmaXaLvdQNZjudTIacDhQU3pXcTZf l6vhiPfQHsqhN2t5xE0FsfHBZqibxp/czx1T+W3gXrtjkW02FviprB8A+ONHYZp1YgNH 9WAw0Gclxqe6kJIvAC0gX8czwoN4ogxf+kJYGnBlVqz6RtTaG9xi5ZTbuqUpoDSA+djZ ufNTUkOJ66PiooNJV2d6ewPAJ5DfrhfTrWQB6nhGSzr05VenCwJR+C3GD9vhVoBu3JsD eUKQ== X-Gm-Message-State: AODbwcCQMM1+rOpn2YTdztAGfJxtclNpZ5OCEY0p9OUWhauHMVfJJELz gmZpGPCOVyPRrU3tTFQ9UNFC2BIj6w== X-Received: by 10.25.29.82 with SMTP id d79mr236829lfd.130.1496309091616; Thu, 01 Jun 2017 02:24:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Thu, 1 Jun 2017 02:24:51 -0700 (PDT) In-Reply-To: <89f91631-063f-706c-b132-c24b72cab10e@tik.ee.ethz.ch> References: <89f91631-063f-706c-b132-c24b72cab10e@tik.ee.ethz.ch> From: Martin Thomson Date: Thu, 1 Jun 2017 19:24:51 +1000 Message-ID: Subject: Re: enumerate packets not to ack? To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Jana Iyengar , IETF QUIC WG , Patrick McManus 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: Thu, 01 Jun 2017 09:24:55 -0000 On 1 June 2017 at 17:47, Mirja K=C3=BChlewind wrote: > These are actually to different things. One is that you should not > send/generate an ack frame just because you received an ack frame but no > other data. The other point is that you actually can't really ack server > retry or version negotiation because they don't have a valid packet numbe= r. That might be better framing. On the issue, I suggested that we instead concentrate on describing what mechanisms we use to ensure reliability. I'm not sure that I got that right either, of course. From nobody Thu Jun 1 06:41: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 A782612EC93 for ; Thu, 1 Jun 2017 06:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lzuJT5cHjBRw for ; Thu, 1 Jun 2017 06:41:22 -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 8A78112EC8F for ; Thu, 1 Jun 2017 06:41:21 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 754F434080D; Thu, 1 Jun 2017 15:41:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.8022); Thu, 1 Jun 2017 15:41:18 +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; Thu, 1 Jun 2017 15:41:18 +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 19398712; Thu, 01 Jun 2017 15:41:18 +0200 Subject: Re: Should QUIC have a path-verifiable proof of source address? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_632A21F0-6D86-4D9D-A306-9C1D9CE625A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> Date: Thu, 1 Jun 2017 15:41:17 +0200 Cc: Martin Thomson , Christian Huitema , QUIC WG Message-Id: <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= 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: Thu, 01 Jun 2017 13:41:25 -0000 --Apple-Mail=_632A21F0-6D86-4D9D-A306-9C1D9CE625A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 01 Jun 2017, at 10:37, Mirja K=C3=BChlewind = wrote: >=20 > Hi all, >=20 > On 01.06.2017 03:29, Martin Thomson wrote: >> On 1 June 2017 at 06:09, Christian Huitema = wrote: >>> Brian, I am not sure I understand your requirement. Do you mean >>> something like the reachability verification implicit in the three = ways >>> handshake of TCP? Or do you mean some kind of cryptographic proof = that >>> the device is allowed to use the source address? >>=20 >> At risk of speaking for Brian, I think that this is intended to cover >> the simple reachability verification implicit in TCP. That is, proof >> that the endpoint was able to see a packet that was sent to their >> claimed address. Or, yeah, what Martin said. > I just would like to note that TCP has a three-way handshake for this = purpose but also during the connection you have the ack number that is = visible to the network and also provides some proof that the sender is = able to receive packets at the indicated source address. Yep. This indicates another way to split this question: how important is = it to be able to distinguish spoofed from non-spoofed sources for = initial packets in a flow, versus to be able to do so in the middle of a = connection? Thanks, cheers, Brian >=20 > Mirja >=20 >>=20 >> The verification provided by ICE also works. There, it's not a >> three-way handshake, but two independent request/response = validations. >>=20 >> (I think that I see a companion to Brian's "what is an endpoint?" = doc: >> "what is a path?") >>=20 >=20 --Apple-Mail=_632A21F0-6D86-4D9D-A306-9C1D9CE625A7 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 iQIcBAEBCgAGBQJZMBl+AAoJEIoSt78L6kajjRcP/RP2/8s9KcM/y5pO2hVM2MAN 0JNLR+hxMTfMmN52qjAxgG1VYK67LgW6ATZaU74alwVdJ0f5sd/Xb/3jUj7cXglR wIVylO7UblRkofuvwjAZTmm2OmQCAdfEEgF2Q4XuFC+i23zp7IwDhuX4r5cu1usx KXpHKsz2N4tEUs5EXs4OKRNtHu8C2y39waHtbYE5yAJ+EpUnhe6s7COyQusxmxLg Ea21EcIpaD7q+8XKrXyfKTqIbUFouaW00Zx1jgPDM+Hio+7YMxGy8KW/Mhz4cEYh aWFiBd+hL+EKH5YCw/EQ1a4a9TktQnx9yC8QrySQ+O7UlftbLeIO1nubbUMvizhT 0PlrFMmwJ0NHJBn0eZts7K96DwM50hMd9mbEm/un7ikTxRcZ0A7aBeIa0a9x9+P9 g4dPBv1Pfbbn7X3NRHLsa5VM9eNombTsldj4hzFICE/8bVGSCPP36RvNAVp2bi7+ EgqjnCLtWvi90uPP6WfibNQ+kjV2dCzsymbMeV3vvnWXLyrnsAk0YRdXuEkoX5Ac DG5JkTFP7zNndIw1jDBJ53h0ydcwZsmYMcf6EiUILVNqglYsvXjhAukHRlu24JRy UY0rNMi73Im3MBTDEpIfTNsNDdib+tUSwvclLQMhXCC+nEbrfqvlnQonDQV/21nO M5H4cdUt4PzMDMSmDxIf =0U2q -----END PGP SIGNATURE----- --Apple-Mail=_632A21F0-6D86-4D9D-A306-9C1D9CE625A7-- From nobody Thu Jun 1 06:42: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 4750612EC93 for ; Thu, 1 Jun 2017 06:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 oTIfx8Rjc49r for ; Thu, 1 Jun 2017 06:42:19 -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 8E97F12EC8F for ; Thu, 1 Jun 2017 06:42:19 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5F7B5340CAF for ; Thu, 1 Jun 2017 15:42:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.8760); Thu, 1 Jun 2017 15:42:18 +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 ; Thu, 1 Jun 2017 15:42:18 +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 19398842 for quic@ietf.org; Thu, 01 Jun 2017 15:42:18 +0200 From: Brian Trammell (IETF) X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_77F2BE9A-7A02-4D75-B039-1EC2BBB177F8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: On the passive measurability of QUIC Date: Thu, 1 Jun 2017 15:42:18 +0200 Message-Id: To: QUIC WG 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: Thu, 01 Jun 2017 13:42:21 -0000 --Apple-Mail=_77F2BE9A-7A02-4D75-B039-1EC2BBB177F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Here's a second, longer list of requirements questions I think we should = ask directly: "To what extent should the design of QUIC support passive measurement of = QUIC flows?" [1] There is one measurement task specifically called out in the text on = manageability in our charter: "the ability to export information about = flows for accounting purposes". To the extent that this process can map = IP addresses to accountable entities, this is trivially supported by = layering on top of UDP and IP. Accounting processes may additionally = seek to classify traffic as QUIC or not-QUIC, which they can do as of = -03 if they observe the 1-RTT handshake (or, simply, make the assumption = that udp/443 is always HTTP over QUIC). Which leads to the first related = subquestion: 1. "Should QUIC packets / flows be distinguishable from non-QUIC flows = on the wire?" Other accounting processes, of course, will want to classify = applications atop QUIC, but I won't even ask that question. It's = precluded by our charter: TLS over TCP (without STARTTLS) does not = expose any application-layer protocol identification, except via server = port number. Determining which other measurement primitives we want to support, IMO, = requires a survey to determine which are actually used in network = operations. Within IPPM and LMAP, the metrics that get the most = attention are packet loss, latency, jitter, and throughput. I also asked = a vendor of IPFIX collecting devices which passive TCP measurement = information elements are most often exported by passive measurement = boxes, and loss/retransmission and RTT were at the top of the list. So, = two more subquestions: 2. "Should end-to-end latency of QUIC flows be measurable by = observation?" and 3. "Should end-to-end packet loss, or reactions to loss, of QUIC flows = be measurable by observation? Related to loss, but not yet widely deployed or measured, is explicit = congestion notification. We anticipate growth in ECN deployment related = to widespread and growing client- and server-default negotiation of ECN = for TCP, and as such, I'd add the following related question: 4. "Should end-to-end congestion, indicated by explicit congestion = notification, or reactions thereto, of QUIC flows be measurable by = observation?" Passive measurement today is done by inference on information = non-optionally exposed by the transport stack. We have the opportunity = to change that with QUIC. Following the priniciples in [1], I'd = therefore ask the following final question: 5. "What level of control over observer capability should be available = to end users, application developers, and application and transport = protocol implementors?" As with the spoofing question, it'd be useful IMO to try and stay off = mechanisms for now, and to focus on desirability, and what cost we're = willing to pay (and not to pay) for these properties of measurability. Thanks, cheers, Brian - - - [1] Way too much background on this in a paper in the April 2017 ACM CCR = (I'm a coauthor); arXiv version at https://arxiv.org/abs/1612.02902 -- = the principles described there are IMO useful to guide thinking about = any measurability we do build into the protocol. --Apple-Mail=_77F2BE9A-7A02-4D75-B039-1EC2BBB177F8 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 iQIcBAEBCgAGBQJZMBm6AAoJEIoSt78L6kaj3KEP/15i9aYoKuD77S6JkxdEIjqx QMnLjvRtJOnzT/XLZYjYjBjWidiGfQv5aAm1Qc0VeguTO/VpKzTWTfJanPHRewNE tmBY9C3q5uDn7QvWw8LUoRzeVeoP6jrs6JZz3wL5Qg08i9aSb8KqjQpVAiW3apBF OwVtdta+28LRAjzGG97AOyL54jH+4qo20/jVnAR7QFU5Q7lQGsp84l2n07H7uT6s hFzdDOKwpvzN4ZgQPzfr+ckBrtwo6sUPDCdTNJpTu+Cp2URwbzuT749Z9/QXeAmU +oXv2ZzLp/kJXlAdCI0CTpDn0hDVQY84znMb178oYPXbUjOE5ACNU/8tqar/JuDh C/Z008UPoV7+2TKvrY/WI/3tQAguJ/olRNUsWE1hCHzWPGQ98Dkf75iEBb0GGhG7 8OhiSP0XxsLLQxN6RmKKwU3EGnyHUQgA2aKU5XyTfHHNAnGsyrmaSYVxdlrvp77+ bM1zvH0R+MKpuZ68nNMK60Givfs64Lp9veZRfsf55qmhLy1vpXceWwBjZOaEY+hL e+im1dpGo9/7o3bsD6OLL7EGkPSVFd+r3v5F2hOWkwnG0VTGf6nrHBVbUjJjCHSf UvZWrDydXJGnWyvF5nQAmEv8D/I4Aw2UTF8KdJF4fAJ+SZgQiF2bIOWrm6GnenUO cPSeCZVO/JyEsu01iUSv =1qUJ -----END PGP SIGNATURE----- --Apple-Mail=_77F2BE9A-7A02-4D75-B039-1EC2BBB177F8-- From nobody Thu Jun 1 06:55:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A5112ECB5 for ; Thu, 1 Jun 2017 06:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, 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 KOSLvtk_TwBl for ; Thu, 1 Jun 2017 06:55:52 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::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 44E95128D40 for ; Thu, 1 Jun 2017 06:55:52 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id 202so10965164ybd.0 for ; Thu, 01 Jun 2017 06:55:52 -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=VnQf+YUIm6nsdv/KeOTvdzrwUnpIP4WD46amLlQrNJY=; b=Flsg+LStkV7TPiQRgCtsrC+EIhpOkaITmzHHEVccJ4zonbM6NZ221vmJWQkI8m/3Vg /v2kgiPHPe0oSQw8TRi1LNpMzIsUh3yt89j0gR2Q/GH+twK5zXn+8uaN9FxO6+UJzIEM PNois9ISwayAwcb9NHFFtlRGkNS2B/oCBgY1mPGKBvJfTKLydWoxC0cke4OY32pH515C pY2wqwg8OZENPW1leH/FPyCMfBgl6BTcKKZohWwgRRy94W+SLCXO+kxb5ziWlBDSjP0z Iwd/fFR5CfYjC2nFJCtB9kV3A21z4edcGZZYnmzXSPoK2HZkObES219DjR+OLAoUgCfL Uslg== 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=VnQf+YUIm6nsdv/KeOTvdzrwUnpIP4WD46amLlQrNJY=; b=iAAtB1FLWG5J4w2fgwwyWi0YG6PqHkl0VBoqizZFvX1Rq0s4fAkGj4lWQuKwyY9QAa EcF3HUJQx5ScYTelrqMzsAHSFUbb0MFh0U+Xn3gNVFUUPwXtWRahAGsFuJZawYCAI50Q 2e4c0SB3KqH4TsHfAEkYkoUTb4u04r7C4nuQzVosPvqOeZYKWtMssh7Aj5qzJYTo3Ney 9y544+awRIdUZU8DovN7Ig0KTJx1WAWO7ivAqHXehm87JNExlJPVXchIiKP7epS2EF11 bH9W+ZipnfrpGKX2K41nED31x8pnCkVmxAEQKqMdnFUNVqIlhQZDxq/zzrs/+1Xywo22 CAwQ== X-Gm-Message-State: AODbwcCtZSUW50lQx4Y/yeAVFFg6s+ea7pS0rarsgrzGVnKkdD6gKJR8 0Ljr5HPVB8B5fVkqH35jqI6Z1/FvHpufqo0= X-Received: by 10.37.173.29 with SMTP id y29mr2502911ybi.52.1496325351381; Thu, 01 Jun 2017 06:55:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.106.137 with HTTP; Thu, 1 Jun 2017 06:55:10 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 1 Jun 2017 06:55:10 -0700 Message-ID: Subject: Re: On the passive measurability of QUIC To: Brian Trammell Cc: QUIC WG Content-Type: multipart/alternative; boundary="f403045da69c09db3e0550e665f5" 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, 01 Jun 2017 13:55:54 -0000 --f403045da69c09db3e0550e665f5 Content-Type: text/plain; charset="UTF-8" I like the general framing of these questions, but it's pretty hard to address them in the abstract. Rather, I think it would be more useful to start not with the specific properties but rather with the *services* that collecting these measurements is intended to facilitate and then work forward to the various baskets of measurements you would need to support said services and from that try to make a cost/benefit analysis [0]. Do you or someone else have such a list of services? -Ekr [0] Where the cost clearly has to include future unknown privacy risk. On Thu, Jun 1, 2017 at 6:42 AM, Brian Trammell wrote: > Greetings, all, > > Here's a second, longer list of requirements questions I think we should > ask directly: > > > "To what extent should the design of QUIC support passive measurement of > QUIC flows?" [1] > > > There is one measurement task specifically called out in the text on > manageability in our charter: "the ability to export information about > flows for accounting purposes". To the extent that this process can map IP > addresses to accountable entities, this is trivially supported by layering > on top of UDP and IP. Accounting processes may additionally seek to > classify traffic as QUIC or not-QUIC, which they can do as of -03 if they > observe the 1-RTT handshake (or, simply, make the assumption that udp/443 > is always HTTP over QUIC). Which leads to the first related subquestion: > > 1. "Should QUIC packets / flows be distinguishable from non-QUIC flows on > the wire?" > > Other accounting processes, of course, will want to classify applications > atop QUIC, but I won't even ask that question. It's precluded by our > charter: TLS over TCP (without STARTTLS) does not expose any > application-layer protocol identification, except via server port number. > > Determining which other measurement primitives we want to support, IMO, > requires a survey to determine which are actually used in network > operations. Within IPPM and LMAP, the metrics that get the most attention > are packet loss, latency, jitter, and throughput. I also asked a vendor of > IPFIX collecting devices which passive TCP measurement information elements > are most often exported by passive measurement boxes, and > loss/retransmission and RTT were at the top of the list. So, two more > subquestions: > > 2. "Should end-to-end latency of QUIC flows be measurable by observation?" > > and > > 3. "Should end-to-end packet loss, or reactions to loss, of QUIC flows be > measurable by observation? > > Related to loss, but not yet widely deployed or measured, is explicit > congestion notification. We anticipate growth in ECN deployment related to > widespread and growing client- and server-default negotiation of ECN for > TCP, and as such, I'd add the following related question: > > 4. "Should end-to-end congestion, indicated by explicit congestion > notification, or reactions thereto, of QUIC flows be measurable by > observation?" > > Passive measurement today is done by inference on information > non-optionally exposed by the transport stack. We have the opportunity to > change that with QUIC. Following the priniciples in [1], I'd therefore ask > the following final question: > > 5. "What level of control over observer capability should be available to > end users, application developers, and application and transport protocol > implementors?" > > > As with the spoofing question, it'd be useful IMO to try and stay off > mechanisms for now, and to focus on desirability, and what cost we're > willing to pay (and not to pay) for these properties of measurability. > > > Thanks, cheers, > > Brian > > - - - > > [1] Way too much background on this in a paper in the April 2017 ACM CCR > (I'm a coauthor); arXiv version at https://arxiv.org/abs/1612.02902 -- > the principles described there are IMO useful to guide thinking about any > measurability we do build into the protocol. > > --f403045da69c09db3e0550e665f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the general framing of these questions, but it'= s pretty hard to address them in
the abstract. Rather, I think it would= be more useful to start not with the specific properties
but rat= her with the *services* that collecting these measurements is intended to f= acilitate
and then work forward to the various baskets of measure= ments you would need to
support said services and from that try t= o make a cost/benefit analysis [0]. Do you or
someone else have s= uch a list of services?

-Ekr

<= div>[0] Where the cost clearly has to include future unknown privacy risk.<= /div>

On Thu= , Jun 1, 2017 at 6:42 AM, Brian Trammell <ietf@trammell.ch> w= rote:
Greetings, all,

Here's a second, longer list of requirements questions I think we shoul= d ask directly:


"To what extent should the design of QUIC support passive measurement = of QUIC flows?" [1]


There is one measurement task specifically called out in the text on manage= ability in our charter: "the ability to export information about flows= for accounting purposes". To the extent that this process can map IP = addresses to accountable entities, this is trivially supported by layering = on top of UDP and IP. Accounting processes may additionally seek to classif= y traffic as QUIC or not-QUIC, which they can do as of -03 if they observe = the 1-RTT handshake (or, simply, make the assumption that udp/443 is always= HTTP over QUIC). Which leads to the first related subquestion:

1. "Should QUIC packets / flows be distinguishable from non-QUIC flows= on the wire?"

Other accounting processes, of course, will want to classify applications a= top QUIC, but I won't even ask that question. It's precluded by our= charter: TLS over TCP (without STARTTLS) does not expose any application-l= ayer protocol identification, except via server port number.

Determining which other measurement primitives we want to support, IMO, req= uires a survey to determine which are actually used in network operations. = Within IPPM and LMAP, the metrics that get the most attention are packet lo= ss, latency, jitter, and throughput. I also asked a vendor of IPFIX collect= ing devices which passive TCP measurement information elements are most oft= en exported by passive measurement boxes, and loss/retransmission and RTT w= ere at the top of the list. So, two more subquestions:

2. "Should end-to-end latency of QUIC flows be measurable by observati= on?"

and

3. "Should end-to-end packet loss, or reactions to loss, of QUIC flows= be measurable by observation?

Related to loss, but not yet widely deployed or measured, is explicit conge= stion notification. We anticipate growth in ECN deployment related to wides= pread and growing client- and server-default negotiation of ECN for TCP, an= d as such, I'd add the following related question:

4. "Should end-to-end congestion, indicated by explicit congestion not= ification, or reactions thereto, of QUIC flows be measurable by observation= ?"

Passive measurement today is done by inference on information non-optionall= y exposed by the transport stack. We have the opportunity to change that wi= th QUIC. Following the priniciples in [1], I'd therefore ask the follow= ing final question:

5. "What level of control over observer capability should be available= to end users, application developers, and application and transport protoc= ol implementors?"


As with the spoofing question, it'd be useful IMO to try and stay off m= echanisms for now, and to focus on desirability, and what cost we're wi= lling to pay (and not to pay) for these properties of measurability.


Thanks, cheers,

Brian

- - -

[1] Way too much background on this in a paper in the April 2017 ACM CCR (I= 'm a coauthor); arXiv version at https://arxiv.org/abs/1612.02902 -- the principles described there are IMO useful to guide thinki= ng about any measurability we do build into the protocol.


--f403045da69c09db3e0550e665f5-- From nobody Thu Jun 1 08:07: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 A1C0B12ECA3 for ; Thu, 1 Jun 2017 08:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qmOtT9lgMg3C for ; Thu, 1 Jun 2017 08:07:15 -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 DC29112ECA7 for ; Thu, 1 Jun 2017 08:07:14 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 554BF3407BA; Thu, 1 Jun 2017 17:07:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.25229); Thu, 1 Jun 2017 17:07:12 +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; Thu, 1 Jun 2017 17:07:12 +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 19411720; Thu, 01 Jun 2017 17:07:09 +0200 Subject: Re: On the passive measurability of QUIC Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6106A0B7-D75B-4513-8E7A-46AAA8D46667"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 1 Jun 2017 17:07:07 +0200 Cc: QUIC WG Message-Id: References: To: Eric Rescorla 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: Thu, 01 Jun 2017 15:07:18 -0000 --Apple-Mail=_6106A0B7-D75B-4513-8E7A-46AAA8D46667 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi ekr, > On 01 Jun 2017, at 15:55, Eric Rescorla wrote: >=20 > I like the general framing of these questions, but it's pretty hard to = address them in > the abstract. Rather, I think it would be more useful to start not = with the specific properties > but rather with the *services* that collecting these measurements is = intended to facilitate > and then work forward to the various baskets of measurements you would = need to > support said services and from that try to make a cost/benefit = analysis [0]. Do you or > someone else have such a list of services? Sure. Here are the ones I know about off the top of my head. Note here, = for "services", I understand "higher-level measurement activities", or = what would be called "solutions" on the marketing-heavy websites of the = vendors who build these boxes. Please correct me if I'm wrong here. = "Service" is unfortunately so overloaded a term as to be unclear in many = cases, even with context. 1. Access network performance measurement. This is largely the problem = the LMAP WG is chartered to address, using IPPM metrics. Here, peak = achievable throughput (of an access link), loss, latency, and = (sometimes) jitter are the metrics of interest, both in controlled = testing (active measurement) as well as passive measurement of user = traffic, on the theory both that accidental and intentional differential = treatment of measurement traffic will make active measurement = unreliable, as well as to reduce network load due to unproductive active = measurement traffic. Loss/congestion and latency are the primary = passively measurable metrics of interest here. This measurement activity = is used by network operators for capacity planning and troubleshooting = purposes, as well as by national and supranational regulatory agencies = to hold network operators within their jurisdictions accountable. The = deployment location changes depending on who's performing the = measurements, but it's generally run as close as possible to the access = link (for broadband access) or on the handset itself (for mobile = measurements). 2. Interdomain troubleshooting of network performance issues. See = https://github.com/quicwg/base-drafts/issues/166. Though it proposes a = mechanism, it clearly calls out the key metrics as packet loss and = congestion, with the ability to localize congestion using = multi-observation-point measurement as important. 3. Service performance monitoring (my example here was Boundary, which = is apparently called bmc TrueSight Pulse (tm) now) uses passive = network-level latency and throughput measurements to augment information = collected by agents running on servers themselves to isolate performance = issues on those servers. 4. Perimeter security monitoring of access and enterprise networks. = Related to work in the DOTS WG, which focuses specifically on the DDoS = mitigation aspect of this broad topic. This is largely concerned with = detecting and blocking attack traffic. Most of the measurement task in = this case is classifying traffic as benign or not, and it uses any input = available to make that determination. None of the metrics I talk about = in the previous message are really relevant here, though -- spoofed = traffic detection is more useful in this context than latency. It's = relevant to QUIC, though, in that one of the inputs to this = classification is whether traffic is TCP or not: the more likely QUIC = traffic is to be classified as default-benign, the better its = deployability on networks employing this monitoring. The obvious one mentioned in our charter, for completeness: -1. Billing, both for metered consumer-grade access as well as transit = contracts. This is -1 because it's not really relevant to transport = protocol design, as it generally doesn't require anything beyond = byte/packet count per billable user, where the billable user is usually = associated with something that happens below layer 3, zero-rating and = other such practices notwithstanding. > -Ekr >=20 > [0] Where the cost clearly has to include future unknown privacy risk. Evaluating an unknown risk is a pretty cool trick. ;) Seriously, though, I'd really appreciate any suggestions you would have = as to how to concretely evaluate this risk, at least for purposes of = comparison of proposals. Information theoretic metrics seem to me to be = not very useful here, since they make the implicit (and false) = assumption that all bits of entropy are equally potentially dangerous to = privacy. Thanks, cheers, Brian --Apple-Mail=_6106A0B7-D75B-4513-8E7A-46AAA8D46667 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 iQIcBAEBCgAGBQJZMC2cAAoJEIoSt78L6kajNccP/A88VwdnkoJRyxCDztMVbgZK f4RH05FHVRqROj5iT3UJixveyfU1MgCViY9nSSUYH2ydi7oVTio7lhxQSpUeVv/v tvNNmp0LHxa9DVp6DsxUmaHtAAgcPURYq6KJQZ4/TfIM4Fq3BqZRcribb2DHzGvu wsWeO4N10WdgrlDlJ0pj9PMA/72YV26AokfmzToQjyPR+ZuCZNpFGBjQ80cb+c0B La3cZrWwTsBuf5F18QVrsFdW7pA3im4m6GIH8C1vB3rm8PyBs/ird+RVXRgNyeg0 m0aAEPvpcU6ZohHfGjo8AHj67fmh4dFH1gOGyFH6YxisNbZCJ/mS7IQ0PjC2l+5i a1R8zjNstcar6mL1/tCLlXB4aJ9G0xWfW/1Mxc5f4gtQ5X7DGgDTEr8KF/fx9Pw1 qCMvN6cJT4OYeD+HF5RVll6brLHZn53k8oVvhojrByJFiSwNC/+4jzNTan5EjcFk Q5d0qiEAGZ3kwluPnt2+C4Cx1ajk5lrHMYl+ZId8VaO3Rpqn/xVN8ZzCGWOLzzMu zx+19K/hpIWTIwIwF0RslcnRDmFTQXyP6phM+g2J938hvCDJeBs48oKrQOL97Sgv cv5O3VpDmu5vhawDL/lQswHIIEolZV6kunbnzGUDtnxSOiXqWOc/Wo1RBfkcId++ RDLsqYqokf++65DqxK3/ =C3ls -----END PGP SIGNATURE----- --Apple-Mail=_6106A0B7-D75B-4513-8E7A-46AAA8D46667-- From nobody Thu Jun 1 10:42:25 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41AF12F26D for ; Thu, 1 Jun 2017 10:42:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 iTrJ13tqnLmf for ; Thu, 1 Jun 2017 10:42:20 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.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 B166612EAAE for ; Thu, 1 Jun 2017 10:42:18 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 1 Jun 2017 13:42:17 -0400 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 1 Jun 2017 13:42:17 -0400 From: Dave Dolson To: "Brian Trammell (IETF)" , Eric Rescorla CC: QUIC WG Subject: RE: On the passive measurability of QUIC Thread-Topic: On the passive measurability of QUIC Thread-Index: AQHS2tznPqtDq9cNR0mnZJLX9d3qC6IQSrIAgAAUGoD//+W1cA== Date: Thu, 1 Jun 2017 17:42:15 +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: [192.168.200.114] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98705FBF43wtlexchp1sandvi_" 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: Thu, 01 Jun 2017 17:42:24 -0000 --_000_E8355113905631478EFF04F5AA706E98705FBF43wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And I have just uploaded https://tools.ietf.org/html/draft-dolson-transport= -middlebox-00 as an update to what I presented in Chicago, attempting to incorporate feed= back from the microphone and email. Abstract This document summarizes benefits that operators perceive to be provided by intermediary devices that provide functions apart from normal IP forwarding. Such intermediary devices are often called "middleboxes". RFC3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application-layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets. A primary goal of this document is to provide information to working groups developing new transport protocols, to aid understanding of what might be gained or lost by design decisions that may affect (or be affected by) middlebox operation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Operator Perspective . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Round Trip Times . . . . . . . . . . . . . . . . . . . . 6 2.3. Measuring Packet Reordering . . . . . . . . . . . . . . . 7 2.4. Throughput and Bottleneck Identification . . . . . . . . 7 2.5. Congestion Responsiveness . . . . . . . . . . . . . . . . 7 2.6. Attack Detection . . . . . . . . . . . . . . . . . . . . 8 2.7. Packet Corruption . . . . . . . . . . . . . . . . . . . . 8 2.8. Application-Layer Measurements . . . . . . . . . . . . . 9 3. Functions Beyond Measurement: A Few Examples . . . . . . . . 9 3.1. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. DDoS Scrubbing . . . . . . . . . . . . . . . . . . . . . 10 3.4. Implicit Identification . . . . . . . . . . . . . . . . . 11 3.5. Performance-Enhancing Proxies . . . . . . . . . . . . . . 11 3.6. Network Coding . . . . . . . . . . . . . . . . . . . . . 12 3.7. Network-Assisted Bandwidth Aggregation . . . . . . . . . 12 3.8. Prioritization and Differentiated Services . . . . . . . 13 3.9. Measurement-Based Shaping . . . . . . . . . . . . . . . . 13 3.10. Fairness to End-User Quota . . . . . . . . . . . . . . . 14 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 14 6.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 15 6.3. More Information Can Improve Security . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 -Dave -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell (IETF= ) Sent: Thursday, June 1, 2017 11:07 AM To: Eric Rescorla Cc: QUIC WG Subject: Re: On the passive measurability of QUIC hi ekr, > On 01 Jun 2017, at 15:55, Eric Rescorla > wrote: > > I like the general framing of these questions, but it's pretty hard to > address them in the abstract. Rather, I think it would be more useful > to start not with the specific properties but rather with the > *services* that collecting these measurements is intended to > facilitate and then work forward to the various baskets of > measurements you would need to support said services and from that try to= make a cost/benefit analysis [0]. Do you or someone else have such a list = of services? Sure. Here are the ones I know about off the top of my head. Note here, for= "services", I understand "higher-level measurement activities", or what wo= uld be called "solutions" on the marketing-heavy websites of the vendors wh= o build these boxes. Please correct me if I'm wrong here. "Service" is unfo= rtunately so overloaded a term as to be unclear in many cases, even with co= ntext. 1. Access network performance measurement. This is largely the problem the = LMAP WG is chartered to address, using IPPM metrics. Here, peak achievable = throughput (of an access link), loss, latency, and (sometimes) jitter are t= he metrics of interest, both in controlled testing (active measurement) as = well as passive measurement of user traffic, on the theory both that accide= ntal and intentional differential treatment of measurement traffic will mak= e active measurement unreliable, as well as to reduce network load due to u= nproductive active measurement traffic. Loss/congestion and latency are the= primary passively measurable metrics of interest here. This measurement ac= tivity is used by network operators for capacity planning and troubleshooti= ng purposes, as well as by national and supranational regulatory agencies t= o hold network operators within their jurisdictions accountable. The deploy= ment location changes depending on who's performing the measurements, but i= t's generally run as close as possible to the access link (for broadband ac= cess) or on the handset itself (for mobile measurements). 2. Interdomain troubleshooting of network performance issues. See https://g= ithub.com/quicwg/base-drafts/issues/166. Though it proposes a mechanism, it= clearly calls out the key metrics as packet loss and congestion, with the = ability to localize congestion using multi-observation-point measurement as= important. 3. Service performance monitoring (my example here was Boundary, which is a= pparently called bmc TrueSight Pulse (tm) now) uses passive network-level l= atency and throughput measurements to augment information collected by agen= ts running on servers themselves to isolate performance issues on those ser= vers. 4. Perimeter security monitoring of access and enterprise networks. Related= to work in the DOTS WG, which focuses specifically on the DDoS mitigation = aspect of this broad topic. This is largely concerned with detecting and bl= ocking attack traffic. Most of the measurement task in this case is classif= ying traffic as benign or not, and it uses any input available to make that= determination. None of the metrics I talk about in the previous message ar= e really relevant here, though -- spoofed traffic detection is more useful = in this context than latency. It's relevant to QUIC, though, in that one of= the inputs to this classification is whether traffic is TCP or not: the mo= re likely QUIC traffic is to be classified as default-benign, the better it= s deployability on networks employing this monitoring. The obvious one mentioned in our charter, for completeness: -1. Billing, both for metered consumer-grade access as well as transit cont= racts. This is -1 because it's not really relevant to transport protocol de= sign, as it generally doesn't require anything beyond byte/packet count per= billable user, where the billable user is usually associated with somethin= g that happens below layer 3, zero-rating and other such practices notwiths= tanding. > -Ekr > > [0] Where the cost clearly has to include future unknown privacy risk. Evaluating an unknown risk is a pretty cool trick. ;) Seriously, though, I'd really appreciate any suggestions you would have as = to how to concretely evaluate this risk, at least for purposes of compariso= n of proposals. Information theoretic metrics seem to me to be not very use= ful here, since they make the implicit (and false) assumption that all bits= of entropy are equally potentially dangerous to privacy. Thanks, cheers, Brian --_000_E8355113905631478EFF04F5AA706E98705FBF43wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And I have just uploaded https://tools.ietf.org/html/draft-dolson-transport-middlebox-00

as an update to what I presented in Chicago, atte= mpting to incorporate feedback from the microphone and email.

 

Abstract

 

   This document summarizes benefits that operators perceive t= o be

   provided by intermediary devices that provide functions apa= rt from

   normal IP forwarding.  Such intermediary devices are o= ften called

   "middleboxes".

 

   RFC3234 defines a taxonomy of middleboxes and issues in the= Internet.

   Most of those middleboxes utilize or modify application-lay= er data.

   This document primarily focuses on devices that observe and= act on

   information carried in the transport layer, and especially<= o:p>

   information carried in TCP packets.

 

   A primary goal of this document is to provide information t= o working

   groups developing new transport protocols, to aid understan= ding of

   what might be gained or lost by design decisions that may a= ffect (or

   be affected by) middlebox operation.

 

 

Table of Contents

 

   1.  Introduction  . . . . . . . . . . . . . . . .= . . . . . . . .   3

     1.1.  Operator Perspective  . . . . .= . . . . . . . . . . . . .   3

     1.2.  Scope . . . . . . . . . . . . . . . = . . . . . . . . . . .   4

     1.3.  Requirements Language . . . . . . . = . . . . . . . . . . .   5

   2.  Measurements  . . . . . . . . . . . . . . . .= . . . . . . . .   5

     2.1.  Packet Loss . . . . . . . . . . . . = . . . . . . . . . . .   5

     2.2.  Round Trip Times  . . . . . . .= . . . . . . . . . . . . .   6

     2.3.  Measuring Packet Reordering . . . . = . . . . . . . . . . .   7

     2.4.  Throughput and Bottleneck Identifica= tion  . . . . . . . .   7

    2.5.  Congestion Responsiveness . . . . . .= . . . . . . . . . .   7

     2.6.  Attack Detection  . . . . . . .= . . . . . . . . . . . . .   8

     2.7.  Packet Corruption . . . . . . . . . = . . . . . . . . . . .   8

     2.8.  Application-Layer Measurements = . . . . . . . . . . . . .   9

   3.  Functions Beyond Measurement: A Few Examples = . . . . . . . .   9

     3.1.  NAT . . . . . . . . . . . . . . . . = . . . . . . . . . . .   9

     3.2.  Firewall  . . . . . . . . . . .= . . . . . . . . . . . . .   9

     3.3.  DDoS Scrubbing  . . . . . . . .= . . . . . . . . . . . . .  10

     3.4.  Implicit Identification . . . . . . = . . . . . . . . . . .  11

     3.5.  Performance-Enhancing Proxies . . . = . . . . . . . . . . .  11

     3.6.  Network Coding  . . . . . . . .= . . . . . . . . . . . . .  12

     3.7.  Network-Assisted Bandwidth Aggregati= on  . . . . . . . . .  12

     3.8.  Prioritization and Differentiated Se= rvices  . . . . . . .  13

     3.9.  Measurement-Based Shaping . . . . . = . . . . . . . . . . .  13

     3.10. Fairness to End-User Quota  . . . . = . . . . . . . . . . .  14

   4.  Acknowledgements  . . . . . . . . . . . . . .= . . . . . . . .  14

   5.  IANA Considerations . . . . . . . . . . . . . . . = . . . . . .  14

   6.  Security Considerations . . . . . . . . . . . . . = . . . . . .  14

     6.1.  Confidentiality . . . . . . . . . . = . . . . . . . . . . .  14

     6.2.  Active Attacks  . . . . . . . .= . . . . . . . . . . . . .  15

     6.3.  More Information Can Improve Securit= y . . . . . . . . . .  15

   7.  References  . . . . . . . . . . . . . . . . .= . . . . . . . .  15

     7.1.  Normative References  . . . . .= . . . . . . . . . . . . .  15

     7.2.  Informative References  . . . .= . . . . . . . . . . . . .  16

   Authors' Addresses  . . . . . . . . . . . . . . . . . = . . . . . .  19

 

-Dave

 

 

 

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell (IETF= )
Sent: Thursday, June 1, 2017 11:07 AM
To: Eric Rescorla
Cc: QUIC WG
Subject: Re: On the passive measurability of QUIC

 

hi ekr,

 

> On 01 Jun 2017, at 15:55, Eric Rescorla <= ekr@rtfm.com> wrote:

>

> I like the general framing of these question= s, but it's pretty hard to

> address them in the abstract. Rather, I thin= k it would be more useful

> to start not with the specific properties bu= t rather with the

> *services* that collecting these measurement= s is intended to

> facilitate and then work forward to the vari= ous baskets of

> measurements you would need to support said = services and from that try to make a cost/benefit analysis [0]. Do you or s= omeone else have such a list of services?

 

Sure. Here are the ones I know about off the top = of my head. Note here, for "services", I understand "higher-= level measurement activities", or what would be called "solutions= " on the marketing-heavy websites of the vendors who build these boxes. Please correct me if I'm wrong here. "Service" is u= nfortunately so overloaded a term as to be unclear in many cases, even with= context.

 

 

1. Access network performance measurement. This i= s largely the problem the LMAP WG is chartered to address, using IPPM metri= cs. Here, peak achievable throughput (of an access link), loss, latency, an= d (sometimes) jitter are the metrics of interest, both in controlled testing (active measurement) as well as pa= ssive measurement of user traffic, on the theory both that accidental and i= ntentional differential treatment of measurement traffic will make active m= easurement unreliable, as well as to reduce network load due to unproductive active measurement traffic. Los= s/congestion and latency are the primary passively measurable metrics of in= terest here. This measurement activity is used by network operators for cap= acity planning and troubleshooting purposes, as well as by national and supranational regulatory agencies to = hold network operators within their jurisdictions accountable. The deployme= nt location changes depending on who's performing the measurements, but it'= s generally run as close as possible to the access link (for broadband access) or on the handset itself (for mo= bile measurements).

 

 

2. Interdomain troubleshooting of network perform= ance issues. See https://github.com/quicwg/base-draf= ts/issues/166. Though it proposes a mechanism, it clearly calls = out the key metrics as packet loss and congestion, with the ability to localize congestion using multi-observatio= n-point measurement as important.

 

 

3. Service performance monitoring (my example her= e was Boundary, which is apparently called bmc TrueSight Pulse (tm) now) us= es passive network-level latency and throughput measurements to augment inf= ormation collected by agents running on servers themselves to isolate performance issues on those servers.=

 

 

4. Perimeter security monitoring of access and en= terprise networks. Related to work in the DOTS WG, which focuses specifical= ly on the DDoS mitigation aspect of this broad topic. This is largely conce= rned with detecting and blocking attack traffic. Most of the measurement task in this case is classifying traffic = as benign or not, and it uses any input available to make that determinatio= n. None of the metrics I talk about in the previous message are really rele= vant here, though -- spoofed traffic detection is more useful in this context than latency. It's relevant to QU= IC, though, in that one of the inputs to this classification is whether tra= ffic is TCP or not: the more likely QUIC traffic is to be classified as def= ault-benign, the better its deployability on networks employing this monitoring.

 

 

The obvious one mentioned in our charter, for com= pleteness:

 

-1. Billing, both for metered consumer-grade acce= ss as well as transit contracts. This is -1 because it's not really relevan= t to transport protocol design, as it generally doesn't require anything be= yond byte/packet count per billable user, where the billable user is usually associated with something that ha= ppens below layer 3, zero-rating and other such practices notwithstanding.<= o:p>

 

 

> -Ekr

>

> [0] Where the cost clearly has to include fu= ture unknown privacy risk.

 

Evaluating an unknown risk is a pretty cool trick= . ;)

 

Seriously, though, I'd really appreciate any sugg= estions you would have as to how to concretely evaluate this risk, at least= for purposes of comparison of proposals. Information theoretic metrics see= m to me to be not very useful here, since they make the implicit (and false) assumption that all bits of entro= py are equally potentially dangerous to privacy.

 

Thanks, cheers,

 

Brian

 

--_000_E8355113905631478EFF04F5AA706E98705FBF43wtlexchp1sandvi_-- From nobody Thu Jun 1 11: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 1B4AE12F9A8 for ; Thu, 1 Jun 2017 11:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Ux1PXAnSfLgO for ; Thu, 1 Jun 2017 11:17:02 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6146A12F287 for ; Thu, 1 Jun 2017 11:17:02 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dGUeY-0007mk-6P for quic@ietf.org; Thu, 01 Jun 2017 20:17:00 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dGUeT-00009B-KP for quic@ietf.org; Thu, 01 Jun 2017 14:16:54 -0400 Received: (qmail 28317 invoked from network); 1 Jun 2017 18:16:52 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.129]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Jun 2017 18:16:52 -0000 To: quic@ietf.org References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> From: Christian Huitema Message-ID: <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> Date: Thu, 1 Jun 2017 11:16:34 -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: <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aaNswS4QI6eTgbo3cwm6DK6dgnVDnnGG3" Subject: Re: Should QUIC have a path-verifiable proof of source address? X-Originating-IP: 168.144.250.230 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.39) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJZYP2pkjqshrWYL747BjInHND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23n+Wz3L7GF6SgBODTEyHsdjCwsQwWQaOhgSJE qnWSx1AJGiE90SRKkhjiVTzW0bd3YOEkjsX7F8KmpUaZQHV+SejOO+5k046wqf0SEutzqoO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpOWca0Z0beD6jMx95O4U5K/6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyYvxPGJVX/aFUPtNFJEaV/HeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj234Kahp30YSTh5OL3yMqjF0jNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxiSsoNTiR/GmpPv4QzJ0uLs078I0y+3uS4dN KiUgYTBUdXbtWDnUeS4liyqO9jjmooAbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/RufmJqHIgpwQblHGid2pC00i13zjCiwPgdt77s k1WBMw== 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, 01 Jun 2017 18:17:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aaNswS4QI6eTgbo3cwm6DK6dgnVDnnGG3 Content-Type: multipart/mixed; boundary="VQ8SSwcCmNCkTFaSP8f6GMHVmKe3KrbVp"; protected-headers="v1" From: Christian Huitema To: quic@ietf.org Message-ID: <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> Subject: Re: Should QUIC have a path-verifiable proof of source address? References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> In-Reply-To: <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> --VQ8SSwcCmNCkTFaSP8f6GMHVmKe3KrbVp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/1/2017 6:41 AM, Brian Trammell (IETF) wrote: > Yep. This indicates another way to split this question: how important i= s it to be able to distinguish spoofed from non-spoofed sources for initi= al packets in a flow, versus to be able to do so in the middle of a conne= ction? OK. Let's tease that apart a bit more. QUIC runs over UDP. The UDP flow can be observed both during the initial phase and in the middle of the connection. As long as the routing is symmetric, the intermediate nodes can see that there are packets flowing in both directions. That's something of a baseline. I suppose the question is then about assumptions that these intermediate nodes can make. For example, a classic example is the need to separate legitimate traffic from a DOS attack. We can assume that in a basic DOS attack, packets will flow in just one direction, from the attacker to the target. So, a firewall that sees packet flowing in just one direction might detect an attack, and slow it down or filter it completely. It could do that by looking at nothing more than the UDP headers. But there may well be some packets coming back from the server, such as public reset packets. And then the naive firewall might mistakenly think that the traffic is legit, because the server is responding. At that point, there are two lines of thought. One is to provide information from the sever to the intermediate nodes. For example, if a smarter firewall would know that this is QUIC traffic, that public reset packets are not a sign that the server finds the traffic legit, and that the offending traffic should thus be slowed down or cut. But that means reliably distinguishing QUIC from other traffic, and letting nodes distinguish public reset from other packets. There is a slippery slope there, because nodes may also want to understand acknowledgements and progress, not just reset packets. The other line of thought is to place some of the defense against DOS burden on the server, and to ask it to just completely stop responding to any traffic that looks like an attack, so that intermediate firewalls can react to "absence of response". That is, the server can predict how the network will react to blow-back traffic, and thus thinks of consequences before sending packets. I kind of like the second approach. Servers would depend on some well known behavior of intermediate nodes, which would in fact force these nodes to be public about their behavior, even to standardize it. Something like standardizing AQM. That seems like a good path towards sanity. -- Christian Huitema --VQ8SSwcCmNCkTFaSP8f6GMHVmKe3KrbVp-- --aaNswS4QI6eTgbo3cwm6DK6dgnVDnnGG3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZMFoQAAoJELba05IUOHVQ0VUH/0GVUvHnlepwUwfvlQ1KySWY 9g9ml4S3GSvgodbQnR9VSoso6J8YTQAvkdF2q2Gcii0II/pSv7e0n/BW5VXrhPd6 NoKswveXqm+PGO84IOmW1yNYdCzeHKgVWpMKRv+Ago8uZMDRqNU5PFzezc4jTCep A9jQmUZ0qpA5pCeYPHoH1a9zma5IerYQqO06vssWe/VXQGA2wZx/B09eunIz7EfA 6PvJzmM4/whSqQJnunIqez8C8REUBhVqtTtWRZh40iNx2zPAnDx8KzXOS9g8qpeh MljWgNdzGu15iNv21UyMQ4XzMnWrQbrPS1qBL5xeSPtlL5FzQ+PBuHfhhh/xznk= =dosy -----END PGP SIGNATURE----- --aaNswS4QI6eTgbo3cwm6DK6dgnVDnnGG3-- From nobody Thu Jun 1 15:29:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3544E12778E for ; Thu, 1 Jun 2017 15:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 UmHE_3LyuV2k for ; Thu, 1 Jun 2017 15:29:02 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43974124D6C for ; Thu, 1 Jun 2017 15:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3wf27c0gf7zMpPd; Fri, 2 Jun 2017 00:29:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2mRptZwkLg3; Fri, 2 Jun 2017 00:28:59 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 2 Jun 2017 00:28:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [quicwg/base-drafts] packet number text limitation on 32 bits of packet number (#566) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 2 Jun 2017 00:28:58 +0200 Cc: quicwg/base-drafts , Subscribed Content-Transfer-Encoding: quoted-printable Message-Id: <14D430CF-1B62-497B-9DC9-89D45F9BB0CC@tik.ee.ethz.ch> References: To: quic@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 22:29:04 -0000 > Am 01.06.2017 um 19:40 schrieb Patrick McManus = : >=20 > 5.8 introduces the fact that only the least significant bits of a = packet number are transmitted and it goes on to say at most 32. >=20 > But acks can use 48. >=20 > I suggest fixing by just leaving out the number. >=20 > =E2=80=94 > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. >=20 From nobody Sat Jun 3 07:22: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 B9777129B95 for ; Sat, 3 Jun 2017 07:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 mmjZ4ghviE8e for ; Sat, 3 Jun 2017 07:22:49 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BE0129BCE for ; Sat, 3 Jun 2017 07:22:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3wg3Fg2HTMzMpLw; Sat, 3 Jun 2017 16:22:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oafyo0Xka4u8; Sat, 3 Jun 2017 16:22:45 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11994.dip0.t-ipconnect.de [217.225.25.148]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Sat, 3 Jun 2017 16:22:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Should QUIC have a path-verifiable proof of source address? From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> Date: Sat, 3 Jun 2017 16:22:46 +0200 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 14:22:52 -0000 The whole point here is to do the DDoS defense before the traffic = reaches your server to e.g. not overload the network between that DDoS = defense system and the server. The idea is that you start blocking = traffic from an IP address when you never see the third leg of a 2-way = exchange (return-routability check).=20 Are you proposing that if you don=E2=80=99t see a reply from the server = (leg 2) for a while (whatever a while means), you block the incoming = traffic from that IP address. That sounds dangerous to me as a middlebox = function. Mirja > Am 01.06.2017 um 20:16 schrieb Christian Huitema = : >=20 > On 6/1/2017 6:41 AM, Brian Trammell (IETF) wrote: >=20 >> Yep. This indicates another way to split this question: how important = is it to be able to distinguish spoofed from non-spoofed sources for = initial packets in a flow, versus to be able to do so in the middle of a = connection? >=20 > OK. Let's tease that apart a bit more. >=20 > QUIC runs over UDP. The UDP flow can be observed both during the = initial > phase and in the middle of the connection. As long as the routing is > symmetric, the intermediate nodes can see that there are packets = flowing > in both directions. That's something of a baseline. >=20 > I suppose the question is then about assumptions that these = intermediate > nodes can make. For example, a classic example is the need to separate > legitimate traffic from a DOS attack. We can assume that in a basic = DOS > attack, packets will flow in just one direction, from the attacker to > the target. So, a firewall that sees packet flowing in just one > direction might detect an attack, and slow it down or filter it > completely. It could do that by looking at nothing more than the UDP > headers. But there may well be some packets coming back from the = server, > such as public reset packets. And then the naive firewall might > mistakenly think that the traffic is legit, because the server is > responding. >=20 > At that point, there are two lines of thought. One is to provide > information from the sever to the intermediate nodes. For example, if = a > smarter firewall would know that this is QUIC traffic, that public = reset > packets are not a sign that the server finds the traffic legit, and = that > the offending traffic should thus be slowed down or cut. But that = means > reliably distinguishing QUIC from other traffic, and letting nodes > distinguish public reset from other packets. There is a slippery slope > there, because nodes may also want to understand acknowledgements and > progress, not just reset packets. >=20 > The other line of thought is to place some of the defense against DOS > burden on the server, and to ask it to just completely stop responding > to any traffic that looks like an attack, so that intermediate = firewalls > can react to "absence of response". That is, the server can predict = how > the network will react to blow-back traffic, and thus thinks of > consequences before sending packets. >=20 > I kind of like the second approach. Servers would depend on some well > known behavior of intermediate nodes, which would in fact force these > nodes to be public about their behavior, even to standardize it. > Something like standardizing AQM. That seems like a good path towards > sanity. >=20 > -- Christian Huitema >=20 From nobody Sat Jun 3 07:53: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 42050129AEE for ; Sat, 3 Jun 2017 07:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=netapp.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 qb6n-GlaOVmU for ; Sat, 3 Jun 2017 07:53:54 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E351286CA for ; Sat, 3 Jun 2017 07:53:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,290,1493708400"; d="asc'?scan'208";a="192238111" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx142-out.netapp.com with ESMTP; 03 Jun 2017 07:31:47 -0700 Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 3 Jun 2017 07:48:47 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Sat, 3 Jun 2017 07:48:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ru+zrY7z1fc5trVZwleWd7M7kRhOWlSyglDb38A94Wk=; b=UGQxBGdmb+fGVEnsSUjkpDzHGsQ0TjSKchowNafqKaZbE6dK+UR+vSs9/oKf01ZuUpd7ItKv705MDbfUkjUBIDrN+m8Ih6BWiFxbgsZi5bjuCJmsgNmTOTphTYqNO2uyaEo3GpEi3kqaWZQmkTa2Em7uu4lB7axhxKJn3GVdqnA= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Sat, 3 Jun 2017 14:48:45 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1143.016; Sat, 3 Jun 2017 14:48:45 +0000 From: "Eggert, Lars" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: Christian Huitema , "quic@ietf.org" Subject: Re: Should QUIC have a path-verifiable proof of source address? Thread-Topic: Should QUIC have a path-verifiable proof of source address? Thread-Index: AQHS2gSLRAiruyrEeEuTZne3W0LFa6IO34mAgABZeYCAAHeogIAAVMmAgABM6gCAAuNXAIAAB0CA Date: Sat, 3 Jun 2017 14:48:44 +0000 Message-ID: <77A01CE3-5779-470F-A9EF-E49B057D5381@netapp.com> References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: tik.ee.ethz.ch; dkim=none (message not signed) header.d=none;tik.ee.ethz.ch; dmarc=none action=none header.from=netapp.com; x-originating-ip: [2001:a61:319c:bf01:d8d7:6a84:aba9:6ae0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:bM/F7i1RZjqElkmhkPxTMPDFICVHb7F3Jn4TD5s99SzZkr7DYczjdWrYW+jSXM+lwQ8/Y1tO3braBmHeiYrywKUNuIRAgb+BlAMQzN5qglK3Z80ppxTZvimhC1MPPnkFwcG7e4e4xJnyQHdk2nT81Tp4LUlea1nfOMsWIqrtnFiNshqB/Drek+nNpFjZZ8SBZ5e5SJecx5gls/a6oXUYk5/9PAPdllO12vMRp+Jc5pKVqV1onbuNNb5pBE6oBsByJwh9N5l6++Vqu971IMvwuZeFVOTzHRtlvSWU8XASdj5Zh1pOVlR/22a7BzEsHTMX7m+H7GuZ9hxuCfRU4Li5jQ== x-ms-traffictypediagnostic: BLUPR06MB1762: x-ms-office365-filtering-correlation-id: 3482fb20-d769-4907-150b-08d4aa8fa2a0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1762; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39400400002)(39840400002)(39410400002)(39450400003)(24454002)(377424004)(2906002)(6436002)(189998001)(99286003)(6916009)(2950100002)(2900100001)(6512007)(54906002)(305945005)(102836003)(86362001)(8676002)(8936002)(81166006)(4326008)(14454004)(82746002)(4001150100001)(7736002)(25786009)(122556002)(50226002)(83716003)(3280700002)(99936001)(76176999)(3660700001)(50986999)(53546009)(53936002)(93886004)(33656002)(6506006)(229853002)(6486002)(77096006)(110136004)(36756003)(5660300001)(38730400002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_61C5D3BE-53A2-4387-A842-393D5A383EF4"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2017 14:48:44.9340 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.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: Sat, 03 Jun 2017 14:53:55 -0000 --Apple-Mail=_61C5D3BE-53A2-4387-A842-393D5A383EF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2017-6-3, at 16:22, Mirja K=C3=BChlewind = wrote: > Are you proposing that if you don=E2=80=99t see a reply from the = server (leg 2) for a while (whatever a while means), you block the = incoming traffic from that IP address. That sounds dangerous to me as a = middlebox function. but that's what middleboxes already do - they drop the binding if there = is no bidirectional traffic for a while. Maybe the timeout for this is = longer than is needed for DDoS defense, but it's not a new behavior. Lars --Apple-Mail=_61C5D3BE-53A2-4387-A842-393D5A383EF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlkyzEsACgkQVLXDCb9w wVenFg//XV3Ln8YFV8lsJYne+vmbboNAI2S1XS4k0F6Usds2h7KpdY1E0+3p2vbJ UFsRkXQIHj5I0GJOerfivEGOVi0UthEZ6Lk3scCX/Xu1tm6E99FoY9/sWeJp6LbJ cejRQpt+1ydQ4A2zSxNGFnG8QUeIgdouqewrLCkG4OBeTSBBKHSM+lD5GK6O0A4o X3djWUtCgPQxUO/o4NKbEf7at+SYnFO0f6GiUzo1255RzE4ug31/lHQMSnA2MXB1 wnOmVcU7x/nONydIhoxTPii7v7NV6FWszDb5CqkBis8lRMA0sluoW+0l0qSzsQ7o PUtVQ+54xwhnnQqInjBYc8gnwVa+o/7lfXIme8y0RlhebgNP15+gNfyTXBkw4Egk /rDgQXePYuC2CzAof7PlLPNeCRMFBrcLbSzycjqRtjR4WPq5ZCYnUcrNOBLeLo/R 7dYI25eTdEsEde3yfMcf3AqYCBlnBn9N99nH+JyMqb9xx/rgZI2zPZMIKjudMwyC BG7XijXYsSS7TJYUg4+VkDJxaD7e08HZ9HbSuMwACmFSZtxE6XTKq7VcurSKG6CQ 2mMkBUxIzr/KAlFb1jW84VJXZTbGfUGOgAoGY1lp7ffoAU+sWcR7ni2JASUxwH3Q BoHfHFoHmurg0sIC2ukUg7jdcuqkrUvQ6ylLqVtccouJvSyMs4k= =8JFT -----END PGP SIGNATURE----- --Apple-Mail=_61C5D3BE-53A2-4387-A842-393D5A383EF4-- From nobody Sat Jun 3 08:16: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 47B8E129423 for ; Sat, 3 Jun 2017 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=netapp.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 DVI0S-BZE4Wq for ; Sat, 3 Jun 2017 08:16:04 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0DA8120721 for ; Sat, 3 Jun 2017 08:16:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,290,1493708400"; d="asc'?scan'208";a="197281525" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx143-out.netapp.com with ESMTP; 03 Jun 2017 07:53:54 -0700 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 3 Jun 2017 08:11:02 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Sat, 3 Jun 2017 08:11:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A2IarvzNxARf7Ene5bwp4a3IM1b6CxrLM/i7IO334jA=; b=RY676p2PSWHfLorr3UzMd1Ou1y3c+Yqk2GNQ36p7gyJQnYndBAxuT+2tyyUWQeMQvmuT7ERCvCVPNLlco+cqy00sFhNrfKVo9w7zQ8ZL2wteqku70xaI2ROeiAn1ySYUFAwqDWQMZML4mSHXUhOeuIwNeN1apX44dKO1jPlhGQA= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Sat, 3 Jun 2017 15:11:01 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1143.016; Sat, 3 Jun 2017 15:11:00 +0000 From: "Eggert, Lars" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "quic@ietf.org" , Christian Huitema Subject: Re: Should QUIC have a path-verifiable proof of source address? Thread-Topic: Should QUIC have a path-verifiable proof of source address? Thread-Index: AQHS2gSLRAiruyrEeEuTZne3W0LFa6IO34mAgABZeYCAAHeogIAAVMmAgABM6gCAAuNXAIAAB0CAgAAGOYA= Date: Sat, 3 Jun 2017 15:11:00 +0000 Message-ID: References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> <77A01CE3-5779-470F-A9EF-E49B057D5381@netapp.com> In-Reply-To: <77A01CE3-5779-470F-A9EF-E49B057D5381@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: tik.ee.ethz.ch; dkim=none (message not signed) header.d=none;tik.ee.ethz.ch; dmarc=none action=none header.from=netapp.com; x-originating-ip: [2001:a61:319c:bf01:d8d7:6a84:aba9:6ae0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 7:P+/SNGOZgy+MInfQAS/ZizePTeoj8R9PmtpQcYRpD2qsyeqgy54DPW9d+OIem0qmKXWj8fcf9koLY6H/WDIal6r0n4CrSfh0TkBs4+H/AOnTebp/2GGIrlrobQP163umLsVLb/fPUcUx/KPilSrXczKfE9IjMwhFn2ZfmK6o4AIHL2LerT4Mzjd8wFRL0SV9gxcJnUar1VEJZqlVF+CnKOtRiux7MN1pzNOp20Bh8pJ31g2eknSXfQWLMPIA13HsIYrqAY7cGPUtunpJ3KC6TRkgk1luFjYySEsyv6ldU49Okhjy1TwWw3YQiXMIFk4hYpD9rPW1LNj7PlpgYK1R0g== x-ms-traffictypediagnostic: BLUPR06MB1763: x-ms-office365-filtering-correlation-id: 778f3e66-dc28-4e8d-a4ed-08d4aa92bec7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1763; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(377424004)(24454002)(6916009)(2950100002)(50226002)(8936002)(6506006)(81166006)(8676002)(6486002)(305945005)(7736002)(99286003)(54906002)(6512007)(77096006)(229853002)(53936002)(82746002)(83716003)(6436002)(25786009)(53546009)(36756003)(86362001)(76176999)(33656002)(2906002)(110136004)(4326008)(189998001)(3660700001)(3280700002)(14454004)(99936001)(5660300001)(93886004)(38730400002)(50986999)(4001150100001)(2900100001)(102836003)(6246003)(122556002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_D6B42F38-5DC8-496D-A4F0-DF389514262C"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2017 15:11:00.6597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.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: Sat, 03 Jun 2017 15:16:05 -0000 --Apple-Mail=_D6B42F38-5DC8-496D-A4F0-DF389514262C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2017-6-3, at 16:48, Eggert, Lars wrote: > On 2017-6-3, at 16:22, Mirja K=C3=BChlewind = wrote: >> Are you proposing that if you don=E2=80=99t see a reply from the = server (leg 2) for a while (whatever a while means), you block the = incoming traffic from that IP address. That sounds dangerous to me as a = middlebox function. >=20 > but that's what middleboxes already do - they drop the binding if = there is no bidirectional traffic for a while. Maybe the timeout for = this is longer than is needed for DDoS defense, but it's not a new = behavior. Ah. You said "IP address". That's obviously a broader block than one = binding. Lars --Apple-Mail=_D6B42F38-5DC8-496D-A4F0-DF389514262C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlky0YMACgkQVLXDCb9w wVc7wxAAgdu51JM4WksqXOgSvCSW2bRBM9IRjUMc6GXbGis3VNCxgADij4aZoO+Q K4ajZa7XpeYyXdDtaoqDGcFiGyYmaIbdO2z9ffXlGa52DbxzVJr9e0tt/laCPWJT Pd+0H2Yqj6iBNMsJ8n3l6mIrFM93R1t6CgdCV7rqn7Jh5cjeefLBgqloTujEEeI4 4n6UQVPf5NLE2w4tihJkh+aBy71nXSnUTluTl9t+upwZZXMftrMf4Xx/zapS3fbq nmrIHzDIUZRaJbtrJzuc0jMEor8kDhZZKHDLXmRmdQppsO1+ONZ34dDVuezg8MT+ NI/bXj9SBhTYs4sojbrhR9WU8BWdqD4mEI/bU5T3cf1f1uNle/oNT0Zyz2OV63rU x2LtisCphQphMRLS5JxHs4CjxcusCrEHMrapRGL/+JrvKBEuqGg9S5FNwSMgbXOR NCcVYE5DOIVGt8M9DXABfUrMRZ3jsu19SVeOoQy0XjUkeNAduWvudLMeIwRtXRAo wnvFubgSZ5yf2zSATJyPPZN63yGj+5JX203dyOrZUZG001D3TD89+jR8VkmYIE9p U2cN65JcvgscFdsUUVUJvoh2uxGqKezjWkwswOxvrxA4w5s6znyfHebdv7fYHrwB Nu+fMU5otZUQTNz7hPl76rUggyJiT2C9gVGBm8Pfta1XJoXUnDY= =vl5W -----END PGP SIGNATURE----- --Apple-Mail=_D6B42F38-5DC8-496D-A4F0-DF389514262C-- From nobody Sat Jun 3 12:26: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 1709D12700F for ; Sat, 3 Jun 2017 12:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObtIpKX9VcZ1 for ; Sat, 3 Jun 2017 12:26:06 -0700 (PDT) Received: from mx36-42.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 76FE8120454 for ; Sat, 3 Jun 2017 12:26:06 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1dHEgW-0002RI-He for quic@ietf.org; Sat, 03 Jun 2017 21:26:05 +0200 Received: from internal.xmail11.myhosting.com ([10.5.2.49] helo=xmail11.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dHEgR-00069Q-OM for quic@ietf.org; Sat, 03 Jun 2017 15:26:03 -0400 Received: (qmail 24570 invoked from network); 3 Jun 2017 19:25:56 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.129]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 Jun 2017 19:25:56 -0000 To: quic@ietf.org References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> <77A01CE3-5779-470F-A9EF-E49B057D5381@netapp.com> From: Christian Huitema Message-ID: <755694b1-9c62-f870-f2a0-d51d0726f5a5@huitema.net> Date: Sat, 3 Jun 2017 12:25:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ee0WTwDBc4lSFkLelEcUprioWMxlgTuVc" Subject: Re: Should QUIC have a path-verifiable proof of source address? X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.33) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbMzHFUa97P3bfY1LzB69ykND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23p3v9zl3ASSXvG8AY5g31gIUzrFsb4MS8Q2Ku zOfVaccxiGtZdj0H5BL0xVaGpTa5YOEkjsX7F8KmpUaZQHV+SaoNpL7PRmmTib7l1mO88Em2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpCbsjdvAic40+cHi4LtB9yD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyaDwpJ3cD0fqDcbWp5S+5wHeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17cd1G8DlRjMfIlvCoF6551S2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe91Y2lWQ2MJXd3CnOcfuxlrTMLn6MURQGfriekzS 9Ga3AA== 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: Sat, 03 Jun 2017 19:26:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ee0WTwDBc4lSFkLelEcUprioWMxlgTuVc Content-Type: multipart/mixed; boundary="2IlHTUaxJeb0LWI6cJnrw50hIkgpwO1vA"; protected-headers="v1" From: Christian Huitema To: quic@ietf.org Message-ID: <755694b1-9c62-f870-f2a0-d51d0726f5a5@huitema.net> Subject: Re: Should QUIC have a path-verifiable proof of source address? References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> <77A01CE3-5779-470F-A9EF-E49B057D5381@netapp.com> In-Reply-To: --2IlHTUaxJeb0LWI6cJnrw50hIkgpwO1vA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/3/2017 8:11 AM, Eggert, Lars wrote: > On 2017-6-3, at 16:48, Eggert, Lars wrote: >> On 2017-6-3, at 16:22, Mirja K=C3=BChlewind wrote: >>> Are you proposing that if you don=E2=80=99t see a reply from the serv= er (leg 2) for a while (whatever a while means), you block the incoming t= raffic from that IP address. That sounds dangerous to me as a middlebox f= unction. >> but that's what middleboxes already do - they drop the binding if ther= e is no bidirectional traffic for a while. Maybe the timeout for this is = longer than is needed for DDoS defense, but it's not a new behavior. > Ah. You said "IP address". That's obviously a broader block than one bi= nding. > Mirja, I was not so much proposing anything as stating the baseline. Exactly what Lars said. In the absence of some additional QUIC-specific smarts, middleboxes might do what firewalls and NAT commonly do today: drop the traffic, or in case of NAT drop the mapping for the 5-tuple if they don't see bidirectional traffic. This "bidirectional five-tuple" behavior is widely deployed. It is specified for NAT in RFC 4787, updated by RFC 7857 and RFC 6888. One possibility would be to start from there and look at improvements. We may discuss on the proper timeout -- such as short timeout if this is the first time a 5-tuple appears at all, longer timer if some bidirectional traffic has been seen. We may also discuss whether the drop should be hard, block everything, or soft, put the 5 tuple in some bandwidth restricted queue. And we may also discuss what else could be done if the middleboxes could reason on the QUIC headers. But there is definitely a baseline. Also note that the problem is twofold. I hear the desire of middlebox developers to implement some smarts in their devices. But there is the symmetric desire from application and transport to make the network behavior predictable. The current state is somewhat predictable: transports "know" that if the bidirectional traffic is not sustained, some middlebox might close the connection. So the implementations do send keep alive traffic. This is not a glorious state, but at least it is reasonably simple to understand. Part of the issue with "smarts in the middleboxes" is that it makes the network less predictable, and transports will have to invent new way to deal with what for them is new breakage. -- Christian Huitema -- Christian Huitema --2IlHTUaxJeb0LWI6cJnrw50hIkgpwO1vA-- --Ee0WTwDBc4lSFkLelEcUprioWMxlgTuVc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZMw1DAAoJELba05IUOHVQ0XoH/2TP7ezCJ3MndQoLcnVwsjbc eMQbQ4vts9OsCL/P//gfBh9zJ6KbXF1Dh4h0HpR7vfI3nj1ESqjy/oHFB74lQuDk tEedlL/HyZbeHIQOi15hyuMaTX5Dq2z6kxg0QHrzfola+Bj5Hq/33VanhwHlsRoD ebamh4d4Pkjj5PB8ad2aw7xK30Bh5cTPugqfY5YfL8g+Ut+SMpkXiTdZHBAXaC7R cNnjPiz1mVZJjFPLNd7xfQ8VMpAeXfveLcWZjECQEIL1GwagBYhzicVnmPA3jCvT jUqLnxWmR+8Drsnua6dRLTEzlpFsf5srnEvSeU7h04I0vNl1kgRPWK03EwrAqPA= =Waz8 -----END PGP SIGNATURE----- --Ee0WTwDBc4lSFkLelEcUprioWMxlgTuVc-- From nobody Sat Jun 3 12:32:25 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4D31270B4 for ; Sat, 3 Jun 2017 12:32:23 -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 MfsUkMB976ko for ; Sat, 3 Jun 2017 12:32:22 -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 194AB120454 for ; Sat, 3 Jun 2017 12:32:22 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id m17so65745560pfg.3 for ; Sat, 03 Jun 2017 12:32:21 -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=UvRZGs2YLHogoeIuPxyuPECBQOMMs0FNGCvGNP/cJZw=; b=RYRzoczAgE3gIHaFCGDSu07264dfKbjMAN2lJtBQ+OErCruw1KFkNhEAplFVv0Rb+A pHp1dCFVQVpChwgXjftOzeZqUejNsoWFfE6GPv6dlSJx8B9W0fYyF6Xef/HeXus98r18 V6CZqpOFvq91fUKao0XuQosa7vQEJv7PaGJbJwYzrexe/URD5YUmnk6mxYmCP4AwmEBm A7/kAzMVIxHs7fbIE4Db/hG6S4fJfO24xF8erft5yCvTehyUMI10JFQZ/vh2irv57KsK xS3pekNPJro12Ik/AiCWFluvxKbn4uENM/rQ4PwXtmJ8eAuAIQ5ZnDWY1lRPQCXcFZ8s IZLg== 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=UvRZGs2YLHogoeIuPxyuPECBQOMMs0FNGCvGNP/cJZw=; b=X7TuILBgSJHePVvzEvAbEfkPetAUcS7lo04ki7RJb5QtapuEG4Eb8wNrqXsUOFF7SK M07WqHst6gCOiw1ysBJ8YyCOqtMCMgFRLwoJuqCs4ExrGW1ORWrgS4iK+1FQdL4SZv7y UQGNhJZ+lQOGUak16HXMNcR7VfZmQiKqsxjHMa4Ahs7r/pKtsV+pfMhMj2t06tl9TEdM uF0xhI5inZ4SV/LZmA7ztvcHxt9YsoaIyu3YgDAsTVHI+6GXxWQB31NGuuTvfOY1vkdK fT4luyLjfZDAj7HyJUZIyryWUiP1V5e5clArLLJDWvfGaeyRSePJ+l9/7JkVE9Hz854z 7O9Q== X-Gm-Message-State: AODbwcCHXyJM2eFzJ7UjT8Sp3DhHTETTAIb0hucAlByoQ+fmwBN44PFN 25G32NSXg/oCMYieFn+/S8P7CZwGsg== X-Received: by 10.98.212.84 with SMTP id u20mr12631220pfl.116.1496518341621; Sat, 03 Jun 2017 12:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.207.228 with HTTP; Sat, 3 Jun 2017 12:32:21 -0700 (PDT) In-Reply-To: References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch> <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch> <79aeac00-c1eb-069a-2b21-018a8b393546@huitema.net> From: Watson Ladd Date: Sat, 3 Jun 2017 12:32:21 -0700 Message-ID: Subject: Re: Should QUIC have a path-verifiable proof of source address? To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Christian Huitema , IETF 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: Sat, 03 Jun 2017 19:32:23 -0000 On Sat, Jun 3, 2017 at 7:22 AM, Mirja K=C3=BChlewind wrote: > The whole point here is to do the DDoS defense before the traffic reaches= your server to e.g. not overload the network between that DDoS defense sys= tem and the server. The idea is that you start blocking traffic from an IP = address when you never see the third leg of a 2-way exchange (return-routab= ility check). How on earth do you have a fatter pipe from outside than inside? Whatever happened to smart hosts, dumb network? We can't even get explicit congestion notification deployed or multicast: things hosts actually need. > > Are you proposing that if you don=E2=80=99t see a reply from the server (= leg 2) for a while (whatever a while means), you block the incoming traffic= from that IP address. That sounds dangerous to me as a middlebox function. > > Mirja > From nobody Mon Jun 5 21:33: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 77FF4126BFD for ; Mon, 5 Jun 2017 21:33:00 -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, 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 KmCh2WewctKe for ; Mon, 5 Jun 2017 21:32:58 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C9E1201F8 for ; Mon, 5 Jun 2017 21:32:58 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l14so63501496ywk.1 for ; Mon, 05 Jun 2017 21:32:57 -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=y85Os/9LsNTjba2wGbnWHDAHc3MQA2ab5cB5P8QPxAw=; b=jsbTzxFw9pHy3fnL1evzkVMBVqYSHdY1etk0h9GH+3jnLnVJ8MYwSvFrOiT3Ctb5Ip FOobVOh/34K9qmC822trJqgk3VYRgIOhCbmiu5CriF7Oebt9f0cvQoPz4zmhrf4SRMoN sGwREAlLTR4/ACfsESqvr3JwTzlstuynFf5EuG7oncqMyviSK7dFlWFa4v5YUaJLecOB 5rsg4jLuGVYS6Cxep6kHe74zy75sUVpUB6dSe1vuAmobCDtAekbtxxj1O2sJEDu86vfU YYSoe589OLUYT7+6C0oR6f2jinrz7C/4oEAZtXFWcZWpKMCg3YKxcxk3MY4gmli8rlEy biXg== 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=y85Os/9LsNTjba2wGbnWHDAHc3MQA2ab5cB5P8QPxAw=; b=VXFtGXPA8UWYoJSDVWeuHDRNnrp5lkGQYt6Xxo74ua+NVbcxDMOpX5iY1NQ5hBcaA+ hg01PIiPQlnrdiIj2oluz4oA5zyc2IDLPAuAnxeFvXGcRSLPQduPkxBgjit0zWTwbx6A 5WuIP4sAxCbghj1Honf4/zoN/9NW+Ppwmm+8yAombD9Lx3TZJdIZYliVwJSCb5s/TkX1 Lmrt21TNbl1NqSGBHh/BXls2iGC0Nz2sDxew/lA+Hsmz8K4VFeGQd86M9DwjzY6qdX9u yxVITgusymUjYKUGfQ3OZhXcm9hy/k8187HejLjLRY3wrS+as3tTeXC+ohP7zNRPbekU i8QQ== X-Gm-Message-State: AODbwcA1hn9FLTdhMPpAAvUCdsZMvEvp1nQVwnuSJMglS2fXPCFbJLH1 20oFxPMb3/D8EwBgtPFtDKUPD74Aug== X-Received: by 10.129.78.84 with SMTP id c81mr1271708ywb.289.1496723577194; Mon, 05 Jun 2017 21:32:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.195.194 with HTTP; Mon, 5 Jun 2017 21:32:56 -0700 (PDT) Received: by 10.37.195.194 with HTTP; Mon, 5 Jun 2017 21:32:56 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Mon, 5 Jun 2017 23:32:56 -0500 Message-ID: Subject: Re: On the passive measurability of QUIC To: Brian Trammell Cc: IETF QUIC WG , Eric Rescorla Content-Type: multipart/alternative; boundary="001a114d2278255ca70551431dc0" 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, 06 Jun 2017 04:33:00 -0000 --001a114d2278255ca70551431dc0 Content-Type: text/plain; charset="UTF-8" So a couple of things, while wearing a couple of hats. On Jun 1, 2017 10:07, "Brian Trammell (IETF)" wrote: hi ekr, > On 01 Jun 2017, at 15:55, Eric Rescorla wrote: > > I like the general framing of these questions, but it's pretty hard to address them in > the abstract. Rather, I think it would be more useful to start not with the specific properties > but rather with the *services* that collecting these measurements is intended to facilitate > and then work forward to the various baskets of measurements you would need to > support said services and from that try to make a cost/benefit analysis [0]. Do you or > someone else have such a list of services? Sure. Here are the ones I know about off the top of my head. Note here, for "services", I understand "higher-level measurement activities", or what would be called "solutions" on the marketing-heavy websites of the vendors who build these boxes. Please correct me if I'm wrong here. "Service" is unfortunately so overloaded a term as to be unclear in many cases, even with context. As AD: this thread, like the spoofing thread, is the type of discussion on the management deliverable I was hoping the working group would have, when I agreed to approve the QUIC charter. Thank you. I know this conversation isn't easy, and so does the rest of the IESG, and so does the IAB. We had high level discussions in this space on the joint IAB-IESG day of our retreat a couple of weeks ago, and the ADs continued that discussion during both days of the IESG retreat. 1. Access network performance measurement. This is largely the problem the LMAP WG is chartered to address, using IPPM metrics. Here, peak achievable throughput (of an access link), loss, latency, and (sometimes) jitter are the metrics of interest, both in controlled testing (active measurement) as well as passive measurement of user traffic, on the theory both that accidental and intentional differential treatment of measurement traffic will make active measurement unreliable, as well as to reduce network load due to unproductive active measurement traffic. Loss/congestion and latency are the primary passively measurable metrics of interest here. This measurement activity is used by network operators for capacity planning and troubleshooting purposes, as well as by national and supranational regulatory agencies to hold network operators within their jurisdictions accountable. The deployment location changes depending on who's performing the measurements, but it's generally run as close as possible to the access link (for broadband access) or on the handset itself (for mobile measurements). 2. Interdomain troubleshooting of network performance issues. See https://github.com/quicwg/base-drafts/issues/166. Though it proposes a mechanism, it clearly calls out the key metrics as packet loss and congestion, with the ability to localize congestion using multi-observation-point measurement as important. 3. Service performance monitoring (my example here was Boundary, which is apparently called bmc TrueSight Pulse (tm) now) uses passive network-level latency and throughput measurements to augment information collected by agents running on servers themselves to isolate performance issues on those servers. 4. Perimeter security monitoring of access and enterprise networks. Related to work in the DOTS WG, which focuses specifically on the DDoS mitigation aspect of this broad topic. This is largely concerned with detecting and blocking attack traffic. Most of the measurement task in this case is classifying traffic as benign or not, and it uses any input available to make that determination. None of the metrics I talk about in the previous message are really relevant here, though -- spoofed traffic detection is more useful in this context than latency. It's relevant to QUIC, though, in that one of the inputs to this classification is whether traffic is TCP or not: the more likely QUIC traffic is to be classified as default-benign, the better its deployability on networks employing this monitoring. As a possibly helpful individual, this list seems to include implicitly what Erik mentioned explicitly in the spoofing thread - thinking about what trusts what, and what controls what. I thought that explictness would be helpful. The obvious one mentioned in our charter, for completeness: -1. Billing, both for metered consumer-grade access as well as transit contracts. This is -1 because it's not really relevant to transport protocol design, as it generally doesn't require anything beyond byte/packet count per billable user, where the billable user is usually associated with something that happens below layer 3, zero-rating and other such practices notwithstanding. As AD: this would be an especially useful assertion to converge on (after the interim, of course). If QUIC isn't able to help with billing(*), that needs to not be a Late Surprise (tm). Spencer (*) Back to speaking as an individual, one of the responses that would not surprise me is "applications using QUIC aren't much harder to bill for than applications using TLS or TCPINC, so, whatever you do for those, do it for QUIC". If something like that turns out to be the answer, people who care about billing need to be figuring out what Plan B is ... > -Ekr > > [0] Where the cost clearly has to include future unknown privacy risk. Evaluating an unknown risk is a pretty cool trick. ;) Seriously, though, I'd really appreciate any suggestions you would have as to how to concretely evaluate this risk, at least for purposes of comparison of proposals. Information theoretic metrics seem to me to be not very useful here, since they make the implicit (and false) assumption that all bits of entropy are equally potentially dangerous to privacy. Thanks, cheers, Brian --001a114d2278255ca70551431dc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So a couple of things, while wearing a couple of hat= s.

On Jun 1, 2= 017 10:07, "Brian Trammell (IETF)" <ietf@trammell.ch> wrote:
hi ekr,

> On 01 Jun 2017, at 15:55, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I like the general framing of these questions, but it's pretty har= d to address them in
> the abstract. Rather, I think it would be more useful to start not wit= h the specific properties
> but rather with the *services* that collecting these measurements is i= ntended to facilitate
> and then work forward to the various baskets of measurements you would= need to
> support said services and from that try to make a cost/benefit analysi= s [0]. Do you or
> someone else have such a list of services?

Sure. Here are the ones I know about off the top of my head. Note her= e, for "services", I understand "higher-level measurement ac= tivities", or what would be called "solutions" on the market= ing-heavy websites of the vendors who build these boxes. Please correct me = if I'm wrong here. "Service" is unfortunately so overloaded a= term as to be unclear in many cases, even with context.

As AD: this t= hread, like the spoofing thread, is the type of discussion on the managemen= t deliverable I was hoping the working group would have, when I agreed to a= pprove the QUIC charter. Thank you.

I know this conversation isn't easy, and so does the rest o= f the IESG, and so does the IAB. We had high level discussions in this spac= e on the joint IAB-IESG day of our retreat a couple of weeks ago, and the A= Ds continued that discussion during both days of the IESG retreat.=C2=A0

1= . Access network performance measurement. This is largely the problem the L= MAP WG is chartered to address, using IPPM metrics. Here, peak achievable t= hroughput (of an access link), loss, latency, and (sometimes) jitter are th= e metrics of interest, both in controlled testing (active measurement) as w= ell as passive measurement of user traffic, on the theory both that acciden= tal and intentional differential treatment of measurement traffic will make= active measurement unreliable, as well as to reduce network load due to un= productive active measurement traffic. Loss/congestion and latency are the = primary passively measurable metrics of interest here. This measurement act= ivity is used by network operators for capacity planning and troubleshootin= g purposes, as well as by national and supranational regulatory agencies to= hold network operators within their jurisdictions accountable. The deploym= ent location changes depending on who's performing the measurements, bu= t it's generally run as close as possible to the access link (for broad= band access) or on the handset itself (for mobile measurements).


2. Interdomain troubleshooting of network performance issues. See https://github.com/quicwg/base-drafts/issues/166. = Though it proposes a mechanism, it clearly calls out the key metrics as pac= ket loss and congestion, with the ability to localize congestion using mult= i-observation-point measurement as important.


3. Service performance monitoring (my example here was Boundary, which is a= pparently called bmc TrueSight Pulse (tm) now) uses passive network-level l= atency and throughput measurements to augment information collected by agen= ts running on servers themselves to isolate performance issues on those ser= vers.


4. Perimeter security monitoring of access and enterprise networks. Related= to work in the DOTS WG, which focuses specifically on the DDoS mitigation = aspect of this broad topic. This is largely concerned with detecting and bl= ocking attack traffic. Most of the measurement task in this case is classif= ying traffic as benign or not, and it uses any input available to make that= determination. None of the metrics I talk about in the previous message ar= e really relevant here, though -- spoofed traffic detection is more useful = in this context than latency. It's relevant to QUIC, though, in that on= e of the inputs to this classification is whether traffic is TCP or not: th= e more likely QUIC traffic is to be classified as default-benign, the bette= r its deployability on networks employing this monitoring.
=

As a possib= ly helpful individual, this list seems to include implicitly what Erik ment= ioned explicitly in the spoofing thread - thinking about what trusts what, = and what controls what. I thought that explictness would be helpful.
<= div dir=3D"auto">
The o= bvious one mentioned in our charter, for completeness:

-1. Billing, both for metered consumer-grade access as well as transit cont= racts. This is -1 because it's not really relevant to transport protoco= l design, as it generally doesn't require anything beyond byte/packet c= ount per billable user, where the billable user is usually associated with = something that happens below layer 3, zero-rating and other such practices = notwithstanding.

As AD: this would be an especially useful assertion t= o converge on (after the interim, of course).=C2=A0
=
If QUIC isn't able to help with billing(*),= that needs to not be a Late Surprise (tm).

Spencer

(*) Back to speaking as an individual, one of the responses that would = not surprise me is "applications using QUIC aren't much harder to = bill for than applications using TLS or TCPINC, so, whatever you do for tho= se, do it for QUIC". If something like that turns out to be the answer= , people who care about billing need to be figuring out what Plan B is ...<= /div>

> -Ekr
>
> [0] Where the cost clearly has to include future unknown privacy risk.=

Evaluating an unknown risk is a pretty cool trick. ;)

Seriously, though, I'd really appreciate any suggestions you would have= as to how to concretely evaluate this risk, at least for purposes of compa= rison of proposals. Information theoretic metrics seem to me to be not very= useful here, since they make the implicit (and false) assumption that all = bits of entropy are equally potentially dangerous to privacy.

Thanks, cheers,

Brian


--001a114d2278255ca70551431dc0-- From nobody Mon Jun 5 23:48:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE50C126B7F for ; Mon, 5 Jun 2017 23:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=OhpwuNfP; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=EOzne8jr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaA9TlAFh8mh for ; Mon, 5 Jun 2017 23:48:42 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47131200CF for ; Mon, 5 Jun 2017 23:48:42 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v566lhjx005352 for ; Mon, 5 Jun 2017 23:48:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=SINjw1gBH5Y4hIq+v82UGVtEOTUckFf64s5QUCJDFBY=; b=OhpwuNfPXH5WHqO8d4mAGeSnHN1Izqjln0WoWJHGsWsbktSq6XVDKEbLfs1RhHQCH4Cb 8vd90VYTN9/Muv0s4BqB102k9LkM8Ve+EX8vPUY229j2qUwf/WhHVlkXdUOQzl1cJsZy eAsRatItyrsAlNapZQnoa/hS/MRGIKPGIY4= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2awk9k8fxa-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 05 Jun 2017 23:48:26 -0700 Received: from PRN-CHUB02.TheFacebook.com (192.168.16.12) by PRN-CHUB01.TheFacebook.com (192.168.16.11) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 5 Jun 2017 23:48:25 -0700 Received: from NAM03-BY2-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; Mon, 5 Jun 2017 23:48:25 -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=SINjw1gBH5Y4hIq+v82UGVtEOTUckFf64s5QUCJDFBY=; b=EOzne8jrsE1u/wthQyQE+VM1NPKr9Glpp4cYTaFXpWzidU6R4eWuWaSE3Pfo0aySwM/xXjfUcux9D+Re6DEJ8332dxJuk75ULP2nBMvDZs/zijDqQJWTgbjmq0yOcM1qeaKpIeOFECb8AoTHvHhOqCat/QGaNcrvt5G/YxW0MK8= Received: from BN6PR15MB1299.namprd15.prod.outlook.com (10.172.206.137) by BN6PR15MB1298.namprd15.prod.outlook.com (10.172.206.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Tue, 6 Jun 2017 06:48:24 +0000 Received: from BN6PR15MB1299.namprd15.prod.outlook.com ([10.172.206.137]) by BN6PR15MB1299.namprd15.prod.outlook.com ([10.172.206.137]) with mapi id 15.01.1143.019; Tue, 6 Jun 2017 06:48:24 +0000 From: Alan Frindell To: IETF QUIC WG Subject: Comparing HTTP over QUIC header compression schemes Thread-Topic: Comparing HTTP over QUIC header compression schemes Thread-Index: AQHS3pDkbL6XmOk6K0ms9bs9UuyP1w== Date: Tue, 6 Jun 2017 06:48:24 +0000 Message-ID: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fb.com; x-originating-ip: [2a01:e35:2fd0:6950:255d:450:c1c4:276c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR15MB1298; 7:NYoRl292u4NjPxAeYzHAE/OtperstI+XDRPTTxQhs4ePvzjD/m4//uNTaEnzfcK7LmyxbR131LXU2PpAATn1nik39aQvXWzRh73W6ql/52uKlcQl2KKC6KmPDvqVJ14LO8JQgiMhrAOX0Zh2RRyF/3RuA/fm5FuLAHnP0vcLGGTKidq/dpAJN46q88V2c9d8ykVSGXQqQ/mXyBLnfJXBm0q3HGJTsmf15Q79BEgl164jg/Pwj17n4QauL1BXsTWdckqQ3LpSJGPd7H5LRJPIqiM1MsyYVNdkRlt++ByKPr5HojkwJKdChFPJg/2D9amuGw3kxN39EjGljm3GWy3nQw==; 20:cxk9rErqsMnb9IIlGT78lkghX42dMWAOcUDANatk0vNn/2oV9LE+5WOTvQ+kX+N0zjHSnphDOfDzZqXx2akCIqoszSb9XRMx9ehBpYLIB9CiCX1Kj9jASwnzYPt3/eEA2dI/L1YIciK5f7EQnO8cnlVLYvgTYQuF7pGHCmyP8lY= x-ms-traffictypediagnostic: BN6PR15MB1298: x-ms-office365-filtering-correlation-id: 6fd2f738-0cbe-4ca0-9cfc-08d4aca8074d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR15MB1298; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(166708455590820)(35073007944872)(60067363179207)(249562145798500)(81227570615382)(64217206974132); 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)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR15MB1298; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR15MB1298; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(81166006)(5660300001)(86362001)(3280700002)(8936002)(575784001)(8676002)(305945005)(189998001)(38730400002)(4001350100001)(7736002)(110136004)(6916009)(3660700001)(33656002)(6506006)(54356999)(77096006)(6486002)(551984002)(83716003)(2900100001)(25786009)(6436002)(966005)(478600001)(82746002)(14454004)(83506001)(102836003)(6116002)(2906002)(50986999)(53936002)(6306002)(6512007)(122556002)(36756003)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR15MB1298; H:BN6PR15MB1299.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0625D08983448D4E9BD0F1B7AF79E2EE@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 06:48:24.1842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1298 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-06-06_05:, , 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: Tue, 06 Jun 2017 06:48:45 -0000 SSBidWlsdCBhIFFDUkFNIGFuZCBRUEFDSyBpbXBsZW1lbnRhdGlvbiBhbmQgYXR0ZW1wdGVkIHRv IHNpbXVsYXRlIHBlcmZvcm1hbmNlIHVuZGVyIHZhcnlpbmcgbmV0d29yayBjb25kaXRpb25zLiAg SGVyZeKAmXMgYSBzdW1tYXJ5IG9mIHRoZSB3b3JrIHNvIGZhci4NCg0KLUFsYW4NCg0KPT09DQoN ClByb2JsZW0NCg0KSFRUUC8yIHVzZXMgSFBBQ0sgZm9yIGhlYWRlciBjb21wcmVzc2lvbiwgd2hp Y2ggcmVsaWVzIG9uIGluLW9yZGVyIHByb2Nlc3Npbmcgb2YgaGVhZGVyIGZyYW1lcy4gVGhlIGN1 cnJlbnQgUVVJQyBkcmFmdCByZXRhaW5zIEhQQUNLIGFuZCBpbnRyb2R1Y2VzIGEgc2VxdWVuY2Ug bnVtYmVyIGZvciBoZWFkZXIgZnJhbWVzIHNvIHRoZSBIVFRQIGltcGxlbWVudGF0aW9uIGNhbiBl bnN1cmUgaW4tb3JkZXIgcHJvY2Vzc2luZy4gIA0KVGhlcmUgYXJlIHR3byBwcm9wb3NlZCBjb21w cmVzc2lvbiBzY2hlbWVzIGZvciBIVFRQIG92ZXIgUVVJQyB0aGF0IGZhY2lsaXRhdGUgb3V0LW9m LW9yZGVyIHByb2Nlc3NpbmcsIFFDUkFNIGFuZCBRUEFDSy4gIA0KTXkgZ29hbCB3YXMgdG8gdW5k ZXJzdGFuZCB0aGUgbWFnbml0dWRlIG9mIHRoZSBwcm9ibGVtIGNhdXNlZCBieSBIT0wgYmxvY2tp bmcgb24gaGVhZGVyIGZyYW1lcyB1bmRlciB2YXJ5aW5nIG5ldHdvcmsgY29uZGl0aW9ucywgYW5k IHF1YW50aWZ5IHRoZSBkZWdyZWUgdG8gd2hpY2ggUUNSQU0gYW5kIFFQQUNLIGFsbGV2aWF0ZSB0 aGUgcHJvYmxlbS4gSSB3YXMgYWxzbyBzZWVraW5nIHRvIHVuZGVyc3RhbmQgdGhlIGltcGxlbWVu dGF0aW9uIGNvbXBsZXhpdHkgb2YgZWFjaCBzY2hlbWUgYW5kIHByb3ZpZGUgZmVlZGJhY2sgdG8g dGhlIGF1dGhvcnMgd2l0aCBvbiB0aGUgc3BlY2lmaWNhdGlvbiBkcmFmdHMuDQoNCk1ldGhvZG9s b2d5DQoNCkkgbW9kaWZpZWQgcHJveHlnZW7igJlzIEhQQUNLIGxpYnJhcnkgKGh0dHBzOi8vZ2l0 aHViLmNvbS9mYWNlYm9vay9wcm94eWdlbikgIHRvIHN1cHBvcnQgYm90aCBRQ1JBTSBhbmQgUVBB Q0suIEkgdGhlbiB3cm90ZSBhIHNpbXVsYXRvciB0byB0ZXN0IHZhcmlvdXMgbmV0d29yayBjb25k aXRpb25zLiBUaGUgc2ltdWxhdG9yIGhhcyB0d28gcHJpbWFyeSBrbm9iczoNCjEuIFNpbXVsYXRl ZCBSVFQgLSByb3VuZCB0cmlwIHRpbWUgYmV0d2VlbiB0aGUgZW5kcG9pbnRzLiBUaGVyZSBpcyBh IG1pbmltdW0gcHJvY2Vzc2luZyBkZWxheSBvZiBydHQgLyAyIGJldHdlZW4gZW5jb2RpbmcgYW5k IGRlY29kaW5nIGEgaGVhZGVyIGJsb2NrDQoyLiBTaW11bGF0ZWQgbG9zcyBwcm9iYWJpbGl0eSAt IHByb2JhYmlsaXR5IHRoYXQgYSBnaXZlbiBwYWNrZXQgaXMgZHJvcHBlZC4gRHJvcHMgYXJlIHNp bXVsYXRlZCBieSBhZGRpbmcgMS4xIC0gMiBSVFRzIGJldHdlZW4gZW5jb2RpbmcgYW5kIGRlY29k aW5nIGEgaGVhZGVyIGJsb2NrDQpBZnRlciBkZWNvZGluZyBhIGhlYWRlciBibG9jaywgYSBzaW11 bGF0ZWQgYWNrIGlzIGdlbmVyYXRlZCBhbmQgZGVsaXZlcmVkIHRvIHRoZSBlbmNvZGVyIHdpdGgg dGhlIHNhbWUgUlRUIGFuZCBsb3NzIG1vZGVsIChlLmcuOiBhY2tzIGNhbiBhbHNvIGJlIGxvc3Qg YW5kIHJldHJhbnNtaXR0ZWQpDQoNCkkga25vdyB0aGlzIGlzIGEgc2ltcGxpc3RpYyBsb3NzIG1v ZGVsLiAgSWYgc29tZW9uZSBoYXMgYSBkaWZmZXJlbnQgbW9kZWwgdGhleSBwcmVmZXIgYW5kIGNh biBwcm92aWRlIG1lIHdpdGggQyBvciBDKysgY29kZSwgSSBjYW4gcmUtcnVuIHRoZSBzaW11bGF0 aW9ucyB3aXRoIGEgZGlmZmVyZW50IGxvc3MgZW5naW5lLiAgSSBob3BlIHRvIG9wZW4gc291cmNl IHRoZSBRUEFDSy9RQ1JBTSBpbXBsZW1lbnRhdGlvbnMgYW5kIHRoZSBzaW11bGF0b3IgZXZlbnR1 YWxseSwgYnV0IHRoZXkgYXJlIG5vdCByZWFkeSBhdCBwcmVzZW50Lg0KDQpFeHBlcmltZW50IFNl dHVwDQoNCkkgbG9hZGVkIG15IEZhY2Vib29rIGZlZWQgaW4gQ2hyb21lIGFuZCBjYXB0dXJlZCBy ZXF1ZXN0IGhlYWRlcnMgYW5kIHRpbWluZyBpbiBhIEhBUiBmaWxlLiBUaGUgc2ltdWxhdG9yIHJl YWRzIHRoZSBIQVIgZmlsZSBhbmQgc2NoZWR1bGVzIHRoZSBlbmNvZGluZ3MgYmFzZWQgb24gdGhl IHJlcXVlc3Qgc3RhcnQgdGltZXMuIEl0IGNvbnRhaW5lZCAyMjcgcmVxdWVzdHMgbWFkZSB0byA1 IG9yaWdpbnMuICBJIHNpbXVsYXRlZCBhcyBpZiBhbGwgZmFjZWJvb2suY29tIGFuZCBmYmNkbi5u ZXQgb3JpZ2lucyB3ZXJlIGNvYWxlc2NlZC4gIEZvciB0aGUgb3JpZ2luYWwgdGVzdCwgSSB0aHJv dHRsZWQgdGhlIGNvbm5lY3Rpb24gdG8gMTAwbXMgUlRULg0KSSByYW4gdGhlIHNpbXVsYXRpb24g NSB0aW1lcyBmb3IgZWFjaCBhbGdvcml0aG0gd2l0aCBSVFQgcmFuZ2luZyBmcm9tIDEwbXMgLSA1 MDBtcyBhbmQgbG9zcyBwZXJjZW50YWdlIGZyb20gMCB0byAxMCUuDQoNCk1ldHJpY3MNCg0KQ3Vt dWxhdGl2ZSBIT0wgRGVsYXkgLSBUaGlzIGlzIHRoZSBzdW0gb2YgdGhlIHRpbWUgaGVhZGVyIGJs b2NrcyBzcGVudCBpbiBhIHF1ZXVlIHdhaXRpbmcgZm9yIGFuIGVhcmxpZXIgYmxvY2sgdG8gYmUg ZGVjb2RlZC4gIEZvciBleGFtcGxlLCBpZiBJIHNlbmQgb25lIHJlcXVlc3QgdGhhdCBhZGRzIGlu ZGV4ZWQgZW50cmllcyB0byB0aGUgaGVhZGVyIHRhYmxlIGZvbGxvd2VkIGJ5IHR3byByZXF1ZXN0 cyB0aGF0IHJlZmVyZW5jZSBpdCwgYnV0IHRoZSBmaXJzdCByZXF1ZXN0IGlzIGRlbGF5ZWQgMTAw bXMsIHRoZSBjdW11bGF0aXZlIGRlbGF5IHdvdWxkIGJlIDIwMG1zICgyIHJlcXVlc3RzIHggMTAw bXMpLg0KDQpDb21wcmVzc2lvbiBSYXRpbyAtIFJhdGlvIG9mIGJ5dGVzIHNlbnQgb24gdGhlIHdp cmUgdG8gdGhlIHRvdGFsIHVuY29tcHJlc3NlZCBoZWFkZXIgc2l6ZQ0KDQpNYXhpbXVtIEJ1ZmZl ciBTaXplIC0gSWYgSE9MIGJsb2NraW5nIG9jY3VycywgdGhlIGRlY29kZXIgbXVzdCBidWZmZXIg c29tZSBoZWFkZXIgZGF0YS4gIFRoaXMgaXMgdGhlIG1heGltdW0gc2l6ZSBvZiB0aGUgYnVmZmVy IGluIGJ5dGVzIG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBzZXNzaW9uLg0KUmVzdWx0cw0KDQpE YXRhOg0KDQpEZWxheTogaHR0cHM6Ly93d3cuZHJvcGJveC5jb20vcy9xZGgzMTBlcHJ5OHNoYTEv SE9MJTIwRGVsYXkucG5nP2RsPTANCkNvbXByZXNzaW9uIFJhdGlvOiBodHRwczovL3d3dy5kcm9w Ym94LmNvbS9zL3Fxd3p0cXQ4dXdicXdqci9Db21wcmVzc2lvbiUyMFJhdGlvLnBuZz9kbD0wDQpC dWZmZXIgU2l6ZTogaHR0cHM6Ly93d3cuZHJvcGJveC5jb20vcy8zYjBjMzR1cHQxMXdtdDcvSE9M JTIwQnVmZmVyaW5nLnBuZz9kbD0wDQoNCg0KSGlnaCBsZXZlbCBvYnNlcnZhdGlvbnMNCg0KMS4g SGVhZC1vZi1saW5lIGJsb2NraW5nIGlzIGEgdmVyeSByZWFsIHByb2JsZW0gZm9yIHNlcmlhbGl6 ZWQgSFBBQ0sgdGhhdCBnZXRzIHByZWRpY3RhYmx5IHdvcnNlIGFzIFJUVCBhbmQgbG9zcyBpbmNy ZWFzZS4gQXQgYSBmYWlybHkgbW9kZXN0IDEwMG1zIFJUVCArIDIlIGxvc3MsIEhPTCBibG9ja2lu ZyBvbiBoZWFkZXJzIGFkZGVkIGFuIGF2ZXJhZ2Ugb2YgNDBtcyAvIHJlcXVlc3QuIEF0IDIwMG1z LzUlIGxvc3MsIGl04oCZcyBhbG1vc3QgMTAwbXMvcmVxdWVzdCwgYW5kIHRoZSBwMTAwIChtYXgp IHdhcyA0OTdtcy9yZXF1ZXN0Lg0KMi4gUVBBQ0sgYW5kIFFDUkFNIGJvdGggZHJhc3RpY2FsbHkg cmVkdWNlIEhPTCBibG9ja2luZy4gUUNSQU3igJlzIGRlc2lnbiBmYXZvcnMgc2FjcmlmaWNpbmcg Y29tcHJlc3Npb24gcmF0aW8gdG8gcmVkdWNlIEhPTCBibG9ja2luZywgd2hpbGUgUVBBQ0sgbWFp bnRhaW5zIEhQQUNL4oCZcyBjb21wcmVzc2lvbiByYXRpbyBhdCB0aGUgZXhwZW5zZSBvZiBhZGRp dGlvbmFsIGxhdGVuY3kuIEFzIHN1Y2gsIFFDUkFNIGluY3VycmVkIDAgaGVhZCBvZiBsaW5lIGJs b2NraW5nIGRlbGF5IGluIDEwMCUgb2YgbXkgc2ltdWxhdGlvbnMsIGFuZCBRUEFDSyBoYWQgMCBp biA4MCUgb2YgdGVzdCBydW5zLiBUaGUgYXZlcmFnZSBkZWxheSB3YXMgOG1zL3JlcSwgcDk1IGRl bGF5IHdhcyA2M21zL3JlcXVlc3QgYW5kIHAxMDAgd2FzIDI0Mm1zL3JlcXVlc3QuICBNaWtlIEJp c2hvcCBzdWdnZXN0ZWQgc29tZSBRQ1JBTSB0ZWNobmlxdWVzIGNvdWxkIGJlIGFwcGxpZWQgdG8g UVBBQ0sgdG8gbW9kaWZ5IHRoZSBibG9ja2luZy9jb21wcmVzc2lvbiByYXRpbyB0cmFkZW9mZi4N CjMuIFFDUkFNIHNlbmRzIHVwIDE1JSBtb3JlIGhlYWRlciBieXRlcyBvbiB0aGUgd2lyZSBldmVu IGluIG1vZGVyYXRlIG5ldHdvcmtzLiBCZWNhdXNlIG9mIHRoZSBuYXR1cmUgb2YgbXkgc2ltdWxh dGlvbiwgdGhlIGNvbXByZXNzaW9uIHJhdGlvIGRhdGEgZm9yIFFDUkFNIG1heSBiZSBwZXNzaW1p c3RpYyBmb3IgUlRUcyA+IDIwMG1zLCBidXQgaXTigJlzIHByb2JhYmx5IGluIHRoZSA4NCUgYmFs bHBhcmsuDQo0LiBCZWNhdXNlIFFDUkFNIG9ubHkgaW5mcmVxdWVudGx5IGluZHVjZXMgSE9MIGJs b2NraW5nLCBub25lIG9mIHRoZSBzaW11bGF0aW9ucyByZXN1bHRlZCBpbiB0aGUgZGVjb2RlciBo YXZpbmcgdG8gYnVmZmVyIGZyYW1lcy4gUVBBQ0tzIGJ1ZmZlcnMgd2VyZSB1c3VhbGx5IG1hbmFn ZWFibGUgKHNtYWxsZXIgdGhhbiAxa2IpLCBidXQgbm90ZSB0aGF0IHdoZW4gUVBBQ0sgZW5jb3Vu dGVycyBIT0wgYmxvY2tpbmcsIGl0IGJ1ZmZlcnMgZGVjb21wcmVzc2VkIGRhdGEgcG90ZW50aWFs bHkgb2NjdXB5aW5nIGEgbG90IG9mIG1lbW9yeS4gIE1pa2UgQmlzaG9wIHN1Z2dlc3RlZCB0aGlz IGNvdWxkIGJlIG1pdGlnYXRlZCBieSBwZXJmb3JtaW5nIHRoZSBkZWNvZGUgaW4gdHdvIHN0ZXBz LCBhbmQgYnVmZmVyaW5nIHRoZSBjb21wcmVzc2VkIGRhdGEgaWYgZGVjb2Rpbmcgd291bGQgYmxv Y2suDQoNCkltcGxlbWVudGF0aW9uIENvbnNpZGVyYXRpb25zDQoNCkEgYmFzaWMgUUNSQU0gaW1w bGVtZW50YXRpb24gaXMgc2ltcGxlciwgYmVjYXVzZSBpdCBjYW4gbW9yZSBkaXJlY3RseSBsZXZl cmFnZSBhbiBleGlzdGluZyBIUEFDSyBpbXBsZW1lbnRhdGlvbi4gSXQgd2FzIGZ1cnRoZXIgc2lt cGxlciBmb3IgRmFjZWJvb2sgYmVjYXVzZSBvdXIgaW1wbGVtZW50YXRpb24gd2FzIGFscmVhZHkg ZGVzaWduZWQgdG8gaGFuZGxlIGFzeW5jaHJvbnkgYXQgdGhlIGxheWVyIG9mIGRlY29kaW5nIGhl YWRlcnMuIEZ1bGwgaW1wbGVtZW50YXRpb24gYWxzbyByZXF1aXJlcyBzb21lIGludGVyYWN0aW9u IHdpdGggdGhlIHRyYW5zcG9ydOKAmXMgYWNrbm93bGVkZ2VtZW50IGhhbmRsaW5nLiBBZGRpdGlv bmFsIGNvbXBsZXhpdHkgYWxzbyBjb21lcyB3aGVuIHRyeWluZyB0byB1c2UgdGhlIHBhY2tldCBl cG9jaCwgYmVjYXVzZSBpdCByZXF1aXJlcyB0aGUgcGFja2V0IHNjaGVkdWxpbmcgbGF5ZXIgb2Yg dGhlIHRyYW5zcG9ydCB0byBpbnRlcmFjdCB3aXRoIHRoZSBoZWFkZXIgY29tcHJlc3Npb24gYWxn b3JpdGhtLiBXaGlsZSBJIHdhcyBhYmxlIHRvIGFwcHJveGltYXRlIHRoaXMgc2ltcGx5IGluIG15 IHNpbXVsYXRpb24sIEZhY2Vib29rIHByZWZlcnMgbW9yZSBzZXBhcmF0aW9uIGJldHdlZW4gdGhl IHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gbGF5ZXJzIG9mIGhxLCBzbyBpbXBsZW1lbnRpbmcg aW4gcHJhY3RpY2UgbWF5IGJlIG1vcmUgZGlmZmljdWx0LiBJbiBteSBzaW11bGF0aW9uIHRob3Vn aCwgY29tcHJlc3Npb24gcmF0aW8gZGlkbuKAmXQgYXBwZWFyIHRvIGltcHJvdmUgZHJhc3RpY2Fs bHkgd2l0aCB0aGlzIGZlYXR1cmUsIGFuZCBtaWdodCBiZSBodXJ0IHBlcmZvcm1hbmNlIGluIHNv bWUgc2NlbmFyaW9zIGlmIHJlLWluZGV4aW5nIHRoZSBzYW1lIGhlYWRlci92YWx1ZSBsZWFkcyB0 byBtb3JlIHRhYmxlIGV2aWN0aW9ucy4NClFQQUNL4oCZcyBkZXNpZ24gaXMgZGlmZmVyZW50IGVu b3VnaCB0aGF0IGl0IGNhbuKAmXQgdXNlIHRoZSBzYW1lIHVuZGVybHlpbmcgc3RydWN0dXJlIGFz IEhQQUNLLiBGdXJ0aGVybW9yZSwgaXTigJlzIHF1aXRlIGRpZmZlcmVudCBpbiB3aGVyZSBhc3lu Y2hyb255IGlzIGV4cGVjdGVkIC0gYXQgdGhlIGxldmVsIG9mIHRhYmxlIGxvb2t1cHMgcmF0aGVy IHRoYW4gYmxvY2sgZGVjb2RpbmcuICBFeHBsaWNpdCBpbmRleGluZyBpcyBzaW1wbGVyIHRvIHVu ZGVyc3RhbmQgdGhhbiBIUEFDS+KAmXMgcmVsYXRpdmUgaW5kZXhpbmcsIGFuZCBhbG9uZyB3aXRo IHJlZmVyZW5jZSBjb3VudHMgYW4gaW1wbGVtZW50YXRpb24gY2FuIGJlIGNsZXZlciBhYm91dCBu ZXZlciBldmljdGluZyBmcmVxdWVudGx5IHVzZWQgaGVhZGVycy4gUVBBQ0sgcmVxdWlyZXMgbW9y ZSBhZGRpdGlvbmFsIHN0YXRlIGluIHRoZSBoZWFkZXIgdGFibGUgdGhhbiBRQ1JBTS4NCg0KQ2F2 ZWF0cw0KDQpEaWZmZXJlbnQgd29ya2xvYWRzIG1heSBwcm9kdWNlIHF1aXRlIGRpZmZlcmVudCBy ZXN1bHRzLiBJbiBsb2FkaW5nIHRoZSBGYWNlYm9vayBmZWVkLCB0aGVyZSB3ZXJlIG5vIGV2aWN0 aW9ucyBmcm9tIHRoZSBoZWFkZXIgdGFibGUgdXNpbmcgUUNSQU0uIFRoaXMgd2lsbCB2YXJ5IGRl cGVuZGluZyBvbiBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbnMgYWJvdXQgd2hpY2ggaGVhZGVyIGZp ZWxkcyB0byBpbmRleC4gRXZpY3Rpb25zIHdpbGwgaGF2ZSBhIG1vcmUgbmVnYXRpdmUgaW1wYWN0 IG9uIFFDUkFN4oCZcyBIT0wgYmxvY2tpbmcsIGFuZCBtb3JlIGltcGFjdCBvbiBRUEFDS+KAmXMg Y29tcHJlc3Npb24gcmF0aW8uIA0KDQpIYXZpbmcgdGhlIENETiBjb2FsZXNjZWQgd2l0aCB0aGUg ZHluYW1pYyBvcmlnaW4gYWxzbyBwbGF5cyBhIHJvbGUgaW4gdGhlIHBlcmZvcm1hbmNlIG9mIHRo ZSBjb21wcmVzc2lvbiBzY2hlbWVzLiAgT3ZlciB0aW1lIEkgaG9wZSB0byBidWlsZCBhIGRpdmVy c2UgY29sbGVjdGlvbiBvZiBpbnB1dCBIQVIgZmlsZXMgZnJvbSBkaWZmZXJlbnQgc2l0ZXMgYW5k IGFwcGxpY2F0aW9ucyB3aGljaCBjYW4gYmUgcnVuIHRocm91Z2ggdGhlIHNpbXVsYXRvciB0byBn ZXQgbW9yZSBjb21wbGV0ZSBkYXRhLg0KDQpUaGFua3MgdG8gTWlrZSBCaXNob3AgYW5kIEJ1Y2sg S3Jhc2ljIHdobyBwcm92aWRlZCBmZWVkYmFjay4NCg0K From nobody Tue Jun 6 01:13:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA81129490 for ; Tue, 6 Jun 2017 01:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6arPrxxpPNR for ; Tue, 6 Jun 2017 01:13:55 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB4B129AD3 for ; Tue, 6 Jun 2017 01:13:54 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-1c-593664403201 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.C3.22014.04466395; Tue, 6 Jun 2017 10:13:52 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.339.0; Tue, 6 Jun 2017 10:11:33 +0200 To: From: Magnus Westerlund Subject: New Issue: Loss detection: Overloading of is_retransmittable Message-ID: <5aacf198-c433-e8a2-0aa6-70d453c05f75@ericsson.com> Date: Tue, 6 Jun 2017 10:11:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020301070500070506040508" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM2K7rq5DilmkwYIjBhY9C7gdGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXR2X+erWC3ZcXV+1OYGhjnm3UxcnJICJhIdH74w9zFyMUhJHCE UWL6oh9sEM4yRomVjxuZQKpEBIQlNiw8B2azCVhI3PzRyAZiCwu4SszZ/4EVxOYVsJc4/uAM O4jNIqAi8eXCDLC4qECMxKMNZ5kgagQlTs58wgJiMwt0M0psnGMKYgsJaEs0NHWwTmDkmYWk bBaSMgjbVuLO3N3MELa4xK0n85kgbG2JZQtfQ8WtJWb8OsgGYStKTOl+yA5hm0q8PvqREcI2 kni3p5F9ASPnKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAkD245bfqDsbLbxwPMQpwMCrx 8N4MNYsUYk0sK67MPcSoAjTn0YbVFxilWPLy81KVRHgZ95pGCvGmJFZWpRblxxeV5qQWH2KU 5mBREud13HchQkggPbEkNTs1tSC1CCbLxMEp1cCY+WF1Z6qTet/2+0fN1X+c+Rk2X9hv7YEF Qlvyp9X2+G1uczl3Iz92zfV2hf33qhtn79qXJjQtuvhQ2qG7/mHG108nMThxPNrppa6x+HLZ J8XXsdXC7zqYoj/x/LrClrXE/cSLbUGlnHMfMk/JU3t88L7T8o57SUcm+flNnSJV8MilafLp 8mfzlViKMxINtZiLihMBWJxnxmECAAA= 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, 06 Jun 2017 08:13:56 -0000 --------------ms020301070500070506040508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, In draft-ietf-quic-recovery-03 there appear to me to be an overloading=20 of the use of the "is_retransmittable" flag. It appears to be used both=20 for the purpose to indicate if there is a frame that can and need be=20 retransmitted and if that frame should be counted as lost and impact=20 congestion control. I think these two purposes should be separated and=20 clarified as being two different ones. The reason is that if we create=20 extensions that will not require retransmission of frames but needs to=20 be included in the congestion control response a significant rewrite=20 would be needed. I also think it would clarify things for some of the=20 control frames also if they should be included or not, even if not=20 regularly retransmitted. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms020301070500070506040508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzA2MDYwODExMTBaMC8GCSqGSIb3DQEJBDEiBCDrDI5N5cfwQUXhfYPy 3fMGTS0gazvzDxbiAXKsCZGWHTBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAaRIVl6m6aTdY+wNziGxCc+XNvRco6JunWSEsyeWwlTP83n+x MprZn8C4bVAu9WgzmnWUNgBXY/SPPlDPnU0N48AwHVnkxsge8fo/sAFqt4BGFbUNgABoHswG nQgJHSxMBBaGBVb4HERDWmQRo5myhWZQyMrdaQjj7jUHOMtsfU6RJtx1J+ExA8rpH97UtKE+ zW5FcZZgCOqhac0hiTNfoBNMXzWD0oiZWBsvXLxzVV0+j9Wc7yHPY4xCPRmFBmp/hIF0tGcT +vXiRtJHCOo6m7stUQeknP4Ax6UXDywNWtdk+Z4mSoO5Hcfo6EwElGpx3Eks8oZxphXgNOuq T4yhLgAAAAAAAA== --------------ms020301070500070506040508-- From nobody Tue Jun 6 02:04: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 ACA0212426E for ; Tue, 6 Jun 2017 02:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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=netapp.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 mI8cei7ErfH0 for ; Tue, 6 Jun 2017 02:04:37 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E646A124217 for ; Tue, 6 Jun 2017 02:04:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,305,1493708400"; d="asc'?scan'208";a="197749258" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx144-out.netapp.com with ESMTP; 06 Jun 2017 01:40:47 -0700 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Jun 2017 01:59:31 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 6 Jun 2017 01:59:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=boBMSPBV1qJTJeUb95yLqjekJepa5ooOqvuDvNTF1Zk=; b=EQb77UVi0k9SiRP6c1blEzVhJY7v4m0RBBjrbGMrNXDxi8pJWum0cS1jgah02RVymqRZ0upLON/6jH+BYAFU8VwI5Q07gokm7oVcI5EYVwngjh4JbELH8/KMgvGMVsWdxzguCzmYr5YQbQQ5mduwHaUSlunbsG2e+ef6HWcrbMg= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Tue, 6 Jun 2017 08:59:33 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1157.012; Tue, 6 Jun 2017 08:59:33 +0000 From: "Eggert, Lars" To: Alan Frindell CC: IETF QUIC WG Subject: Re: Comparing HTTP over QUIC header compression schemes Thread-Topic: Comparing HTTP over QUIC header compression schemes Thread-Index: AQHS3pDkbL6XmOk6K0ms9bs9UuyP16IXiUoA Date: Tue, 6 Jun 2017 08:59:33 +0000 Message-ID: <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> In-Reply-To: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: fb.com; dkim=none (message not signed) header.d=none;fb.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [2001:450:1e:232:f1e9:551d:ec8b:7d09] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:FiH7bIjYiLwwIhAWsEf1CcgRbBNAmpsqjFQ4Zj7mHWr0dLNSqE5K6uRBtmGygr1kwj0DACbw8gDP50sRALDGVlxi8ca2sL5JpvuZZn9WrDKJNkQ0HWMtD37BaXiQIswlUujahwx5HYc6NYFIwOGpD0dhMSgW0QubwBGO7yCTfdaXOF8srpM7JYlmctRpaQSw+T/g7wINV7wzK82qEEKmIiLIUKMYAYLLyoYE6ikOArc2un9x2O37n+1DG52RzlaS7pY4QSVz6/wwcmd5uKL+XCTQ3wGZSBclifXo/vUmsrk7BBKBQbzBul5rZQPUy34+vx/ygiIsLOavhE4k8Yt/VQ== x-ms-traffictypediagnostic: BLUPR06MB1762: x-ms-office365-filtering-correlation-id: dd27e87f-4088-4775-a50e-08d4acba59b2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60067363179207)(67672495146484)(249562145798500); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1762; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(377424004)(24454002)(575784001)(50986999)(86362001)(77096006)(6486002)(5660300001)(99936001)(122556002)(6306002)(6512007)(25786009)(76176999)(189998001)(53546009)(305945005)(2900100001)(6116002)(7736002)(102836003)(4326008)(3280700002)(6506006)(8936002)(2906002)(81166006)(83716003)(14454004)(36756003)(4001150100001)(6916009)(82746002)(3660700001)(2950100002)(6436002)(478600001)(6246003)(99286003)(8676002)(966005)(33656002)(50226002)(38730400002)(110136004)(229853002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_782F7E20-EC92-4AE9-9432-E8B186716CAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 08:59:33.2513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 09:04:38 -0000 --Apple-Mail=_782F7E20-EC92-4AE9-9432-E8B186716CAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-6-6, at 8:48, Alan Frindell wrote: > Data: >=20 > Delay: https://www.dropbox.com/s/qdh310epry8sha1/HOL%20Delay.png?dl=3D0 > Compression Ratio: = https://www.dropbox.com/s/qqwztqt8uwbqwjr/Compression%20Ratio.png?dl=3D0 > Buffer Size: = https://www.dropbox.com/s/3b0c34upt11wmt7/HOL%20Buffering.png?dl=3D0 >=20 two quick points: (1) the way your plot your results, i.e., varying both delay and loss = rate on the x-axis but plotting one line, is very confusing (2) simulating loss rates much above 1% is likely going to be pretty = uninteresting, given that QUIC (and TCP, FWIW) have congestion = controllers that will struggle to even deliver useful throughputs in = these cases Lars --Apple-Mail=_782F7E20-EC92-4AE9-9432-E8B186716CAB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlk2bvQACgkQVLXDCb9w wVdUfQ/+NSA/xub8AfLuuO/P5sV6eOOF4EQYi4697Pts9Y5lVbF6AGiMLl7N7xMm Rmvf3eWj6UXHjbqyEdVwUjWBiC//2fLxnMMjVyMA5Gxyezv6RBqE3/Io+DJdm8K4 pukn8HH7Frc7+XZwnfrKCsyXczqkSQZK29ghR6krNQxjoZTysPVV94iVz/nZjjPB iCMsseE4OkcWYxTmAJi0hR67peb6dVO/bKOGOrzeA+QpVg33/L0WPTKhNrphXkzR u9KTqOD8TOJTg9JhhwvKmk2NZEvvpE37ZSpa3GG6YeSekKQXWsumDunWexGXarTS 4x9x31t9T6GkIP/ywjQZiZYaDmG8uUBSFuSbYn8k/RA/aiZPZ1VN4GSEU5N2nR/C /Tl335Kx7A/vIYb/N14nCC9JyPasb+otUT7/4IvPRBg7h1+zgZgnFSRInzTtige6 qBbbcz/lAXAe0Cv58jpxjAKx9RnzWwT73GAVnKkH2bFHDk0DE43crgS7Yglu9+Ns bemPaxwSqReMs/v54vsZ9DP/MEaqcOuh8IbSPX2GeccyyXezhLQXu7BOTFvftm50 70J8zP4bsHgje7gYu3lcAMurRtRywJvz7tbC7wgaUUIWZGvXsaENjXSnKfXU+fEX fsFMW3kyAHaCdZegUuum1GMT4N4spM2sBHO4c7TlVe6IvGulI6c= =US82 -----END PGP SIGNATURE----- --Apple-Mail=_782F7E20-EC92-4AE9-9432-E8B186716CAB-- From nobody Tue Jun 6 02: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 D1A5812426E for ; Tue, 6 Jun 2017 02:11: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 Kah5zNHRLW7f for ; Tue, 6 Jun 2017 02:10:59 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 A6397129B70 for ; Tue, 6 Jun 2017 02:10:56 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id o83so35558820lff.3 for ; Tue, 06 Jun 2017 02:10:56 -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=8DBdlHNMBOqQlNgbBjkIuN0/Jsy135Mtn0rvaJbPb+M=; b=DKkQhLJ23bIdUvcDnVUe1BwgqbPZau/mv6Yt1E2YDlVhOowmbcfYsHhapOZUfKFyDY Q7G7tll2y+TYy0C2YLIeUwGvBRdjD7VaKtt+PcYPFYF6nE8a8ADRZaLdMGrhiZrtXOhc pyTD+hPyXBqxlnbuLSVUDE6A7g011R71lkvDgnpaAqHpCJ5MHuo3kzZvLdfknH20pK7u aSlXghkLMbWlAAydD7rBvjbXotIe+yO5F8U1j9K3N7rbsL9mQLImxoYOmoeNC1jpzWng 8rkftPOaT+8GOdtYBvab9QC+t+jMoC8kqHKL6E0tGhxcJm5Pw1xSUuMRbFlmW/9LSmX7 kWVA== 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=8DBdlHNMBOqQlNgbBjkIuN0/Jsy135Mtn0rvaJbPb+M=; b=VWDNuwMAdAypa648+SKFZwL2A3tYAKOGO4/y+9AeU8kSFP+dOn5bXiZpICwqBf5NXo HzvsErEHe6iQdZSZe91m4CH0xTRvBu6ThKNbKmp6e6PrZCe7iKRDwK85teSBJ5sQPWbe 0BwjChFrN7yrbyvGzHF0oM7WaPPj26LsChvd/xb9Lose9vYhU2T6ALWUwNpIiEhW2lsi gANtac84JY1oe1TMLtqrAdpqOIL/XytN5TYa1cT19f0p8occ/JH+GRDHaDcvQPEHvn3B dcX0hjObisNQRaPHirE48qS0GB+z4aZhH4WEc5vE5PIxUN5Y7Ff+FA1FJvcC5CaBCp/h 6/xQ== X-Gm-Message-State: AODbwcA90iG6oO2fmYVrA3dukJXKpmZ1X/f71mI9i8SD0qipI7oz9aJY fizTnMOEHX2DFxM6hjT5K/nCYbXrDQ== X-Received: by 10.25.166.133 with SMTP id p127mr6245481lfe.43.1496740254958; Tue, 06 Jun 2017 02:10:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Tue, 6 Jun 2017 02:10:54 -0700 (PDT) In-Reply-To: <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> From: Martin Thomson Date: Tue, 6 Jun 2017 11:10:54 +0200 Message-ID: Subject: Re: Comparing HTTP over QUIC header compression schemes To: "Eggert, Lars" Cc: Alan Frindell , 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: Tue, 06 Jun 2017 09:11:03 -0000 On 6 June 2017 at 10:59, Eggert, Lars wrote: > (2) simulating loss rates much above 1% is likely going to be pretty uninteresting, given that QUIC (and TCP, FWIW) have congestion controllers that will struggle to even deliver useful throughputs in these cases That's an interesting point. I've seen a presentation (that I can't find now, but I can try) that shows that packet loss in real-world scenarios approaches 2% in a great many cases. From nobody Tue Jun 6 02:12:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3583D126DC2 for ; Tue, 6 Jun 2017 02:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 OSf1GJX0rIbJ for ; Tue, 6 Jun 2017 02:12:31 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0121.outbound.protection.outlook.com [104.47.41.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F1F12426E for ; Tue, 6 Jun 2017 02:12:31 -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=2Vlo9ztHIk+4AVGNkDr3+IVQ51ZdRDANmX8HeX0aj6Q=; b=e2EZ8IHq+O0U1WjWcxEYJmOGOZcapYftfi4biLo/wU/Q/QboFXJ6Crc8TVn2lJ8kGMRA7z4BiyOx6NMrb5WymRKHTgKvC1WAOCyxpLNyXcmae53ai+kLgFYjXajOu3tCj5+30YidzSpYSj+Wlldcb065vleLVl9CpupXUwt0REw= Received: from MWHPR03MB2944.namprd03.prod.outlook.com (10.175.136.137) by MWHPR03MB2944.namprd03.prod.outlook.com (10.175.136.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Tue, 6 Jun 2017 09:12:24 +0000 Received: from MWHPR03MB2944.namprd03.prod.outlook.com ([10.175.136.137]) by MWHPR03MB2944.namprd03.prod.outlook.com ([10.175.136.137]) with mapi id 15.01.1143.018; Tue, 6 Jun 2017 09:12:24 +0000 From: Mike Bishop To: Alan Frindell , IETF QUIC WG Subject: RE: Comparing HTTP over QUIC header compression schemes Thread-Topic: Comparing HTTP over QUIC header compression schemes Thread-Index: AQHS3pDkbL6XmOk6K0ms9bs9UuyP16IXhbIQ Date: Tue, 6 Jun 2017 09:12:24 +0000 Message-ID: References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> In-Reply-To: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fb.com; dkim=none (message not signed) header.d=none;fb.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:450:1e:232:3df2:793b:6da5:6ca2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR03MB2944; 7:R6IESwpHbcCwKwY5xsdOom/Xi30klSzG7CEfWP6i01/DQTcVkA/cGzjdEKz25t9rIfRLHm5NkNk5dK8b600gO7KfoQ3brYO66mBq80IAqElkAfYMcG/szo2HXk9tepS4job5rimlCvzAG/Grw/TjjuDvq++gtUeVVg+G4FPnrrHEW9HYl5sNNHa5Lo0Dx2dyA474kjDpyQIoSjnjD589y7HTEfPgh0nnjV66H9/d2P2PYtwC9JNFPzkAM8u1D6daiKkkxXjnnFtINDM8tOo0wnapulMbf2jwfCioVoF5QIVoBFv8EJMOlDO7yakL2K57O0SsY/LPTnTTTC2bZahhm6Iq5JFHA0UWMsW12g/I/3M= x-ms-traffictypediagnostic: MWHPR03MB2944: x-ms-office365-filtering-correlation-id: 2dd5c921-16d1-4e0b-5f69-08d4acbc256b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR03MB2944; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(189930954265078)(35073007944872)(60067363179207)(219752817060721)(81227570615382)(21748063052155)(64217206974132); 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)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR03MB2944; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR03MB2944; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(39860400002)(377454003)(53546009)(478600001)(86612001)(25786009)(6306002)(54896002)(9686003)(74316002)(99286003)(53936002)(236005)(7696004)(86362001)(575784001)(189998001)(3660700001)(3280700002)(50986999)(54356999)(5660300001)(10090500001)(7906003)(7736002)(6436002)(6506006)(606005)(5005710100001)(77096006)(2906002)(76176999)(33656002)(72206003)(229853002)(38730400002)(81166006)(10290500003)(966005)(122556002)(551984002)(6116002)(8936002)(790700001)(8676002)(102836003)(14454004)(2950100002)(6246003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2944; H:MWHPR03MB2944.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR03MB294475C20C1E4937386D171E87CB0MWHPR03MB2944namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 09:12:24.4953 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2944 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, 06 Jun 2017 09:12:36 -0000 --_000_MWHPR03MB294475C20C1E4937386D171E87CB0MWHPR03MB2944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdhaW4sIHRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyLCBBbGFuLiAgTXkgY29tbWVu dHMgaW4gbW9yZSBkZXRhaWwgd2VyZToNCg0KICAqICAgUUNSQU0gZm9yYmlkcyByZWZlcmVuY2lu ZyBhIGhlYWRlciB1bnRpbCB5b3XigJlyZSBzdXJlIGl0IGhhcyBhcnJpdmVkLiAgVGhhdCBsZWFk cyBvbmUgdG8gZXhwZWN0IHdoYXQgeW91IGZvdW5kIGJlbG93OiAgTmV2ZXIgSE9MLWJsb2NraW5n LCBtb3JlIGJ5dGVzLiAgUVBBQ0sgbGVhdmVzIHRoYXQgY2hvaWNlIHRvIHRoZSBlbmNvZGVyLCB3 aGljaCBtZWFucyB5b3UgY2FuIGNob29zZSB0byB0YWtlIHRoZSByaXNrIGFuZCBnZXQgYmV0dGVy IGJ5dGUtZWZmaWNpZW5jeSBvciBiZSBtb3JlIGNvbnNlcnZhdGl2ZS4gIEl04oCZcyBqdXN0IG5v dCBtYW5kYXRlZC4NCiAgKiAgIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgd2FudGVkIHRvIGRvIGJs b2NraW5nIGF0IHRoZSBoZWFkZXIgc2V0IGxldmVsIGNvdWxkIGRvIHRoYXQg4oCTIHlvdeKAmWQg YWRkIGFuIGluaXRpYWwgcGFzcyBvZiB0aGUgZW5jb2RlZCBoZWFkZXJzIHRvIHNlZSB3aGV0aGVy IGFsbCByZWZlcmVuY2VzIGNhbiBiZSBzYXRpc2ZpZWQuICBJZiBub3QsIHdhaXQgdG8gZGVjb21w cmVzcyBhbnl0aGluZyB1bnRpbCB0aGV5IGNhbiBiZS4gIFRoYXQgYWxzbyBzYXZlcyB0aGUgZGVj b2RlciBidWZmZXJpbmcgdW5jb21wcmVzc2VkIGhlYWRlciBkYXRhIHdoaWxlIHdhaXRpbmcuDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsYW4gRnJpbmRlbGwNClNlbnQ6IFR1ZXNk YXksIEp1bmUgNiwgMjAxNyA4OjQ4IEFNDQpUbzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3Jn Pg0KU3ViamVjdDogQ29tcGFyaW5nIEhUVFAgb3ZlciBRVUlDIGhlYWRlciBjb21wcmVzc2lvbiBz Y2hlbWVzDQoNCg0KDQpJIGJ1aWx0IGEgUUNSQU0gYW5kIFFQQUNLIGltcGxlbWVudGF0aW9uIGFu ZCBhdHRlbXB0ZWQgdG8gc2ltdWxhdGUgcGVyZm9ybWFuY2UgdW5kZXIgdmFyeWluZyBuZXR3b3Jr IGNvbmRpdGlvbnMuICBIZXJl4oCZcyBhIHN1bW1hcnkgb2YgdGhlIHdvcmsgc28gZmFyLg0KDQoN Cg0KLUFsYW4NCg0KDQoNCj09PQ0KDQoNCg0KUHJvYmxlbQ0KDQoNCg0KSFRUUC8yIHVzZXMgSFBB Q0sgZm9yIGhlYWRlciBjb21wcmVzc2lvbiwgd2hpY2ggcmVsaWVzIG9uIGluLW9yZGVyIHByb2Nl c3Npbmcgb2YgaGVhZGVyIGZyYW1lcy4gVGhlIGN1cnJlbnQgUVVJQyBkcmFmdCByZXRhaW5zIEhQ QUNLIGFuZCBpbnRyb2R1Y2VzIGEgc2VxdWVuY2UgbnVtYmVyIGZvciBoZWFkZXIgZnJhbWVzIHNv IHRoZSBIVFRQIGltcGxlbWVudGF0aW9uIGNhbiBlbnN1cmUgaW4tb3JkZXIgcHJvY2Vzc2luZy4N Cg0KVGhlcmUgYXJlIHR3byBwcm9wb3NlZCBjb21wcmVzc2lvbiBzY2hlbWVzIGZvciBIVFRQIG92 ZXIgUVVJQyB0aGF0IGZhY2lsaXRhdGUgb3V0LW9mLW9yZGVyIHByb2Nlc3NpbmcsIFFDUkFNIGFu ZCBRUEFDSy4NCg0KTXkgZ29hbCB3YXMgdG8gdW5kZXJzdGFuZCB0aGUgbWFnbml0dWRlIG9mIHRo ZSBwcm9ibGVtIGNhdXNlZCBieSBIT0wgYmxvY2tpbmcgb24gaGVhZGVyIGZyYW1lcyB1bmRlciB2 YXJ5aW5nIG5ldHdvcmsgY29uZGl0aW9ucywgYW5kIHF1YW50aWZ5IHRoZSBkZWdyZWUgdG8gd2hp Y2ggUUNSQU0gYW5kIFFQQUNLIGFsbGV2aWF0ZSB0aGUgcHJvYmxlbS4gSSB3YXMgYWxzbyBzZWVr aW5nIHRvIHVuZGVyc3RhbmQgdGhlIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgb2YgZWFjaCBz Y2hlbWUgYW5kIHByb3ZpZGUgZmVlZGJhY2sgdG8gdGhlIGF1dGhvcnMgd2l0aCBvbiB0aGUgc3Bl Y2lmaWNhdGlvbiBkcmFmdHMuDQoNCg0KDQpNZXRob2RvbG9neQ0KDQoNCg0KSSBtb2RpZmllZCBw cm94eWdlbuKAmXMgSFBBQ0sgbGlicmFyeSAoaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGZmFjZWJvb2sl MkZwcm94eWdlbiZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20l N0NmMTRlMGMwZjlmYWQ0ZDQyNjAzOTA4ZDRhY2E4MTU0NyU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzMjMyODUzMTgwMDQzNzMmc2RhdGE9bWFEUFo1bEd5 NFBzSlo3cVFUZHhaSTdxdGZSVWFOZ0FQMEtVajBoeWZpMCUzRCZyZXNlcnZlZD0wKSAgdG8gc3Vw cG9ydCBib3RoIFFDUkFNIGFuZCBRUEFDSy4gSSB0aGVuIHdyb3RlIGEgc2ltdWxhdG9yIHRvIHRl c3QgdmFyaW91cyBuZXR3b3JrIGNvbmRpdGlvbnMuIFRoZSBzaW11bGF0b3IgaGFzIHR3byBwcmlt YXJ5IGtub2JzOg0KDQoxLiBTaW11bGF0ZWQgUlRUIC0gcm91bmQgdHJpcCB0aW1lIGJldHdlZW4g dGhlIGVuZHBvaW50cy4gVGhlcmUgaXMgYSBtaW5pbXVtIHByb2Nlc3NpbmcgZGVsYXkgb2YgcnR0 IC8gMiBiZXR3ZWVuIGVuY29kaW5nIGFuZCBkZWNvZGluZyBhIGhlYWRlciBibG9jayAyLiBTaW11 bGF0ZWQgbG9zcyBwcm9iYWJpbGl0eSAtIHByb2JhYmlsaXR5IHRoYXQgYSBnaXZlbiBwYWNrZXQg aXMgZHJvcHBlZC4gRHJvcHMgYXJlIHNpbXVsYXRlZCBieSBhZGRpbmcgMS4xIC0gMiBSVFRzIGJl dHdlZW4gZW5jb2RpbmcgYW5kIGRlY29kaW5nIGEgaGVhZGVyIGJsb2NrIEFmdGVyIGRlY29kaW5n IGEgaGVhZGVyIGJsb2NrLCBhIHNpbXVsYXRlZCBhY2sgaXMgZ2VuZXJhdGVkIGFuZCBkZWxpdmVy ZWQgdG8gdGhlIGVuY29kZXIgd2l0aCB0aGUgc2FtZSBSVFQgYW5kIGxvc3MgbW9kZWwgKGUuZy46 IGFja3MgY2FuIGFsc28gYmUgbG9zdCBhbmQgcmV0cmFuc21pdHRlZCkNCg0KDQoNCkkga25vdyB0 aGlzIGlzIGEgc2ltcGxpc3RpYyBsb3NzIG1vZGVsLiAgSWYgc29tZW9uZSBoYXMgYSBkaWZmZXJl bnQgbW9kZWwgdGhleSBwcmVmZXIgYW5kIGNhbiBwcm92aWRlIG1lIHdpdGggQyBvciBDKysgY29k ZSwgSSBjYW4gcmUtcnVuIHRoZSBzaW11bGF0aW9ucyB3aXRoIGEgZGlmZmVyZW50IGxvc3MgZW5n aW5lLiAgSSBob3BlIHRvIG9wZW4gc291cmNlIHRoZSBRUEFDSy9RQ1JBTSBpbXBsZW1lbnRhdGlv bnMgYW5kIHRoZSBzaW11bGF0b3IgZXZlbnR1YWxseSwgYnV0IHRoZXkgYXJlIG5vdCByZWFkeSBh dCBwcmVzZW50Lg0KDQoNCg0KRXhwZXJpbWVudCBTZXR1cA0KDQoNCg0KSSBsb2FkZWQgbXkgRmFj ZWJvb2sgZmVlZCBpbiBDaHJvbWUgYW5kIGNhcHR1cmVkIHJlcXVlc3QgaGVhZGVycyBhbmQgdGlt aW5nIGluIGEgSEFSIGZpbGUuIFRoZSBzaW11bGF0b3IgcmVhZHMgdGhlIEhBUiBmaWxlIGFuZCBz Y2hlZHVsZXMgdGhlIGVuY29kaW5ncyBiYXNlZCBvbiB0aGUgcmVxdWVzdCBzdGFydCB0aW1lcy4g SXQgY29udGFpbmVkIDIyNyByZXF1ZXN0cyBtYWRlIHRvIDUgb3JpZ2lucy4gIEkgc2ltdWxhdGVk IGFzIGlmIGFsbCBmYWNlYm9vay5jb20gYW5kIGZiY2RuLm5ldCBvcmlnaW5zIHdlcmUgY29hbGVz Y2VkLiAgRm9yIHRoZSBvcmlnaW5hbCB0ZXN0LCBJIHRocm90dGxlZCB0aGUgY29ubmVjdGlvbiB0 byAxMDBtcyBSVFQuDQoNCkkgcmFuIHRoZSBzaW11bGF0aW9uIDUgdGltZXMgZm9yIGVhY2ggYWxn b3JpdGhtIHdpdGggUlRUIHJhbmdpbmcgZnJvbSAxMG1zIC0gNTAwbXMgYW5kIGxvc3MgcGVyY2Vu dGFnZSBmcm9tIDAgdG8gMTAlLg0KDQoNCg0KTWV0cmljcw0KDQoNCg0KQ3VtdWxhdGl2ZSBIT0wg RGVsYXkgLSBUaGlzIGlzIHRoZSBzdW0gb2YgdGhlIHRpbWUgaGVhZGVyIGJsb2NrcyBzcGVudCBp biBhIHF1ZXVlIHdhaXRpbmcgZm9yIGFuIGVhcmxpZXIgYmxvY2sgdG8gYmUgZGVjb2RlZC4gIEZv ciBleGFtcGxlLCBpZiBJIHNlbmQgb25lIHJlcXVlc3QgdGhhdCBhZGRzIGluZGV4ZWQgZW50cmll cyB0byB0aGUgaGVhZGVyIHRhYmxlIGZvbGxvd2VkIGJ5IHR3byByZXF1ZXN0cyB0aGF0IHJlZmVy ZW5jZSBpdCwgYnV0IHRoZSBmaXJzdCByZXF1ZXN0IGlzIGRlbGF5ZWQgMTAwbXMsIHRoZSBjdW11 bGF0aXZlIGRlbGF5IHdvdWxkIGJlIDIwMG1zICgyIHJlcXVlc3RzIHggMTAwbXMpLg0KDQoNCg0K Q29tcHJlc3Npb24gUmF0aW8gLSBSYXRpbyBvZiBieXRlcyBzZW50IG9uIHRoZSB3aXJlIHRvIHRo ZSB0b3RhbCB1bmNvbXByZXNzZWQgaGVhZGVyIHNpemUNCg0KDQoNCk1heGltdW0gQnVmZmVyIFNp emUgLSBJZiBIT0wgYmxvY2tpbmcgb2NjdXJzLCB0aGUgZGVjb2RlciBtdXN0IGJ1ZmZlciBzb21l IGhlYWRlciBkYXRhLiAgVGhpcyBpcyB0aGUgbWF4aW11bSBzaXplIG9mIHRoZSBidWZmZXIgaW4g Ynl0ZXMgb3ZlciB0aGUgbGlmZXRpbWUgb2YgdGhlIHNlc3Npb24uDQoNClJlc3VsdHMNCg0KDQoN CkRhdGE6DQoNCg0KDQpEZWxheTogaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuZHJvcGJveC5jb20lMkZzJTJGcWRoMzEw ZXByeThzaGExJTJGSE9MJTI1MjBEZWxheS5wbmclM0ZkbCUzRDAmZGF0YT0wMiU3QzAxJTdDbWlj aGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDZjE0ZTBjMGY5ZmFkNGQ0MjYwMzkwOGQ0YWNh ODE1NDclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2MzIz Mjg1MzE4MDA0MzczJnNkYXRhPTNXRjQ4T1BoR2lobWVFSXB5NTlXb1hOVWNPNnNSMndCWXh0YWpD dVA5OEklM0QmcmVzZXJ2ZWQ9MA0KDQpDb21wcmVzc2lvbiBSYXRpbzogaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuZHJv cGJveC5jb20lMkZzJTJGcXF3enRxdDh1d2Jxd2pyJTJGQ29tcHJlc3Npb24lMjUyMFJhdGlvLnBu ZyUzRmRsJTNEMCZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20l N0NmMTRlMGMwZjlmYWQ0ZDQyNjAzOTA4ZDRhY2E4MTU0NyU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzYzMjMyODUzMTgwMDQzNzMmc2RhdGE9VXhOTVg2cnl1 dTZmVVJYd0EweE01JTJGNzE4eUpvZGprMlVOQ3JISXM4WE5VJTNEJnJlc2VydmVkPTANCg0KQnVm ZmVyIFNpemU6IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmRyb3Bib3guY29tJTJGcyUyRjNiMGMzNHVwdDExd210NyUy RkhPTCUyNTIwQnVmZmVyaW5nLnBuZyUzRmRsJTNEMCZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJp c2hvcCU0MG1pY3Jvc29mdC5jb20lN0NmMTRlMGMwZjlmYWQ0ZDQyNjAzOTA4ZDRhY2E4MTU0NyU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzYzMjMyODUzMTgw MDQzNzMmc2RhdGE9R0NaSXhONnB1UEtkNVVBa3RMb2VIVmJyRkljJTJCY2pNdDRsVDlWZ29hVHln JTNEJnJlc2VydmVkPTANCg0KDQoNCg0KDQpIaWdoIGxldmVsIG9ic2VydmF0aW9ucw0KDQoNCg0K MS4gSGVhZC1vZi1saW5lIGJsb2NraW5nIGlzIGEgdmVyeSByZWFsIHByb2JsZW0gZm9yIHNlcmlh bGl6ZWQgSFBBQ0sgdGhhdCBnZXRzIHByZWRpY3RhYmx5IHdvcnNlIGFzIFJUVCBhbmQgbG9zcyBp bmNyZWFzZS4gQXQgYSBmYWlybHkgbW9kZXN0IDEwMG1zIFJUVCArIDIlIGxvc3MsIEhPTCBibG9j a2luZyBvbiBoZWFkZXJzIGFkZGVkIGFuIGF2ZXJhZ2Ugb2YgNDBtcyAvIHJlcXVlc3QuIEF0IDIw MG1zLzUlIGxvc3MsIGl04oCZcyBhbG1vc3QgMTAwbXMvcmVxdWVzdCwgYW5kIHRoZSBwMTAwICht YXgpIHdhcyA0OTdtcy9yZXF1ZXN0Lg0KDQoyLiBRUEFDSyBhbmQgUUNSQU0gYm90aCBkcmFzdGlj YWxseSByZWR1Y2UgSE9MIGJsb2NraW5nLiBRQ1JBTeKAmXMgZGVzaWduIGZhdm9ycyBzYWNyaWZp Y2luZyBjb21wcmVzc2lvbiByYXRpbyB0byByZWR1Y2UgSE9MIGJsb2NraW5nLCB3aGlsZSBRUEFD SyBtYWludGFpbnMgSFBBQ0vigJlzIGNvbXByZXNzaW9uIHJhdGlvIGF0IHRoZSBleHBlbnNlIG9m IGFkZGl0aW9uYWwgbGF0ZW5jeS4gQXMgc3VjaCwgUUNSQU0gaW5jdXJyZWQgMCBoZWFkIG9mIGxp bmUgYmxvY2tpbmcgZGVsYXkgaW4gMTAwJSBvZiBteSBzaW11bGF0aW9ucywgYW5kIFFQQUNLIGhh ZCAwIGluIDgwJSBvZiB0ZXN0IHJ1bnMuIFRoZSBhdmVyYWdlIGRlbGF5IHdhcyA4bXMvcmVxLCBw OTUgZGVsYXkgd2FzIDYzbXMvcmVxdWVzdCBhbmQgcDEwMCB3YXMgMjQybXMvcmVxdWVzdC4gIE1p a2UgQmlzaG9wIHN1Z2dlc3RlZCBzb21lIFFDUkFNIHRlY2huaXF1ZXMgY291bGQgYmUgYXBwbGll ZCB0byBRUEFDSyB0byBtb2RpZnkgdGhlIGJsb2NraW5nL2NvbXByZXNzaW9uIHJhdGlvIHRyYWRl b2ZmLg0KDQozLiBRQ1JBTSBzZW5kcyB1cCAxNSUgbW9yZSBoZWFkZXIgYnl0ZXMgb24gdGhlIHdp cmUgZXZlbiBpbiBtb2RlcmF0ZSBuZXR3b3Jrcy4gQmVjYXVzZSBvZiB0aGUgbmF0dXJlIG9mIG15 IHNpbXVsYXRpb24sIHRoZSBjb21wcmVzc2lvbiByYXRpbyBkYXRhIGZvciBRQ1JBTSBtYXkgYmUg cGVzc2ltaXN0aWMgZm9yIFJUVHMgPiAyMDBtcywgYnV0IGl04oCZcyBwcm9iYWJseSBpbiB0aGUg ODQlIGJhbGxwYXJrLg0KDQo0LiBCZWNhdXNlIFFDUkFNIG9ubHkgaW5mcmVxdWVudGx5IGluZHVj ZXMgSE9MIGJsb2NraW5nLCBub25lIG9mIHRoZSBzaW11bGF0aW9ucyByZXN1bHRlZCBpbiB0aGUg ZGVjb2RlciBoYXZpbmcgdG8gYnVmZmVyIGZyYW1lcy4gUVBBQ0tzIGJ1ZmZlcnMgd2VyZSB1c3Vh bGx5IG1hbmFnZWFibGUgKHNtYWxsZXIgdGhhbiAxa2IpLCBidXQgbm90ZSB0aGF0IHdoZW4gUVBB Q0sgZW5jb3VudGVycyBIT0wgYmxvY2tpbmcsIGl0IGJ1ZmZlcnMgZGVjb21wcmVzc2VkIGRhdGEg cG90ZW50aWFsbHkgb2NjdXB5aW5nIGEgbG90IG9mIG1lbW9yeS4gIE1pa2UgQmlzaG9wIHN1Z2dl c3RlZCB0aGlzIGNvdWxkIGJlIG1pdGlnYXRlZCBieSBwZXJmb3JtaW5nIHRoZSBkZWNvZGUgaW4g dHdvIHN0ZXBzLCBhbmQgYnVmZmVyaW5nIHRoZSBjb21wcmVzc2VkIGRhdGEgaWYgZGVjb2Rpbmcg d291bGQgYmxvY2suDQoNCg0KDQpJbXBsZW1lbnRhdGlvbiBDb25zaWRlcmF0aW9ucw0KDQoNCg0K QSBiYXNpYyBRQ1JBTSBpbXBsZW1lbnRhdGlvbiBpcyBzaW1wbGVyLCBiZWNhdXNlIGl0IGNhbiBt b3JlIGRpcmVjdGx5IGxldmVyYWdlIGFuIGV4aXN0aW5nIEhQQUNLIGltcGxlbWVudGF0aW9uLiBJ dCB3YXMgZnVydGhlciBzaW1wbGVyIGZvciBGYWNlYm9vayBiZWNhdXNlIG91ciBpbXBsZW1lbnRh dGlvbiB3YXMgYWxyZWFkeSBkZXNpZ25lZCB0byBoYW5kbGUgYXN5bmNocm9ueSBhdCB0aGUgbGF5 ZXIgb2YgZGVjb2RpbmcgaGVhZGVycy4gRnVsbCBpbXBsZW1lbnRhdGlvbiBhbHNvIHJlcXVpcmVz IHNvbWUgaW50ZXJhY3Rpb24gd2l0aCB0aGUgdHJhbnNwb3J04oCZcyBhY2tub3dsZWRnZW1lbnQg aGFuZGxpbmcuIEFkZGl0aW9uYWwgY29tcGxleGl0eSBhbHNvIGNvbWVzIHdoZW4gdHJ5aW5nIHRv IHVzZSB0aGUgcGFja2V0IGVwb2NoLCBiZWNhdXNlIGl0IHJlcXVpcmVzIHRoZSBwYWNrZXQgc2No ZWR1bGluZyBsYXllciBvZiB0aGUgdHJhbnNwb3J0IHRvIGludGVyYWN0IHdpdGggdGhlIGhlYWRl ciBjb21wcmVzc2lvbiBhbGdvcml0aG0uIFdoaWxlIEkgd2FzIGFibGUgdG8gYXBwcm94aW1hdGUg dGhpcyBzaW1wbHkgaW4gbXkgc2ltdWxhdGlvbiwgRmFjZWJvb2sgcHJlZmVycyBtb3JlIHNlcGFy YXRpb24gYmV0d2VlbiB0aGUgdHJhbnNwb3J0IGFuZCBhcHBsaWNhdGlvbiBsYXllcnMgb2YgaHEs IHNvIGltcGxlbWVudGluZyBpbiBwcmFjdGljZSBtYXkgYmUgbW9yZSBkaWZmaWN1bHQuIEluIG15 IHNpbXVsYXRpb24gdGhvdWdoLCBjb21wcmVzc2lvbiByYXRpbyBkaWRu4oCZdCBhcHBlYXIgdG8g aW1wcm92ZSBkcmFzdGljYWxseSB3aXRoIHRoaXMgZmVhdHVyZSwgYW5kIG1pZ2h0IGJlIGh1cnQg cGVyZm9ybWFuY2UgaW4gc29tZSBzY2VuYXJpb3MgaWYgcmUtaW5kZXhpbmcgdGhlIHNhbWUgaGVh ZGVyL3ZhbHVlIGxlYWRzIHRvIG1vcmUgdGFibGUgZXZpY3Rpb25zLg0KDQpRUEFDS+KAmXMgZGVz aWduIGlzIGRpZmZlcmVudCBlbm91Z2ggdGhhdCBpdCBjYW7igJl0IHVzZSB0aGUgc2FtZSB1bmRl cmx5aW5nIHN0cnVjdHVyZSBhcyBIUEFDSy4gRnVydGhlcm1vcmUsIGl04oCZcyBxdWl0ZSBkaWZm ZXJlbnQgaW4gd2hlcmUgYXN5bmNocm9ueSBpcyBleHBlY3RlZCAtIGF0IHRoZSBsZXZlbCBvZiB0 YWJsZSBsb29rdXBzIHJhdGhlciB0aGFuIGJsb2NrIGRlY29kaW5nLiAgRXhwbGljaXQgaW5kZXhp bmcgaXMgc2ltcGxlciB0byB1bmRlcnN0YW5kIHRoYW4gSFBBQ0vigJlzIHJlbGF0aXZlIGluZGV4 aW5nLCBhbmQgYWxvbmcgd2l0aCByZWZlcmVuY2UgY291bnRzIGFuIGltcGxlbWVudGF0aW9uIGNh biBiZSBjbGV2ZXIgYWJvdXQgbmV2ZXIgZXZpY3RpbmcgZnJlcXVlbnRseSB1c2VkIGhlYWRlcnMu IFFQQUNLIHJlcXVpcmVzIG1vcmUgYWRkaXRpb25hbCBzdGF0ZSBpbiB0aGUgaGVhZGVyIHRhYmxl IHRoYW4gUUNSQU0uDQoNCg0KDQpDYXZlYXRzDQoNCg0KDQpEaWZmZXJlbnQgd29ya2xvYWRzIG1h eSBwcm9kdWNlIHF1aXRlIGRpZmZlcmVudCByZXN1bHRzLiBJbiBsb2FkaW5nIHRoZSBGYWNlYm9v ayBmZWVkLCB0aGVyZSB3ZXJlIG5vIGV2aWN0aW9ucyBmcm9tIHRoZSBoZWFkZXIgdGFibGUgdXNp bmcgUUNSQU0uIFRoaXMgd2lsbCB2YXJ5IGRlcGVuZGluZyBvbiBpbXBsZW1lbnRhdGlvbiBkZWNp c2lvbnMgYWJvdXQgd2hpY2ggaGVhZGVyIGZpZWxkcyB0byBpbmRleC4gRXZpY3Rpb25zIHdpbGwg aGF2ZSBhIG1vcmUgbmVnYXRpdmUgaW1wYWN0IG9uIFFDUkFN4oCZcyBIT0wgYmxvY2tpbmcsIGFu ZCBtb3JlIGltcGFjdCBvbiBRUEFDS+KAmXMgY29tcHJlc3Npb24gcmF0aW8uDQoNCg0KDQpIYXZp bmcgdGhlIENETiBjb2FsZXNjZWQgd2l0aCB0aGUgZHluYW1pYyBvcmlnaW4gYWxzbyBwbGF5cyBh IHJvbGUgaW4gdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBjb21wcmVzc2lvbiBzY2hlbWVzLiAgT3Zl ciB0aW1lIEkgaG9wZSB0byBidWlsZCBhIGRpdmVyc2UgY29sbGVjdGlvbiBvZiBpbnB1dCBIQVIg ZmlsZXMgZnJvbSBkaWZmZXJlbnQgc2l0ZXMgYW5kIGFwcGxpY2F0aW9ucyB3aGljaCBjYW4gYmUg cnVuIHRocm91Z2ggdGhlIHNpbXVsYXRvciB0byBnZXQgbW9yZSBjb21wbGV0ZSBkYXRhLg0KDQoN Cg0KVGhhbmtzIHRvIE1pa2UgQmlzaG9wIGFuZCBCdWNrIEtyYXNpYyB3aG8gcHJvdmlkZWQgZmVl ZGJhY2suDQoNCg0K --_000_MWHPR03MB294475C20C1E4937386D171E87CB0MWHPR03MB2944namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDUxMTQ5MjY1Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTAyMTI5NzEwOCA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkFnYWluLCB0aGFua3MgZm9yIHB1dHRpbmcgdGhpcyB0b2dldGhlciwgQWxhbi4m bmJzcDsgTXkgY29tbWVudHMgaW4gbW9yZSBkZXRhaWwgd2VyZTo8bzpwPjwvbzpwPjwvcD4NCjx1 bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlFD UkFNIGZvcmJpZHMgcmVmZXJlbmNpbmcgYSBoZWFkZXIgdW50aWwgeW914oCZcmUgc3VyZSBpdCBo YXMgYXJyaXZlZC4mbmJzcDsgVGhhdCBsZWFkcyBvbmUgdG8gZXhwZWN0IHdoYXQgeW91IGZvdW5k IGJlbG93OiZuYnNwOyBOZXZlciBIT0wtYmxvY2tpbmcsIG1vcmUgYnl0ZXMuJm5ic3A7IFFQQUNL IGxlYXZlcyB0aGF0IGNob2ljZSB0byB0aGUgZW5jb2RlciwNCiB3aGljaCBtZWFucyB5b3UgY2Fu IGNob29zZSB0byB0YWtlIHRoZSByaXNrIGFuZCBnZXQgYmV0dGVyIGJ5dGUtZWZmaWNpZW5jeSBv ciBiZSBtb3JlIGNvbnNlcnZhdGl2ZS4mbmJzcDsgSXTigJlzIGp1c3Qgbm90IG1hbmRhdGVkLjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+QW4gaW1wbGVtZW50YXRpb24gdGhhdCB3YW50 ZWQgdG8gZG8gYmxvY2tpbmcgYXQgdGhlIGhlYWRlciBzZXQgbGV2ZWwgY291bGQgZG8gdGhhdCDi gJMgeW914oCZZCBhZGQgYW4gaW5pdGlhbCBwYXNzIG9mIHRoZSBlbmNvZGVkIGhlYWRlcnMgdG8g c2VlIHdoZXRoZXIgYWxsIHJlZmVyZW5jZXMgY2FuIGJlIHNhdGlzZmllZC4mbmJzcDsgSWYNCiBu b3QsIHdhaXQgdG8gZGVjb21wcmVzcyBhbnl0aGluZyB1bnRpbCB0aGV5IGNhbiBiZS4mbmJzcDsg VGhhdCBhbHNvIHNhdmVzIHRoZSBkZWNvZGVyIGJ1ZmZlcmluZyB1bmNvbXByZXNzZWQgaGVhZGVy IGRhdGEgd2hpbGUgd2FpdGluZy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PG86cD4mbmJzcDs8L286cD48L2E+ PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K RnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFs YW4gRnJpbmRlbGw8YnI+DQpTZW50OiBUdWVzZGF5LCBKdW5lIDYsIDIwMTcgODo0OCBBTTxicj4N ClRvOiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVjdDogQ29t cGFyaW5nIEhUVFAgb3ZlciBRVUlDIGhlYWRlciBjb21wcmVzc2lvbiBzY2hlbWVzPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5JIGJ1aWx0IGEgUUNSQU0gYW5kIFFQQUNLIGltcGxlbWVudGF0aW9uIGFuZCBh dHRlbXB0ZWQgdG8gc2ltdWxhdGUgcGVyZm9ybWFuY2UgdW5kZXIgdmFyeWluZyBuZXR3b3JrIGNv bmRpdGlvbnMuJm5ic3A7IEhlcmXigJlzIGEgc3VtbWFyeSBvZiB0aGUgd29yayBzbyBmYXIuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi1BbGFuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPj09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Qcm9ibGVtPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkhUVFAvMiB1c2VzIEhQQUNLIGZvciBoZWFkZXIgY29tcHJl c3Npb24sIHdoaWNoIHJlbGllcyBvbiBpbi1vcmRlciBwcm9jZXNzaW5nIG9mIGhlYWRlciBmcmFt ZXMuIFRoZSBjdXJyZW50IFFVSUMgZHJhZnQgcmV0YWlucyBIUEFDSyBhbmQgaW50cm9kdWNlcyBh IHNlcXVlbmNlIG51bWJlciBmb3IgaGVhZGVyIGZyYW1lcyBzbyB0aGUgSFRUUCBpbXBsZW1lbnRh dGlvbiBjYW4gZW5zdXJlIGluLW9yZGVyIHByb2Nlc3NpbmcuJm5ic3A7DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZXJlIGFyZSB0d28gcHJvcG9zZWQgY29tcHJl c3Npb24gc2NoZW1lcyBmb3IgSFRUUCBvdmVyIFFVSUMgdGhhdCBmYWNpbGl0YXRlIG91dC1vZi1v cmRlciBwcm9jZXNzaW5nLCBRQ1JBTSBhbmQgUVBBQ0suJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk15IGdvYWwgd2FzIHRvIHVuZGVyc3RhbmQgdGhlIG1h Z25pdHVkZSBvZiB0aGUgcHJvYmxlbSBjYXVzZWQgYnkgSE9MIGJsb2NraW5nIG9uIGhlYWRlciBm cmFtZXMgdW5kZXIgdmFyeWluZyBuZXR3b3JrIGNvbmRpdGlvbnMsIGFuZCBxdWFudGlmeSB0aGUg ZGVncmVlIHRvIHdoaWNoIFFDUkFNIGFuZCBRUEFDSyBhbGxldmlhdGUgdGhlIHByb2JsZW0uIEkg d2FzIGFsc28gc2Vla2luZyB0byB1bmRlcnN0YW5kDQogdGhlIGltcGxlbWVudGF0aW9uIGNvbXBs ZXhpdHkgb2YgZWFjaCBzY2hlbWUgYW5kIHByb3ZpZGUgZmVlZGJhY2sgdG8gdGhlIGF1dGhvcnMg d2l0aCBvbiB0aGUgc3BlY2lmaWNhdGlvbiBkcmFmdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPk1ldGhvZG9sb2d5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgbW9kaWZp ZWQgcHJveHlnZW7igJlzIEhQQUNLIGxpYnJhcnkgKDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNv bSUyRmZhY2Vib29rJTJGcHJveHlnZW4mYW1wO2RhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9w JTQwbWljcm9zb2Z0LmNvbSU3Q2YxNGUwYzBmOWZhZDRkNDI2MDM5MDhkNGFjYTgxNTQ3JTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjMyMzI4NTMxODAwNDM3 MyZhbXA7c2RhdGE9bWFEUFo1bEd5NFBzSlo3cVFUZHhaSTdxdGZSVWFOZ0FQMEtVajBoeWZpMCUz RCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmZhY2Vib29rJTJGcHJveHlnZW4mYW1w O2RhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2YxNGUwYzBm OWZhZDRkNDI2MDM5MDhkNGFjYTgxNTQ3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN0MxJTdDMCU3QzYzNjMyMzI4NTMxODAwNDM3MyZhbXA7c2RhdGE9bWFEUFo1bEd5NFBzSlo3 cVFUZHhaSTdxdGZSVWFOZ0FQMEtVajBoeWZpMCUzRCZhbXA7cmVzZXJ2ZWQ9MDwvc3Bhbj48L2E+ KSZuYnNwOw0KIHRvIHN1cHBvcnQgYm90aCBRQ1JBTSBhbmQgUVBBQ0suIEkgdGhlbiB3cm90ZSBh IHNpbXVsYXRvciB0byB0ZXN0IHZhcmlvdXMgbmV0d29yayBjb25kaXRpb25zLiBUaGUgc2ltdWxh dG9yIGhhcyB0d28gcHJpbWFyeSBrbm9iczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjEuIFNpbXVsYXRlZCBSVFQgLSByb3VuZCB0cmlwIHRpbWUgYmV0d2VlbiB0aGUg ZW5kcG9pbnRzLiBUaGVyZSBpcyBhIG1pbmltdW0gcHJvY2Vzc2luZyBkZWxheSBvZiBydHQgLyAy IGJldHdlZW4gZW5jb2RpbmcgYW5kIGRlY29kaW5nIGEgaGVhZGVyIGJsb2NrIDIuIFNpbXVsYXRl ZCBsb3NzIHByb2JhYmlsaXR5IC0gcHJvYmFiaWxpdHkgdGhhdCBhIGdpdmVuIHBhY2tldCBpcyBk cm9wcGVkLiBEcm9wcyBhcmUNCiBzaW11bGF0ZWQgYnkgYWRkaW5nIDEuMSAtIDIgUlRUcyBiZXR3 ZWVuIGVuY29kaW5nIGFuZCBkZWNvZGluZyBhIGhlYWRlciBibG9jayBBZnRlciBkZWNvZGluZyBh IGhlYWRlciBibG9jaywgYSBzaW11bGF0ZWQgYWNrIGlzIGdlbmVyYXRlZCBhbmQgZGVsaXZlcmVk IHRvIHRoZSBlbmNvZGVyIHdpdGggdGhlIHNhbWUgUlRUIGFuZCBsb3NzIG1vZGVsIChlLmcuOiBh Y2tzIGNhbiBhbHNvIGJlIGxvc3QgYW5kIHJldHJhbnNtaXR0ZWQpPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkkga25vdyB0aGlzIGlzIGEgc2ltcGxpc3RpYyBsb3NzIG1vZGVsLiZuYnNw OyBJZiBzb21lb25lIGhhcyBhIGRpZmZlcmVudCBtb2RlbCB0aGV5IHByZWZlciBhbmQgY2FuIHBy b3ZpZGUgbWUgd2l0aCBDIG9yIEMmIzQzOyYjNDM7IGNvZGUsIEkgY2FuIHJlLXJ1biB0aGUgc2lt dWxhdGlvbnMgd2l0aCBhIGRpZmZlcmVudCBsb3NzIGVuZ2luZS4mbmJzcDsgSSBob3BlIHRvIG9w ZW4gc291cmNlIHRoZSBRUEFDSy9RQ1JBTSBpbXBsZW1lbnRhdGlvbnMNCiBhbmQgdGhlIHNpbXVs YXRvciBldmVudHVhbGx5LCBidXQgdGhleSBhcmUgbm90IHJlYWR5IGF0IHByZXNlbnQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkV4cGVyaW1lbnQgU2V0dXA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+SSBsb2FkZWQgbXkgRmFjZWJvb2sgZmVlZCBpbiBDaHJvbWUgYW5kIGNh cHR1cmVkIHJlcXVlc3QgaGVhZGVycyBhbmQgdGltaW5nIGluIGEgSEFSIGZpbGUuIFRoZSBzaW11 bGF0b3IgcmVhZHMgdGhlIEhBUiBmaWxlIGFuZCBzY2hlZHVsZXMgdGhlIGVuY29kaW5ncyBiYXNl ZCBvbiB0aGUgcmVxdWVzdCBzdGFydCB0aW1lcy4gSXQgY29udGFpbmVkIDIyNyByZXF1ZXN0cyBt YWRlIHRvIDUgb3JpZ2lucy4mbmJzcDsgSQ0KIHNpbXVsYXRlZCBhcyBpZiBhbGwgZmFjZWJvb2su Y29tIGFuZCBmYmNkbi5uZXQgb3JpZ2lucyB3ZXJlIGNvYWxlc2NlZC4mbmJzcDsgRm9yIHRoZSBv cmlnaW5hbCB0ZXN0LCBJIHRocm90dGxlZCB0aGUgY29ubmVjdGlvbiB0byAxMDBtcyBSVFQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIHJhbiB0aGUgc2ltdWxhdGlv biA1IHRpbWVzIGZvciBlYWNoIGFsZ29yaXRobSB3aXRoIFJUVCByYW5naW5nIGZyb20gMTBtcyAt IDUwMG1zIGFuZCBsb3NzIHBlcmNlbnRhZ2UgZnJvbSAwIHRvIDEwJS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+TWV0cmljczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DdW11 bGF0aXZlIEhPTCBEZWxheSAtIFRoaXMgaXMgdGhlIHN1bSBvZiB0aGUgdGltZSBoZWFkZXIgYmxv Y2tzIHNwZW50IGluIGEgcXVldWUgd2FpdGluZyBmb3IgYW4gZWFybGllciBibG9jayB0byBiZSBk ZWNvZGVkLiZuYnNwOyBGb3IgZXhhbXBsZSwgaWYgSSBzZW5kIG9uZSByZXF1ZXN0IHRoYXQgYWRk cyBpbmRleGVkIGVudHJpZXMgdG8gdGhlIGhlYWRlciB0YWJsZSBmb2xsb3dlZCBieSB0d28gcmVx dWVzdHMNCiB0aGF0IHJlZmVyZW5jZSBpdCwgYnV0IHRoZSBmaXJzdCByZXF1ZXN0IGlzIGRlbGF5 ZWQgMTAwbXMsIHRoZSBjdW11bGF0aXZlIGRlbGF5IHdvdWxkIGJlIDIwMG1zICgyIHJlcXVlc3Rz IHggMTAwbXMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Db21wcmVzc2lvbiBSYXRp byAtIFJhdGlvIG9mIGJ5dGVzIHNlbnQgb24gdGhlIHdpcmUgdG8gdGhlIHRvdGFsIHVuY29tcHJl c3NlZCBoZWFkZXIgc2l6ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NYXhpbXVtIEJ1 ZmZlciBTaXplIC0gSWYgSE9MIGJsb2NraW5nIG9jY3VycywgdGhlIGRlY29kZXIgbXVzdCBidWZm ZXIgc29tZSBoZWFkZXIgZGF0YS4mbmJzcDsgVGhpcyBpcyB0aGUgbWF4aW11bSBzaXplIG9mIHRo ZSBidWZmZXIgaW4gYnl0ZXMgb3ZlciB0aGUgbGlmZXRpbWUgb2YgdGhlIHNlc3Npb24uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXN1bHRzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkRhdGE6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRlbGF5 OiA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5kcm9wYm94LmNvbSUyRnMlMkZxZGgzMTBlcHJ5OHNoYTEl MkZIT0wlMjUyMERlbGF5LnBuZyUzRmRsJTNEMCZhbXA7ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5i aXNob3AlNDBtaWNyb3NvZnQuY29tJTdDZjE0ZTBjMGY5ZmFkNGQ0MjYwMzkwOGQ0YWNhODE1NDcl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2MzIzMjg1MzE4 MDA0MzczJmFtcDtzZGF0YT0zV0Y0OE9QaEdpaG1lRUlweTU5V29YTlVjTzZzUjJ3Qll4dGFqQ3VQ OThJJTNEJmFtcDtyZXNlcnZlZD0wIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5kcm9wYm94LmNvbSUyRnMlMkZxZGgzMTBl cHJ5OHNoYTElMkZIT0wlMjUyMERlbGF5LnBuZyUzRmRsJTNEMCZhbXA7ZGF0YT0wMiU3QzAxJTdD bWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDZjE0ZTBjMGY5ZmFkNGQ0MjYwMzkwOGQ0 YWNhODE1NDclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2 MzIzMjg1MzE4MDA0MzczJmFtcDtzZGF0YT0zV0Y0OE9QaEdpaG1lRUlweTU5V29YTlVjTzZzUjJ3 Qll4dGFqQ3VQOThJJTNEJmFtcDtyZXNlcnZlZD0wPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNvbXByZXNzaW9uIFJhdGlvOiA8YSBocmVmPSJodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy5kcm9wYm94LmNvbSUyRnMlMkZxcXd6dHF0OHV3YnF3anIlMkZDb21wcmVzc2lvbiUy NTIwUmF0aW8ucG5nJTNGZGwlM0QwJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0 MG1pY3Jvc29mdC5jb20lN0NmMTRlMGMwZjlmYWQ0ZDQyNjAzOTA4ZDRhY2E4MTU0NyU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzYzMjMyODUzMTgwMDQzNzMm YW1wO3NkYXRhPVV4Tk1YNnJ5dXU2ZlVSWHdBMHhNNSUyRjcxOHlKb2RqazJVTkNySElzOFhOVSUz RCZhbXA7cmVzZXJ2ZWQ9MCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuZHJvcGJveC5jb20lMkZzJTJGcXF3enRxdDh1d2Jx d2pyJTJGQ29tcHJlc3Npb24lMjUyMFJhdGlvLnBuZyUzRmRsJTNEMCZhbXA7ZGF0YT0wMiU3QzAx JTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDZjE0ZTBjMGY5ZmFkNGQ0MjYwMzkw OGQ0YWNhODE1NDclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdD NjM2MzIzMjg1MzE4MDA0MzczJmFtcDtzZGF0YT1VeE5NWDZyeXV1NmZVUlh3QTB4TTUlMkY3MTh5 Sm9kamsyVU5DckhJczhYTlUlM0QmYW1wO3Jlc2VydmVkPTA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QnVmZmVyIFNpemU6IDxhIGhyZWY9Imh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmRyb3Bib3guY29tJTJGcyUyRjNiMGMzNHVwdDExd210NyUyRkhPTCUyNTIwQnVmZmVy aW5nLnBuZyUzRmRsJTNEMCZhbXA7ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNy b3NvZnQuY29tJTdDZjE0ZTBjMGY5ZmFkNGQ0MjYwMzkwOGQ0YWNhODE1NDclN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2MzIzMjg1MzE4MDA0MzczJmFtcDtz ZGF0YT1HQ1pJeE42cHVQS2Q1VUFrdExvZUhWYnJGSWMlMkJjak10NGxUOVZnb2FUeWclM0QmYW1w O3Jlc2VydmVkPTAiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmRyb3Bib3guY29tJTJGcyUyRjNiMGMzNHVwdDExd210NyUy RkhPTCUyNTIwQnVmZmVyaW5nLnBuZyUzRmRsJTNEMCZhbXA7ZGF0YT0wMiU3QzAxJTdDbWljaGFl bC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDZjE0ZTBjMGY5ZmFkNGQ0MjYwMzkwOGQ0YWNhODE1 NDclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2MzIzMjg1 MzE4MDA0MzczJmFtcDtzZGF0YT1HQ1pJeE42cHVQS2Q1VUFrdExvZUhWYnJGSWMlMkJjak10NGxU OVZnb2FUeWclM0QmYW1wO3Jlc2VydmVkPTA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkhpZ2ggbGV2ZWwgb2JzZXJ2YXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjEu IEhlYWQtb2YtbGluZSBibG9ja2luZyBpcyBhIHZlcnkgcmVhbCBwcm9ibGVtIGZvciBzZXJpYWxp emVkIEhQQUNLIHRoYXQgZ2V0cyBwcmVkaWN0YWJseSB3b3JzZSBhcyBSVFQgYW5kIGxvc3MgaW5j cmVhc2UuIEF0IGEgZmFpcmx5IG1vZGVzdCAxMDBtcyBSVFQgJiM0MzsgMiUgbG9zcywgSE9MIGJs b2NraW5nIG9uIGhlYWRlcnMgYWRkZWQgYW4gYXZlcmFnZSBvZiA0MG1zIC8gcmVxdWVzdC4gQXQg MjAwbXMvNSUNCiBsb3NzLCBpdOKAmXMgYWxtb3N0IDEwMG1zL3JlcXVlc3QsIGFuZCB0aGUgcDEw MCAobWF4KSB3YXMgNDk3bXMvcmVxdWVzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjIuIFFQQUNLIGFuZCBRQ1JBTSBib3RoIGRyYXN0aWNhbGx5IHJlZHVjZSBIT0wg YmxvY2tpbmcuIFFDUkFN4oCZcyBkZXNpZ24gZmF2b3JzIHNhY3JpZmljaW5nIGNvbXByZXNzaW9u IHJhdGlvIHRvIHJlZHVjZSBIT0wgYmxvY2tpbmcsIHdoaWxlIFFQQUNLIG1haW50YWlucyBIUEFD S+KAmXMgY29tcHJlc3Npb24gcmF0aW8gYXQgdGhlIGV4cGVuc2Ugb2YgYWRkaXRpb25hbCBsYXRl bmN5LiBBcyBzdWNoLCBRQ1JBTQ0KIGluY3VycmVkIDAgaGVhZCBvZiBsaW5lIGJsb2NraW5nIGRl bGF5IGluIDEwMCUgb2YgbXkgc2ltdWxhdGlvbnMsIGFuZCBRUEFDSyBoYWQgMCBpbiA4MCUgb2Yg dGVzdCBydW5zLiBUaGUgYXZlcmFnZSBkZWxheSB3YXMgOG1zL3JlcSwgcDk1IGRlbGF5IHdhcyA2 M21zL3JlcXVlc3QgYW5kIHAxMDAgd2FzIDI0Mm1zL3JlcXVlc3QuJm5ic3A7IE1pa2UgQmlzaG9w IHN1Z2dlc3RlZCBzb21lIFFDUkFNIHRlY2huaXF1ZXMgY291bGQgYmUgYXBwbGllZCB0byBRUEFD Sw0KIHRvIG1vZGlmeSB0aGUgYmxvY2tpbmcvY29tcHJlc3Npb24gcmF0aW8gdHJhZGVvZmYuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4zLiBRQ1JBTSBzZW5kcyB1cCAx NSUgbW9yZSBoZWFkZXIgYnl0ZXMgb24gdGhlIHdpcmUgZXZlbiBpbiBtb2RlcmF0ZSBuZXR3b3Jr cy4gQmVjYXVzZSBvZiB0aGUgbmF0dXJlIG9mIG15IHNpbXVsYXRpb24sIHRoZSBjb21wcmVzc2lv biByYXRpbyBkYXRhIGZvciBRQ1JBTSBtYXkgYmUgcGVzc2ltaXN0aWMgZm9yIFJUVHMgJmd0OyAy MDBtcywgYnV0IGl04oCZcyBwcm9iYWJseSBpbiB0aGUgODQlIGJhbGxwYXJrLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+NC4gQmVjYXVzZSBRQ1JBTSBvbmx5IGluZnJl cXVlbnRseSBpbmR1Y2VzIEhPTCBibG9ja2luZywgbm9uZSBvZiB0aGUgc2ltdWxhdGlvbnMgcmVz dWx0ZWQgaW4gdGhlIGRlY29kZXIgaGF2aW5nIHRvIGJ1ZmZlciBmcmFtZXMuIFFQQUNLcyBidWZm ZXJzIHdlcmUgdXN1YWxseSBtYW5hZ2VhYmxlIChzbWFsbGVyIHRoYW4gMWtiKSwgYnV0IG5vdGUg dGhhdCB3aGVuIFFQQUNLIGVuY291bnRlcnMgSE9MIGJsb2NraW5nLA0KIGl0IGJ1ZmZlcnMgZGVj b21wcmVzc2VkIGRhdGEgcG90ZW50aWFsbHkgb2NjdXB5aW5nIGEgbG90IG9mIG1lbW9yeS4mbmJz cDsgTWlrZSBCaXNob3Agc3VnZ2VzdGVkIHRoaXMgY291bGQgYmUgbWl0aWdhdGVkIGJ5IHBlcmZv cm1pbmcgdGhlIGRlY29kZSBpbiB0d28gc3RlcHMsIGFuZCBidWZmZXJpbmcgdGhlIGNvbXByZXNz ZWQgZGF0YSBpZiBkZWNvZGluZyB3b3VsZCBibG9jay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+QSBiYXNpYyBRQ1JBTSBpbXBsZW1lbnRhdGlvbiBpcyBzaW1wbGVyLCBiZWNhdXNl IGl0IGNhbiBtb3JlIGRpcmVjdGx5IGxldmVyYWdlIGFuIGV4aXN0aW5nIEhQQUNLIGltcGxlbWVu dGF0aW9uLiBJdCB3YXMgZnVydGhlciBzaW1wbGVyIGZvciBGYWNlYm9vayBiZWNhdXNlIG91ciBp bXBsZW1lbnRhdGlvbiB3YXMgYWxyZWFkeSBkZXNpZ25lZCB0byBoYW5kbGUgYXN5bmNocm9ueSBh dCB0aGUgbGF5ZXIgb2YNCiBkZWNvZGluZyBoZWFkZXJzLiBGdWxsIGltcGxlbWVudGF0aW9uIGFs c28gcmVxdWlyZXMgc29tZSBpbnRlcmFjdGlvbiB3aXRoIHRoZSB0cmFuc3BvcnTigJlzIGFja25v d2xlZGdlbWVudCBoYW5kbGluZy4gQWRkaXRpb25hbCBjb21wbGV4aXR5IGFsc28gY29tZXMgd2hl biB0cnlpbmcgdG8gdXNlIHRoZSBwYWNrZXQgZXBvY2gsIGJlY2F1c2UgaXQgcmVxdWlyZXMgdGhl IHBhY2tldCBzY2hlZHVsaW5nIGxheWVyIG9mIHRoZSB0cmFuc3BvcnQgdG8gaW50ZXJhY3QNCiB3 aXRoIHRoZSBoZWFkZXIgY29tcHJlc3Npb24gYWxnb3JpdGhtLiBXaGlsZSBJIHdhcyBhYmxlIHRv IGFwcHJveGltYXRlIHRoaXMgc2ltcGx5IGluIG15IHNpbXVsYXRpb24sIEZhY2Vib29rIHByZWZl cnMgbW9yZSBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24g bGF5ZXJzIG9mIGhxLCBzbyBpbXBsZW1lbnRpbmcgaW4gcHJhY3RpY2UgbWF5IGJlIG1vcmUgZGlm ZmljdWx0LiBJbiBteSBzaW11bGF0aW9uIHRob3VnaCwNCiBjb21wcmVzc2lvbiByYXRpbyBkaWRu 4oCZdCBhcHBlYXIgdG8gaW1wcm92ZSBkcmFzdGljYWxseSB3aXRoIHRoaXMgZmVhdHVyZSwgYW5k IG1pZ2h0IGJlIGh1cnQgcGVyZm9ybWFuY2UgaW4gc29tZSBzY2VuYXJpb3MgaWYgcmUtaW5kZXhp bmcgdGhlIHNhbWUgaGVhZGVyL3ZhbHVlIGxlYWRzIHRvIG1vcmUgdGFibGUgZXZpY3Rpb25zLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UVBBQ0vigJlzIGRlc2lnbiBp cyBkaWZmZXJlbnQgZW5vdWdoIHRoYXQgaXQgY2Fu4oCZdCB1c2UgdGhlIHNhbWUgdW5kZXJseWlu ZyBzdHJ1Y3R1cmUgYXMgSFBBQ0suIEZ1cnRoZXJtb3JlLCBpdOKAmXMgcXVpdGUgZGlmZmVyZW50 IGluIHdoZXJlIGFzeW5jaHJvbnkgaXMgZXhwZWN0ZWQgLSBhdCB0aGUgbGV2ZWwgb2YgdGFibGUg bG9va3VwcyByYXRoZXIgdGhhbiBibG9jayBkZWNvZGluZy4mbmJzcDsgRXhwbGljaXQgaW5kZXhp bmcNCiBpcyBzaW1wbGVyIHRvIHVuZGVyc3RhbmQgdGhhbiBIUEFDS+KAmXMgcmVsYXRpdmUgaW5k ZXhpbmcsIGFuZCBhbG9uZyB3aXRoIHJlZmVyZW5jZSBjb3VudHMgYW4gaW1wbGVtZW50YXRpb24g Y2FuIGJlIGNsZXZlciBhYm91dCBuZXZlciBldmljdGluZyBmcmVxdWVudGx5IHVzZWQgaGVhZGVy cy4gUVBBQ0sgcmVxdWlyZXMgbW9yZSBhZGRpdGlvbmFsIHN0YXRlIGluIHRoZSBoZWFkZXIgdGFi bGUgdGhhbiBRQ1JBTS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q2F2ZWF0czxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EaWZmZXJlbnQgd29ya2xvYWRzIG1heSBwcm9kdWNl IHF1aXRlIGRpZmZlcmVudCByZXN1bHRzLiBJbiBsb2FkaW5nIHRoZSBGYWNlYm9vayBmZWVkLCB0 aGVyZSB3ZXJlIG5vIGV2aWN0aW9ucyBmcm9tIHRoZSBoZWFkZXIgdGFibGUgdXNpbmcgUUNSQU0u IFRoaXMgd2lsbCB2YXJ5IGRlcGVuZGluZyBvbiBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbnMgYWJv dXQgd2hpY2ggaGVhZGVyIGZpZWxkcyB0byBpbmRleC4NCiBFdmljdGlvbnMgd2lsbCBoYXZlIGEg bW9yZSBuZWdhdGl2ZSBpbXBhY3Qgb24gUUNSQU3igJlzIEhPTCBibG9ja2luZywgYW5kIG1vcmUg aW1wYWN0IG9uIFFQQUNL4oCZcyBjb21wcmVzc2lvbiByYXRpby4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5IYXZpbmcgdGhlIENETiBjb2FsZXNjZWQgd2l0aCB0aGUgZHluYW1pYyBv cmlnaW4gYWxzbyBwbGF5cyBhIHJvbGUgaW4gdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBjb21wcmVz c2lvbiBzY2hlbWVzLiZuYnNwOyBPdmVyIHRpbWUgSSBob3BlIHRvIGJ1aWxkIGEgZGl2ZXJzZSBj b2xsZWN0aW9uIG9mIGlucHV0IEhBUiBmaWxlcyBmcm9tIGRpZmZlcmVudCBzaXRlcyBhbmQgYXBw bGljYXRpb25zIHdoaWNoIGNhbiBiZSBydW4NCiB0aHJvdWdoIHRoZSBzaW11bGF0b3IgdG8gZ2V0 IG1vcmUgY29tcGxldGUgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtz IHRvIE1pa2UgQmlzaG9wIGFuZCBCdWNrIEtyYXNpYyB3aG8gcHJvdmlkZWQgZmVlZGJhY2suPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR03MB294475C20C1E4937386D171E87CB0MWHPR03MB2944namp_-- From nobody Tue Jun 6 02:15:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4291412426E for ; Tue, 6 Jun 2017 02:15:04 -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 CHmO_hlOCQPO for ; Tue, 6 Jun 2017 02:15:02 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CD2124217 for ; Tue, 6 Jun 2017 02:15:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3whmH82Q6ZzMl4X; Tue, 6 Jun 2017 11:15:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA-n_4syIZbI; Tue, 6 Jun 2017 11:14:59 +0200 (CEST) X-MtScore: NO score=0 Received: from [10.243.37.8] (unknown [89.202.203.52]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 6 Jun 2017 11:14:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Comparing HTTP over QUIC header compression schemes From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 6 Jun 2017 11:14:59 +0200 Cc: "Eggert, Lars" , IETF QUIC WG , Alan Frindell Content-Transfer-Encoding: quoted-printable Message-Id: <6A169408-892A-4E56-B171-E2F0F1731097@tik.ee.ethz.ch> References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> To: Martin Thomson 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, 06 Jun 2017 09:15:04 -0000 > Am 06.06.2017 um 11:10 schrieb Martin Thomson = : >=20 > On 6 June 2017 at 10:59, Eggert, Lars wrote: >> (2) simulating loss rates much above 1% is likely going to be pretty = uninteresting, given that QUIC (and TCP, FWIW) have congestion = controllers that will struggle to even deliver useful throughputs in = these cases >=20 >=20 > That's an interesting point. I've seen a presentation (that I can't > find now, but I can try) that shows that packet loss in real-world > scenarios approaches 2% in a great many cases. >=20 With TCP traffic or a traffic aggregate that includes TCP traffic?= From nobody Tue Jun 6 02:19: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 C7DA71294C9 for ; Tue, 6 Jun 2017 02:18:59 -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 bA2AejFof59g for ; Tue, 6 Jun 2017 02:18:57 -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 BBE79126CB6 for ; Tue, 6 Jun 2017 02:18:57 -0700 (PDT) Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com [209.85.216.172]) by linode64.ducksong.com (Postfix) with ESMTPSA id 8EAB03A0A1 for ; Tue, 6 Jun 2017 05:18:55 -0400 (EDT) Received: by mail-qt0-f172.google.com with SMTP id u19so64323740qta.3 for ; Tue, 06 Jun 2017 02:18:55 -0700 (PDT) X-Gm-Message-State: AKS2vOyfIP+/FOO7tR3GcwcHbMVljKOVQ96zIBCYtYdKI889Pod1qMZC wDfDCChr4s8T1Bm99isVydzGtRhkfw== X-Received: by 10.55.4.137 with SMTP id 131mr30261828qke.140.1496740735373; Tue, 06 Jun 2017 02:18:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.178.74 with HTTP; Tue, 6 Jun 2017 02:18:54 -0700 (PDT) In-Reply-To: References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> From: Patrick McManus Date: Tue, 6 Jun 2017 11:18:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Comparing HTTP over QUIC header compression schemes To: Martin Thomson Cc: "Eggert, Lars" , IETF QUIC WG , Alan Frindell Content-Type: multipart/alternative; boundary="001a1148c15cda5a380551471b3c" 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, 06 Jun 2017 09:19:00 -0000 --001a1148c15cda5a380551471b3c Content-Type: text/plain; charset="UTF-8" Alan, I think this is really interesting. I want to reserve comment until I can read it when not multipexing with a WG meeting :) on the PLT: fastly generously shared some of their US based loss rates here https://www.slideshare.net/Fastly/http2-what-no-one-is-telling-you (slide 102) .. which shows > 1.5% on roughly ~12% of connections. There are a million caveats of course - but its one of the broader datapoints I've seen and its awesome they shared operational information. On Tue, Jun 6, 2017 at 11:10 AM, Martin Thomson wrote: > On 6 June 2017 at 10:59, Eggert, Lars wrote: > > (2) simulating loss rates much above 1% is likely going to be pretty > uninteresting, given that QUIC (and TCP, FWIW) have congestion controllers > that will struggle to even deliver useful throughputs in these cases > > > That's an interesting point. I've seen a presentation (that I can't > find now, but I can try) that shows that packet loss in real-world > scenarios approaches 2% in a great many cases. > > --001a1148c15cda5a380551471b3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan, I think this is really interesting. I want to r= eserve comment until I can read it when not multipexing with a WG meeting := )

on the PLT: fastly generously shared some of= their US based loss rates here https://www.slideshare.net/Fastly/http2= -what-no-one-is-telling-you (slide 102) .. which shows > 1.5% on rou= ghly ~12% of connections. There are a million caveats of course - but its o= ne of the broader datapoints I've seen and its awesome they shared oper= ational information.

On Tue, Jun 6, 2017 at 11:10 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 6 June 2017 at 10:59, Eggert, Lars <lars@netapp.com> wrote:
> (2) simulating loss rates much above 1% is likely going to be pretty u= ninteresting, given that QUIC (and TCP, FWIW) have congestion controllers t= hat will struggle to even deliver useful throughputs in these cases


That's an interesting point.=C2=A0 I've seen a presentation = (that I can't
find now, but I can try) that shows that packet loss in real-world
scenarios approaches 2% in a great many cases.


--001a1148c15cda5a380551471b3c-- From nobody Tue Jun 6 02:19:25 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291CE12426E for ; Tue, 6 Jun 2017 02:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 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] 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 K4Lbd6zQ-vAb for ; Tue, 6 Jun 2017 02:19:21 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.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 ADD83124217 for ; Tue, 6 Jun 2017 02:19:20 -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=RGnBPrTTtUBJRuz72P3Vj5tcdfuK+70g8fSZP9VGSeg=; b=IJrKaexgz6C1GTH9Mv6TM9Et/ZAqF63H08XDjiq16TzDVSpDssz7VFhh1sYGVh0b4xnlnOvxDltEDDtK6dUsaZDIonTexegknycKiOK5QZ8c6Y/KsvwZAJSS39oYyMZVnL+Sglg3MVam2wthsMRYia1x5+2j+EAUJHod3gWH9VM= Received: from MWHPR03MB2944.namprd03.prod.outlook.com (10.175.136.137) by MWHPR03MB2944.namprd03.prod.outlook.com (10.175.136.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Tue, 6 Jun 2017 09:19:17 +0000 Received: from MWHPR03MB2944.namprd03.prod.outlook.com ([10.175.136.137]) by MWHPR03MB2944.namprd03.prod.outlook.com ([10.175.136.137]) with mapi id 15.01.1143.018; Tue, 6 Jun 2017 09:19:17 +0000 From: Mike Bishop To: Spencer Dawkins at IETF , Brian Trammell CC: Eric Rescorla , IETF QUIC WG Subject: RE: On the passive measurability of QUIC Thread-Topic: On the passive measurability of QUIC Thread-Index: AQHS2tzplifpxin9rE2RC1WTo3MLQqIQB6QAgAAUGoCAByp4AIAATp1A Date: Tue, 6 Jun 2017 09:19:16 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:450:1e:232:3df2:793b:6da5:6ca2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR03MB2944; 7:NNnvTFSzIgcAqBAP2z3nkhJJGVDLwU9eyGFCNtdrDL3L8HhKVpkJ3nf3q+G6vNeVpCIEAgo5SCOPTSCWlH4zfbaA3+QVce55XPqFJcrGTRBYGpCfNrWmUxB8jyR/eESPjoM5jQMs6Ih41Sa/nFJhBLZEDlQDAPa4zL/639kOU4vIVsXNPTcp3nAEs2zw9M+RzJ3LQ/UcDqf4eKbOKUEE5x48jxBqLNXHpzdLlA748jnmQ51GCwP76xMRoVdLFngaq+J1VHiXzYBY6898qaAq9Mxf1/TafWeDgz3KuKq16nx0UTjcueJXrWC2g5J8uu2WPP7oTz8tlDNFZ6N1CzUGlLwtM3FPV9IXUjSEaZegZaI= x-ms-traffictypediagnostic: MWHPR03MB2944: x-ms-office365-filtering-correlation-id: 1af5637d-5d37-4527-4326-08d4acbd1b48 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR03MB2944; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(72170088055959)(166708455590820)(192374486261705)(189930954265078)(219752817060721)(21748063052155); 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)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR03MB2944; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR03MB2944; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(39860400002)(377454003)(24454002)(53546009)(478600001)(86612001)(25786009)(6306002)(54896002)(9686003)(74316002)(99286003)(53936002)(236005)(4326008)(7696004)(39060400002)(86362001)(54906002)(55016002)(189998001)(3660700001)(3280700002)(8990500004)(50986999)(54356999)(5660300001)(10090500001)(7906003)(7736002)(6436002)(6506006)(606005)(5005710100001)(77096006)(2906002)(76176999)(33656002)(72206003)(229853002)(93886004)(38730400002)(81166006)(10290500003)(966005)(122556002)(19609705001)(6116002)(8936002)(790700001)(8676002)(102836003)(14454004)(2950100002)(6246003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2944; H:MWHPR03MB2944.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR03MB2944F8F742286CFB0C9979E487CB0MWHPR03MB2944namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 09:19:17.0637 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2944 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, 06 Jun 2017 09:19:24 -0000 --_000_MWHPR03MB2944F8F742286CFB0C9979E487CB0MWHPR03MB2944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVnYXJkaW5nIHRoZSBiaWxsaW5nIHF1ZXN0aW9u4oCmLiAgRm9yIG1vYmlsZSBkZXZpY2VzLCBJ IGJlbGlldmUgdGhlIG1ham9yIE9TZXMgc3VwcG9ydCBwdXNoaW5nIHBvbGljaWVzIHRvIHRoZSBj bGllbnRzIHRoYXQgZGlmZmVyZW50bHktYmlsbGVkIHRyYWZmaWMgc2hvdWxkIGJlIHNlbnQgb3Zl ciBhIGRpZmZlcmVudCBBUE4uICBXZeKAmXJlIGRvaW5nIHdvcmsgaW4gUlMzIHRvIGVuYWJsZSBt b3JlIGFwcHMgdG8gaG9vayBpbnRvIHRoZXNlIHBvbGljaWVzIGFuZCBoYXZlIHRoZWlyIHRyYWZm aWMgY29ycmVjdGx5IHJvdXRlZCB0byB0aGUgcmlnaHQgQVBOLiAgKEluIHByZXZpb3VzIHZlcnNp b25zLCBpdCB3YXMgaW1wbGVtZW50ZWQgaW4gb3VyIEhUVFAgc3RhY2sgYW5kIHJlcXVpcmVkIGV4 dHJhIHdvcmsgaWYgeW91IHdlcmUgdXNpbmcgeW91ciBvd24gc3RhY2suKSBUaGlzIG1pZ2h0IGp1 c3QgYmUgYSBwcm9ibGVtIHRoYXQgZ2V0cyBzb2x2ZWQgYXQgYSBkaWZmZXJlbnQgbGF5ZXIsIHJh dGhlciB0aGFuIHZpYSB0cmFmZmljIGluc3BlY3Rpb24sIGFuZCBub3Qgc29tZXRoaW5nIHdlIG5l ZWQgdG8gY2F0ZXIgdG8gaW4gUVVJQyAob3IgVExTKS4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRG DQpTZW50OiBUdWVzZGF5LCBKdW5lIDYsIDIwMTcgNjozMyBBTQ0KVG86IEJyaWFuIFRyYW1tZWxs IDxpZXRmQHRyYW1tZWxsLmNoPg0KQ2M6IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT47IElF VEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBPbiB0aGUgcGFzc2l2ZSBt ZWFzdXJhYmlsaXR5IG9mIFFVSUMNCg0KU28gYSBjb3VwbGUgb2YgdGhpbmdzLCB3aGlsZSB3ZWFy aW5nIGEgY291cGxlIG9mIGhhdHMuDQoNCk9uIEp1biAxLCAyMDE3IDEwOjA3LCAiQnJpYW4gVHJh bW1lbGwgKElFVEYpIiA8aWV0ZkB0cmFtbWVsbC5jaDxtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaD4+ IHdyb3RlOg0KaGkgZWtyLA0KDQo+IE9uIDAxIEp1biAyMDE3LCBhdCAxNTo1NSwgRXJpYyBSZXNj b3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCj4NCj4gSSBs aWtlIHRoZSBnZW5lcmFsIGZyYW1pbmcgb2YgdGhlc2UgcXVlc3Rpb25zLCBidXQgaXQncyBwcmV0 dHkgaGFyZCB0byBhZGRyZXNzIHRoZW0gaW4NCj4gdGhlIGFic3RyYWN0LiBSYXRoZXIsIEkgdGhp bmsgaXQgd291bGQgYmUgbW9yZSB1c2VmdWwgdG8gc3RhcnQgbm90IHdpdGggdGhlIHNwZWNpZmlj IHByb3BlcnRpZXMNCj4gYnV0IHJhdGhlciB3aXRoIHRoZSAqc2VydmljZXMqIHRoYXQgY29sbGVj dGluZyB0aGVzZSBtZWFzdXJlbWVudHMgaXMgaW50ZW5kZWQgdG8gZmFjaWxpdGF0ZQ0KPiBhbmQg dGhlbiB3b3JrIGZvcndhcmQgdG8gdGhlIHZhcmlvdXMgYmFza2V0cyBvZiBtZWFzdXJlbWVudHMg eW91IHdvdWxkIG5lZWQgdG8NCj4gc3VwcG9ydCBzYWlkIHNlcnZpY2VzIGFuZCBmcm9tIHRoYXQg dHJ5IHRvIG1ha2UgYSBjb3N0L2JlbmVmaXQgYW5hbHlzaXMgWzBdLiBEbyB5b3Ugb3INCj4gc29t ZW9uZSBlbHNlIGhhdmUgc3VjaCBhIGxpc3Qgb2Ygc2VydmljZXM/DQpTdXJlLiBIZXJlIGFyZSB0 aGUgb25lcyBJIGtub3cgYWJvdXQgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZC4gTm90ZSBoZXJlLCBm b3IgInNlcnZpY2VzIiwgSSB1bmRlcnN0YW5kICJoaWdoZXItbGV2ZWwgbWVhc3VyZW1lbnQgYWN0 aXZpdGllcyIsIG9yIHdoYXQgd291bGQgYmUgY2FsbGVkICJzb2x1dGlvbnMiIG9uIHRoZSBtYXJr ZXRpbmctaGVhdnkgd2Vic2l0ZXMgb2YgdGhlIHZlbmRvcnMgd2hvIGJ1aWxkIHRoZXNlIGJveGVz LiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcgaGVyZS4gIlNlcnZpY2UiIGlzIHVuZm9y dHVuYXRlbHkgc28gb3ZlcmxvYWRlZCBhIHRlcm0gYXMgdG8gYmUgdW5jbGVhciBpbiBtYW55IGNh c2VzLCBldmVuIHdpdGggY29udGV4dC4NCg0KQXMgQUQ6IHRoaXMgdGhyZWFkLCBsaWtlIHRoZSBz cG9vZmluZyB0aHJlYWQsIGlzIHRoZSB0eXBlIG9mIGRpc2N1c3Npb24gb24gdGhlIG1hbmFnZW1l bnQgZGVsaXZlcmFibGUgSSB3YXMgaG9waW5nIHRoZSB3b3JraW5nIGdyb3VwIHdvdWxkIGhhdmUs IHdoZW4gSSBhZ3JlZWQgdG8gYXBwcm92ZSB0aGUgUVVJQyBjaGFydGVyLiBUaGFuayB5b3UuDQoN Ckkga25vdyB0aGlzIGNvbnZlcnNhdGlvbiBpc24ndCBlYXN5LCBhbmQgc28gZG9lcyB0aGUgcmVz dCBvZiB0aGUgSUVTRywgYW5kIHNvIGRvZXMgdGhlIElBQi4gV2UgaGFkIGhpZ2ggbGV2ZWwgZGlz Y3Vzc2lvbnMgaW4gdGhpcyBzcGFjZSBvbiB0aGUgam9pbnQgSUFCLUlFU0cgZGF5IG9mIG91ciBy ZXRyZWF0IGEgY291cGxlIG9mIHdlZWtzIGFnbywgYW5kIHRoZSBBRHMgY29udGludWVkIHRoYXQg ZGlzY3Vzc2lvbiBkdXJpbmcgYm90aCBkYXlzIG9mIHRoZSBJRVNHIHJldHJlYXQuDQoNCjEuIEFj Y2VzcyBuZXR3b3JrIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LiBUaGlzIGlzIGxhcmdlbHkgdGhl IHByb2JsZW0gdGhlIExNQVAgV0cgaXMgY2hhcnRlcmVkIHRvIGFkZHJlc3MsIHVzaW5nIElQUE0g bWV0cmljcy4gSGVyZSwgcGVhayBhY2hpZXZhYmxlIHRocm91Z2hwdXQgKG9mIGFuIGFjY2VzcyBs aW5rKSwgbG9zcywgbGF0ZW5jeSwgYW5kIChzb21ldGltZXMpIGppdHRlciBhcmUgdGhlIG1ldHJp Y3Mgb2YgaW50ZXJlc3QsIGJvdGggaW4gY29udHJvbGxlZCB0ZXN0aW5nIChhY3RpdmUgbWVhc3Vy ZW1lbnQpIGFzIHdlbGwgYXMgcGFzc2l2ZSBtZWFzdXJlbWVudCBvZiB1c2VyIHRyYWZmaWMsIG9u IHRoZSB0aGVvcnkgYm90aCB0aGF0IGFjY2lkZW50YWwgYW5kIGludGVudGlvbmFsIGRpZmZlcmVu dGlhbCB0cmVhdG1lbnQgb2YgbWVhc3VyZW1lbnQgdHJhZmZpYyB3aWxsIG1ha2UgYWN0aXZlIG1l YXN1cmVtZW50IHVucmVsaWFibGUsIGFzIHdlbGwgYXMgdG8gcmVkdWNlIG5ldHdvcmsgbG9hZCBk dWUgdG8gdW5wcm9kdWN0aXZlIGFjdGl2ZSBtZWFzdXJlbWVudCB0cmFmZmljLiBMb3NzL2Nvbmdl c3Rpb24gYW5kIGxhdGVuY3kgYXJlIHRoZSBwcmltYXJ5IHBhc3NpdmVseSBtZWFzdXJhYmxlIG1l dHJpY3Mgb2YgaW50ZXJlc3QgaGVyZS4gVGhpcyBtZWFzdXJlbWVudCBhY3Rpdml0eSBpcyB1c2Vk IGJ5IG5ldHdvcmsgb3BlcmF0b3JzIGZvciBjYXBhY2l0eSBwbGFubmluZyBhbmQgdHJvdWJsZXNo b290aW5nIHB1cnBvc2VzLCBhcyB3ZWxsIGFzIGJ5IG5hdGlvbmFsIGFuZCBzdXByYW5hdGlvbmFs IHJlZ3VsYXRvcnkgYWdlbmNpZXMgdG8gaG9sZCBuZXR3b3JrIG9wZXJhdG9ycyB3aXRoaW4gdGhl aXIganVyaXNkaWN0aW9ucyBhY2NvdW50YWJsZS4gVGhlIGRlcGxveW1lbnQgbG9jYXRpb24gY2hh bmdlcyBkZXBlbmRpbmcgb24gd2hvJ3MgcGVyZm9ybWluZyB0aGUgbWVhc3VyZW1lbnRzLCBidXQg aXQncyBnZW5lcmFsbHkgcnVuIGFzIGNsb3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBhY2Nlc3MgbGlu ayAoZm9yIGJyb2FkYmFuZCBhY2Nlc3MpIG9yIG9uIHRoZSBoYW5kc2V0IGl0c2VsZiAoZm9yIG1v YmlsZSBtZWFzdXJlbWVudHMpLg0KDQoNCjIuIEludGVyZG9tYWluIHRyb3VibGVzaG9vdGluZyBv ZiBuZXR3b3JrIHBlcmZvcm1hbmNlIGlzc3Vlcy4gU2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9xdWlj d2cvYmFzZS1kcmFmdHMvaXNzdWVzLzE2NjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2clMkZi YXNlLWRyYWZ0cyUyRmlzc3VlcyUyRjE2NiZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0 MG1pY3Jvc29mdC5jb20lN0M4OGVjODliMTBlNjY0NGY1M2MxOTA4ZDRhYzk1MjA3NiU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzMjMyMDM4OTE2MzU2NjIm c2RhdGE9TnpUa3BUSyUyRlV3Ukp4Njk1SlBESDRXWTZDNyUyRkVZMGlrS1Z6Mk9ENVNkNlElM0Qm cmVzZXJ2ZWQ9MD4uIFRob3VnaCBpdCBwcm9wb3NlcyBhIG1lY2hhbmlzbSwgaXQgY2xlYXJseSBj YWxscyBvdXQgdGhlIGtleSBtZXRyaWNzIGFzIHBhY2tldCBsb3NzIGFuZCBjb25nZXN0aW9uLCB3 aXRoIHRoZSBhYmlsaXR5IHRvIGxvY2FsaXplIGNvbmdlc3Rpb24gdXNpbmcgbXVsdGktb2JzZXJ2 YXRpb24tcG9pbnQgbWVhc3VyZW1lbnQgYXMgaW1wb3J0YW50Lg0KDQoNCjMuIFNlcnZpY2UgcGVy Zm9ybWFuY2UgbW9uaXRvcmluZyAobXkgZXhhbXBsZSBoZXJlIHdhcyBCb3VuZGFyeSwgd2hpY2gg aXMgYXBwYXJlbnRseSBjYWxsZWQgYm1jIFRydWVTaWdodCBQdWxzZSAodG0pIG5vdykgdXNlcyBw YXNzaXZlIG5ldHdvcmstbGV2ZWwgbGF0ZW5jeSBhbmQgdGhyb3VnaHB1dCBtZWFzdXJlbWVudHMg dG8gYXVnbWVudCBpbmZvcm1hdGlvbiBjb2xsZWN0ZWQgYnkgYWdlbnRzIHJ1bm5pbmcgb24gc2Vy dmVycyB0aGVtc2VsdmVzIHRvIGlzb2xhdGUgcGVyZm9ybWFuY2UgaXNzdWVzIG9uIHRob3NlIHNl cnZlcnMuDQoNCg0KNC4gUGVyaW1ldGVyIHNlY3VyaXR5IG1vbml0b3Jpbmcgb2YgYWNjZXNzIGFu ZCBlbnRlcnByaXNlIG5ldHdvcmtzLiBSZWxhdGVkIHRvIHdvcmsgaW4gdGhlIERPVFMgV0csIHdo aWNoIGZvY3VzZXMgc3BlY2lmaWNhbGx5IG9uIHRoZSBERG9TIG1pdGlnYXRpb24gYXNwZWN0IG9m IHRoaXMgYnJvYWQgdG9waWMuIFRoaXMgaXMgbGFyZ2VseSBjb25jZXJuZWQgd2l0aCBkZXRlY3Rp bmcgYW5kIGJsb2NraW5nIGF0dGFjayB0cmFmZmljLiBNb3N0IG9mIHRoZSBtZWFzdXJlbWVudCB0 YXNrIGluIHRoaXMgY2FzZSBpcyBjbGFzc2lmeWluZyB0cmFmZmljIGFzIGJlbmlnbiBvciBub3Qs IGFuZCBpdCB1c2VzIGFueSBpbnB1dCBhdmFpbGFibGUgdG8gbWFrZSB0aGF0IGRldGVybWluYXRp b24uIE5vbmUgb2YgdGhlIG1ldHJpY3MgSSB0YWxrIGFib3V0IGluIHRoZSBwcmV2aW91cyBtZXNz YWdlIGFyZSByZWFsbHkgcmVsZXZhbnQgaGVyZSwgdGhvdWdoIC0tIHNwb29mZWQgdHJhZmZpYyBk ZXRlY3Rpb24gaXMgbW9yZSB1c2VmdWwgaW4gdGhpcyBjb250ZXh0IHRoYW4gbGF0ZW5jeS4gSXQn cyByZWxldmFudCB0byBRVUlDLCB0aG91Z2gsIGluIHRoYXQgb25lIG9mIHRoZSBpbnB1dHMgdG8g dGhpcyBjbGFzc2lmaWNhdGlvbiBpcyB3aGV0aGVyIHRyYWZmaWMgaXMgVENQIG9yIG5vdDogdGhl IG1vcmUgbGlrZWx5IFFVSUMgdHJhZmZpYyBpcyB0byBiZSBjbGFzc2lmaWVkIGFzIGRlZmF1bHQt YmVuaWduLCB0aGUgYmV0dGVyIGl0cyBkZXBsb3lhYmlsaXR5IG9uIG5ldHdvcmtzIGVtcGxveWlu ZyB0aGlzIG1vbml0b3JpbmcuDQoNCkFzIGEgcG9zc2libHkgaGVscGZ1bCBpbmRpdmlkdWFsLCB0 aGlzIGxpc3Qgc2VlbXMgdG8gaW5jbHVkZSBpbXBsaWNpdGx5IHdoYXQgRXJpayBtZW50aW9uZWQg ZXhwbGljaXRseSBpbiB0aGUgc3Bvb2ZpbmcgdGhyZWFkIC0gdGhpbmtpbmcgYWJvdXQgd2hhdCB0 cnVzdHMgd2hhdCwgYW5kIHdoYXQgY29udHJvbHMgd2hhdC4gSSB0aG91Z2h0IHRoYXQgZXhwbGlj dG5lc3Mgd291bGQgYmUgaGVscGZ1bC4NCg0KVGhlIG9idmlvdXMgb25lIG1lbnRpb25lZCBpbiBv dXIgY2hhcnRlciwgZm9yIGNvbXBsZXRlbmVzczoNCg0KLTEuIEJpbGxpbmcsIGJvdGggZm9yIG1l dGVyZWQgY29uc3VtZXItZ3JhZGUgYWNjZXNzIGFzIHdlbGwgYXMgdHJhbnNpdCBjb250cmFjdHMu IFRoaXMgaXMgLTEgYmVjYXVzZSBpdCdzIG5vdCByZWFsbHkgcmVsZXZhbnQgdG8gdHJhbnNwb3J0 IHByb3RvY29sIGRlc2lnbiwgYXMgaXQgZ2VuZXJhbGx5IGRvZXNuJ3QgcmVxdWlyZSBhbnl0aGlu ZyBiZXlvbmQgYnl0ZS9wYWNrZXQgY291bnQgcGVyIGJpbGxhYmxlIHVzZXIsIHdoZXJlIHRoZSBi aWxsYWJsZSB1c2VyIGlzIHVzdWFsbHkgYXNzb2NpYXRlZCB3aXRoIHNvbWV0aGluZyB0aGF0IGhh cHBlbnMgYmVsb3cgbGF5ZXIgMywgemVyby1yYXRpbmcgYW5kIG90aGVyIHN1Y2ggcHJhY3RpY2Vz IG5vdHdpdGhzdGFuZGluZy4NCg0KQXMgQUQ6IHRoaXMgd291bGQgYmUgYW4gZXNwZWNpYWxseSB1 c2VmdWwgYXNzZXJ0aW9uIHRvIGNvbnZlcmdlIG9uIChhZnRlciB0aGUgaW50ZXJpbSwgb2YgY291 cnNlKS4NCg0KSWYgUVVJQyBpc24ndCBhYmxlIHRvIGhlbHAgd2l0aCBiaWxsaW5nKCopLCB0aGF0 IG5lZWRzIHRvIG5vdCBiZSBhIExhdGUgU3VycHJpc2UgKHRtKS4NCg0KU3BlbmNlcg0KDQooKikg QmFjayB0byBzcGVha2luZyBhcyBhbiBpbmRpdmlkdWFsLCBvbmUgb2YgdGhlIHJlc3BvbnNlcyB0 aGF0IHdvdWxkIG5vdCBzdXJwcmlzZSBtZSBpcyAiYXBwbGljYXRpb25zIHVzaW5nIFFVSUMgYXJl bid0IG11Y2ggaGFyZGVyIHRvIGJpbGwgZm9yIHRoYW4gYXBwbGljYXRpb25zIHVzaW5nIFRMUyBv ciBUQ1BJTkMsIHNvLCB3aGF0ZXZlciB5b3UgZG8gZm9yIHRob3NlLCBkbyBpdCBmb3IgUVVJQyIu IElmIHNvbWV0aGluZyBsaWtlIHRoYXQgdHVybnMgb3V0IHRvIGJlIHRoZSBhbnN3ZXIsIHBlb3Bs ZSB3aG8gY2FyZSBhYm91dCBiaWxsaW5nIG5lZWQgdG8gYmUgZmlndXJpbmcgb3V0IHdoYXQgUGxh biBCIGlzIC4uLg0KDQo+IC1Fa3INCj4NCj4gWzBdIFdoZXJlIHRoZSBjb3N0IGNsZWFybHkgaGFz IHRvIGluY2x1ZGUgZnV0dXJlIHVua25vd24gcHJpdmFjeSByaXNrLg0KRXZhbHVhdGluZyBhbiB1 bmtub3duIHJpc2sgaXMgYSBwcmV0dHkgY29vbCB0cmljay4gOykNCg0KU2VyaW91c2x5LCB0aG91 Z2gsIEknZCByZWFsbHkgYXBwcmVjaWF0ZSBhbnkgc3VnZ2VzdGlvbnMgeW91IHdvdWxkIGhhdmUg YXMgdG8gaG93IHRvIGNvbmNyZXRlbHkgZXZhbHVhdGUgdGhpcyByaXNrLCBhdCBsZWFzdCBmb3Ig cHVycG9zZXMgb2YgY29tcGFyaXNvbiBvZiBwcm9wb3NhbHMuIEluZm9ybWF0aW9uIHRoZW9yZXRp YyBtZXRyaWNzIHNlZW0gdG8gbWUgdG8gYmUgbm90IHZlcnkgdXNlZnVsIGhlcmUsIHNpbmNlIHRo ZXkgbWFrZSB0aGUgaW1wbGljaXQgKGFuZCBmYWxzZSkgYXNzdW1wdGlvbiB0aGF0IGFsbCBiaXRz IG9mIGVudHJvcHkgYXJlIGVxdWFsbHkgcG90ZW50aWFsbHkgZGFuZ2Vyb3VzIHRvIHByaXZhY3ku DQoNClRoYW5rcywgY2hlZXJzLA0KDQpCcmlhbg0KDQo= --_000_MWHPR03MB2944F8F742286CFB0C9979E487CB0MWHPR03MB2944namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZWdhcmRpbmcgdGhlIGJpbGxpbmcgcXVlc3Rpb27igKYuJm5ic3A7IEZvciBtb2JpbGUgZGV2aWNl cywgSSBiZWxpZXZlIHRoZSBtYWpvciBPU2VzIHN1cHBvcnQgcHVzaGluZyBwb2xpY2llcyB0byB0 aGUgY2xpZW50cyB0aGF0IGRpZmZlcmVudGx5LWJpbGxlZCB0cmFmZmljIHNob3VsZCBiZSBzZW50 IG92ZXIgYSBkaWZmZXJlbnQgQVBOLiZuYnNwOyBXZeKAmXJlIGRvaW5nIHdvcmsgaW4gUlMzIHRv IGVuYWJsZSBtb3JlIGFwcHMgdG8NCiBob29rIGludG8gdGhlc2UgcG9saWNpZXMgYW5kIGhhdmUg dGhlaXIgdHJhZmZpYyBjb3JyZWN0bHkgcm91dGVkIHRvIHRoZSByaWdodCBBUE4uJm5ic3A7IChJ biBwcmV2aW91cyB2ZXJzaW9ucywgaXQgd2FzIGltcGxlbWVudGVkIGluIG91ciBIVFRQIHN0YWNr IGFuZCByZXF1aXJlZCBleHRyYSB3b3JrIGlmIHlvdSB3ZXJlIHVzaW5nIHlvdXIgb3duIHN0YWNr LikgVGhpcyBtaWdodCBqdXN0IGJlIGEgcHJvYmxlbSB0aGF0IGdldHMgc29sdmVkIGF0IGEgZGlm ZmVyZW50DQogbGF5ZXIsIHJhdGhlciB0aGFuIHZpYSB0cmFmZmljIGluc3BlY3Rpb24sIGFuZCBu b3Qgc29tZXRoaW5nIHdlIG5lZWQgdG8gY2F0ZXIgdG8gaW4gUVVJQyAob3IgVExTKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PG86cD4mbmJzcDs8L286cD48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBR VUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5T cGVuY2VyIERhd2tpbnMgYXQgSUVURjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDYs IDIwMTcgNjozMyBBTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gVHJhbW1lbGwgJmx0O2lldGZAdHJh bW1lbGwuY2gmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBFcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5j b20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBPbiB0aGUgcGFzc2l2ZSBtZWFzdXJhYmlsaXR5IG9mIFFVSUM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBhIGNvdXBsZSBvZiB0aGluZ3MsIHdoaWxl IHdlYXJpbmcgYSBjb3VwbGUgb2YgaGF0cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBKdW4gMSwgMjAxNyAxMDowNywgJnF1b3Q7QnJpYW4gVHJhbW1lbGwgKElFVEYp JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaCIgdGFyZ2V0PSJfYmxh bmsiPmlldGZAdHJhbW1lbGwuY2g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5oaSBla3IsPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQomZ3Q7IE9uIDAxIEp1biAyMDE3LCBhdCAxNTo1NSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgbGlrZSB0aGUgZ2VuZXJhbCBmcmFtaW5n IG9mIHRoZXNlIHF1ZXN0aW9ucywgYnV0IGl0J3MgcHJldHR5IGhhcmQgdG8gYWRkcmVzcyB0aGVt IGluPGJyPg0KJmd0OyB0aGUgYWJzdHJhY3QuIFJhdGhlciwgSSB0aGluayBpdCB3b3VsZCBiZSBt b3JlIHVzZWZ1bCB0byBzdGFydCBub3Qgd2l0aCB0aGUgc3BlY2lmaWMgcHJvcGVydGllczxicj4N CiZndDsgYnV0IHJhdGhlciB3aXRoIHRoZSAqc2VydmljZXMqIHRoYXQgY29sbGVjdGluZyB0aGVz ZSBtZWFzdXJlbWVudHMgaXMgaW50ZW5kZWQgdG8gZmFjaWxpdGF0ZTxicj4NCiZndDsgYW5kIHRo ZW4gd29yayBmb3J3YXJkIHRvIHRoZSB2YXJpb3VzIGJhc2tldHMgb2YgbWVhc3VyZW1lbnRzIHlv dSB3b3VsZCBuZWVkIHRvPGJyPg0KJmd0OyBzdXBwb3J0IHNhaWQgc2VydmljZXMgYW5kIGZyb20g dGhhdCB0cnkgdG8gbWFrZSBhIGNvc3QvYmVuZWZpdCBhbmFseXNpcyBbMF0uIERvIHlvdSBvcjxi cj4NCiZndDsgc29tZW9uZSBlbHNlIGhhdmUgc3VjaCBhIGxpc3Qgb2Ygc2VydmljZXM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUuIEhlcmUgYXJlIHRo ZSBvbmVzIEkga25vdyBhYm91dCBvZmYgdGhlIHRvcCBvZiBteSBoZWFkLiBOb3RlIGhlcmUsIGZv ciAmcXVvdDtzZXJ2aWNlcyZxdW90OywgSSB1bmRlcnN0YW5kICZxdW90O2hpZ2hlci1sZXZlbCBt ZWFzdXJlbWVudCBhY3Rpdml0aWVzJnF1b3Q7LCBvciB3aGF0IHdvdWxkIGJlIGNhbGxlZCAmcXVv dDtzb2x1dGlvbnMmcXVvdDsgb24gdGhlIG1hcmtldGluZy1oZWF2eSB3ZWJzaXRlcyBvZiB0aGUg dmVuZG9ycyB3aG8gYnVpbGQgdGhlc2UNCiBib3hlcy4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdt IHdyb25nIGhlcmUuICZxdW90O1NlcnZpY2UmcXVvdDsgaXMgdW5mb3J0dW5hdGVseSBzbyBvdmVy bG9hZGVkIGEgdGVybSBhcyB0byBiZSB1bmNsZWFyIGluIG1hbnkgY2FzZXMsIGV2ZW4gd2l0aCBj b250ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgQUQ6IHRoaXMgdGhyZWFkLCBs aWtlIHRoZSBzcG9vZmluZyB0aHJlYWQsIGlzIHRoZSB0eXBlIG9mIGRpc2N1c3Npb24gb24gdGhl IG1hbmFnZW1lbnQgZGVsaXZlcmFibGUgSSB3YXMgaG9waW5nIHRoZSB3b3JraW5nIGdyb3VwIHdv dWxkIGhhdmUsIHdoZW4gSSBhZ3JlZWQgdG8gYXBwcm92ZSB0aGUgUVVJQyBjaGFydGVyLiBUaGFu ayB5b3UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkga25vdyB0aGlzIGNvbnZlcnNhdGlvbiBpc24ndCBlYXN5LCBhbmQgc28gZG9lcyB0aGUg cmVzdCBvZiB0aGUgSUVTRywgYW5kIHNvIGRvZXMgdGhlIElBQi4gV2UgaGFkIGhpZ2ggbGV2ZWwg ZGlzY3Vzc2lvbnMgaW4gdGhpcyBzcGFjZSBvbiB0aGUgam9pbnQgSUFCLUlFU0cgZGF5IG9mIG91 ciByZXRyZWF0IGEgY291cGxlIG9mIHdlZWtzIGFnbywgYW5kIHRoZSBBRHMgY29udGludWVkIHRo YXQgZGlzY3Vzc2lvbg0KIGR1cmluZyBib3RoIGRheXMgb2YgdGhlIElFU0cgcmV0cmVhdC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gQWNjZXNzIG5ldHdvcmsgcGVyZm9ybWFuY2Ug bWVhc3VyZW1lbnQuIFRoaXMgaXMgbGFyZ2VseSB0aGUgcHJvYmxlbSB0aGUgTE1BUCBXRyBpcyBj aGFydGVyZWQgdG8gYWRkcmVzcywgdXNpbmcgSVBQTSBtZXRyaWNzLiBIZXJlLCBwZWFrIGFjaGll dmFibGUgdGhyb3VnaHB1dCAob2YgYW4gYWNjZXNzIGxpbmspLCBsb3NzLCBsYXRlbmN5LCBhbmQg KHNvbWV0aW1lcykgaml0dGVyIGFyZSB0aGUgbWV0cmljcw0KIG9mIGludGVyZXN0LCBib3RoIGlu IGNvbnRyb2xsZWQgdGVzdGluZyAoYWN0aXZlIG1lYXN1cmVtZW50KSBhcyB3ZWxsIGFzIHBhc3Np dmUgbWVhc3VyZW1lbnQgb2YgdXNlciB0cmFmZmljLCBvbiB0aGUgdGhlb3J5IGJvdGggdGhhdCBh Y2NpZGVudGFsIGFuZCBpbnRlbnRpb25hbCBkaWZmZXJlbnRpYWwgdHJlYXRtZW50IG9mIG1lYXN1 cmVtZW50IHRyYWZmaWMgd2lsbCBtYWtlIGFjdGl2ZSBtZWFzdXJlbWVudCB1bnJlbGlhYmxlLCBh cyB3ZWxsIGFzDQogdG8gcmVkdWNlIG5ldHdvcmsgbG9hZCBkdWUgdG8gdW5wcm9kdWN0aXZlIGFj dGl2ZSBtZWFzdXJlbWVudCB0cmFmZmljLiBMb3NzL2Nvbmdlc3Rpb24gYW5kIGxhdGVuY3kgYXJl IHRoZSBwcmltYXJ5IHBhc3NpdmVseSBtZWFzdXJhYmxlIG1ldHJpY3Mgb2YgaW50ZXJlc3QgaGVy ZS4gVGhpcyBtZWFzdXJlbWVudCBhY3Rpdml0eSBpcyB1c2VkIGJ5IG5ldHdvcmsgb3BlcmF0b3Jz IGZvciBjYXBhY2l0eSBwbGFubmluZyBhbmQgdHJvdWJsZXNob290aW5nDQogcHVycG9zZXMsIGFz IHdlbGwgYXMgYnkgbmF0aW9uYWwgYW5kIHN1cHJhbmF0aW9uYWwgcmVndWxhdG9yeSBhZ2VuY2ll cyB0byBob2xkIG5ldHdvcmsgb3BlcmF0b3JzIHdpdGhpbiB0aGVpciBqdXJpc2RpY3Rpb25zIGFj Y291bnRhYmxlLiBUaGUgZGVwbG95bWVudCBsb2NhdGlvbiBjaGFuZ2VzIGRlcGVuZGluZyBvbiB3 aG8ncyBwZXJmb3JtaW5nIHRoZSBtZWFzdXJlbWVudHMsIGJ1dCBpdCdzIGdlbmVyYWxseSBydW4g YXMgY2xvc2UgYXMgcG9zc2libGUNCiB0byB0aGUgYWNjZXNzIGxpbmsgKGZvciBicm9hZGJhbmQg YWNjZXNzKSBvciBvbiB0aGUgaGFuZHNldCBpdHNlbGYgKGZvciBtb2JpbGUgbWVhc3VyZW1lbnRz KS48YnI+DQo8YnI+DQo8YnI+DQoyLiBJbnRlcmRvbWFpbiB0cm91Ymxlc2hvb3Rpbmcgb2YgbmV0 d29yayBwZXJmb3JtYW5jZSBpc3N1ZXMuIFNlZSA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20l MkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRmlzc3VlcyUyRjE2NiZhbXA7ZGF0YT0wMiU3QzAxJTdD bWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDODhlYzg5YjEwZTY2NDRmNTNjMTkwOGQ0 YWM5NTIwNzYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 MzIzMjAzODkxNjM1NjYyJmFtcDtzZGF0YT1OelRrcFRLJTJGVXdSSng2OTVKUERINFdZNkM3JTJG RVkwaWtLVnoyT0Q1U2Q2USUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMTY2PC9hPi4gVGhvdWdo IGl0IHByb3Bvc2VzIGEgbWVjaGFuaXNtLCBpdCBjbGVhcmx5IGNhbGxzIG91dCB0aGUga2V5IG1l dHJpY3MgYXMgcGFja2V0IGxvc3MgYW5kIGNvbmdlc3Rpb24sIHdpdGggdGhlIGFiaWxpdHkgdG8g bG9jYWxpemUgY29uZ2VzdGlvbiB1c2luZyBtdWx0aS1vYnNlcnZhdGlvbi1wb2ludCBtZWFzdXJl bWVudCBhcyBpbXBvcnRhbnQuPGJyPg0KPGJyPg0KPGJyPg0KMy4gU2VydmljZSBwZXJmb3JtYW5j ZSBtb25pdG9yaW5nIChteSBleGFtcGxlIGhlcmUgd2FzIEJvdW5kYXJ5LCB3aGljaCBpcyBhcHBh cmVudGx5IGNhbGxlZCBibWMgVHJ1ZVNpZ2h0IFB1bHNlICh0bSkgbm93KSB1c2VzIHBhc3NpdmUg bmV0d29yay1sZXZlbCBsYXRlbmN5IGFuZCB0aHJvdWdocHV0IG1lYXN1cmVtZW50cyB0byBhdWdt ZW50IGluZm9ybWF0aW9uIGNvbGxlY3RlZCBieSBhZ2VudHMgcnVubmluZyBvbiBzZXJ2ZXJzIHRo ZW1zZWx2ZXMNCiB0byBpc29sYXRlIHBlcmZvcm1hbmNlIGlzc3VlcyBvbiB0aG9zZSBzZXJ2ZXJz Ljxicj4NCjxicj4NCjxicj4NCjQuIFBlcmltZXRlciBzZWN1cml0eSBtb25pdG9yaW5nIG9mIGFj Y2VzcyBhbmQgZW50ZXJwcmlzZSBuZXR3b3Jrcy4gUmVsYXRlZCB0byB3b3JrIGluIHRoZSBET1RT IFdHLCB3aGljaCBmb2N1c2VzIHNwZWNpZmljYWxseSBvbiB0aGUgRERvUyBtaXRpZ2F0aW9uIGFz cGVjdCBvZiB0aGlzIGJyb2FkIHRvcGljLiBUaGlzIGlzIGxhcmdlbHkgY29uY2VybmVkIHdpdGgg ZGV0ZWN0aW5nIGFuZCBibG9ja2luZyBhdHRhY2sgdHJhZmZpYy4gTW9zdCBvZiB0aGUNCiBtZWFz dXJlbWVudCB0YXNrIGluIHRoaXMgY2FzZSBpcyBjbGFzc2lmeWluZyB0cmFmZmljIGFzIGJlbmln biBvciBub3QsIGFuZCBpdCB1c2VzIGFueSBpbnB1dCBhdmFpbGFibGUgdG8gbWFrZSB0aGF0IGRl dGVybWluYXRpb24uIE5vbmUgb2YgdGhlIG1ldHJpY3MgSSB0YWxrIGFib3V0IGluIHRoZSBwcmV2 aW91cyBtZXNzYWdlIGFyZSByZWFsbHkgcmVsZXZhbnQgaGVyZSwgdGhvdWdoIC0tIHNwb29mZWQg dHJhZmZpYyBkZXRlY3Rpb24gaXMgbW9yZQ0KIHVzZWZ1bCBpbiB0aGlzIGNvbnRleHQgdGhhbiBs YXRlbmN5LiBJdCdzIHJlbGV2YW50IHRvIFFVSUMsIHRob3VnaCwgaW4gdGhhdCBvbmUgb2YgdGhl IGlucHV0cyB0byB0aGlzIGNsYXNzaWZpY2F0aW9uIGlzIHdoZXRoZXIgdHJhZmZpYyBpcyBUQ1Ag b3Igbm90OiB0aGUgbW9yZSBsaWtlbHkgUVVJQyB0cmFmZmljIGlzIHRvIGJlIGNsYXNzaWZpZWQg YXMgZGVmYXVsdC1iZW5pZ24sIHRoZSBiZXR0ZXIgaXRzIGRlcGxveWFiaWxpdHkgb24gbmV0d29y a3MNCiBlbXBsb3lpbmcgdGhpcyBtb25pdG9yaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXMgYSBwb3NzaWJseSBoZWxwZnVsIGluZGl2aWR1YWwsIHRoaXMgbGlzdCBzZWVtcyB0byBp bmNsdWRlIGltcGxpY2l0bHkgd2hhdCBFcmlrIG1lbnRpb25lZCBleHBsaWNpdGx5IGluIHRoZSBz cG9vZmluZyB0aHJlYWQgLSB0aGlua2luZyBhYm91dCB3aGF0IHRydXN0cyB3aGF0LCBhbmQgd2hh dCBjb250cm9scyB3aGF0LiBJIHRob3VnaHQgdGhhdCBleHBsaWN0bmVzcyB3b3VsZCBiZSBoZWxw ZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb2J2aW91cyBvbmUgbWVudGlvbmVkIGlu IG91ciBjaGFydGVyLCBmb3IgY29tcGxldGVuZXNzOjxicj4NCjxicj4NCi0xLiBCaWxsaW5nLCBi b3RoIGZvciBtZXRlcmVkIGNvbnN1bWVyLWdyYWRlIGFjY2VzcyBhcyB3ZWxsIGFzIHRyYW5zaXQg Y29udHJhY3RzLiBUaGlzIGlzIC0xIGJlY2F1c2UgaXQncyBub3QgcmVhbGx5IHJlbGV2YW50IHRv IHRyYW5zcG9ydCBwcm90b2NvbCBkZXNpZ24sIGFzIGl0IGdlbmVyYWxseSBkb2Vzbid0IHJlcXVp cmUgYW55dGhpbmcgYmV5b25kIGJ5dGUvcGFja2V0IGNvdW50IHBlciBiaWxsYWJsZSB1c2VyLCB3 aGVyZSB0aGUgYmlsbGFibGUNCiB1c2VyIGlzIHVzdWFsbHkgYXNzb2NpYXRlZCB3aXRoIHNvbWV0 aGluZyB0aGF0IGhhcHBlbnMgYmVsb3cgbGF5ZXIgMywgemVyby1yYXRpbmcgYW5kIG90aGVyIHN1 Y2ggcHJhY3RpY2VzIG5vdHdpdGhzdGFuZGluZy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIEFEOiB0aGlzIHdvdWxkIGJlIGFuIGVzcGVjaWFsbHkgdXNlZnVsIGFzc2VydGlvbiB0byBj b252ZXJnZSBvbiAoYWZ0ZXIgdGhlIGludGVyaW0sIG9mIGNvdXJzZSkuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIFFVSUMgaXNu J3QgYWJsZSB0byBoZWxwIHdpdGggYmlsbGluZygqKSwgdGhhdCBuZWVkcyB0byBub3QgYmUgYSBM YXRlIFN1cnByaXNlICh0bSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNwZW5jZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+KCopIEJhY2sgdG8gc3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVh bCwgb25lIG9mIHRoZSByZXNwb25zZXMgdGhhdCB3b3VsZCBub3Qgc3VycHJpc2UgbWUgaXMgJnF1 b3Q7YXBwbGljYXRpb25zIHVzaW5nIFFVSUMgYXJlbid0IG11Y2ggaGFyZGVyIHRvIGJpbGwgZm9y IHRoYW4gYXBwbGljYXRpb25zIHVzaW5nIFRMUyBvciBUQ1BJTkMsIHNvLCB3aGF0ZXZlciB5b3Ug ZG8gZm9yIHRob3NlLCBkbyBpdCBmb3IgUVVJQyZxdW90Oy4gSWYNCiBzb21ldGhpbmcgbGlrZSB0 aGF0IHR1cm5zIG91dCB0byBiZSB0aGUgYW5zd2VyLCBwZW9wbGUgd2hvIGNhcmUgYWJvdXQgYmls bGluZyBuZWVkIHRvIGJlIGZpZ3VyaW5nIG91dCB3aGF0IFBsYW4gQiBpcyAuLi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyAt RWtyPGJyPg0KJmd0Ozxicj4NCiZndDsgWzBdIFdoZXJlIHRoZSBjb3N0IGNsZWFybHkgaGFzIHRv IGluY2x1ZGUgZnV0dXJlIHVua25vd24gcHJpdmFjeSByaXNrLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkV2 YWx1YXRpbmcgYW4gdW5rbm93biByaXNrIGlzIGEgcHJldHR5IGNvb2wgdHJpY2suIDspPGJyPg0K PGJyPg0KU2VyaW91c2x5LCB0aG91Z2gsIEknZCByZWFsbHkgYXBwcmVjaWF0ZSBhbnkgc3VnZ2Vz dGlvbnMgeW91IHdvdWxkIGhhdmUgYXMgdG8gaG93IHRvIGNvbmNyZXRlbHkgZXZhbHVhdGUgdGhp cyByaXNrLCBhdCBsZWFzdCBmb3IgcHVycG9zZXMgb2YgY29tcGFyaXNvbiBvZiBwcm9wb3NhbHMu IEluZm9ybWF0aW9uIHRoZW9yZXRpYyBtZXRyaWNzIHNlZW0gdG8gbWUgdG8gYmUgbm90IHZlcnkg dXNlZnVsIGhlcmUsIHNpbmNlIHRoZXkgbWFrZSB0aGUgaW1wbGljaXQNCiAoYW5kIGZhbHNlKSBh c3N1bXB0aW9uIHRoYXQgYWxsIGJpdHMgb2YgZW50cm9weSBhcmUgZXF1YWxseSBwb3RlbnRpYWxs eSBkYW5nZXJvdXMgdG8gcHJpdmFjeS48YnI+DQo8YnI+DQpUaGFua3MsIGNoZWVycyw8YnI+DQo8 YnI+DQpCcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR03MB2944F8F742286CFB0C9979E487CB0MWHPR03MB2944namp_-- From nobody Tue Jun 6 02:20: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 8C404126DC2 for ; Tue, 6 Jun 2017 02:20:23 -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 yVKXvc1PDKcK for ; Tue, 6 Jun 2017 02:20:21 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0114.outbound.protection.outlook.com [104.47.1.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D527B12426E for ; Tue, 6 Jun 2017 02:20:20 -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=tzR+uF+t7gwb+5fiQQPGR9ORPqjcUBm3UOnkvl3rEbo=; b=LZ5GdN85jhR7/XXe/E41nE7s0GaV3SIBNYhloDn63vkUy3ZP1HWUaE9h/6g+BDsa80uFd7/uKf8xfE5eiD49tmIYLOX3jbsqMpefh/dFqUO3YAGV9P2q1U6MJYxQsEQzHNwH718KpI2EiY4bPUuB2OASv1K4h/wisKz8stV+hvg= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB1525.eurprd07.prod.outlook.com (10.165.212.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Tue, 6 Jun 2017 09:20:17 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::e14c:70a:c224:95c8]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::e14c:70a:c224:95c8%14]) with mapi id 15.01.1157.010; Tue, 6 Jun 2017 09:20:17 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Martin Thomson , "Eggert, Lars" CC: IETF QUIC WG , Alan Frindell Subject: RE: Comparing HTTP over QUIC header compression schemes Thread-Topic: Comparing HTTP over QUIC header compression schemes Thread-Index: AQHS3pDkbL6XmOk6K0ms9bs9UuyP16IXiUoAgAADLQCAAACxQA== Date: Tue, 6 Jun 2017 09:20:17 +0000 Message-ID: References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB1525; 7:74JQ3LNmaWaV5J96fct3F7GbbMf5jmaN1FI4Sucdmq6Bsfh3KW9Z5WBMjaG6gPNPtbBU57Sb62Jf5ODpZw8sIoV+rOOFkM0LgTaC4rN0lUX7bBCCPUX8XV0MJiR1XwJI+bXtuTKIcIzzKiVryqQiFT6NpnuN5i1ljlkE0qet7vSDwFyavujv5ILn1kT9UhS9gC63wsiuiNQdL2B23iONTFKamHEw69I93YdE9dCuFjCIQ3le2J7pNPVqaaKKxRP7bJg5KVDIxAFkGBSVND7P1mH7WtnNfFpvUxXVcRoc3qK8fqgOt+ReJbgLoHOsLPmggvjUvTKF52MKKbPQOb44Hg== x-ms-traffictypediagnostic: DB5PR07MB1525: x-ms-office365-filtering-correlation-id: e0a8fbd5-b69d-4b09-e522-08d4acbd3f60 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB5PR07MB1525; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1525; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1525; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39850400002)(39410400002)(39860400002)(39840400002)(24454002)(13464003)(54356999)(53546009)(9686003)(2900100001)(25786009)(54906002)(966005)(39060400002)(14454004)(55016002)(99286003)(6306002)(4326008)(8936002)(3280700002)(86362001)(5660300001)(81166006)(478600001)(8676002)(2906002)(74316002)(3660700001)(66066001)(189998001)(5250100002)(305945005)(76176999)(347745004)(53936002)(7696004)(229853002)(50986999)(3846002)(2950100002)(102836003)(6116002)(16799955002)(7736002)(6506006)(33656002)(6436002)(38730400002)(6246003)(15188555004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1525; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 09:20:17.7724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1525 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, 06 Jun 2017 09:20:24 -0000 VHdvIHVzZWZ1bCByZWZlcmVuY2VzIEkndmUgZm91bmQgYXJlIHRoZSBmb2xsb3dpbmc6DQpodHRw Oi8vd3d3LmlzcHJldmlldy5jby51ay9pbmRleC5waHAvMjAxMi8wOC9hLWNsb3Nlci1sb29rLWF0 LWxhdGVuY3ktYW5kLXBhY2tldC1sb3NzLW9uLXRoZS1iaWdnZXN0LWJyb2FkYmFuZC1pc3BzLmh0 bWwgd2hpY2ggY292ZXJzIFVLIEFEU0wgYW5kIEZpYnJlLA0KUGFnZSA0NCBvZiBodHRwczovL2Nv bW11bml0eS5jYWJsZWxhYnMuY29tL3dpa2kvcGx1Z2lucy9zZXJ2bGV0L2NhYmxlbGFicy9hbGZy ZXNjby9kb3dubG9hZD9pZD0zZWRiMTYwOS0xN2ZmLTQ4NDQtODdlZC0xMjQzMTRhNzNlN2Mgd2hp Y2ggY292ZXJzIFVTIGNhYmxlIG1hcmtldHMuDQoNClRoZSBrZXkgc3VtbWFyeSBmcm9tIHRoZXNl Og0KQURTTDogVHlwaWNhbGx5IGxlc3MgdGhhbiAwLjUlLCB0aG91Z2ggc29tZSBwcm92aWRlcnMg c2VlbSB0byBnZXQgbXVjaCB3b3JzZSBxdWFsaXR5ICh1cCB0byAxLjUlKQ0KRmlicmU6IFR5cGlj YWxseSBsZXNzIHRoYW4gMC4zJSBidXQgZHVyaW5nIGNvbmdlc3RlZCBwZXJpb2RzIG1heSBnbyBo aWdoZXIgLXVwIHRvIGFib3V0IDElDQpDYWJsZTogQXZlcmFnZSB3YXMgMC4wMDAwMjY1MjklLCBW ZXJ5IFdvcnN0IGNhc2Ugd2FzIDEuMyUsIDc4LjUlIGhhZCAwIHBhY2tldCBsb3NzIG92ZXIgMjQg aG91cnMuDQoNCk9idmlvdXNseSB0aGVzZSBhcmUgYWxsIG1hcmtldCBhbmQgdGVjaG5vbG9neSBk ZXBlbmRlbnQgYW5kIGFyZSBhdmVyYWdlcyBzbyB0aGVyZSBtYXkgYmUgc2lnbmlmaWNhbnQgb3V0 bGllcnMuDQpBbnkgbW9yZSBkZXRhaWxlZCByZWZlcmVuY2VzIHdvdWxkIGJlIHZlcnkgdXNlZnVs IGluIHVuZGVyc3RhbmRpbmcgdGhpcyAoYW5kIGZvciBGRUMgc2NoZW1lIHByb3Bvc2FscyB3aGVu IHRoZSBXRyBnZXRzIHRvIHRoYXQpLg0KDQpUaG9tYXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KPiBTZW50OiAwNiBKdW5lIDIwMTcgMTA6MTENCj4g VG86IEVnZ2VydCwgTGFycyA8bGFyc0BuZXRhcHAuY29tPg0KPiBDYzogSUVURiBRVUlDIFdHIDxx dWljQGlldGYub3JnPjsgQWxhbiBGcmluZGVsbCA8YWZyaW5kQGZiLmNvbT4NCj4gU3ViamVjdDog UmU6IENvbXBhcmluZyBIVFRQIG92ZXIgUVVJQyBoZWFkZXIgY29tcHJlc3Npb24gc2NoZW1lcw0K PiANCj4gT24gNiBKdW5lIDIwMTcgYXQgMTA6NTksIEVnZ2VydCwgTGFycyA8bGFyc0BuZXRhcHAu Y29tPiB3cm90ZToNCj4gPiAoMikgc2ltdWxhdGluZyBsb3NzIHJhdGVzIG11Y2ggYWJvdmUgMSUg aXMgbGlrZWx5IGdvaW5nIHRvIGJlIHByZXR0eQ0KPiA+IHVuaW50ZXJlc3RpbmcsIGdpdmVuIHRo YXQgUVVJQyAoYW5kIFRDUCwgRldJVykgaGF2ZSBjb25nZXN0aW9uDQo+ID4gY29udHJvbGxlcnMg dGhhdCB3aWxsIHN0cnVnZ2xlIHRvIGV2ZW4gZGVsaXZlciB1c2VmdWwgdGhyb3VnaHB1dHMgaW4N Cj4gPiB0aGVzZSBjYXNlcw0KPiANCj4gDQo+IFRoYXQncyBhbiBpbnRlcmVzdGluZyBwb2ludC4g IEkndmUgc2VlbiBhIHByZXNlbnRhdGlvbiAodGhhdCBJIGNhbid0IGZpbmQgbm93LCBidXQgSQ0K PiBjYW4gdHJ5KSB0aGF0IHNob3dzIHRoYXQgcGFja2V0IGxvc3MgaW4gcmVhbC13b3JsZCBzY2Vu YXJpb3MgYXBwcm9hY2hlcyAyJSBpbiBhDQo+IGdyZWF0IG1hbnkgY2FzZXMuDQoNCg== From nobody Tue Jun 6 02:21:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5D3124D68 for ; Tue, 6 Jun 2017 02:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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=netapp.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 7NZsZ73W8PqH for ; Tue, 6 Jun 2017 02:21:50 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A2E12426E for ; Tue, 6 Jun 2017 02:21:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,305,1493708400"; d="asc'?scan'208";a="207099118" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx141-out.netapp.com with ESMTP; 06 Jun 2017 02:00:44 -0700 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Jun 2017 02:16:45 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 6 Jun 2017 02:16:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T+Vilz4ioKxAFg3gYGWz7k7E/ojCMUUF98KRKcdB4jg=; b=pFWLANoa+9yg5Y+gzwTDsF8dRis3e0NGU3jwksMR6ff8NHj4nVMabQPedtx7iXTnLqE2MiV83pK5rvMl0KYaAfVR+gpbb5sDlcFiak/uLycVB1Ymz8Z+p8ui/URLbS5Cj+tOCui7qitMM9ZAWdEOmOY9HSYB/M+QbJxDoYEtMyM= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Tue, 6 Jun 2017 09:16:46 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1157.012; Tue, 6 Jun 2017 09:16:46 +0000 From: "Eggert, Lars" To: Martin Thomson CC: Alan Frindell , IETF QUIC WG Subject: Re: Comparing HTTP over QUIC header compression schemes Thread-Topic: Comparing HTTP over QUIC header compression schemes Thread-Index: AQHS3pDkbL6XmOk6K0ms9bs9UuyP16IXiUoAgAADLQCAAAGjgA== Date: Tue, 6 Jun 2017 09:16:46 +0000 Message-ID: <2C0AE395-D044-4773-B24B-E1933BCF7EDB@netapp.com> References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [2001:450:1e:232:f1e9:551d:ec8b:7d09] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:ATCpkq0ZLZ7kRyB54mj5VysG/4DG2/fuTi1xwFpAh59c+0qOTn0O61m2SvLO8hBC916wnNCEjf2eS2Rt6Fz+Ol89DT+ckRTNsL4HXwkxUNNdneaDF2YeMyJ1f3oYTwO+3BT/5seEgw9Lz0VisuIF8/RfX1uLg9DkIy/1He4t0Ji/ZK5xRXdTOTktz0MLaiEq7EXwZITrcm8gf/2tjRET6sEpGmygv7JusFqmLhtxUzJHM9I0oSNjfUuw7B06drbJH2ZCP4nkarefiZE4XUa01tWhxWB+iVzNR4n66x9RRF5Vb42m1LKBAwjhrRlpYiBGDKVW0S8q7p2JLffMdbBC4Q== x-ms-traffictypediagnostic: BLUPR06MB1762: x-ms-office365-filtering-correlation-id: d40eecf7-18b6-439f-e79d-08d4acbcc1a6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1762; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(377424004)(24454002)(82746002)(3660700001)(4001150100001)(6916009)(2950100002)(6436002)(6506006)(3280700002)(14454004)(36756003)(2906002)(8936002)(83716003)(81166006)(33656002)(50226002)(8676002)(229853002)(53936002)(38730400002)(110136004)(6246003)(478600001)(99286003)(54906002)(57306001)(122556002)(6512007)(6486002)(77096006)(50986999)(86362001)(5660300001)(99936001)(2900100001)(305945005)(7736002)(102836003)(4326008)(6116002)(76176999)(39060400002)(25786009)(53546009)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_B9747FEC-F811-4AC1-A903-477639B976AC"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 09:16:46.6620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 09:21:51 -0000 --Apple-Mail=_B9747FEC-F811-4AC1-A903-477639B976AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-6-6, at 11:10, Martin Thomson wrote: > On 6 June 2017 at 10:59, Eggert, Lars wrote: >> (2) simulating loss rates much above 1% is likely going to be pretty = uninteresting, given that QUIC (and TCP, FWIW) have congestion = controllers that will struggle to even deliver useful throughputs in = these cases >=20 > That's an interesting point. I've seen a presentation (that I can't > find now, but I can try) that shows that packet loss in real-world > scenarios approaches 2% in a great many cases. SACK helps. But he measures up to 10% ("much above"). Lars --Apple-Mail=_B9747FEC-F811-4AC1-A903-477639B976AC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlk2cv0ACgkQVLXDCb9w wVc0Dw//cUTjPDfbEcSfIFEbcBGH6OallpPMEmVXyVLClQBIvhSNBePlijwjQ+a+ yf13IePAv6dFFRtQLPGUBUxJwSxzXGITkED8GJYABrAT9Ny3U5+nzobFRQ8JK9g2 tyxpfGtHLpCmrI5HiRJ953Fr/7H9QD4ItP4qxidzknnu3GkCBIPQgemm5vTxq+wd jGC5E1B74U3XBR+GsIbGK5a1nuUJP+oJZQMyujjoyUgUt6c/Yi3RoOWTY8RxNIvI kafCFg5nZbzN9LcnI1ggR8BNEGMxZheoOyW8JrqWC8bZevK+E3P7qfKFNFCi4QL2 8U9iCsQbKOqR//Xomjw4fxfGHzlwfhLcBESn+VQvITvSRNxTLcfhlimeL5rRRxM3 h64VJNYCJXQBUAqBuOYt2+h09A6oR3tHADIIYqKo/CNZnh9rqWYLPYbzVnyvMBkc WnWKaKOVxIY4mCgkRlaQAc+ql30duK22toIGRn8b4ov4o1isKgWc9YHSpxIEuV4a IyU4/466rh3s7BlrbdfbxfpbpcOomvwaMaDNjljGrreo2UKn9xwnSlMQObplJe6u mELqq7NRsDPIqQ/nmpocDLrazVSxGXOhljazVmthaQBhgKkLSzLi/UaHtDXX60GH OZKbiyYM8oorHY4rJCPUqExzip9fDIIPikuT3GLHVF/rOu1ZOas= =HmYR -----END PGP SIGNATURE----- --Apple-Mail=_B9747FEC-F811-4AC1-A903-477639B976AC-- From nobody Tue Jun 6 02:24: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 69D41129B9B for ; Tue, 6 Jun 2017 02:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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=netapp.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 TGr04eBqbBYs for ; Tue, 6 Jun 2017 02:24:29 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A02B12426E for ; Tue, 6 Jun 2017 02:24:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,305,1493708400"; d="asc'?scan'208";a="197751425" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx144-out.netapp.com with ESMTP; 06 Jun 2017 02:00:39 -0700 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Jun 2017 02:19:24 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 6 Jun 2017 02:19:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9V/28vEuMLSdz/46Q0vQhq22nayHziauzWtkqdW5RMI=; b=dqeZQiTYXx6YbNRJwpEtde2JFgGi3i8MIn29k7oB4fmCaV77wOzbnHBb0SXZJhAqr7L8+rcMvF696ugJN8kPAq8ofkTCIQX5SXD2udnPb8NIGa50g6AngJIreMKu04RUY0a8Vjw+ffmRL1qK6mEsdOCoXOwsljd+FuX0lEe9vMo= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Tue, 6 Jun 2017 09:19:25 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1157.012; Tue, 6 Jun 2017 09:19:26 +0000 From: "Eggert, Lars" To: Martin Thomson CC: Alan Frindell , IETF QUIC WG Subject: Re: Comparing HTTP over QUIC header compression schemes Thread-Topic: Comparing HTTP over QUIC header compression schemes Thread-Index: AQHS3pDkbL6XmOk6K0ms9bs9UuyP16IXiUoAgAADLQCAAAGjgIAAALyA Date: Tue, 6 Jun 2017 09:19:25 +0000 Message-ID: References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> <2C0AE395-D044-4773-B24B-E1933BCF7EDB@netapp.com> In-Reply-To: <2C0AE395-D044-4773-B24B-E1933BCF7EDB@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [2001:450:1e:232:f1e9:551d:ec8b:7d09] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:0TkkJ4TH2hkskBofNaw9vo0rmiZPqn5yoamfmVkwk7hhQEG4LDFc2sGdZeimgZVRi+niMH6NmOEn0WfNYWMKG92ENuFTHvYN3t3pDWO2VTxdnKiSgN6DWsUHF5mfXpB0qQdmDtZeUbBwLUPWiBmON8BKIiL44mNStNDJ/n8gKDZvZsTKgl6N0t4AQtUeiUfgK6fOT9WZIwzy37xHJiBNizyPdrMcjd5seKEefievvPq9U/e2ROJOhgIUxU8+qRG65lP14EDfVVO+uQAODQJq1ewYEABq3XFbHWRxo2eK2mCVBGCJ4UNmbVeZXewGJYfuAT+kJeEcErvDWlgsLuiyLQ== x-ms-traffictypediagnostic: BLUPR06MB1762: x-ms-office365-filtering-correlation-id: c609e853-5e0b-4cfe-ad86-08d4acbd2086 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1762; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(377424004)(24454002)(82746002)(3660700001)(4001150100001)(6916009)(2950100002)(6436002)(6506006)(3280700002)(14454004)(36756003)(2906002)(8936002)(83716003)(81166006)(33656002)(50226002)(8676002)(229853002)(53936002)(38730400002)(110136004)(6246003)(478600001)(99286003)(54906002)(57306001)(122556002)(6512007)(6486002)(77096006)(50986999)(86362001)(5660300001)(99936001)(2900100001)(305945005)(7736002)(102836003)(4326008)(6116002)(76176999)(39060400002)(25786009)(53546009)(189998001)(93886004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_82845DB6-2DC8-463E-BB02-DABACA496F19"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 09:19:25.7323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 09:24:30 -0000 --Apple-Mail=_82845DB6-2DC8-463E-BB02-DABACA496F19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 2017-6-6, at 11:16, Lars Eggert wrote: >=20 > On 2017-6-6, at 11:10, Martin Thomson = wrote: >> On 6 June 2017 at 10:59, Eggert, Lars wrote: >>> (2) simulating loss rates much above 1% is likely going to be pretty = uninteresting, given that QUIC (and TCP, FWIW) have congestion = controllers that will struggle to even deliver useful throughputs in = these cases >>=20 >> That's an interesting point. I've seen a presentation (that I can't >> find now, but I can try) that shows that packet loss in real-world >> scenarios approaches 2% in a great many cases. >=20 > SACK helps. But he measures up to 10% ("much above"). s/measures/simulates/ Also, I'm sure you see 2% in traces, but it's not clear if those = connections are able to usefully deliver information anymore. Things may be better with QUIC, given that there is more space for ACK = blocks compared to TCP. But I'd be surprised if that would let QUIC = remain useful under 10% loss. Lars --Apple-Mail=_82845DB6-2DC8-463E-BB02-DABACA496F19 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlk2c5sACgkQVLXDCb9w wVcuCQ/9EwPgQo4g/Ueu3zKuqB9XudNy4NxvDRkXTCdMAXrna0xSETMJtmHjU+eO /3MZFrYnHuvDpJbkh5dZpMlhAfnzNuEJ/Oc2nZZySAvFDwoU/ZR7g9B1oPhJOI0O l5NdwW8SdOtW1zujshQG7o1eFG7cRPOBMo3ZydSt2UFTuhd3CIpa0QQ2UBx05WPb V6jp3ZLvg+5wJpjI+HC2h/rQmS6Zz4QVCt6pitWbOUxYfWQhnWDz0+nApvQxx32K IvB8JY5Y2L86qWpLPY7/+5I7lGbLmjYCAjCE6HtG8s3c34WbTfhTIslcznvpQ/35 bIe8ZWN1mD4xivNiXUmROC3chQiFtStP0qoM4LDO3v7sXA3gGkp6ehDgLgozDJlD lEprUGkiK4KlkGVW76WA1T+98jDJ/u6sEh0iULXfPDXJtSiUSO/eClpxoWuNYq5G G3s7y4GGzrY0gM1HOhhvDkQ7VxNE5j4T/MkJfDHi8SzumHfwD3cqODfZYRheJOIw ogF2ma+/O46ZbLtE5G1Uxdn4PUmhkXhZ+nKVAOLeKFNA+6z6TB6A45q8C8yBwETH PsGP4IIvMkejWf/o5lC2slcJYIolBp+Mbp6HRJEdQVEAsDdiHh9SEGP6o8ss/CWE PinfneCh6hzHWq1/ZpQa/UDwRJ5IsGx4PwX5JrrgB8sbxIPqqn8= =1NTz -----END PGP SIGNATURE----- --Apple-Mail=_82845DB6-2DC8-463E-BB02-DABACA496F19-- From nobody Tue Jun 6 02:25: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 E1BFF1289C3 for ; Tue, 6 Jun 2017 02:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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, 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=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 VRZ5Wg6nXEIG for ; Tue, 6 Jun 2017 02:25:50 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 0C9AB129B8D for ; Tue, 6 Jun 2017 02:25:50 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id r66so40119329yba.2 for ; Tue, 06 Jun 2017 02:25:50 -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=XP/TEyuWIIqs4/qby7U6nqdN5pkfqNSD91GS55L+/bs=; b=t6A2KXWDEK1lT1dDqDoru78dlEwAtP+qQjy+ER9GnidAFuIszdV69DorLn7Jr5cxzm VxpEUtEnIZZK2K5LwgQXNBPMAQ5O2zlmZHITEMCPSWa7UzCPvXVn02KlPG3RBfvPI6rb vH6I946NrNsgZ5asbLyfzA/2eVFGcQZMsFrRZ2kTn55wXwaruVatpbl432G+RCB6XqYp 48x3b9LQbdIqojsHPt4xbWuk+XHy0fS6ATL/dkFe+4uBwm/evmlPPTxllIid5w0P4T4C KhAzPkknLK3NNfu/FuN43TSIo4wFtFVzYKmOP4CCmBWXFzAaffBgecexms1mUm3BCWG3 EvdQ== 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=XP/TEyuWIIqs4/qby7U6nqdN5pkfqNSD91GS55L+/bs=; b=B7l5/K43UtUgNy3Ddznyorc6EYajrJWTZAOyvZdIPu0HEESi/Qn2SMS8KVbvuwFgcN em3F+3X6+5I5xUz9CVWW+rdClQSAF2R3zaQn+42AfP90lMn4065xhCDo93fA65oSpK58 JoTPBj25j+QAEA64ih5418xOXklioGQBt+vSmGDM4xKfmowhw3mIXyFWMSaDpLSVYSrZ r11wCOS9cHy/Cq1O4VKhMfNWHv0oYr7tKiFJxhp6EB6kDqZfyzhbHfNlZyGqLNc6VYVl e/21xarfPjt3oS5uFXSXROJ8cbdv9za60Si4QCZDwpnVccJMzOCPN5MeWwKwHbq1WYO0 /L2A== X-Gm-Message-State: AODbwcDwRye0XOrUqB3liNEZyDZgXalIUVRrGP5USOnivAxg+epUgGKq h87Nv9C3lEC2FwWvFhSnuASs1bvVnyDF X-Received: by 10.37.216.4 with SMTP id p4mr1847557ybg.35.1496741149088; Tue, 06 Jun 2017 02:25:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.3.142 with HTTP; Tue, 6 Jun 2017 02:25:28 -0700 (PDT) In-Reply-To: References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> From: "Charles 'Buck' Krasic" Date: Tue, 6 Jun 2017 02:25:28 -0700 Message-ID: Subject: Re: Comparing HTTP over QUIC header compression schemes To: Mike Bishop Cc: Alan Frindell , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114fd372839ce9055147346e" 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, 06 Jun 2017 09:25:53 -0000 --001a114fd372839ce9055147346e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 6, 2017 at 2:12 AM, Mike Bishop wrote: > Again, thanks for putting this together, Alan. My comments in more detai= l > were: > > - QCRAM forbids referencing a header until you=E2=80=99re sure it has > arrived. > > Minor nit. QCRAM allows references within the same packet if the "packet epoch" is used. > > - That leads one to expect what you found below: Never HOL-blocking, > more bytes. QPACK leaves that choice to the encoder, which means you = can > choose to take the risk and get better byte-efficiency or be more > conservative. It=E2=80=99s just not mandated. > - An implementation that wanted to do blocking at the header set level > could do that =E2=80=93 you=E2=80=99d add an initial pass of the encod= ed headers to see > whether all references can be satisfied. If not, wait to decompress > anything until they can be. That also saves the decoder buffering > uncompressed header data while waiting. > > > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Alan Frindell > Sent: Tuesday, June 6, 2017 8:48 AM > To: IETF QUIC WG > Subject: Comparing HTTP over QUIC header compression schemes > > > > I built a QCRAM and QPACK implementation and attempted to simulate > performance under varying network conditions. Here=E2=80=99s a summary o= f the work > so far. > > > > -Alan > > > > =3D=3D=3D > > > > Problem > > > > HTTP/2 uses HPACK for header compression, which relies on in-order > processing of header frames. The current QUIC draft retains HPACK and > introduces a sequence number for header frames so the HTTP implementation > can ensure in-order processing. > > There are two proposed compression schemes for HTTP over QUIC that > facilitate out-of-order processing, QCRAM and QPACK. > > My goal was to understand the magnitude of the problem caused by HOL > blocking on header frames under varying network conditions, and quantify > the degree to which QCRAM and QPACK alleviate the problem. I was also > seeking to understand the implementation complexity of each scheme and > provide feedback to the authors with on the specification drafts. > > > > Methodology > > > > I modified proxygen=E2=80=99s HPACK library (https://na01.safelinks. > protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com% > 2Ffacebook%2Fproxygen&data=3D02%7C01%7Cmichael.bishop%40microsoft.com% > 7Cf14e0c0f9fad4d42603908d4aca81547%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636323285318004373&sdata=3DmaDPZ5lGy4PsJZ7qQTdxZI7qtfRUaN > gAP0KUj0hyfi0%3D&reserved=3D0) to support both QCRAM and QPACK. I then > wrote a simulator to test various network conditions. The simulator has t= wo > primary knobs: > > 1. Simulated RTT - round trip time between the endpoints. There is a > minimum processing delay of rtt / 2 between encoding and decoding a heade= r > block 2. Simulated loss probability - probability that a given packet is > dropped. Drops are simulated by adding 1.1 - 2 RTTs between encoding and > decoding a header block After decoding a header block, a simulated ack is > generated and delivered to the encoder with the same RTT and loss model > (e.g.: acks can also be lost and retransmitted) > > > > I know this is a simplistic loss model. If someone has a different model > they prefer and can provide me with C or C++ code, I can re-run the > simulations with a different loss engine. I hope to open source the > QPACK/QCRAM implementations and the simulator eventually, but they are no= t > ready at present. > > > > Experiment Setup > > > > I loaded my Facebook feed in Chrome and captured request headers and > timing in a HAR file. The simulator reads the HAR file and schedules the > encodings based on the request start times. It contained 227 requests mad= e > to 5 origins. I simulated as if all facebook.com and fbcdn.net origins > were coalesced. For the original test, I throttled the connection to 100= ms > RTT. > > I ran the simulation 5 times for each algorithm with RTT ranging from 10m= s > - 500ms and loss percentage from 0 to 10%. > > > > Metrics > > > > Cumulative HOL Delay - This is the sum of the time header blocks spent in > a queue waiting for an earlier block to be decoded. For example, if I se= nd > one request that adds indexed entries to the header table followed by two > requests that reference it, but the first request is delayed 100ms, the > cumulative delay would be 200ms (2 requests x 100ms). > > > > Compression Ratio - Ratio of bytes sent on the wire to the total > uncompressed header size > > > > Maximum Buffer Size - If HOL blocking occurs, the decoder must buffer som= e > header data. This is the maximum size of the buffer in bytes over the > lifetime of the session. > > Results > > > > Data: > > > > Delay: https://na01.safelinks.protection.outlook.com/?url=3D > https%3A%2F%2Fwww.dropbox.com%2Fs%2Fqdh310epry8sha1%2FHOL% > 2520Delay.png%3Fdl%3D0&data=3D02%7C01%7Cmichael.bishop%40microsoft.com% > 7Cf14e0c0f9fad4d42603908d4aca81547%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C1%7C636323285318004373&sdata=3D3WF48OPhGihmeEIpy59WoXNUcO6sR2 > wBYxtajCuP98I%3D&reserved=3D0 > > Compression Ratio: https://na01.safelinks.protection.outlook.com/?url=3D > https%3A%2F%2Fwww.dropbox.com%2Fs%2Fqqwztqt8uwbqwjr% > 2FCompression%2520Ratio.png%3Fdl%3D0&data=3D02%7C01% > 7Cmichael.bishop%40microsoft.com%7Cf14e0c0f9fad4d42603908d4aca81547% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636323285318004373&sdata=3D > UxNMX6ryuu6fURXwA0xM5%2F718yJodjk2UNCrHIs8XNU%3D&reserved=3D0 > > Buffer Size: https://na01.safelinks.protection.outlook.com/?url=3D > https%3A%2F%2Fwww.dropbox.com%2Fs%2F3b0c34upt11wmt7%2FHOL% > 2520Buffering.png%3Fdl%3D0&data=3D02%7C01%7Cmichael.bishop%40microsoft.co= m% > 7Cf14e0c0f9fad4d42603908d4aca81547%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C1%7C636323285318004373&sdata=3DGCZIxN6puPKd5UAktLoeHVbrFIc% > 2BcjMt4lT9VgoaTyg%3D&reserved=3D0 > > > > > > High level observations > > > > 1. Head-of-line blocking is a very real problem for serialized HPACK that > gets predictably worse as RTT and loss increase. At a fairly modest 100ms > RTT + 2% loss, HOL blocking on headers added an average of 40ms / request= . > At 200ms/5% loss, it=E2=80=99s almost 100ms/request, and the p100 (max) w= as > 497ms/request. > > 2. QPACK and QCRAM both drastically reduce HOL blocking. QCRAM=E2=80=99s = design > favors sacrificing compression ratio to reduce HOL blocking, while QPACK > maintains HPACK=E2=80=99s compression ratio at the expense of additional = latency. > As such, QCRAM incurred 0 head of line blocking delay in 100% of my > simulations, and QPACK had 0 in 80% of test runs. The average delay was > 8ms/req, p95 delay was 63ms/request and p100 was 242ms/request. Mike > Bishop suggested some QCRAM techniques could be applied to QPACK to modif= y > the blocking/compression ratio tradeoff. > > 3. QCRAM sends up 15% more header bytes on the wire even in moderate > networks. Because of the nature of my simulation, the compression ratio > data for QCRAM may be pessimistic for RTTs > 200ms, but it=E2=80=99s prob= ably in > the 84% ballpark. > > 4. Because QCRAM only infrequently induces HOL blocking, none of the > simulations resulted in the decoder having to buffer frames. QPACKs buffe= rs > were usually manageable (smaller than 1kb), but note that when QPACK > encounters HOL blocking, it buffers decompressed data potentially occupyi= ng > a lot of memory. Mike Bishop suggested this could be mitigated by > performing the decode in two steps, and buffering the compressed data if > decoding would block. > > > > Implementation Considerations > > > > A basic QCRAM implementation is simpler, because it can more directly > leverage an existing HPACK implementation. It was further simpler for > Facebook because our implementation was already designed to handle > asynchrony at the layer of decoding headers. Full implementation also > requires some interaction with the transport=E2=80=99s acknowledgement ha= ndling. > Additional complexity also comes when trying to use the packet epoch, > because it requires the packet scheduling layer of the transport to > interact with the header compression algorithm. While I was able to > approximate this simply in my simulation, Facebook prefers more separatio= n > between the transport and application layers of hq, so implementing in > practice may be more difficult. In my simulation though, compression rati= o > didn=E2=80=99t appear to improve drastically with this feature, and might= be hurt > performance in some scenarios if re-indexing the same header/value leads = to > more table evictions. > > QPACK=E2=80=99s design is different enough that it can=E2=80=99t use the = same underlying > structure as HPACK. Furthermore, it=E2=80=99s quite different in where as= ynchrony > is expected - at the level of table lookups rather than block decoding. > Explicit indexing is simpler to understand than HPACK=E2=80=99s relative = indexing, > and along with reference counts an implementation can be clever about nev= er > evicting frequently used headers. QPACK requires more additional state in > the header table than QCRAM. > > > > Caveats > > > > Different workloads may produce quite different results. In loading the > Facebook feed, there were no evictions from the header table using QCRAM. > This will vary depending on implementation decisions about which header > fields to index. Evictions will have a more negative impact on QCRAM=E2= =80=99s HOL > blocking, and more impact on QPACK=E2=80=99s compression ratio. > > > > Having the CDN coalesced with the dynamic origin also plays a role in the > performance of the compression schemes. Over time I hope to build a > diverse collection of input HAR files from different sites and applicatio= ns > which can be run through the simulator to get more complete data. > > > > Thanks to Mike Bishop and Buck Krasic who provided feedback. > > > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a114fd372839ce9055147346e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 6, 2017 at 2:12 AM, Mike Bishop <Michael.Bishop= @microsoft.com> wrote:

Again, thanks for putting th= is together, Alan.=C2=A0 My comments in more detail were:

  • Q= CRAM forbids referencing a header until you=E2=80=99re sure it has arrived.= =C2=A0
Minor nit.=C2=A0 QCRAM allow= s references within the same packet if the "packet epoch" is used= .
=C2=A0
  • That leads one to expect= what you found below:=C2=A0 Never HOL-blocking, more bytes.=C2=A0 QPACK le= aves that choice to the encoder, which means you can choose to take the risk and get better byte-efficiency= or be more conservative.=C2=A0 It=E2=80=99s just not mandated.
  • An implementation that wanted to do blocking at the header set level = could do that =E2=80=93 you=E2=80=99d add an initial pass of the encoded he= aders to see whether all references can be satisfied.=C2=A0 If not, wait to decompress anything until they can be.=C2=A0 That also saves = the decoder buffering uncompressed header data while waiting.=

=C2=A0

-----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Alan Frindell
Sent: Tuesday, June 6, 2017 8:48 AM
To: IETF QUIC WG <qui= c@ietf.org>
Subject: Comparing HTTP over QUIC header compression schemes

=C2=A0

I built a QCRAM and QPACK im= plementation and attempted to simulate performance under varying network co= nditions.=C2=A0 Here=E2=80=99s a summary of the work so far.<= /p>

=C2=A0

-Alan

=C2=A0

=3D=3D=3D

=C2=A0

Problem

=C2=A0

HTTP/2 uses HPACK for header= compression, which relies on in-order processing of header frames. The cur= rent QUIC draft retains HPACK and introduces a sequence number for header f= rames so the HTTP implementation can ensure in-order processing.=C2=A0

There are two proposed compr= ession schemes for HTTP over QUIC that facilitate out-of-order processing, = QCRAM and QPACK.=C2=A0

My goal was to understand th= e magnitude of the problem caused by HOL blocking on header frames under va= rying network conditions, and quantify the degree to which QCRAM and QPACK = alleviate the problem. I was also seeking to understand the implementation complexity of each scheme and provide feedback to the a= uthors with on the specification drafts.

=C2=A0

Methodology

=C2=A0

I modified proxygen= =E2=80=99s HPACK library (https://na01.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%= 2Ffacebook%2Fproxygen&data=3D02%7C01%7Cmichael.bishop%40= microsoft.com%7Cf14e0c0f9fad4d42603908d4aca81547%7C72f988bf8= 6f141af91ab2d7cd011db47%7C1%7C0%7C636323285318004373&sdata=3D= maDPZ5lGy4PsJZ7qQTdxZI7qtfRUaNgAP0KUj0hyfi0%3D&reserved=3D0)=C2=A0 to support both QCRAM and QPACK. I then wrote a simulator to test various = network conditions. The simulator has two primary knobs:

<= span class=3D"">

1. Simulated RTT - round tri= p time between the endpoints. There is a minimum processing delay of rtt / = 2 between encoding and decoding a header block 2. Simulated loss probabilit= y - probability that a given packet is dropped. Drops are simulated by adding 1.1 - 2 RTTs between encoding and decoding a header bl= ock After decoding a header block, a simulated ack is generated and deliver= ed to the encoder with the same RTT and loss model (e.g.: acks can also be = lost and retransmitted)

=C2=A0

I know this is a simplistic = loss model.=C2=A0 If someone has a different model they prefer and can prov= ide me with C or C++ code, I can re-run the simulations with a different lo= ss engine.=C2=A0 I hope to open source the QPACK/QCRAM implementations and the simulator eventually, but they are not ready at present.=

=C2=A0

Experiment Setup

=C2=A0

I loaded my Facebook feed in= Chrome and captured request headers and timing in a HAR file. The simulato= r reads the HAR file and schedules the encodings based on the request start= times. It contained 227 requests made to 5 origins.=C2=A0 I simulated as if all face= book.com and fbcdn.net origins were coalesced.=C2=A0 For the original test, I throttled the con= nection to 100ms RTT.

I ran the simulation 5 times= for each algorithm with RTT ranging from 10ms - 500ms and loss percentage = from 0 to 10%.

=C2=A0

Metrics

=C2=A0

Cumulative HOL Delay - This = is the sum of the time header blocks spent in a queue waiting for an earlie= r block to be decoded.=C2=A0 For example, if I send one request that adds i= ndexed entries to the header table followed by two requests that reference it, but the first request is delayed 100ms, the cumulative = delay would be 200ms (2 requests x 100ms).

=C2=A0

Compression Ratio - Ratio of= bytes sent on the wire to the total uncompressed header size=

=C2=A0

Maximum Buffer Size - If HOL= blocking occurs, the decoder must buffer some header data.=C2=A0 This is t= he maximum size of the buffer in bytes over the lifetime of the session.=

Results

=C2=A0

Data:

=C2=A0

Delay: https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.dropbox.com%2Fs%2Fqdh310epry8sha1%2FHOL%2520Delay.png%3Fdl%3D0&data=3D0= 2%7C01%7Cmichael.bishop%40microsoft.com%7Cf14e0c0f9fad4d42603908d= 4aca81547%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C= 636323285318004373&sdata=3D3WF48OPhGihmeEIpy59WoXNUcO6sR2wBYx= tajCuP98I%3D&reserved=3D0

Compression Ratio: https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.dropbox.com%2Fs%2Fqqwztqt8uwbqwjr%2FCompression%2520Ratio.png%3Fdl%3D0&= data=3D02%7C01%7Cmichael.bishop%40microsoft.com%7Cf14e0c0f9f= ad4d42603908d4aca81547%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C1%7C636323285318004373&sdata=3DUxNMX6ryuu6fURXwA0xM5%2F718yJodjk2UNCrHIs8XNU%3D&reserved=3D0<= /p>

Buffer Size: https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.dropbox.com%2Fs%2F3b0c34upt11wmt7%2FHOL%2520Buffering.png%3Fdl%3D0&data= =3D02%7C01%7Cmichael.bishop%40microsoft.com%7Cf14e0c0f9fad4d42603= 908d4aca81547%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636323285318004373&sdata=3DGCZIxN6puPKd5UAktLoeHVbrFIc%2B= cjMt4lT9VgoaTyg%3D&reserved=3D0

=C2=A0

=C2=A0

High level observations

=C2=A0

1. Head-of-line blocking is = a very real problem for serialized HPACK that gets predictably worse as RTT= and loss increase. At a fairly modest 100ms RTT + 2% loss, HOL blocking on= headers added an average of 40ms / request. At 200ms/5% loss, it=E2=80=99s almost 100ms/request, and the p100 (max) was 497ms/requ= est.

2. QPACK and QCRAM both dras= tically reduce HOL blocking. QCRAM=E2=80=99s design favors sacrificing comp= ression ratio to reduce HOL blocking, while QPACK maintains HPACK=E2=80=99s= compression ratio at the expense of additional latency. As such, QCRAM incurred 0 head of line blocking delay in 100% of my simulations, and QPAC= K had 0 in 80% of test runs. The average delay was 8ms/req, p95 delay was 6= 3ms/request and p100 was 242ms/request.=C2=A0 Mike Bishop suggested some QC= RAM techniques could be applied to QPACK to modify the blocking/compression ratio tradeoff.

3. QCRAM sends up 15% more h= eader bytes on the wire even in moderate networks. Because of the nature of= my simulation, the compression ratio data for QCRAM may be pessimistic for= RTTs > 200ms, but it=E2=80=99s probably in the 84% ballpark.<= /u>

4. Because QCRAM only infreq= uently induces HOL blocking, none of the simulations resulted in the decode= r having to buffer frames. QPACKs buffers were usually manageable (smaller = than 1kb), but note that when QPACK encounters HOL blocking, it buffers decompressed data potentially occupying a lot of memory.=C2=A0 = Mike Bishop suggested this could be mitigated by performing the decode in t= wo steps, and buffering the compressed data if decoding would block.=

=C2=A0

Implementation Consideration= s

=C2=A0

A basic QCRAM implementation= is simpler, because it can more directly leverage an existing HPACK implem= entation. It was further simpler for Facebook because our implementation wa= s already designed to handle asynchrony at the layer of decoding headers. Full implementation also requires some interaction with = the transport=E2=80=99s acknowledgement handling. Additional complexity als= o comes when trying to use the packet epoch, because it requires the packet= scheduling layer of the transport to interact with the header compression algorithm. While I was able to approximate thi= s simply in my simulation, Facebook prefers more separation between the tra= nsport and application layers of hq, so implementing in practice may be mor= e difficult. In my simulation though, compression ratio didn=E2=80=99t appear to improve drastically with this f= eature, and might be hurt performance in some scenarios if re-indexing the = same header/value leads to more table evictions.

QPACK=E2=80=99s design is di= fferent enough that it can=E2=80=99t use the same underlying structure as H= PACK. Furthermore, it=E2=80=99s quite different in where asynchrony is expe= cted - at the level of table lookups rather than block decoding.=C2=A0 Expl= icit indexing is simpler to understand than HPACK=E2=80=99s relative indexing, and along= with reference counts an implementation can be clever about never evicting= frequently used headers. QPACK requires more additional state in the heade= r table than QCRAM.

=C2=A0

Caveats

=C2=A0

Different workloads may prod= uce quite different results. In loading the Facebook feed, there were no ev= ictions from the header table using QCRAM. This will vary depending on impl= ementation decisions about which header fields to index. Evictions will have a more negative impact on QCRAM=E2=80=99s HOL blocking= , and more impact on QPACK=E2=80=99s compression ratio.

=C2=A0

Having the CDN coalesced wit= h the dynamic origin also plays a role in the performance of the compressio= n schemes.=C2=A0 Over time I hope to build a diverse collection of input HA= R files from different sites and applications which can be run through the simulator to get more complete data.

=C2=A0

Thanks to Mike Bishop and Bu= ck Krasic who provided feedback.

=C2=A0




--
Charles '= ;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--001a114fd372839ce9055147346e-- From nobody Tue Jun 6 02:36: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 C6B09129B8D for ; Tue, 6 Jun 2017 02:36: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, 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 BR-3nIjB1EnE for ; Tue, 6 Jun 2017 02:36:14 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3CE1289C3 for ; Tue, 6 Jun 2017 02:36:14 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 83so38311758pfr.0 for ; Tue, 06 Jun 2017 02:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Jwgkr5j6N1S0J3/pfaJlWvyF/7JE730+00DsJ0QN6go=; b=FmEzjLw7GumgoTOc06W+d4T1cz7FBIcFJ+25m3yabd6tjC80m6WuvtUp7ZiWQ89LSO gqKNS/Gj1UNqCNucpupBhQoQrNvfWdvAZy2bXgw5ta665T2bg9o5JAHQpkmse8PlgwQq AExWvrvJfLZsZK1hIhqD22lNWE1lFcwTLgjfwo8aAW90peypkLUqu10IyN3Ye1EfvZP8 PKXM1nUCeHhsOTfAepS9fbexOSfaemZNvSbSnrvMklGmzTcNCM/dEyRUeROYW8jDu0J9 i0J473E5CbNxUQykXqp004wEWFAnpvdrxAbAm0p0AMlY+PkUrkWD39InlrkZgS4j3zia kqAQ== 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=Jwgkr5j6N1S0J3/pfaJlWvyF/7JE730+00DsJ0QN6go=; b=sxLF83kvCAfoiSaEkSeLGASQnnmKhw80vPXhqAdT8CUuWlnQvTWBA20O0+DYdDVtDY 3y2UsJzk/Fv+mneF0aNdg2oFjXG+RKLAhXuWitXFhGfz4m7BDzPBXPAqnmHmkYVX/ihW v8IEwZkMyJ/hiWcKO6jSNAGKUx5upSI92IShkeE33+Xi2SrbIkFnCtF7O8+YaqCrU3N0 Ecs77A2uCr8N7BDy1UPzVQ1+Q0AIR6viconJnXseSmeID2ATtjWteFz1RmucJOSfrdpB O92bXE10ffLsyMoWp72SiyWpx9GyQKd14pmFU5UJpRpRuAXhQm37FEvpN+F/qjtxNEqP +1FQ== X-Gm-Message-State: AODbwcAe123rkDg7PrmH2xjP2dbxTuiMfpDY5Y4zcxdaT/M/CdVwT8S4 9K48MrX1HjUQ+/AHNT/UnADf3o7BCKI5QdM= X-Received: by 10.99.186.91 with SMTP id l27mr21259371pgu.87.1496741773567; Tue, 06 Jun 2017 02:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Tue, 6 Jun 2017 02:36:12 -0700 (PDT) From: Jana Iyengar Date: Tue, 6 Jun 2017 02:36:12 -0700 Message-ID: Subject: Connection ID slides for Interim To: IETF QUIC WG Content-Type: multipart/mixed; boundary="089e0821c1c4bdee2305514759bd" 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, 06 Jun 2017 09:36:16 -0000 --089e0821c1c4bdee2305514759bd Content-Type: multipart/alternative; boundary="089e0821c1c4bdee1f05514759bb" --089e0821c1c4bdee1f05514759bb Content-Type: text/plain; charset="UTF-8" are attached. --089e0821c1c4bdee1f05514759bb Content-Type: text/html; charset="UTF-8"
are attached.
--089e0821c1c4bdee1f05514759bb-- --089e0821c1c4bdee2305514759bd Content-Type: application/pdf; name="QUIC Connection ID.pdf" Content-Disposition: attachment; filename="QUIC Connection ID.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j3ldelvt0 JVBERi0xLjQKJSDi48/TCjQKMApvYmoKPDwKL1R5cGUKL0NhdGFsb2cKL05hbWVzCjw8Ci9KYXZh U2NyaXB0CjMKMApSCj4+Ci9QYWdlTGFiZWxzCjw8Ci9OdW1zClsKMAo8PAovUwovRAovU3QKMQo+ PgpdCj4+Ci9PdXRsaW5lcwoyCjAKUgovUGFnZXMKMQowClIKPj4KZW5kb2JqCjUKMApvYmoKPDwK L0NyZWF0b3IKKP7/AEcAbwBvAGcAbABlKQo+PgplbmRvYmoKNgowCm9iago8PAovVHlwZQovUGFn ZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRzCjcKMApS Ci9SZXNvdXJjZXMKOAowClIKL0Fubm90cwoxMAowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVu Y3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjcKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVE ZWNvZGUKL0xlbmd0aAo5CjAKUgo+PgpzdHJlYW0KeJy1VVFvEzEMjrQ3v4A0eIAfUGCCNHFin/MI GtMQe6DoWMXjBKwVum508P+Fk/Z6d1XH0LQ2as/+Lo7tz1/UJXjrIK83K4Oi0+e3BSxBDecTC7lY dmz7uik/FhCYKnYlvOkcrGLAbDSw5eTfOUzhSpPkNX7b/JpfOJj9XuWBm9m9Tp7D5RFMdC3vGT49 KjX1wpSXzY7eZm19/GFxMfvh4fi6pJz8o5fgkC27BBilcmRzaUzeJRup6sCmD3LiFArYRXdYr9N9 HL7mgdEJWomyJsIlEdWA7IjaEIJDQlZ0hExH1lf7VVI8R8zDCMTBlaqlikOo6SAl3kuB2rgO6ZFx 2wQ8RhYbQgTBoD0xxywPCpjQDtCmh/rkhcRyldNuTuijm9RlEtLepc4qF6l18jOgrZBQCNCzRW1D 2tvmiYWxIjUVJmUb1QyEKXrMXbyr9ZD6BsYn11d/InDSevTDUF8Or3E+mshXCXwlVpJQgnp1W+vv 8NKwOTVfzNfy+9iMzEfz2ZyrNzEHr6D+Ce/rBy2HE+krH3dXs4+MGKJNJFEF6nNGHrQ/0nYnuk7N iZmas+IdmNfmxV6ap2QpoewspU14h4TulraKK6mEM8+dsPtg04EY2Du/AtvoPnZPUcfogZyopbpb SzrElP8y8BZzm0eCUK14xJ2ajs5FhBithJTScKjRiI5wVAY50bFmbZ+ZT+o/NYfmiXmuSj80z8wj RYI5Lm/Pu4E/YKWsKvfkKt5d6X/PPK+/R1hvWAplbmRzdHJlYW0KZW5kb2JqCjkKMApvYmoKNTY4 CmVuZG9iagoxMAowCm9iagpbCl0KZW5kb2JqCjE3CjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJl bnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAKXQovQ29udGVudHMKMTgKMApSCi9SZXNv dXJjZXMKMTkKMApSCi9Bbm5vdHMKMjEKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9D UwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iagoxOAowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29k ZQovTGVuZ3RoCjIwCjAKUgo+PgpzdHJlYW0KeJy9V99PFDEQruGtmkiC/gcGlWjpdtrZ9lFz4oFE Ah6cRF6ICsQc4KGP/vF+0/XYvdsD+XVcc7czc9uZ6Xwz03aoC2O1jNcVEbzF8+uxHmoQtkgcg/X5 jUkeL8njWBOHkm2ePqgZV3pyQgz0BCO/R7qvT2BkqJffDH4e7ZM+/JV9GX3PDm+k/UgfLOlNjGFD uRXl1TKhlqxjwzZp52NpgxEjHAqbjA9lLRw0hZw4URbWs2tZw+gslPeXcqjY2ehM9LHCy9kUIyCJ U2YBmuXV4/3D7053TrNnlwWkcJ6jxJRK8oaZJeqBXHJjwkEtDB4hhzBCOJrdlJ0HJIckjnKspnKC jRh5kjOl877AKo1LoSxGOVgEjuzKABL6AxbtQFJwyRdOvH/bg4remV5eOT357TWVhuTjdO9gPLkT vt6bSCkl1r0qe3vf9AtFalt11a5aV1vqs9pRc+o5+B3wa2oT3EP1Hm901Krqq3m1oJ6qRy9174d+ 17tTBz0yu4gcpns5svifsF4FaC48ByMuNICuhQ2gnScuCdIG0E3ZLYAuuDDkmPwIafJJ+ou7gJyM JIsqOxVlSrAxhvCi2gCaXaDZB54r6gOQ3gLC3Yz2IuhNjC7+6ecsENRfIQsE+0UMoRuY342rSBET Q/Jtf29sSbqJFKvU66Q5RlalFJxOyYxl1oM/t1jZxfaK3OkmjU1AIVwXpbUNrqu+4PcxpAsos6BK jDlA1UFpdvO7GYiZOBvE2TJaajk8WywK4nsEo2VNMSLeybHfyMUg5RBA9YHI3l4GI4Hdzt2wqosC /BpoqZROo15aQOXqWcW/26B2s5Z18Ouosnrebarq4uVGCTCabHvFd13E0m+K1Go4nJdbLfq6DYdn 1nAoynblwhSPZ5vmLtxnz2lZm4Cj3XSq7BVomm/O/wNuJ7er+4Dt4pWVEVsuwGsvbsbIpftsUC1r 6hmw2kB8nzS2hE/AakV9zG1qZ6zz8Ay3CI9zMJUcqO3lLJoKBSlRix3pbg+BRDGmaKi6jAjM+ZJl o+cx4aAhlHuFM1l2PruWXf8QCB3GYz5uQTgOcixvegiMaPDVcZraeFlclpyXCJMnsuVYXu3dHLRL jUbcxJimG70yejL+Ao3Q2d4KZW5kc3RyZWFtCmVuZG9iagoyMAowCm9iago4NDUKZW5kb2JqCjIx CjAKb2JqClsKXQplbmRvYmoKMjUKMApvYmoKPDwKL1R5cGUKL1BhZ2UKL1BhcmVudAoxCjAKUgov TWVkaWFCb3gKWwowCjAKNzIwCjU0MApdCi9Db250ZW50cwoyNgowClIKL1Jlc291cmNlcwoyNwow ClIKL0Fubm90cwoyOQowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVuY3kKL0NTCi9EZXZpY2VS R0IKPj4KPj4KZW5kb2JqCjI2CjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgK MjgKMApSCj4+CnN0cmVhbQp4nLVW224TMRC1lDc/8RVAK3DtGdtrP4JCeougQdsEUF4qoKlQ2pLC /4tjL5vdXFpKmsTa3fFZezxzjnecmTRKy9ReV4azGs+v13ImYWgTfXDa5hHLfQxKj2vJ3hVe5+nT pkOFZUrGVC510v1KjuQNFpnJgzfTn1cXLCe/ciz1dTfZyPuVvNyXA7RZy7lOzqs04ZY1eeV1lGRD oZ1Ki3hndFTWFQ04bYM++sgZbGY3WGvRXTgf7WeqPOlAKthQ6UU6hgBJwppZkObg+Ppi8p1k9zZH 9hAhhqwPiVMu2CrvfWLdMUVaAKcN6CwoBxgA1rPb2JyQTEmo91hj5Q1Wd9KTSRVkrUGWiqIrTL0H jfPBU+Fgwr9D0gSTHUVrKEX/toSL8k4e9G5vflvJheL0I1leLm7uiMtaFTjG6GVZ7d7ym3wpXokh 2idxJDrii+iLkTiF9QL9IXonYrAnyx/yXbnVcKCaMtpwWB9UveQ/WHyMrt5Y71SKoaVrA7Z0Jcu+ YKAtXdvYE3Q13igmz7YWlm1M5YTuMZep9MmVXisqR6yxIKiHdOfic753xJnoivE4a9sVA6jbwfUR 93MMOITC6dnLeB/ve3h3lq0TIKk3QKtG9HOvnt8VnWZnbC+fwMv5pCCP0Y5yqFUKwybHbQdBFFM9 wdZcCWUX+RoblhN+npUagOWU6mFmu/+X+VNYw4zOv0/0nqEtkJJnDDM2wrfdE+9b7xt1P8DOlG47 syI6hdMSpWI1v12wSOY+rZ5QQphDiEFxdXKhTsV8Iutg/QI4bYHpECKVsfnsBvv/EgIfymI+jkwU EzC6aQkJ0nBVjXmFQfztCZZsopctsy4WtuN4b2PFHlw04DPzvH7RR6uX2h8LSs8kCmVuZHN0cmVh bQplbmRvYmoKMjgKMApvYmoKNjU4CmVuZG9iagoyOQowCm9iagpbCl0KZW5kb2JqCjMwCjAKb2Jq Cjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAKXQov Q29udGVudHMKMzEKMApSCi9SZXNvdXJjZXMKMzIKMApSCi9Bbm5vdHMKMzQKMApSCi9Hcm91cAo8 PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iagozMQowCm9iago8 PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjMzCjAKUgo+PgpzdHJlYW0KeJy9Vt9TEzEQ jtO3yIzO4Pjma1UGQ7Kb5JJHncoP6aiFQlGfGH/AOAUEffSP90tKe9drQSgtl+kl2Ut2N/t92e65 NErL1F4NBs5q9F9P5LnEQJvog9M2r6jPsSh1J5K9K7zO2/vlhArLlAZ9WZuk97HsyVMYOZdrr/u/ jg9ZHv3Ovgx/F0czaT+WP1ZkB+28olwn5YNjQi1r8srrKMmGQjuVjHhndFTWFaWwXxX66CNnYbm7 lFWMLkJ5byWHypMOpIINA7xIxxAASZiyC9CsbZ0cHn0n2TrLnl0XEEPWQxOwt9DjvUtRd0yRxoT9 UsguhiQNEA53V2WjgOSQhCHHylEm2HCSeiZVkLVGGqsousLwkITG+eCpcBgCZ4dTE4bsKFpDyf03 XejoXsi19bPTP1ZyoTg9JLs/xtkd8bNWBY4xetkd0Lf7Tb4QRmyKz6IhnqPfF23xTnQweyg2xJ5o iS3RE4/FsngqlsQzyD1WfBS74gNWN0QTK/bF5kvZ/SnfdufqsDdGGW0LO93tocn/BPom0DO8dHDD VqEvhRXoybABx5gr0Fdld4AeS5g8j5BnG1PCoSuG9Uj6pElPRZ0jTIwh3gR6beDXAbYNsS62xQ7a fsY/YbqDLx3M1vG9nWcNsQp+JFY00dJ4qcR8Pq6CIiq4aCf9ndlSSi/p+uKZpBdIFaMjGaMaI9aD v3c42dX2TE59dWM1KFbRt3PQW5A/gmQZl8+JAq0BmFri0+W1yyAsxFHrSdkCN7ju67wBT9w0nurk 9DjhXj7nHk66i/cOiLiJtpHp2crvA7wPRlG6HYX9oigcDBKgBoUnj7VYDhPRPZJ4wloNs2b+c2hh 3EP/JTN7+xI3v0jmGlIcKYRJDxccfnefOWTCWi2JTAt/C9820D+ppJNdSNfFe6zpZWjK9LJIkDxq bBecmTzGIvILU7qIWvOcSwfmEGJQPChqEw9ysa4D6sWqsF8RpvqUVJaNdpey25cO0KEs9qOaxiF9 QKU0W+0QpOFBFcaTd0qj6CabIsyWWRdjxFuZGbNrbQYU9J6n27wxeKn9A3EqiocKZW5kc3RyZWFt CmVuZG9iagozMwowCm9iago3OTcKZW5kb2JqCjM0CjAKb2JqClsKXQplbmRvYmoKMzUKMApvYmoK PDwKL1R5cGUKL1BhZ2UKL1BhcmVudAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIwCjU0MApdCi9D b250ZW50cwozNgowClIKL1Jlc291cmNlcwozNwowClIKL0Fubm90cwozOQowClIKL0dyb3VwCjw8 Ci9TCi9UcmFuc3BhcmVuY3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjM2CjAKb2JqCjw8 Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgKMzgKMApSCj4+CnN0cmVhbQp4nL1Y33MTNxAW 4zfBTJkB+tbXtOWHImmlPYm3dpxgwAMkOHZKeWHakgzjAKE88sfzSbbvzudLAMdn3/hOWum0q/0+ 7Up3Lo3SMl0PZgXvNJ7/nMlziYI2kYPXLvdo1tEpPc4ksS9Y59enVcUWjmwqTGWjku6nciLfQ8m5 3P1j+vH0DcmT/7Mti/+nk7VGP5Vv78oDXOe1wXUafDZNDEvasmIdpXWh0F4lJeyNjsr5ohJO60KO HCkLq7crWU1pF4NP7mZXsdXBquDCDC+rYwiAJLS8BWh2H5+9OfnPyv6HbNllDjHWMUYC9g7jMPvk dU822iXhtBKSjyFJA4SLt+uy0iHZJWHBsaqUCbaopCdZVVjnjDRO2egLQwsSGs+BbeFRBM4es7Yo krfRGZvM/3OEMUaf5O7+h/efnaRCUfpZOXq7zO6Iv3MqUIyR5WhG39G/8jdhxEC8Ej3xK55jMRRP xAFq18UjcST64rGYiJvilvhZ3BC/QP4QPSbiKUoe/Sfo8/r173L0Tu6NNmqvj1p5Ym43eqHxG27+ HuAJRnpY4erAV8Ia8NaQAcOIasDXZVcAHl3IMpW4k4sp3NgLik1HchpJt2JOESqW8N4Rz4HhAChP gOI+sDzENc7o99B6iJYD1PbRPsy1nrgPdiRO7OBK5RsV5JsxFQxRwUe3au/amlJwSYsXvxV1DFLF 6K2MUS0R69qXK8zsYn0mB76msgYU9/EcZqf3If8JkltYel4UuHqAqS/+Qt/eAoRODHVslSuwgJu2 bhrwxE3DtklOxgyP8jyPfpicPCfn7Q7o6QoVCW5ZNblbflprt0jQFW3w6QS8m8DjzzMG46XAn0ka M1jjEo6UT56gPCNyBVNF4BKoTqbChVc5h67MpmOogt4mVE1tguDfffEsg9ODx4/FC7E3X0iD+VIa IKv3kNMPs3S2zIaoD9FeYtWJ1d4HZQO7VcO7iCzkCMtUa7ok3B5grmnfczSn8zATPDF6D75LPV6V e51NMLbVWBdAH5ciS6vJ3TLWacLWWeNIsy3WtmpcMw12G0UcY0OivWs3uQvOOuYWzi4nxJe4H2Kt DvJKTsG4n+/HuB+X/lovbd7ZfNoMtlAenmyfW7fk9vlcuE1yt2psALiT82gf5ZRT/86EfzoHsQSi G0KjKZrguN3OjsHgbUeaVo2NSNMGRh9tKUfersWcl7XMOm6NQd1Axt4rYzRaWmfTRRBiyxfsb69w 1CYKIQZFs09AiRP505YGGZeE05owfc2xKsvKtyvZjx+1MYZyeB9OxQ6eQ+HWPGsHaWj20YJWPJgP r9Fn/yKfky6W2HdvbcQuU+oCqMHUrvO70UvXV8Ih1DwKZW5kc3RyZWFtCmVuZG9iagozOAowCm9i agoxMDExCmVuZG9iagozOQowCm9iagpbCl0KZW5kb2JqCjQwCjAKb2JqCjw8Ci9UeXBlCi9QYWdl Ci9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAKXQovQ29udGVudHMKNDEKMApS Ci9SZXNvdXJjZXMKNDIKMApSCi9Bbm5vdHMKNDQKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJl bmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iago0MQowCm9iago8PAovRmlsdGVyCi9GbGF0 ZURlY29kZQovTGVuZ3RoCjQzCjAKUgo+PgpzdHJlYW0KeJy9Vm1PE0EQ3qTfVhMxGn+BASW47M3s 60dNhYJNoE3hhG9EBWIKWPT/x9m5lluOAxFaeunt7NzuvDzz7MtEFkrL9HyoBGs0td/O5ESSoIvo gtWGRzT7NCg1ZxKd9U7z9HHdAW8QkjCWjU56n8pSnpOTiVz/OP51eoTy5DfHMvtfnjzI+qk8XpUD eiaZcZ2MV2mSWdTglNNRggleW5WcOFvoqIz1tXKcK110EVlZz651mdNFGC9XGSoHOoAKJlT1Ah1D oJKElllUmvWts6OTHyC7FxzZXYAUYFxIsHuHQTnnEuoWIcI15bhWmlD4pAyknM3OdVeAMCRhxrFa YoLNOqlFUB6MKaRxCqL1xYyDhXXBgbckUpktJQ0kooVoCkjRfxqRidGlXN+4OP9jJHqF6QdydHyd 3DEFaVTAGKOTo4q9o+/ynShETxyKjlihdl/0xbYYUO+Z2BR7oiu2RCmWxCvxRjx/L0c/5efRXMNC qmIRNGJ7cDOX/0DzPvU1WPgUBuT1rZVZfQEsBkvarL657hH1LQpUCI7MTAuMJqZtBW4Rm1C6ZEq3 Fhcj+WjDbp5OCm0aXoQXQ6LLHpFnk8iT2g2iTIfeO9TvEZlK8YL6HSJXj74f8LtDNEvfekyykqnX EU4sizUi4mse/ZVsfCGppHeXbS5nNjsLyc+EZn5r5K1P/voUww7FcEjSDksp1+40xs3p4qlwaOZ6 SGN6vKzyDPucczm1U05ndpN2IblFaOaW47nEmQw58gFjPaR2MK1nn3sdjv3lvKMzYJXXSFvHzRgX gQRY/wReEG7g7TJWNPFOyCZOJDnyiP0r1NMWvU1yxcK6GvvUO5iunS5rLK1HnzNu3pkFjypqB7Yl v4Wg6FwTxSY6u7ySdhmZajW+JcRWeLXlq7C5R83mD6m3QbsN2Zx3Bl7TgW5bklgEVHSYPYWXeFsu jzikke4BMSis7oh0E4h899WBLkS5cpwp03UPFOuuZte6/z+kyYai5CJdTonYLnjzwEM6yHTK8+/m fSed0tEyvmgQtb9+2Dy4Ync5pUPNaYftPu9dvfT8BY1/YzsKZW5kc3RyZWFtCmVuZG9iago0Mwow Cm9iago4MDAKZW5kb2JqCjQ0CjAKb2JqClsKXQplbmRvYmoKMTEKMApvYmoKPDwKL0NBCjAKL2Nh CjAKPj4KZW5kb2JqCjEyCjAKb2JqCjw8Ci9TdWJ0eXBlCi9JbWFnZQovV2lkdGgKMTAyMQovSGVp Z2h0CjgwMQovQ29sb3JTcGFjZQovRGV2aWNlUkdCCi9CaXRzUGVyQ29tcG9uZW50CjgKL0ZpbHRl cgovRENURGVjb2RlCi9MZW5ndGgKMzM1MzUKL1NNYXNrCjQ1CjAKUgo+PgpzdHJlYW0K/9j/4AAQ SkZJRgABAgAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUf GhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAMhA/0DASIAAhEBAxEB /8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQID AAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RF RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdh cRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldY WVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPE xcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD5UooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKvWGl Xl8A0ER8skDzG4Xr19/wzW1a+Ffum6uf95Yx/In/AAqlCT2RLnFbs5eiu3g8N6fHneskuf774x+W Km/sHTM/8ev/AJEb/Gr9jIn2sTgqK7afw3YSPlBLEMY2o+R+uay7nwtOi5t50lIBJDDafYDr/Sk6 UkCqRZztFWLyzuLOQJcxNGT0zyD9D0PWq9Z7Gm4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFPijeWQJEjO56KoyT+FdLpvhj7sl+/v 5SH6dT+Y4/OqjFy2JlJR3MCxsbi+l2W0Zb1bsv1NdZpfh63tRvugtxL7j5V45GO/1PtwK2Yo0iQJ Eiog6KowB+FOrojSUdTCVRvYKKKK1MwooooAKKKKAGyxpLG0cqK6N1VhkGuc1Tw0rAyacdp7xO3B 47H1+vr2rpaKmUVLcqMnHY80ubea2lMdxG0bjsw6+49R71FXpN3Z294gW5iWQDpnqPoeo6Vy2q+H JoGL2O6aEAfKT84459M/hzz+Nc8qTWxtGonozn6KUjBwetJWRqFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFaGmaTc6g6lEKQ55lYcD6evTt+lNJvRCbS1Zn1ua V4euLpg90Ggh9CPmbnkAdvqf1rotL0a109lkQNJOBjzG+nOB2/nz1rSreNH+YxlV7FexsoLGER26 BRgbm7tjuT36mrFFFbJW2MgooopiCiiigAooooAKKKKACiiigAooooAz9T0m2v1YugSYjiVRyDx1 9enf9K5LVNGutPBdwJIM48xe3pkdv5c9a72is5U1IuNRxPL6K7XVfD9vdJutVS3mGTwPlbjgEdun Uep61yd9ZT2MpjuIyvOA2Plb6Hv1Fc8oOO5vGakVqKKKgsKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAoopyI0jhEUsxOAAMk0bgNqxZ2dxeSbLaJpCOuOg+p6DpW9pXhpiRJqJ2r1ESnk8/wAR 9Pp69RXS21vDbRCO3jWNB2Udfc+p961hSb1ZlKrbRGLpfhyGALJe4mlBztB+Qen1/HjnpW8oCqFU AKBgAdqWiumMVFWRi5N7hRRRTJCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKbJGkil ZUR0PVXUEH8DTqKBnMaj4YzuewkA6nypPxOAfyAz+JrmZY3icpKjI46qwwRXptVr+xt7+LZcpuxn aw4K/Q1jKinsaRqNbnnFFbmq+Hri1O+1DXER7AfMvPAx3+o9+lYdc7i1ozdNPYKKKKQwooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACirum6bc6hJtgTCjOZG4Ue2fX2rrtM0O1sdrMBNODkSMOnpgdv51cabkRKaic5 pmgXN6iyuRBCwyGYZJHPIH+OOveutsNOtbFcW8QDYwXPLH8fw6dKt0V0xpqJhKbkFFFFWQFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFZuqaNa6gWdgY5yP8A WL+mR3/nx1rSopNJ6MadndHAappNzp8jllZ4AfllA4I7Z9Ovf9azq9PdVdSrgMrDBBGQRWDqnhyG cNJZYhlJztJ+Q88/T8OOOlYTo9Ym0avRnHUVYvLO4s3CXMTRk9M9D9D0PWq9YGyd9gooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACinI rOwVAWYnAAGSTW/pfhuWdRJfFoU7IMbiMfp2/XpVRi5bCcktzEtrea6lEdvG0j+ijp2yfQc9a6nT PDUcLJLeuJXBz5aj5O/XPXt6fjW3a2sNpF5dtGsadcDv9T3qauiNJLcwlUb2ERVRQqKFVRgADAAp aKK1MgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAiubeG5iMdxGsiHswzj3HofeuZ1Pw06s0mnsHUn/VMcEfQ9+/X9a6uiplBS3Kj Jx2PMXVkdldSrKcEEYINNr0W/wBOtr9cXEYLYwHHDDr3/Hp0rk9S8P3VnG8qFZoVGWZeCBx1H49s 9M8VzSpOJvGonuY1FFFZmgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFXLDTrq/bFvESoOC54UdO/49OtNK+wm0tynWtpeh3N9h2BhgI/1jDr9B369eldBpnh+ 1tkV7lRPPjndyoPsO/4+natqto0esjKVXpEpadpdrp+Tbod5GC7nLEZ/z09Ku0UVuklojFu4UUUU xBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQBk6poVtfEuv7iY/wAajg89x371yWo6bc6fJtnTKnGJFyVPtn16 16HSOqupVwGVhggjIIrOdNSNI1GjzCiuu1Xw2ku+WxbY5yfKP3T7D07/AP1q5a5t5rWUx3EbRuOz Dr7j1HvXPKDjubxkpEVFFFQUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABUlvDJc TJFCheRzgAVt6d4buJwr3beRH/d6uenbt3688dK6qzs7ezjKW0Sxg9cdT9T1PWtY0m9zOVVLYwNL 8NAYk1Bs/wDTJT/M/wCH510kUaRIEiRUQdFUYA/CnUV0Rio7GDk5bhRRRVEhRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAVDd2sF3F5VzGJEznB7H69qmopNXHschqvhuSBPMsWeZecoQNwGO vv34x6dawHVkdldSrKcEEYINenVS1PTLbUQv2hW3qNqupwQM5x/n1NYyo/ymsar2Z55RWrqWh3dl lgvnQjneg6DnqO3T6e9ZVYNOLszZNPVBRRRSGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFORSzBRjJOOTgf ma7HSvD0FttkuitxLj7pHyD8O/f/AAqowctiZSUUc9pekXOoNlB5cPUyODg8449T1/Kut0vSLbTw GQeZP3kYc9Mceg61pHnrSV0wpqJhKo5BRRRWhmFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAVLbW811OkNtE8srnCoi5J/Cut8M+AtR1XZNe5srQ85cfOw9l7fU/rXq uhaDp2hweXp8AViPmlbl2+p/p0rWFJy3OStjIU9FqzgvDPw3d9k+vPsXr9mjPJ/3m7fQfnXc3nhr R7rTlspLGFYEHybF2snuCOc/z71sUV0RpxSseXUxFSo7tnjnib4fX2nb59MLXtqOdoH7xR9O/wCH 5VxBBUkMCCOCDX01XO+JfCGma6Gklj8i7PSeIYJ/3h/F/P3rKdHrE66OPa0qfeeDUV0PiTwlqegs zzx+da54niGV/H0/GuerBprRnpRnGavF3CiiikUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABWLqfh+1uUZrZRBPjjbwpPuO34evetqik4qW402tjzu/026sSftETBM4Eg5U 9cc/geOtU69OljSVCkqK6HqrDINc3qnhkEmTT2C8f6pj/I/lwfzrnnSa1RvGrfc5WipJ4ZLeZ4pk KSKcFTUdYmu4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABVm0vrm0P+jTvGM52g/KT9OlVqKE7bAdbp3ieKTC3yeU39 9ASvft1Hb1/CuhikSVA8Tq6HoynIP415jVyw1G6sWzbykLnJQ8qfw/Dr1raNZr4jKVLseiUVjaZ4 gtboKk5EE2Od33Seeh/x9e9bNdCaeqMGmtwooopiCiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKuaXpl5qtyLfT7d55D1CjhfcnoB9a9P8M/Dq2tNk+tMt1N1EK/6tfr3b+X1qowctjGrX hSXvM4Dw74Y1LXpB9kh224OGnk4Qf4n2Fer+GfBem6JtlZftV4OfOlH3T/sjt/P3rpo0SKNUjVUR RhVUYAHoBTq6YUlE8qti51dFogooorU5QooooAKKKKAEZQylWAKkYIPeuG8TfDyyv90+lFbO5POz H7tj9P4fw/Ku6oqZRUty6dWVN3iz501jR77R7nydQt3ib+Fjyre4PQ1n19J31nbX9s1veQxzQt1R xkV5r4m+G7pvn0F969TbSHkf7rd/ofzrnnRa2PUo46M9J6M82oqW5gmtZnhuYnilQ4ZHUgj8DUVY ncFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBDdWlvdoFuoUlUdN 3UdOhHI6DpXJap4dntgZLUm4jz90D5xz6d+3P6V2dFRKCluXGTjseX0V3+q6RbagpLDy5uokUDJ4 xz6jpXJarpFzp7EsPMh7SIDgc459D0rnlTcTeNRMzaKKKzLCiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKcis7BUBZmOAAMkmgBtPijeVwkSM7noqjJNdNpvh jGH1B/fykP06n8+n510VtbxWsQit41jQdgOvufU1tGi3qzKVVLY4eDQ9RmCsLcqrHq5C4+oPP6Vb /wCEXvc/622/76b/AArsqK0VGJDqs43/AIRe9/5623/fTf4VRm0bUIVDPauQTj5MMfyGa9AoodGI Kqzy+ivSLuytbsYuYEk4xkjBxnOMjkVy+qeG5YB5lkWnTuhxuAx+v/6utZSpNbGkaqe5z9FOZWRi rgqwOCCMEGm1kaBWrpet3NiQjEzQAY8tj0+h7fTpWVRTTa1Qmk1Znoenapa6gG+zuQ68lHGGAz1/ /V61drzFGZGDISrA5BBwQa39L8SSQgR3ytMg6Ov3hx+vb/69dEKqfxGMqXY6+io7a4iuYhLbyLIh 7qf0PoeelSVsYhRRRQAUUUUAFFFFABRRRQAUUUUAFFFdX4Z8EalrWyaVfslmefNkHLD/AGV7/XgU 0m9ETOcYK8nY5eKKSaVY4UaSRjhVUZJPsK9A8M/Dm4udk+uObeLqIEPzt9T0X+f0rv8Aw94a03QY 8WUOZiMNPJy7fj2+grZrohRS1keZWxzlpT0Kmm6daaZbC3sLeOCIdlHX3J6k+5q3RRW+x57bbuwo oooAKKKKACiiigAooooAKKKKACiiigDK17QNO1yDy7+AM4GFlXh0+h/p0ryrxN4C1HSt81mDe2g5 yg+dR7r3+o/SvaqKznTUjejiZ0ttj5kor3PxN4K03W98qr9lvD/y2jHDH/aXv/P3ryfxF4Y1LQZD 9sh3QE4WePlD/gfY1zTpuJ61HFQq6LRmJRRRUHQFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQBh6r4eguiZbUrBLgDaFAQ4HoOnbn9K5O7s7izk2XMTRk9M9D9D0PWvS KZPDHcQvFMgeNxgg1lKknsaRqOOh5lRXT6p4awDJpxLHP+qYj17H8uv51zcsbxOUlRkcdVYYIrnl Fx3N4yUthlFFFSUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGhaa xf2uAlw7IMDbJ8wwOgGeg+mK6LTfElvPtS7HkSdN3VCePy/H8642irjUlEhwTPT0ZXRWRgysMgg5 BFLXAaZq1zYOoRy8IPMTHjHPT069v1rrdL1m11AiNCY5yM+W3fjnB7/z46V0RqKRjKDiaVFFFaGY UUUUAUdR0q0v+Zo8Sf8APROG/wDr/jXI6lol3ZZbb5sI53pzgc9R24H0967yionTUjSM3E8vortt T8P2tyjNbKIJscbeFJ9x2/D171ymoWFxYSbLlMA/dYcq30P+TXNKnKJtGakVKKKKgsltria2lElv I0bjup6+x9R7V1WmeJY5nSK9QROTjzFPyfjnp29fwrkKKqM3HYmUFLc9PRldFZGDKwyCDkEUteea dqVzp7k27/KeqNyp/Cu20m/GoW3m+TJEc9GBIPPUNjmumFRS0OecHEu0UUVoQFFFFABRRVnT7G61 G5W3sYJJ5m6Kgz+J9B70A3bVlatfQfD2o67NssICYwcNK/CL9T/Qc13vhn4bxRbLjXXEr9Rbxn5R /vHv9B+teh28MVvCsVvGkUSDCoigAD2FbQot6yOCtjox0p6s5Twz4E07SNk10Be3g53uPkU/7K/1 P6V19FFdKio6I8ydSVR3k7hRRRTICiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKbJGk sbJKiujDDKwyCPcU6igDz/xN8Oba63z6Ky2s3Uwt/q2+n93+X0rzDVNNvNLuTBqFu8Eo6BhwfcHo R9K+j6qanp1pqds1vf26TxHsw6e4PY+4rGdFPY7aONlDSeqPm+ivQvE3w5uLbfPojm4h6mBz86/Q 9G/n9a4CWN4ZGjlRkkU4ZWGCD7iueUXHc9SnVhVV4sZRRRUmgUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFVL/T7a/TbcRgsBw44Yfj+PTpVuijyHexxWpeHrq3ctbKbiIng KMuOnUd+vb07ViV6hWZqOiWd7ucoYpjk74+MnnqOh5OT396wlR/lNY1e5wVFXtR0u608/v0BQnAk XlT/AJ96o1g01ubp3CiiikAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFORWd1VFLMxwABkk10ul+GiQJNQ Yrz/AKpT/M/n0/OqjFy2JlJR3OYrQg0fUJt2y1kG3rv+T+eM13NpZ29nHstoUjHfA5P1PU9anrZU e7MnW7I4iHw3qEgO9Y4sf33zn8s0T+HNQjZQiRygjOUcDHtzj/Jrt6Kr2URe1kedXWn3drv8+3kV UxlsZUfiOKqV6hVLUdLtdQO64T97/wA9F4bsOvfgAc1DodmUqvdHnlFbWo+Hru1JaAfaIvVB8w6d v8M1i1jKLi7M1TT2CiiikM3NK8Q3FqQl0Wnhz1J+defXv9D+ldZY3sF9CJLdw3HK5+ZfYjt0rzen xSPFIHidkcdGU4I/GtY1WtzOVNPY9Norl9N8T/dS/T281B9OSPzPH5V00UqTRiSJ1dD0ZTkGuiM1 LYwlFx3HUUUVRIU2WNJUKSoroeqsMg06igZzOqeGQSZNPYLx/qmP8j+XB/OuZnhkt5nimQpIpwQa 9MqC7s7e7ULdQpKoORnII/EcjpWMqKexpGq1uebVYs7O4vH2W0TSEdSOg+p6DpXTQeF4VuXaaZ5I OqKODnPQn0x6Y69sc7ttbw2sQjt41jQdlHX3PqaiNFvcuVVLYxtL8OQQYe9Inl/uj7g5/X8eOelb 1FFdCilsYtt6sKKKKZIU5FZ2CopZicAAZJNdH4Z8HalrpWRU+z2Z6zyjAI/2R/F/L3r1fw34V03Q VDW0Xm3OOZ5OW/D0H0rSFNyOati4UtN2ef8Ahn4d3l9sn1dms7c8+WP9a3/xP48+1eo6RpNjpFsI NPt0hTuQOWPqT1NXqK6YwUdjya2InV+J6BRRRVmIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAVjeIfDWm69Hi9hxMBhZ4+HX8e/0NbNFJpPRjjJxd4s8P8TeC NS0XfNEv2uzHPmxjlR/tL2+vIrlK+m65DxN4E07V981qBZ3h53oPkY/7S/1H61hOj1ielRx/Sp95 4nRWtr3h7UdDm2X8BCE4WVeUb6H+h5rJrnatuejGSkroKKKKBhRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAjKrqVcBlYYIIyCKwNU8NxTtvsSsDnqjZ2nnr7f/q6V0FFTKKl uUpOOx5td2s1nMYrmMo+M4POR9agr0u5t4bmIx3EayIezDp7j0PvXLar4bkhBksS0yckxnG5Rjt6 9+OvTrXPOk1qjaNRPc52iiisjUKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAqSCGS4mSKFC8jnAAqOu78P6Wun2waRR9qcf Oc5wP7o/r7/hVwhzMicuVEmkaTDpqtsYyyt1kK4OPQDnFaNFFdaSSsjmbb3CiiimIKKKKACiiigA rM1LRLS9DNs8qY8+YnGTz1HQ8n6+9adFJpPRjTa2PPtS0q608gzoDGeBIhypP9PxqhXp7KGUqwDK wwQRkEelYGqeG4p2MliywueqH7p5/Tv+nSsJ0bfCbxq9zj6Knu7WazmMVzGUfGcHnI+tQVgap32C ren39xYSM9s+3dgMCMhgDn/J69aqUU07aoTSe52uleIbe6Gy6K28vuflbjk57fQ+3WtuvL609L1m 608CNCJIAc+W3b1we38uelbQrdJGUqXVHe0VT0vUItRtvNiVlI4ZSDwfTPQ//q6VcrdO+qMWraMK KKKYgooooAKKmtLWe8uFgtIZJpm6Ii5Jr0jwz8N/uXGvP7i2jb/0Jv6D86qMHLYyq1oUleTOD0TR NQ1q48rT7dpMH5nPCJ9TXqnhn4f2GmbJ9RK3t0OcMP3an2Hf6n8q6+0tYLO3SC1hSGFeFRFwBU1d MKSjueXWxk6mkdEAAAAAwBRRRWpxhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU0SIzsiu pdcblB5GemaAHUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEc8MVxC8U8aSxOMMjjII9 xXnnib4cRS77jQnET9TbyH5T/unt9D+lej0VMoKW5pTrTpO8WfNt/Y3Wn3LQXsEkEy9VcY/Eeo96 rV9G6vpNjq9t5GoW6TJ2J6r7g9RXl3ib4eXljvn0hmvLccmM/wCtX/4r8OfauadJx1R6tHGwnpLR nB0U51ZGKuCrA4IIwQabWR2BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAYmu6JHeRmW1VY7kZOAMCT6+/v+ftxjqyOyupVlOCCMEGvTq5rxZphkBvoQzOMCUdeAMA/h gD/JrCpT6o2pz6M5Siiiuc3CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigDe8K6d9puTcyqfJhPynsX/rjr+IrsqzfDlsLbSYOBukH mMQeuen6YrSrspq0Tlm7sKKKKsgKKKKACiiigAooooAKKKKACiiigCK5t4bqIx3EayIexHT3Hoa5 jVvDbo0k1gQ0eS3k85UegPfv15+tdZRUygpblRk47HmLKyMVcFWBwQRgg02vRNR0221CPbOmH4xI uAw9s+nXisODwric+fc7oR02DDHj34HP1/CueVKSehuqqe5zltby3Mojt42kc9lHT3PoK6nTPDUc LLJeuJXBz5a/d/H17en41vW1vFbRCK3jWNB2UfqfU8dakrSNJLczlUb2ERVRFVFCqowABgAUtFFb GQUUVv8AhzwpqevMGtovKts4M8nC/h6n6U0m9EKUlBXkzBAJIAGSa7Xwz8P7/U9k+o7rK1POGH7x h7Dt9T+VegeGvB2maGFkVPtF4P8AlvKMkH/ZH8P8/eulreFHrI82tj29Kf3mbomiafotv5Wn26x5 +855d/qa0qKK3Stsec5OTuwooopiCiiigAooooAKKKKACiiigAooooAKKKKACiimyyJFG0krqiKM szHAA9zQA6qmp6jaaZbNcX9wkEQ7sevsB3PsK4rxN8Rra13waKouZuhmb/Vr9P738vrXmGqaleap cm4v7h55T3Y8D2A6AfSsZ1ktjto4KU9Z6I7bxN8Rri53waIhtoehnf77fQdF/n9K4i11K9tL77Zb 3UyXWcmUMSx+vr+NVKK55ScndnqQowprlij1Twz8R4pdlvrqCJ+guIx8p/3h2+o/SvQ7eaK4hSW3 kSWJxlXRsgj2NfNFa+g+IdR0ObfYTkRk5aJ+Ub6j+o5rSFZrSRyVsDGWtPRn0JRXIeGfHenavshu iLK8PGxz8jH/AGW/of1rr66VJS1R5k6cqbtJWCiiimQFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFAGB4k8KaZrylriLyrrGBPHw34+v415P4l8HanoRaR0+0Wg/5bxDgD/aH8P8vevd6CAQQRkGs5 01I6aOKnS03R8yUV7N4m+H9hqe+fTttldHnCj92x9x2+o/KvK9b0TUNFuPK1C3aPP3XHKP8AQ1zS puO56tHEQq7bmbRRRUG4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUjqroyuA ysMEEZBFLRQB51qtm1jfSwHO0HKE91PT/Prmqldd4ytS9tDcquTGdrEL2PTJ9Af51yNcc48rsdcJ cyuFFFFQUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAVJbxNPPHEhAaRgoJ6ZJxUdWtL/5Cdn/12T/0IU1uDPRVVUUKihVAwABgAUtFFdxxBRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFSW8MtxMsVvG8srnCoikkn2FAEdXtI0m+1e 58jT7d5n7kcBR6k9BXc+GfhxLLsuNdcxJ1FvGfmP+8e30H6V6XYWNrp9stvZQRwQr0VBj8fc+9bQ ot6s4a2NjDSGrOM8M/Duzsdk+rst5cDkRj/Vr/8AFfjx7V3aKqIFRQqgYAAwAKWiuiMVHY8upVlU d5MKKKKogKKKKACiiigAooooAKKKKACiiigAooooAKKKKACisrXtf07Q4d9/OFcjKxLy7/Qf16V5 V4m8eajq2+GzJsrM8YQ/Ow92/oP1rOdRRN6OGnV22PQfE3jXTdE3xI32u8HHkxnhT/tN2/nXlHiH xNqWvSH7ZNtgzlYI+EH4dz7msSiuadRyPWo4WFLVasKKKKg6AooooAKKKKACur8M+N9S0XZDK32u zHHlSHlR/st2+nIrlKKabWqJnCM1aSufQXh7xLpuvR5spsTAZaCTh1/Dv9RWzXzPFI8MiyQu0cin KspwQfY13/hn4jXFtsg1tDcQ9BOg/eL9R0b+f1rohWT0keZWwLjrT1PWaKqabqNpqdstxYXCTxHu p6exHUH2NW633PPaadmFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABUN3awXlu0F3DHNC3VHX INTUUAnY8x8TfDf79xoL+5tpG/8AQW/ofzrzi7tZ7O4eC6heGZeGR1wRX0rWbreiafrVv5WoW6yY +644dfoawnRT1id9HHSjpPVHztRXa+JvAF/pm+fTt17ajnCj94o9x3+o/KuLIwcHg1zuLjoz06dS NRXixKKKKRYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFLW4lm0i7VyQBGW49RyP1Fe eV6dIiSxtHIu5GBVlOeQe3FeY1z11qmb0XugooorA2CiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKtaV/yFLP8A67J/6EKq1a0r/kKWf/XZP/Qh TW4nsejUUUV3HGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRW14e8Nalr0mLKHEIOGnk4Rf x7n2Fer+GfBGm6LsmlX7XeDnzZBwp/2V7fXk1cKbkc9bEwpaPVnnvhnwJqOr7JroGyszzvkHzsP9 lf6n9a9W0Dw9p2hQ7LCACQjDSty7fU/0HFa1FdMKaieVWxM6u+wUUUVoc4UUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFIzBVLMQFAySe1cN4m+IdlYb4NJC3lyOPMz+6U/X+L8OPeplJR3Lp0pV HaKOyvry2sLZri8njhhXqznArzXxN8SHk32+goY16G5kHzH/AHV7fU/kK4bWNXvtYufO1C4eVv4V PCr7AdBWfXPOs3sepRwMYaz1ZLczzXMzzXMryyucs7sST+JqKiisTuCiioLy8t7OMPcyrGD0z1P0 HU9aTdhpXJ6KwLbxPbSTMs8bwpn5X+9xz1A6duma3Y3SRA8bq6HoynIP40oyUthuLW46iiiqJCii igAooooAKKKKALml6leaXci40+4eCUd1PB9iOhH1r0/wz8Rra62Qa0otpugmX/Vt9f7v8vpXklFV GbjsY1aEKq95H0zHIksavGyujDKspyCPY06vn/w74n1LQZB9jm3QE5aCTlD+HY+4r1jwz4103W9k TN9lvDx5Mh4Y/wCy3f8An7V0wqqR5VbCTparVHUUUUVqcoUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFc14l8HaZrgaRk+zXh/5bxDBJ/wBod/5+9dLRSaT0ZUJyg7xdjwPxH4V1PQWLXMXmW2cC ePlfx9D9awK+mnVXQq6hlIwQRkEVwnib4d2d7vn0hltLg8+Uf9Ux/wDZfw49q550baxPSo45PSp9 55BRV7VtKvdIuTBqFu8L9ieje4PQ1RrDY9FNNXQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA KOory6vUR1FeXVz190b0eoUUUVgbBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFWtK/5Cln/wBdk/8AQhVWrWlf8hSz/wCuyf8AoQprcT2PRqKK K7jjCiiigAooooAKKKKACiiigAooooAKKK1fC9hFqmv2VncFxDM+G2HBxgn+lCVxSaim2VdN0671 O5FvYW8k8p7KOnuT0A9zXpvhn4c29vsn1txcS9RAh+Rfqep/l9a7fS9Ms9KthBp9ukEY6hRyT6k9 SfrVyuqFFLc8itjZT0hohkUaQxrHEipGowqqMAD2FPoorY4gooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKzta1qw0a387ULhYgfup1ZvoOppN23Gk5OyNGuc8S+L9M0INHLJ592OkERyR/vHoP 5+1efeJviDfajvg0wNZWp43A/vGH17fh+dcSSSSSSSeSTWE63SJ6FHAN61PuOg8SeLdT15mSeTyb XPEEXC/j6/jXPUUVg23qz0owjBWirBRRRSKCmyyJFGXldUQdWY4Ap1Yuv6VPfRlobmQlRkQMfkJH THoeTyc9ewqZNpaFRSb1KuqeJUVdmnfM5yDI68AY4wPX6jt3zXL3E0lxM0s7l5GOSTS3NvNbSmO4 jaNx2YdfceoqKuWU5Pc6YxUVoFW7DUbmwfNvIQpOSh5U/h+HXrVSioTtsU1c7nTNftb1kjcNDOxw FbkE89D+XXHWtevL61tL1y6scIxM0IGNjnp9D2+nSt4VukjGVL+U7qiqenajbagha3f5hnMbcMB6 49ORz71crdNPVGIUUUUxBRRRQAUUUUAFFFFAHY+GfHmo6TshvCb2zHGHPzqPZv6H9K9V0LX9O1yD fYThmAy0TcOn1H9elfPNS21xNazpNbSvFKhyro2CPxrWFVx3OStg4VNVoz6Wory3wz8SHTZb68hd en2mMcj/AHl7/UflXpVjeW1/bLcWc8c0LdGQ5FdEZqWx5VWhOk/eRYoooqzIKKKKACiiigAooooA KKKKACiiigAooooAKKKKAK2oWNrqNs1vfQRzwt1Vxn8R6H3rzTxN8OJYt9xoTmVOpt5D8w/3T3+h /WvVKKiUFLc1pV50n7rPmieGW3meKeN4pUOGRxgg+4qOvoTxB4f07XICt9ADIo+WVeHX6H+h4r57 rlnDkZ7GHxCrJ6WaCiiioOgKKKKACiiigAooooAKKKKACiiigBR1FeXV6iOory6uevujej1Ciiis DYKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig Aq1pX/IUs/8Arsn/AKEKq1a0r/kKWf8A12T/ANCFNbiex6NRRRXccYUUUUAFFFFABRRRQAUUUUAF FFFABXQeAv8AkcNM/wCuh/8AQTXP10HgL/kcNM/66H/0E047oir8EvRnvdFFFd586FFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFB4HNABUV1cw2kDzXUqQwoMs7tgCuR8TePtP0vfBYYvbscfKf3an3 bv8AQfpXleua7qGtz+ZqFwzgH5YxwifQf161lOqo7HXRwc6mstEd54m+JAXfBoKbj0NzIOP+Ar/U /lXm17d3F9cNPeTSTTN1d2yagormlNy3PVpUYUlaKCiiipNQoqO4nit4jJPIsaDuxxngnA9TweKy bXxHZTylH3w5Pys44PTrjpzn2461LkluNJvY2qKKKoQUUUUAQ3drDeQ+VcxiRM5weOfrXLar4bkg TzLFnmXnKEDcBjqPXvxj06119FRKCluVGTjseYMpVirAhgcEEYINJXoOoaTaX+TNHtk/56Jw3b8+ neuT1HQ7yz3MEM0Iyd8YzgDJyR1HAz6e9c8qbibxqJmVRRRWZoORmR1ZGKspyCDgg10GmeJZIVWO 9QyoBjzF+/8Ajnr29PxrnaKqMnHYmUVLc9LtriG5iElvIsiHup6ex9D7VLXmtrczWsokt5Gjf1Hf 2PqK6rSvEcU7CO+CwueA4+6Tn9O3t16V0Rqp7mMqbWqOgopEZXUMhDKRkEHIIpa1MgooooAKKKKA CiiigArQ0fWL7R7nztPuHib+JRyrexHQ1n0UJ2BpNWZ7D4Z+IVlf7INVC2dyeN+f3TH6/wAP4/nX cqwZQykFSMgjvXzLXQ+G/Fup6CypDJ51pnmCU5X8PT8K3hW6SPOrYBPWn9x71RXO+GvF+ma6Fjik 8i77wSnBP+6f4v5+1dFXQmnqjzZwlB2krBRRRTJCiiigAooooAKKKKACiiigAooooAKKKKAEf7jf SvmWvpp/uN9K+Za56/Q9PLvtfL9QooornPSCiiigAooooAKKKKACiiigAooooAUdRXl1eojqK8ur nr7o3o9QooorA2CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKtaV/yFLP8A67J/6EKq1a0r/kKWf/XZP/QhTW4nsejUUUV3HGFFFFABRRRQAUUU UAFFFFABRRRQAV0HgL/kcNM/66H/ANBNc/XQeAv+Rw0z/rof/QTTjuiKvwS9Ge90UUV3nzoUUUUA FFFFABRRRQAUUUUAFFFFABRVLVdUstJtjPqFwkMfbceWPoB1J+leX+JviJd3m+DRla0gPHmn/WN9 P7v8/eolNR3NqWHnV+FaHoHiPxTpugoRdS+Zc4ysEfLn6+g+teUeJfGep65ui3/ZrM/8sYj1H+0e p/l7VzUjtI7PIzM7HJZjkk02uadVyPVo4SFLXdhRRRWZ1BRRRQAjsqKWchVUZJJwAK57U/EscLNH ZIJXBx5jfd7dPXv6fjT/ABHpd5esHt5i8Yx+4Jxg+o7dz1/+tXIzRSQyFJkeNxjKsMEZGRxWFSbT sjaEIvcdc3E1zKZLiRpHPdj09h6D2qKiiuc3NHTNWubB1COXhB5iY8Ee3p17frXW6XrNrf4RT5c/ /PNu/wBD3/nx0rgaK0hUcSJQUj1CiuN0vxFPbAR3YNxHn7xb5xz69+/H611NjewX0Ikt3DcZK5+Z fYjtXRGakYSg47lmiiirICiiigDE1Tw/b3QL2wW3m/2R8rcccdvqP1rlNQsLiwlCXKbc52sDkNj0 r0amyxxyoUlRXQ9VYZBrKdJS2NI1GtzzGiuq1TwyCWk09gvH+qY/yP5dfzrmrmCS2neGdSkiHDD/ AD1rnlBx3N4zUtiKiiipKL2m6pc6eT5DAoTkowypP+fSut0vXLa+CqxEM5OPLY9fTB79enWuEoq4 1HEiUFI9QoridK1+4sykc5M1uMDB+8o9j/j6dq6ux1G1vlzbygtjJQ8MOnb8evSumNRS2MJQcS3R RRVkBRRRQAUUUUAFFFFACglSCpII5BFdv4Z+IN9p2yDUw17ajjcT+8UfX+L8fzrh6KcZOOqIqU41 FaSPorRdZsNZt/O0+4WUD7y9GX6jqK0a+a7K7uLG4WezmkhmXo6Ng16T4Z+JCtst9eTaen2mMcf8 CUfzH5V0wrJ6M8utgZR1hqj0uiorW4hu4EntpUlhcZV0bINS1scOwUUUUAFFFFABRRRQAUUUUAFF FFACP9xvpXzLX00/3G+lfMtc9foenl32vl+oUUUVznpBRRRQAUUUUAFFFFABRRRQAUUUUAKOory6 vUR1FeXVz190b0eoUUUVgbBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFWtK/5Cln/12T/0IVVq1pX/ACFLP/rsn/oQprcT2PRqKKK7jjCiiigA ooooAKKKKACiiigAooooAK6DwF/yOGmf9dD/AOgmufroPAX/ACOGmf8AXQ/+gmnHdEVfgl6M97oo orvPnQooooAKKKKACiiigAooooAZNLHBE0s8iRxoMs7nAA9zXnvib4jwwb7fQ0E8nQ3Dj5B9B3/l 9a7jVtMtNWs2tb+ESxHnHQg+oPY15Z4m+Hl5Yb59JLXlsOfL/wCWqj6fxfhz7VlUckvdOvCxot/v Hr+Bx2o391qVy1xfTyTzH+Jz09h6D2FVaVlKsVYEMDgg9QaSuQ9pJJWQUUUUAFFFFABRRRQAVUv9 Otb5cXEQLYwHHDDr3/Hp0q3RSavoxp2OJ1bQJ7QyS24MtsCSMHLKPcd/qPTPFYteoVlapoltfBnU CGcnPmKOvPOR369etYzo/wAprGr0ZwlFXtS0u608gzoChOA6nKk4/wA9fSqNYNNbmyaeqCnxSPFI HidkcdGU4I/GmUUhnU6b4m6R6gmO3moPp1H5nj8q6WKRJoxJE6ujdGU5BrzGren39xYS77Z8ZxuU jIYDsf8AOa2jWa0ZlKknqj0WisTSvENvdDZdFbeX3Pytx1z2+h9utbddCkpaoxaa0YUUUUyQqvfW UF9CY7hA3BAb+JfcHtViik1cadjjNU8Oz2waS1Jniz90D5xz6d+3+FYVeoVnappFtqA3OPLm7SIB k8YGfUdKxnR6xNY1e5wFFaOp6RdaezF0Lw54lUcfj6de9Z1YNNOzNk77BT4pHhkDxOyOOjKcEfjT KKQzptK8SsG8vUfmU9JVXkc9x6fT07108E0dxCksLh42GQwrzKrFneXFm5a2maMnqB0P1HQ9TWsa rW5lKknsekUVg6b4kt5wqXY8iXpu6oenft368e9b1dEZKWxi01uFFFFUSFFFFABRRRQAUUUUAamh 67qGiT+Zp85QE5aM8o/1H9eteqeGfH2n6psgv8WV2ePmP7tz7N2+h/WvHbS2nvLhILWJ5pnOFRBk mvR/DPw3J2T68+O4to2/9CYfyH51rTcr6HHio0bXno/xPTuvSio7eCK2gjhgRY4o1CqqjgAVJXWe MFFFFABRRRQAUUUUAFFFFACP9xvpXzLX00/3G+lfMtc9foenl32vl+oUUUVznpBRRRQAUUUUAFFF FABRRRQAUUUUAKOory6vUR1FeXVz190b0eoUUUVgbBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFWtK/wCQpZ/9dk/9CFVataV/yFLP/rsn/oQp rcT2PRqKKK7jjCiiigAooooAKKKKACiiigAooooAK6DwF/yOGmf9dD/6Ca5+ug8Bf8jhpn/XQ/8A oJpx3RFX4JejPe6KKK7z50KKKKACiiigAooooAKKKKACiiigDn/EnhPTNeUvPF5V1jieLhvx9fxr yjxL4P1PQi0kifaLQdJ4hwP94dv5e9e70hAIIIyD1BrOdNSOmjip0tN0fMtFeyeJvh/Y6lvn0zbZ XR52gfu2PuO34flXlutaLf6LceTqFu0ZP3X6q/0PeuaUHHc9WjiIVdtzNoooqDcKKKKACiiigAoo ooAR1V1KuoZSMEEZBFYOreHIrhvMsdkD90OdrHPX2+gGOnSt+iplFS3KTad0ea3VtNaymO4jaN/Q jr7j1FQ16Xc28NzEY7iNZEPZh09x6H3rltT8NSQo0tk5lQDJjYfN+GOvf0/GuedJrVG0aqe5ztFO dWR2V1KspwQRgg02sjUK09L1q6sMICJYB/yzftz2Pb+XPSsyimm1sJpPc9C0/VrS+AEMuJD/AMs3 4bv+fTPGavV5ijMjBkJVlOQQcEGt7S/Ec0BCXuZogPvAfOPT6/jzz1reNb+YxlSa2OwoqC0u4LyP fbSrIvfHUfUdRU9bmQUUUUCCsHUvDdvPue0PkSHnb1Qnnt27dOPat6iplFS3Gm1seb3lncWbhbmJ oyehPQ/Q9D1FV69NniSeB4ZV3RuMMp7iuY1Tw0ykyacdw7xOeevY/wCPp3rCVFrY3jUvuczRT5Y3 icpKjI46qwwRTKxNQrR0zVrnT2ARy8PeJjx+Hp1rOopptaoTSe53+lavbaiAqHZN3jY8njJx6jr+ XatGvL63dL8RT2wEd0DcRZ+8T84/Hv3/AMa3hW6SMZUux2dFV7G9gvoRJbyBuMlc/MvsR26VYrZO 5lsFFFFMQV2XhTwJeawkd1duLWxfkHq7j2Hb6n8jXG1seH/EWpaFLusZz5ROWhflG/D+o5qo2v7x nVU3H929T3HRND0/RLfytPt1jJHzSHl3+p/yK0q5Lwz4503WNkNwRZ3h42SH5WP+y39DzXW12Raa 908KrGcZe/uFFFFUZhRRRQAUUUUAFFFFABRRRQAj/cb6V8y19NP9xvpXzLXPX6Hp5d9r5fqFFFFc 56QUUUUAFFFFABRRRQAUUUUAFFFFACjqK8ur1EdRXl1c9fdG9HqFFFFYGwUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABVrSv+QpZ/8AXZP/AEIV Vq1pX/IUs/8Arsn/AKEKa3E9j0aiiiu44wooooAKKKKACiiigAooooAKKKKACug8Bf8AI4aZ/wBd D/6Ca5+ug8Bf8jhpn/XQ/wDoJpx3RFX4JejPe6KKK7z50KKKKACiiigAooooAKKKKACiiigAoooo AKhvLWC9t3gu4UmhbqjjINTUUAnY8w8TfDcjfPoL5HU20jf+gt/Q/nXnN3bT2lw8F1E8MyHDI4wR X0rWZrmh6frdv5WoW6uQPlkHDp9D/kVhOinrE76OOlHSeqPneiu08TeANQ0zfNp+69tBz8o/eKPd e/1H5CuMIwcHrXO4uOjPThUjUV4sSiiikWFFFFABRRRQAUUUUAU9R0621CLbOgDcYkUAOMds+nJ4 rkdU0O6sSWUGaADPmKOnrkdunXpXdUVEqakXGbieX0V3Op6BbXrtKhMM7HJZeQT7j/DHWuRv9Our FsXERC5wHHKn8fw6da5pU3E3jNSKlFFFQWS21xLbSiSCRo3HcH/ORXT6Z4mjZFjv1KOBjzVGQevJ Hbt0z+FcnRVRm47Eyipbnp6MrorIQysMgjoRS151Yajc2D5t5SFzkoeVP4fh1611+la5b35EbfuZ z0VjwxzjCnv24966I1VLQwlTcdTWooorUzCiiigCpf6da364uIgWxgOOGHXv+PTpXK6l4eureQm1 RriIn5QnLjpjI79e3p2rtaKiVNSLjNx2PL6K7vVNDtb7LKBBOTnzFHXnnI7/AF61yepaVdadgzqD GxwHU5BOM/Ufj6GuaVNxN4zUihRRRUFj4ZZIZBJC7I46MpwRXT6X4lBIj1EBf+myj+YH48j8q5Wi qjNx2JlFS3PTo5ElQPE6uh6MpyD+NOrznT7+4sJS9s+3ONykZDD3rq9L8Q290uy6K283uflbjrnt 9D7da6I1U9zCVNrY26KKK1MwrrPDPjjUtG2wzk3lmOPLkb5lH+y39DkVydFNNrVEzpxqK0lc+g/D /iPTddizYzjzQMtC/Dr+Hf6itivmiGWSCVZYJHjkQ5V0OCD7GvQPDPxHnt9kGuIZ4uguEHzj6jof 5/WuiFZPSR5lbAuOtPU9Xoqrp2oWmpWy3FjPHPEf4kPT2I7H2NWq3PPaadmFFFFABRRRQAUUUUAI /wBxvpXzLX00/wBxvpXzLXPX6Hp5d9r5fqFFFFc56QUUUUAFFFFABRRRQAUUUUAFFFFACjqK8ur1 EdRXl1c9fdG9HqFFFFYGwUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABVrSv+QpZ/wDXZP8A0IVVq1pX/IUs/wDrsn/oQprcT2PRqKKK7jjCiiig AooooAKKKKACiiigAooooAK2vBlzDaeKNOnuZFihST5nY4A4I5rFooTs7ilHmTXc+mY3SRFeNldG GQynIIp1eAeHfFGpaDIBaTb7fPzQScofp6H3FeseGfGmm62FiL/Zbw8eTKfvH/ZPf+ftXXCqpHi1 sJOlqtUdPRRRWpyhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVzPibwbpuuBpCn2a8P/AC3i HU/7Q7/z966aik0noyoTlB3i7HgXiPwrqeguTcxeZbZ4njGU/H0P1rBr6ZdFkRkdQyMMFSMgiuE8 TfDu0vd8+jstpcdfKP8Aq2+n93+XtXPOi1rE9Ojjk9Kmh5DRV7VtKvdJuTBqFu8MnbI4YeoPQ1Rr A9BNNXQUUUUAFFFFABRRRQAU2SNJUKSIroeqsMg06igDmtU8NKwMmnHae8TtweOx9fr69q5q5tpr WXy7iJ436gMOozjI9Rwea9KqC8s7e8QJcxLIB0z1H0PUdKxlST2NY1Wtzzaiug1Xw5LCTJY5lhAH yE5ccc9gD/Pn8awCMHB61g4uO5vGSkroSiiipGa+l67c2I2N+/h7K7HK8YwD2HSut07UrbUEzA+H 5zG2Aw98enTmvO6cjMjqyMVZTkEHBBrSFRx0M5U0z06iuT0rxI8eyK/G9OB5o+8B7jv2/wDr11Fv cQ3MYkt5FkQ91OccZwfQ89K6YzUtjCUXHckoooqiQpHVXUq6hlIwQRkEUtFAHP6t4cinPmWOyB+6 HO1jnr7fhx06Vyt1bTWspjuI2jf0I6+49RXpVRXNvDcxGO4jWRD2YdPceh96ylST2NYVGtGeaUV0 Wp+GpIUaWycyoBny2Hzfhjr39Pxrn3VkdldSrKcEEYINc8ouO5tGSlsNoooqSjT0vWrqwwikSQD/ AJZv2+h7fy56V12n6taX2BDJtkP/ACzfhu/59M8V59TkZkdWRirKcgg4INaRqyREqakenUVx2l+I 54CEvczRAY3D74/x/HnnrXV2l1Ddw+bbSCSPOMj1+nauiM1LY55RcdyaiiirJLulape6TcifT7h4 ZO+08MPQjoR9a9Q8M/EW1vNkGsqtrOePOX/Vt9f7v8q8ioqozcdjGrh4VfiWp9MxusiK8bBkYZDK cginV4D4d8UaloLgWku+3zloJOUP09D9K9X8M+M9N1wLEX+y3h/5Yyn7x/2T3/n7V0wqqR5VbCTp arVHT0UUVqcoUUjEKpZiABySe1cP4m+IVlp++DSgt7cjjeD+7U/X+L8PzqZSUdy6dKVR2ijsNQvL extJJ7yaOGFRyznAr5trQ1nWL7WbnztQuHlb+Feir7AdBWfXLUnzs9nC4f2Kd3qwooorM6QooooA KKKKACiiigAooooAKKKKAFHUV5dXqI6ivLq56+6N6PUKKKKwNgooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACrWlf8hSz/67J/6EKq1a0r/kKWf/ AF2T/wBCFNbiex6NRRRXccYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAdn4Z8fahpWyG+ze2 g4w5+dB7N3+h/SvVNC17T9cg8zT51dgMtG3Dp9R/XpXzxUttcTWs6TW0rxSocq6HBH41rCq47nJW wcKmq0Z9LUV5d4Z+JDJsg15N69BcxryP95R1+o/KvSrK8t762Wezmjmhbo6HIrojNS2PKq0J0n7y J6KKKsyCiiigAooooAKKKKACiiigAooooAKKKKACiiigCtqFha6jbNb30CTwt1Vx+o9D715n4m+H E0G+40JzNH1Nu5+cf7p7/jz9a9VoqJQUtzWlXnSfus+aJ4ZIJWinjeOVDhkcYIPuKjr6E1/w7puu w7b6AeYBhZk4dfx/oeK8p8TeBdS0fdNbA3tmOd8a/Mo/2l/qP0rmnScT1qOMhU0ejORooorM6goo ooAKKKKACiiigArP1PSba/Vi6BJiOJVHIPHX16d/0rQopNJ6MabWxwWqaNdaeC7gSQZx5i9ueMjt /LnrWZXqFYmq+H7e6TdaqlvMMngfK3HAx26dR6nrWEqPWJtGr0ZxVFWb6xuLGXy7iMrydrfwt9DV asWmtGbbhU9pdTWcwltpCj4xkc8fSoKKQHYaV4jjnby74LC56OPunn9P5delb6sHUMhDKwyCDkEV 5hV7TdUutPP7hwYzyY35U/59q3hWt8RlKl2PQqKzNO1u0vQq7/KmPHlvxk8dD0PJ+vtWnW6aexg0 1uFFFFMQVT1HTrbUIts6ANxiRQA4x2z6cnirlFJq+jGcLqmh3ViSygzQAZ8xR09cjt069Kya9QrI 1PQLa9dpUJhnY5LLyCfcf4Y61hOj1ibRq/zHDUVcv9OurBsXERCk4DjlT17/AIdOtU6watubJ3Cp ra5mtZRJbyNG/qp685wfUcdKhooA6zTPEsbKsd+pRwMGVRkH6gdO3TP4V0aMrqGQhlIyCDkEV5hV zT9RubB828hC5yUPKn8Pw69a2hVa0kZSpLoeiUVk6VrlvfkRt+5nPRWPDHOMKe56ce9a1dCkpaow atowpenSkopiOz8M+PtQ0vZDfZvbQcfOf3ij2bv9D+ldze/EHRINPW4gkeeVx8sCrhgf9rPA/wA4 zXidFaRqySsc1TCU5vmaOi8SeLdT11mSaTybTtBEcL/wI/xfj+Vc7RRUNt6s3jCMFaKsFFFFIoKK KKACiiigAooooAKKKKACiiigAooooAUdRXl1eojqK8urnr7o3o9QooorA2CiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKtaX/yE7P8A67J/6EKq 1JbytBcRTIAWjYOAemQc01uJ7HplFFFdxxhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFaGjaxf6Ncedp9w8R/iXqrfUdDWfRRewmlJWZ7F4Z+IVlqGyDVAtlcnjfn92x+v8P4/nXcKQyhl IIIyCO9fMtdF4a8XanoTKkMnn2neCU5X/gJ/h/D8q3hW6SPPrYBPWn9x7zRXPeGvF2ma6qpDJ5F3 3glOG/4Cf4v88V0NdCaeqPNlCUHaSsFFFFMkKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOT8 TeB9N1nfNCos7w8+ZGvysf8AaXv9eteU+IPDmpaFLi+gPlE4WZOUb8e30NfQVMmijmiaKZFkjYYZ WGQR7isp0lI66OLnT0eqPmeivV/E3w4guN0+huIJepgc/Ifoeo/l9K8y1HT7vTblre+geCYfwuOv uD3HuK5pQcdz1aVeFVe6yrRRRUmoUUUUAFFFFABRRRQA2REkUrKiOh6q6hgfwNczqXhj70lg/v5T /jwD+Q5/OuooqZQUtylJrY8yljeJykqMjjqrDBFMr0i9s4L2Fo7iNWBGA2BuX3B7dBXJ6p4euLY7 7UNcRegHzLzwMd/qPfpXPOk47G8aie5h0UUVkaBW3pniG5tmC3LG4h77j8w+h7/j+lYlFOMnHVCa T3PRtPv7e/iL2z7sY3KeCp9x/kVarzKKR4nDxOyOOjKcEV0ml+JiAI9QUtz/AK1QP1H59PyrohVT 0ZhKk1sdTRTIJo7iFJYXDxuMhh3p9bGYUUUUCGyIkiFJEV0PVWGQfwrnNV8NKQZNOO094mbg8dj6 /X17V0tFTKKkrMqMnHY80ubea2lMdxG0bjsw6+49R71FXpN3Z294gW5hWQDpnqPoRyOlctqvhyWB i9jumhAGVYjeOOfTP4c8/jXPKk1sbRqJ6M5+ilIwcHrSVkahWvpeu3NiPLf9/D2V2OV4xgHsOnFZ FFNNp3Qmk9GeiadqVtqEe6B8PzmNsBh749OnNXK8xRmR1ZGKspyCDgg10OleJJIykV+N6cDzR94D 3Hft/wDXrohWT+IxlStqjraKjt7iG5jElvIsiHupzjjOD6HnpUlbGQUUUUCCiiigAooooAKKKKAC iiigAooooAKKKKACiiigBk8qwQSSybtiKWbaMnAGeK8yr0PXJVh0i7ZgSDGU49W4H8688rnrvVI6 KWwUUUVgahRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFAHfeHLkXOkQHI3Rjy2AB4x0/TFaVcb4SvvIvDbSNiObpk8Bh+Pfp9cV2VdlOV4nL NWYUUUVZAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAqkqwKkgjkEdq7jwz8Qr 3T9sGqhr22HG/P7xR9f4vx/OuGopxk47EVKcaitJH0Xo2sWOs23nafcJKv8AEvRl+o6itCvmyyvL ixuFns5pIZl6Ohwa9J8M/EhH2Qa8mxuguY14/wCBL2+o/KumFZPRnl1sDKGsNUelUVFbXEN1Ak1t KksTjKujZB/Gpa2OHYKKKKACiiigAooooAKKKKACiiigAooooAKKKKACqeq6ZZ6ram31C3SaM9N3 VT6g9QfpVyila4JtO6PI/E3w6urTfPozNdQdfJb/AFij2/vfzrgpEaN2SRWV1OCrDBBr6ZrD8ReF 9N15CbuHZcY+WePhx9fUfWsZ0esT0KOOa0qangFFdP4m8Galoe6XZ9qsx/y2iH3R/tDt/L3rmVBZ gFBJPAA71ztNaM9OE4zV4sSp7K0uL65S3s4XmmboiDJrsvDPw9vdQ2T6oWsrY87MfvGH0/h/H8q9 S0bR7HRrbydPt1iX+JurN7k9TWkKTluctbGwp6R1Z5jH8M9SbTDM9xAt51Fv1GPQt6/p71xmo2F1 pty1vfQSQTD+Fx19x6j3FfSNUtV0uy1a2MGoW6TR9tw5U+oPUH6VpKiraHLTx8k/f1R840V33ib4 d3dnvn0Zmu4Bz5R/1i/T+9/P2rg5EaN2SRWV1OCrDBBrnlFx3PTp1Y1FeLG0UUUizN1TRrXUCzsD HOR/rF78cZHf+fHWuS1TSLnT3cspe3BIWUDgj3Hbr3/Wu/pGUMpVgCpGCD3rOVNSLjNxPMKK7HVP DkM4L2WIZSfuk/Ieefp+HHHSuWvLK5s3C3MLx56E9D06HoeormlBx3OiM1LYr0UUVJRa0++nsJ1l t2xggshztf2IrqdL8RQXJWO6Aglx94n5D+Pbv/jXGUVcZuOxEoKR6hRXA6Vq9zp7YQ+ZD0Mbk4HO ePQ9fzrrdK1e21EbUPlzd42PJ4zx6jr+VdEaikYypuJo0UUVoZhRRRQBn6lpNrfo5eNVnI4lUcg8 cn16d/0rktU0a608F2AkgB/1i9ueMjt/LnrXe0VnKmpFxm4nl9Fdpqnh23ucyWuLeX0A+Q8enbty PyrlL6ynsZTHcRlecBsfK30PfqK55wcTojNS2K1FFFQUT2l1NZzebbSFHxjI5yPpXU6V4jinIjvg sMh6OPunn9P5Vx9FXGbjsTKCluenoyuoZCGVhkEHIIpa8+0/VruwIEMm6Mf8s35X/wCt17V1um63 aXoVd/lTHjy34yeOh6Hk/X2rojUUjCUHE1KKKK0MwooooAKKKKACiiigAooooAKKKKACiikZlRSz kKoGSScACgDnvGVzstobZT8ztvbDdh0yPQk/pXI1c1W8a/vpJznaThAf4V7D+v1JqnXHOXM7nXBc qsFFFFQUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFd3oGqLqFsFkYfakHzjGMj+8P8/0rhKsWN3NZXCzW7YYdR2Yeh9quE+VkTjzI9Io qlpepwahCGiYLJj5oyfmX1+o561drrTvqjmasFFFFMQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAauha9qGhz+Zp85VSctG3KP8AUf1616p4Z8e6fquyG+Isrs8Yc/u2Ps3b 6H9a8Woq41HEwrYaFXfc+m6K8M8M+NNS0TbEW+1WY48mQ/dH+yeo/l7V6v4d8Uabr0YFpNsuMfNB Jw4+nqPcV0wqKR5VbCzpa7o3KKKK0OYKKKKACiiigAooooAKKKKACiiigAooooAKKKKADr1rMtdB 0q0v3vbexgjuX6uF6e4HQfhWnRSsmNSa2YUUUUxBRRRQAVheI/C2m68hN1F5dzjCzx8OPr6j61u0 Umk9GVGTg7xZ4X4l8Ganoe6XZ9psx/y2iHQf7Q6j+XvXMV9Nnkc1xnibwDp+qb57DFldnn5R+7Y+ 69vqP1rnnR6xPRo4++lT7zxeitPXNC1DRJ/L1C3ZAT8sg5R/of6dazKwaseipKSugqK5t4bmIx3E ayIezDp7j0PvUtFBRyuq+GmXD6dlhj5o3bnOf4T6Y9fTvXNujRuUdSrA4IIwRXp1VL/TrW+XFxEC 2MBxww69/wAenSsZ0k9UaxqW0Z51RWxqegXVkjSoRNCoyWXgge4/wz0rHrnaa0ZsmnsFFFFIZv6d 4kuIAqXa+fGP4ujjp379+vPPWuqs7y3vEL20qyAdcdR9R1HSvNqkt5pLeZJYXKSIcgitY1WtzOVN PY9MormdL8Sg4j1Bcf8ATVR/Mf4flXSRSJKgeJ1dD0ZTkH8a6IyUtjBxcdx1FFFUSFNkjSRSsqI6 HqrqCD+Bp1FAzmNQ8MZ3PYSY6ny5PxOAfyHP4muZljeJykqMjjqrDBFem1Wv7C3v4tlxGGxnaw4K /Q1jKinsaRqNbnnFFbmqeHri1O+1DXER7AfMvPAx3+o9+lYdc7i46M3TT2CiiikM29M8Q3VsyrcM biHPO7lx16H8e/p2rq9Pv7e/iL2z7sY3KRgqSOh/zivOafFLJDIHido3HRlOCPxrSNVx3M5U09j0 2iuW0vxMQBHqCljn/WqB+o/Pp+VdNBNHcQpLC4eNxkMO9dMZqWxhKLjuPoooqiQooooAKKKKACii igArmvFeqbQbGAsHOPNYccY+7+PH+c1b13W0sk8q1ZHuWzyCCI+cc+/HT8/fi3ZndmdizMckk5JN YValtEbU4X1Y2iiiuc3CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAkgmkglWWFykinIYV1ej+Io5gsN+RHJgAS/wsc9/T+X XpXIUVUZuOxMoqW56ejK6hkYMpGQQcgilrz7TdVutOyIGBjY7ijDIJxj6j8PQV1ml65bXwVWIhnJ x5bHr6YPfr0610xqKRhKm4mrRRRWhmFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABTo3eN1eNmR1OQynBBptFAHf+GfiLdWm2DWla6g6CZf8AWL9ezfz+teoaVqdnqtsLjT7h J4j1KnkH0I6g/WvnCrem6hd6ZcrcWE8kEo/iQ9fYjuPY1rCq1ucVbBQnrDRn0hRXnnhn4jwXGyDX EEEvQToPkP1HUfy+legQyxzRLJC6yRsMqynII9jXTGSlseXUpTpO0kPoooqjMKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKAIrq2hu4HhuokmhcYZHXINeceJvhuDvuNBfB6/Z pG4/4Cx/kfzr0yiplBS3NaVadJ3iz5rvLS4srhoLuGSGZeqOuDUFfRWtaLYazb+TqFusoH3X6Mv0 PUV5Z4m+H19pu+fTC17ajnaB+8Ue47/h+Vc06TjsepRxkKmktGcRRSkEEgggjgg0lZHYFZOqaFbX xLr+4mPV1HB57jv35rWopNJ7jTa2PPNS02509wJ0yh6SLyp9s1Sr091V1KuoZSMEEZBFc/qnhuOe R5bJ1idjkxkfJ+GOnf1/CsJ0bfCbRqrqchRUtzbzW0pjuI2jcdmHX3HqKirA2CrlhqN1Ytm3lIUn JQ8qenb8OvWqdFCdthNJ7nbaX4gtrpUS4Ignxg7vuk+x/wAfXvW1Xl9a2l65dWJCMTNABjy2PT0w e3Tp0reNbpIylS6o7qiqOm6pbagD5DESAZaNhggf1/D1q9W6aexi1bQKKKKYgrN1TRrXUCzsDHOR /rF/TI7/AM+OtaVFJpPcadndHn+o6Td2BJlj3RD/AJaJyvbr6dcc1n16e6q6lXAZSMEEZBFYOqeH IZgXssQy5+6T8h55+n4ccdKwnR6xNo1e5x1FWLyzuLNwlzE0ZPTPQ/Q9D1qvWBsnfYKtaffT2E6y 274wQWQk7X9iO9VaKE7CavodlpviS3n2pdjyJOm7qh6fl+PHvW6jK6KyMGVhkEHIIrzCpra6ntm3 W8rxnIJ2nAOPUd62jWa3M5Uk9j0qiuKh8TX8ce1xDKc53OmD9OCBj8KsQeKpxu8+2jf02MVx+ea0 VWJn7OR1tFcc/ii8LHZDAFzwCCSB9c1Sudb1C4yDcMiltwEfy49sjnH40OtEapSO2vL62sx/pMyR nGdpOWIzjIHWuX1TxHNOSllmGIj7xHznjn6fz461guzOxZyWZjkknJJptZSqt7GkaaW4UUUVkaBR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAbWla/cWeyOc+dbjAwfvKPY/4+naursNRtb5c28oLYyUPDDp 2/Hr0rzqnxSPE4eJ2Rx0ZTgitY1WtzOVNPU9NorldK8SsGEeojcvQSqvI57j0+np3rpreeK5iEsE iyIe6n/ODXRGSlsYSi47klFFFUSFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABWz4f8SaloUoNlOTCTloH5Rvw7fUVjUUJ22FKKkrSR7h4Z8cabrOyGZhZ3h48uRvlY/7Ld/p wa6uvmSuu8M+OtS0jZDck3tmONkjfMo/2W/of0rohW6SPNrYDrT+49torI0DxFp2uw7rGcGQDLQv w6/Uf1HFa9bpp6o86UXF2YUUUUxBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB TXdY0Z3YKijJYnAArnPEvjLTNDDRl/tN4P8AlhEeh/2j0H8/avJ/EfirU9ecrcy+XbZ4gj4T8fU/ Wsp1VE6qOEnV12R0HxG1bw9fyMthB59+D811Edq/j/f/AM81wNFFcspczuexSpqnHlQUUUUiwooo oAjuIIriMxzxpIhzwwzjjGR6HnrXKap4blgBksS0yDqhxuHH6/z+tdfRUSgpblRk47HmLqyOyupV lOCCMEGm16HqWl2uoAfaEIcDAdThgM/56+tclquh3NiS6AzwAA+Yq4xxzkZOMYPPTp9K55U3E3jU UtDJooorM0HIzIwZCVYHIIOCDW/pXiSWBfLvg0ydnGNwGP17fr1rnqKqMnHYTinuelWt1DdxeZbS LInTI7fUdqmrzS2uJrWUSW8jRuO6nr7H1HtXVaZ4ljmZIr1BE5OPMU/J3656dvX8K6I1U9zCVNrY 6GikRldFZCGVhkEHIIpa1MgooooAiubeG5iMdxGsiHswzj3HofeuZ1Pw06s0mnsHUnPlMcEfQ9+/ X9a6uiplBS3KjJx2PMXVkdldSrKcEEYINNr0W/061vkIuIgWxgOOGHXv+PTpXMal4cuYGke1xNCC Sq5+cD34wfw6+lc8qTWxvGqmYNFKysjFXBVgcEEYINJWRoFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABVizvLizctbStGT1A6H6joepqvRRsG52Wm+JLefal2vkSHjd1 Qnj8vx/Ot6vL60dM1e609lCOXhzzEx4/D069q3hW6SMZUux39FZ2lavbaiNqHy5u8bEZPGTj1HX8 u1aNbpp6oxatowooopiCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCSCa S3mSWCR45UOVdDgg+xr0Lwz8R5YdkGuoZo+guIx8w/3h3/D9a85oqoycdjOpRhVVpI+ktPvrXUbZ bixnjnhboyHP4H0PtVmvnLSdVvdIuRPp9w8L98dGHoR0NeoeGfiJaXuyDWFW0uDx5o/1bfX+7+PH vXRCsnueXWwU4ax1R3tFNR1kRXRgysMgg5BFOrY4gooooAKKKKACiiigAooooAKKKKACiiigAoqG 8uoLK3ee7mSGFerucAV5t4m+JBO+DQEwOhuZF/8AQVP8z+VTKajua0qM6rtFHea5rmn6Jb+bqFwq EjKxjl3+gryvxN4/1DU98On7rK0PHyn94w927fQfma5G7uZ7y4ee6leaZzlnc5JqGuadVy2PVo4O FPWWrFJycnrSUUVkdYUUUUAFFFFABRRRQAUUUUAFFFFAGLqfh+2uVZ7dRBNjjbwpPHUdunb1zzXK 3+nXVi2LiIhScBxyp69/w6da9EpssaSoUlRXQ9VYZB/CspUk9jSNRo8xorq9V8NIU36dlXySY3bg jHGD6/U9+2K5i4hkt5minQpIpwQawlBx3N4yUtiOiiioKLunalc6e+YHynOY2yVOe+PXgc+1dXp/ iG0uvlmP2aT0c/Kev8X+OK4eirjNxIlBSPUKK87tNTvLQAQXEiqBgKTuUDOeAeOtalv4oukKCaKK RQMHGVY8dc9P0rZVl1MnSfQ7CiuX/wCEs/6cv/Iv/wBjTZfFblCIrRVfsWfcPywKr2sRezkdVUNz dQWqbriVIxgkbjgnHXA71xdz4g1CbIEixKRgiNcfjk5OazJZHlkLyuzuerMck/jUOsuhSpPqbWv6 1HfBoIYEMYOBK4+bt9306fiPSsKiisJScndm0YqKsgooopDCiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAK3dL8RT2wEd0DcRZ+8T84/Hv3/AMawqKak46oTipbn pFjewX0Ikt5A3AJXPzL7EdulWK8yhlkhkEkLsjjoynBFdPpniYMRHqCheP8AWoD6dx+fT8q6I1U9 GYSptao6aimxyJKgeJ1dD0ZSCD+Ip1bGQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAG94c8VanoLhbaXzLbPMEnK/h6H6V6x4a8ZaZrgWMP9mvD/wAsJT1P+yeh/n7V 4TSg4ORwa0hUcTmrYWFXXZn01RXjPhnx/f6Zsg1Hde2g4yx/eKPY9/ofzFeqaJrmn63b+bp9wshA +aM8On1H+RXTGopHlVsNOlvsaVFFFWYBRRRQAUUUUAFFFc/4k8WaZoKlZ5fNuscQRct+Pp+NJtLV lRhKbtFXOgJABJOAK4nxN8QbDTd8Gm7b26HG4H92p9z3/D868+8S+MNT10tG7/Z7Q/8ALCI4B/3j /F/L2rm6551ukT0qOAS1qfcaWta1f61cedqFw0hH3U6Kn0Has2iisG7noJKKsgooooGFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABUF5Z295GEuYlkA6Z6j6HqOlT0UmrjTscbqXhu4g3PaHz4+u 3o4HP5/h+VYNeoVnappFtqCkuvlzdpFHPTv6jpWMqP8AKaxq9zgKK1b/AEK9tX+WMzx54aMZ/MdR /L3rKrBprc2TT2CiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigC1p9/cWEpe2fGcblIyGHvXV6X4ht7oBLrbby+p Pytxyc9vofbrXFUVcZuOxMoKR6hRXCabrl3ZBU3ebCP4H5wOOh6jgfT2rrNO1a0v8CGTbJ/zzfhu /wCfTtXRGopHPKDiX6KKK0ICiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig Aqa0uZ7O4Se1leGZDlXQ4IqGigNz03wz8SCNkGvJnsLmNf8A0JR/MflXpFndQXtuk9pNHNC3R0bI NfNVaWi61f6Lcebp9w0efvJ1R/qO9bQrNaM4a2BjLWGjPomiuJ8M/ECw1LZBqQWyujxkn92x9j2/ H867GeeG3gaeeVI4VGS7MAoH1roUlJXR5c6U6btJEtUNX1ax0i2M+oXCQp2B5ZvYDqa4bxN8SI4t 9voSCR+huJB8o/3R3+p/WvNb+9udQuWuL2eSeZurOc/h7D2rOdZLRHXRwMp6z0R2Xib4h3l/vg0k NZ254Mn/AC0YfX+H8OfeuFZmdizksxOSSckmkormlJy1Z6lOlGmrRQUUUUiwooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKydV1y2sDsXE8x/hRhhecYY9j14pNpasaV3ZG q7KilnIVQMkk4AFchr2p6fcq629sssp/5bkbcHH5nv19B1rLv9Rub983EhK5yEHCjr2/Hr1qnXPO rfRG8adtWFFFFYmoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU5GZHVkYqynIIOCDTaKAOg0vxHNBiO9BmiH8 Q++P8f589a6q0uYbuHzbaQSR5xkcc/Q9K81qa2uJrWUSW8jRv6qevOcH1HHStY1WtzKVNPY9Korm 9M8Sxsix36lXAwZVGQfcjt26Z/CujVldQyEMpGQQcgiuiMlLYxlFx3FoooqiQooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKsS3t1Lax20txM9vHykTOSq/Qdqr0UBYKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooqK5uIbaIyXEixoO7Hr7D1 PtQMlqnqWpW2nx7p3y/GI1wWPvj0681z+reJHcyQ2ACpkr53dh6gdu/Xn6VzrszuzOxZmOSSckms Z1UvhNYU76s1dU125vhsT9xD3VGOW4xgnuOvHvWRRRXO23qzZJLRBRRRSGFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFXdO1O5098wPlDnMbZKn3x68DmqVFNO2qE1fRndaVrlvfkRt+5nPRW PDHOMKe56ce/etavL619L125sV8tv38PZXY5XjoD2HSto1v5jKVLqjuaKp6dqVtqCZt3+cDJjbhh +H4jmrlb3vsYtW3CiiimIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACkdlRSzkKoGSScACszUtbtLLcm7zZh xsTseep7cj6+1cnqGr3l9lZZSsR4MacKenX15APNZyqKJcYOR0GqeJIoCY7JVmcdXP3Rz+vf9Otc teXU95N5tzIXfAGcAYA9hUFFc0puW50Rio7BRRRUlBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQA5GZHVkYqynIIOCDXR6Z4mkVljv1DKTgyqMEdeSO/bpj8a5qiq jJx2JlFS3PS7a4huYhJbyLIh7qensfQ+1S15taXU1pN5ttIUfGMjnI+ldTpfiSKciO9CwyHgOPuH n9P89K6IVU9zGVNrY6CikRldQyEMrDIIOQRS1qZBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUVHcTR28LSzOEjUZJNc3qnibKtH p6kHP+ubHv0X345PvxUymo7lRi5bG/qF9Bp8IkuWKhshQBksR2H6fmK5PU/ENzcsyWxMEOeNv3z9 T2/D9ax5ZHlcvK7O56sxyTTK55VW9EbxpqO4UUUVkaBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAaGn6td2A2wybo/+eb8r36enXtXW abrdpe7U3eVMeNj8ZPHQ9+T9fauDoq41HEiVNM9Qori9K8Qz2pCXRaeHpyfmXnk57/Q+3IrqtPv7 e/iL2z7sY3KRgr9a6Y1FIwlBx3LVFFFWQFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFZ2qavbaeCrt5k3aNTz07+nak3bcaTexo1h6p4igti0dqBPLj7wPy D8e/b/Gud1XV7nUDhz5cI6RqTg89/U9KzawlW/lNo0u5YvLy4vZN9zKzkdAeg+g7dKr0UVi3d3Zs FFFFIAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKfFI8Th4nZHHRlOCKZRQB0+l+JSAseoKW5/1qj+YH49PyrpoJo54l khdXjbowNeZVZsb2exmElvIV5BK5+VvqO/U1tCq1ozKVNPVHo9FYemeIoLpljuQLeTH3i3yHj17d +P1rcreMlLVGLTW4UUUVRIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRTZJEiQvK6 og6sxAA/GgY6oLu8t7NN1zKsY7A9T9B1PWsDVPEoGY9PUNx/rWHt2H+P5VzNxNJcTPLM5eRzkk1j OqlojSNJvc29R8S3E25LRRBGcjd1Yjkfhx6cg96wKKK53Jy3N1FLYKKKKQwooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACtLStYudObap8yHvGx4HOePQ9azaKabWqE0nuegaZq1rfqoRwk5HMTd Qfb16dq0K8vre03xJcQbUux58Y43dHHTv3/H863jW/mMZUux2VFQWd5b3iFraVZAOuOo+o6ip62T uZBRRRTEFFFFABRRRQAUUUUAFFFFABRRRQAUVS1LVLXTwBcMTIRkRqMsRn9Px9K5LVdcub4lULQQ EAeWrZzxzk4Gc+nT+dRKoolxg5HQ6n4gtbZHS3YTz4+XbygPHU/j29McVyl/qV1fE/aJWKZyIxwo 644/E89ap0VzSm5bm8YJBRRRUFhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFAElvNJbyrLC7JIvQiun0rxKjAR6iNjDpKq8HjuPX6evauUoqozcdiZRUtz06KRJUDxO roejKcg/jTq87sNRurBs28pC5yUPKn8Pw69a6rTPEFrcoq3LCCbHO7hSeeh7dO/r3rojVT3MJU2j aooorUzCiiigAooooAKKR2VFLOwVQMkk4AFc/qPiaOCRo7ONZmU4Lsfk7dMcnv6fjUyko7jSb2Nu 6uYbSLzbmQRpnGT6/wBa5bVfEkk6+XYhoU7ucbiMfp3/AE6Vh3NxLcymS4kaRz3Y/oPQVFXPOq3o jojTS3HOzO7M7FmY5JJySabRRWRoFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGhp2r3dhhYn3xD/AJZycr36enJzx+Nbdt4qjPF1bsuF +9Gc5P0OMDr3NcpRVxnKOxDhF6s7qLxDpzoGaVoyf4WQ5H5ZFO/t/Tf+fn/yG3+FcHRVe2kL2UTu JvEWnxoCkjynONqIc/XnFZ134pOSLO3GM8NKev4D/GuYoodaQKnFFq91C6vcfaZmcDovQfXA4zz1 qrRRWV7mlrBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFAH/2QplbmRzdHJlYW0KZW5kb2JqCjEzCjAKb2JqCjw8Ci9TdWJ0eXBlCi9JbWFn ZQovV2lkdGgKNzc1Ci9IZWlnaHQKMjYyCi9Db2xvclNwYWNlCi9EZXZpY2VSR0IKL0JpdHNQZXJD b21wb25lbnQKOAovRmlsdGVyCi9EQ1REZWNvZGUKL0xlbmd0aAoxMzIyNgovU01hc2sKNDYKMApS Cj4+CnN0cmVhbQr/2P/gABBKRklGAAECAAABAAEAAP/bAEMABgQFBgUEBgYFBgcHBggKEAoKCQkK FA4PDBAXFBgYFxQWFhodJR8aGyMcFhYgLCAjJicpKikZHy0wLSgwJSgpKP/bAEMBBwcHCggKEwoK EygaFhooKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKP/A ABEIAQYDBwMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAAC AQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZ GiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOU lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T1 9vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAAB AncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Sl pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEA AhEDEQA/APlSiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAoorWtdAv7gZMQhXB5lO3v0x1/Smot7CcktzJore/wCEXvf+etv/AN9N/hWX e6fdWWPtMLID0bqPpkcZ46U3CS3QlOL2ZVoooqSgooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiprS1mu5hFbRl3xnA7D60JXAhq9p ul3WoEmBQEBwXY4UHH+enrXRaX4bjgYSXzLM46IM7Rz+vb/69b6KqIFRQqqMAAYAFdEKDesjCdZL SJl6XodrYhWZRNODnzGHT6Dt069a1aKK6Uktjnbb1YUjqrqVdQykYIIyCKWimI5vU/DUbI0lgxRw M+UxyD7Anp365/CuYubea2lMdxG0bjsw6+49R716XUN3aw3cJiuYw6Zzg8c/WsJ0E9Ym0KzW55rR XQap4cmgzJZEzRAcqT8445+v4c81gMpRirAqwOCCMEGuaUHF2Z0RkpbCUUUVJQUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABTkVnYKgLMxwABkk1q6XoVzf De/7iHszry3Gcgdx05rrdO0220+PbAmW5zI2Cxz2z6cDitYUZS1Mp1VE53S/DUkypLeuYkIz5a/e /H07ev4V1Ntbw20Qjt41jQdlHX3PqfepaK64QUVoc8puW4UUUVRAUUUUAFFFFABRRRQAVQ1DSbS/ yZo9sn/PROG7fn071fopNJ6MabWqOD1LRLuy3Nt82Ec705wOeo7cD6e9ZdeoViap4et7pS9qFt5v YfK3HQjt9R+tc86HWJvCt0kcVRVq/sLiwlCXKbc52sOQ30NVa52mtGbp31QUUUUhhRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU+KN5XCRIzueiqMk1eXRtQaHzRavtwTgkBuPbrTUW 9hNpbkGn2FxfylLZN2MbmJwF+prr9M0G1snWRyZ5lOQzDAHuB/8Ar6Vx3+lWMv8Ay2t5CPdCR/hx W/pfiUgCPUFLc/61R/Mfn0/KtqTjF67mVRSa93Y6mimQTR3EKSwsHjcZDDvT66zlCiiigAooq3pm nXeqXIt7C3eaU9lHA9yegH1ppXE2krsqVteHvDWpa7IPscO2AHDTycIPx7n2Fd94a+HdtbbZ9acX M3UQr/q1+p6t/L613scaRRqkSKiKMKqjAA9hXRDDt6yPLxGZxj7tLV9zzPUvhmyWKNp16ZbpR86y jarn/ZPb8c/UV5/qFjdafctb3sDwTL1Vxj8R6j3r6Oqlq2l2WrWxg1C3SZO2eqn1B6itJ4dP4dDm oZnOLtU1R860V3fiX4e3dlvn0hmu7cc+Uf8AWL/8V+HPtXDOrI7I6lWU4IIwQa5JQcXZns0q0Kyv B3G0UUVJqFFFFADZY0lQpKiuh6qwyD+Fc3qnhoEmTT2C8f6pifTsfy6/nXTUVMoKW5UZuOx5nPDJ bzPFMhSRTgqajr0i+soL2Ix3EYbjhu6/Q9q5TVPDs9sDJakzxZ+6B8459O/bn9K5Z0XHVanTCqpa MwqKKKxNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKu6Vp8uo3Ijj+VBy7kcKP8famk27ITdtWUqK 7uw0GytV+eMTyY5aQZH4Dp/X3q3/AGdZf8+dt/36X/Ctlh31Zk66OS0XW/7PURtbxtGfvMgw556k 98ZPH6111hewX0Ikt3DcDK919iKyNS8NQSR5sf3Mgx8rMSp/mQf8PxrmpoLvTbhTIskEg+6wPt2I 69apSnS0lsS4xqarc9CnhjuIXimQPG4wVPeuZ1Tw0QDJp7Fuf9Ux/kfy4P507S/EoJEeogLx/rVH 8wPx5H5V0sUiSoHidXQ9GU5B/GtPcqoz9+mzzy3uLvTbg+W0kMg+8jDGeO4P1rq9H16O+kSCWMx3 BHGOVbA5+nfj261oahYW9/EEuU3YztYHBU+1Ps7O3s49ltEsYPUjqfqep60oU5Qdk9CpTjJarUnp 8UbzSLHEjPIxwqqMkn2FdN4a8FalrO2WRfslmefNkHLD/ZXv9eleq+H/AA3puhRj7HDmYjDTycuf x7D2FdkKMpa9Dy8Rj6dHRas4Hw18O7i52T605t4uogT77fU/w/z+lemabp1pplsLewgSCIdlHX3J 6k/WrdFdkKcYbHiV8TUrv3np2CiiirOcKKKKACsLxF4W03XULXMXl3OOJ4+G/H1H1rdopNJqzKhO UHzRdmeG+JPB2paIWkKfabMf8t4h0H+0O38veuar6XIyMHpXGeJfAVhqe+awxZXR5+Ufu2PuO31H 5GuWeH6xPYw+Zp+7W+88borT1vRNQ0WfytQt2QE/LIOUf6H/ACazK5mmtGetGSkrxd0FFFFIYUUU UAZ2qaPbagNzDy5u0iAZPHf1HSuS1TR7nTyWYeZD2kUHA5xz6HpXfUVnOkpeppGo4nl9Fdhq/h2G VHlsR5c3Xy8/K3+B/SuRdWRirgqynBBGCDXJODg9TqjNS2G0UUVBQUUUUAFFFbOj6FNfeXNKRHbE 5zn5mHOcD8O/61UYuWwnJRV2ZMUbzSBIkZ3PRVGSfwroNP8ADEr4a+fyl/uIQW79+g7ev4V0Vhp9 tYJtt4wGI5c8sfx/p0q3XTCgl8RzyrN/CYP/AAi9l/z1uf8Avpf8KP8AhF7L/nrc/wDfS/4VvUVp 7KHYz9pLuYP/AAi9l/z1uf8Avpf8KP8AhF7L/nrc/wDfS/4VvUUeyh2D2ku5g/8ACL2X/PW5/wC+ l/wo/wCEXsv+etz/AN9L/hW9RR7KHYPaS7nGX/hu6gXfbsLhQMkAbW79u/8AP2rCr1Cs/U9Jtb9W LoEmI4lUc59/Xp3rKdDrE0jWf2jz+itDVtKn01gZMPExwsi9PofQ1n1zNNOzOhNPVBRRRSGFFFFA HWWXhy0ns4JnknDSRqxAYYyRn0qb/hF7L/nrc/8AfS/4VqaV/wAguz/64p/6CKtV3KnG2xxupK+5 g/8ACL2X/PW5/wC+l/wrmtYtUstRmt4ixRMYLdeQD/WvQ64PxN/yHLn/AID/AOgisq0IxjdI0pSb epl0UUVzHQFT2USz3kETkhZJFQkdcE4qCrWlf8hSz/67J/6EKa3E9jqP+EXsv+etz/30v+FH/CL2 X/PW5/76X/Ct6iu72UOxx+0l3MH/AIRey/563P8A30v+FcbXqFeX1z14qNrG1GTle4UUUVgbhRRR QB1ll4ctJ7OCV5Jw0kauQGGMkZ9Km/4Rey/563P/AH0v+Famlf8AILs/+uKf+girVdypxtscbqSv uYP/AAi9l/z1uf8Avpf8K5rWLVLLUZreIsUTGC3XkA/1r0OuD8Tf8hy5/wCA/wDoIrKtCMY3SNKU m3qZdFFFcx0BRRRQAUVYsbSa9uFht1yx6nso9T7V1uleHre1XfdBbib3Hyrx0x3+p9ulXCm57ESm o7nO6Xo11qAWRQI4CceY364Hf+XHWt2LwtahAJZ5mfuVwo/LBroKK6o0Yrc55VZPYwf+EXsv+etz /wB9L/hR/wAIvZf89bn/AL6X/Ct6iq9lDsT7SXcwf+EXsv8Anrc/99L/AIUf8IvZf89bn/vpf8K3 qKPZQ7B7SXcwf+EXsv8Anrc/99L/AIVDe+HLSCznlSSctHGzgFhjIGfSukqrqv8AyDLz/ri//oJp OnG2w1Ulfc85ooorhOwKKKKACiiigAooooAKKKKACu88OWi22lwttUSSrvZh3zyP0NcHXp6qFUKo AUDAA6CujDpXbMK70SFooorqOYKiubeG6iMdxGsiHsw6e49DUtFAHMXnhctcA2kypCx5V8kqPb17 9cVsaRpkOmRMsTM7vjezd8eg7Dr+dbFhZXOoXK29lA80zdFQZ/H2HvXpPhr4cxxbJ9dcSv1FvGfl H+8e/wBB+tFOhzO8UZYjGRpR99/I4PQfD+o65NssYCUBw0rcIv1P9BzXqfhrwNp2k7JroC8uxzud fkU/7K/1P6V1UEMVvCkUEaRRIMKiDAA9hUld8KMY6vVng4jH1KukdEFFFFbHCFFFYPiPxVpuhKVu JfNucZEEfLfj6fjSbSV2VCEpvlirs3iQBk8CuL8S+PrDTd8Onbb26HGVP7tT7nv+H51wHiTxhqWu Fo2f7PaH/lhEeCP9o9T/AC9q5uuWeI6RPYw+WJe9W+47LTfiFq9vfPLdmO6gc5aEgLt/3SOn45r0 vw94l03XYx9jm2zgZaCThx+Hce4rwKnxSPFIskTsjqcqynBB9jWcK8o76nTXy+lVXu6M+lKK8o8N fES4tdkGtKbmEcCZf9Yv17N/P616Zpmo2mp2wnsLhJ4j3U8j2I6g/WuuFSM9jxK+FqUH7y07luii itDnIbq2gu4HguokmhcYZHGQa878S/DkHdPoL4PU20jf+gsf5H869KoqJwjPc2o4ipRd4M+b7y1n srhoLuF4Zl6o4wagr6G1nRrDWbfytQt1kA+6/Rl+h6ivL/EvgC+07fPppa9tRztA/eKPcd/w/KuS dCUdVqe3h8wp1dJaM4milIIJBGCOoNJWB6AUUUUAFcj4xtBHdR3SA4lG1+OMjpz7jt7V11YPjL/k GRf9dh/6C1Z1VeDNKTtJHG0UUVwnYFFFFABXp6KqIqoAqqMADoBXmFeoV04fqc9foFFFFdJzhRXB anf3aajdKl1OqrK4AEhAAyfeq39o3v8Az+XP/f1v8aweIS6G6oN9T0aivOf7Rvf+fy5/7+t/jR/a N7/z+XP/AH9b/Gl9YXYPYPuejUV5z/aN7/z+XP8A39b/ABrS8O3t1LrFuktzO6HdlWkJB+U01XTd rCdFpXudpRRRW5iUtbiWbSLtWyAIy3HqOR/KvPK9G1X/AJBd5/1xf/0E15zXLiN0dNDZhRRRXObh RRRQB6NpX/ILs/8Arin/AKCKtVV0r/kF2f8A1xT/ANBFWq9GOyOB7hXB+Jv+Q5c/8B/9BFd5XB+J v+Q5c/8AAf8A0EVjiPhNaHxGXRRRXIdQVa0r/kKWf/XZP/QhVWrWlf8AIUs/+uyf+hCnHdCex6NR RRXonAFeX16hXl9c2I6HRQ6hRRRXMdAUUUUAejaV/wAguz/64p/6CKtVV0r/AJBdn/1xT/0EVar0 Y7I4JbsK4PxN/wAhy5/4D/6CK7yuD8Tf8hy5/wCA/wDoIrHEfCa0PiMuiiiuQ6gooooA7DwZGosJ 5APnaTaT6gAY/ma6CsHwb/yDJf8Arsf/AEFa3q76XwI4qnxMKKK5zxhcT2/2TyJpIt2/Oxiufu+l OcuVXFGPM7HR0V5z/aN7/wA/lz/39b/Gj+0b3/n8uf8Av63+NY/WF2NfYPuejUV5z/aN7/z+XP8A 39b/ABo/tG9/5/Ln/v63+NH1hdg9g+56NVXVf+QZef8AXF//AEE1wf8AaN7/AM/lz/39b/Gke/u3 Uq91cMrDBBkJBH50OumrWGqDT3K1FFFcp0BRRRQAUUUUAFFFFABRRRQAV6hXl9eoV04fqc9foFFF FdJzhXS+BvDsfiLUJY552ihhUOwQfM2TjAPauar0P4Of8hHUf+uS/wA60pJOSTOfFzlToylHc9G0 nSrLSbYQafbpCncjqx9Sepq9RRXoJW2Pl3Jyd2FFFR3E0VvC8txIkUSDLO5wAPc0xbklUdW1Wy0m 2M+oXCQp2B6sfQDqa4jxL8Ro4t8GhoJX6G4kHyj/AHR3+p/WvNr+9udQuWuL2eSeZurOc/gPQe1c 866WkdT0sPls6nvVNF+J2XiX4hXl7vg0lWs7c8eYf9Yw/wDZfw5964Z2Z2LOSzE5JJySaxdb1tNP PlRxmS4IzhgQoHY57/h78iqeneJkclb9BGc8PGCV/Ecn+dcM66lK0me7RwqpR/do2NUa+W3/AOJc kbSHg7zyPp2z35PbvXFQ6ne2t7LN5jecx/eK464PQjt6e1egIyuqshDKwyCDkEVU1HTbbUExOnzD pIvDD8fxPFZzg5apm0JqOjRR0zxBa3Kqlwwgmxzu4Qn2Pb8fXvW1XDapoVzYgun7+HuyryvHcdh1 5pmm63d2W1d3mwj+B+cDjoe3A+ntURquOky3SUtYHeVb03UbvTLkXFhO8Eo7qevsR0I+tYunataX +BDJtl/55vw3f8+nar9dEZX1RhKPSSPV/DXxEt7nZBrSC3m6CdB+7P1HUfy+ld9FIksayROrxsMq ynII9jXzVW14f8SaloUgNnNmEnLQPyjfh2PuK6YYhrSR5WIyyMvepaPse+0Vy3hrxrpus7IpG+yX h48qQ8Mf9lu/04NdTXVGSkro8apTlTfLNWYUUUVRBzviTwjpuuBpJE8i7PSeMYJ/3h0b+fvXiWoW xs7+5tmYMYZGjLAYzgkZ/Svo+vnnxF/yMGp/9fUv/oZrkxEUrNHs5XVnK8G9EZ1FFFcp7AVg+Mv+ QZF/12H/AKC1b1YPjL/kGRf9dh/6C1RV+Bl0/iRxtFFFcB2hRRRQAV6hXl9eoV04fqc9foFFFFdJ znnOq/8AIUvP+uz/APoRqrVrVf8AkKXn/XZ//QjVWvOe53rYKKKKQwrU8M/8hy2/4F/6Cay61PDP /Ictv+Bf+gmqh8SJn8LO8ooor0DhKuq/8gu8/wCuL/8AoJrzmvRtV/5Bd5/1xf8A9BNec1y4jdHT Q2YUUUVzm4UUUUAejaV/yC7P/rin/oIq1VXSv+QXZ/8AXFP/AEEVar0Y7I4HuFcH4m/5Dlz/AMB/ 9BFd5XB+Jv8AkOXP/Af/AEEVjiPhNaHxGXRRRXIdQVa0r/kKWf8A12T/ANCFVataV/yFLP8A67J/ 6EKcdxPY9Gooor0TgCvL69Qry+ubEdDoodQooormOgKKKKAPRtK/5Bdn/wBcU/8AQRVqqulf8guz /wCuKf8AoIq1Xox2RwS3YVwfib/kOXP/AAH/ANBFd5XB+Jv+Q5c/8B/9BFY4j4TWh8Rl0UUVyHUF FFFAHZeDf+QZL/12P/oK1vVg+Df+QZL/ANdj/wCgrW9XfS+BHFU+JhXL+Nv+XL/gf/stdRXL+Nv+ XL/gf/stKt8DHS+NHL0UUVwnYFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXqFeX16hXTh+p z1+gUUUV0nOFeh/Bz/kI6j/1yX+deeV6H8HP+QjqP/XJf51rR+NHJjv4Ej1SiiivQPmQry/4h6H4 guJXuTO19YqdyxRDb5Q/3O/15P0r1CionBTVmbUK7oS5krnzRRXuPiXwbput7pQv2W8PPnRj7x/2 h3/n715V4i8MaloTk3UW+3zhZ4+UP19D9a4p0pQPoMPjadfRaPsc9c28VzEY7iNZEPZh09x6H3rl dV8NywDzLEtMndDjcBj9f/1da6+iuedNT3O2M3HY88s7+706UrE7JhvmjYcZ75Hrxj1rrNM162vX WJgYZmOFVjkE+gP+OOtWdS0u21ADz1IkAwHU4IGf89fWuT1TQ7qxJZAZoAM+Yo6cc5Hbp16VjadL bVG14VN9Gd1WTquhW18fMX9xN3ZQMNznJHc9ea5vS9cubHCMTNABjYx6ccYPb6dK67TtSttQj3QP hhnMbYDD3x6cjmtFOFRWZDhKnqjib/T7vTJlMgIwQVlTO3PsfXj9K09L8SSwL5d8GmTs4xuAx+vb 9etdc6q6lXAZWGCCMgiuc1Tw1GytJYEo+M+UxyD7A9u/X9Kh0pQ1gylUjLSZvWl1DeQ+bbSB0zjI 7H6VNXnP+l6Zdf8ALS3mH4ZGfyIyPpXRaZ4ljZVj1BSrgY81RkH6jt26fpVQrJ6S0FKk1rHU6uzt bi9uEgtIXmmboiDJr2vwRpus6dY7NZvBKCPkhPzNH/wPv9OR714ha3MkMkdxazMjjDJJG2D9QRXo fhr4jSR7INdQyJ0FxGPmH+8vf6j8jXbQlGL1PJx9KrUhaCTX4nqNFV7C9ttQtluLKeOeFujIc/h7 H2qxXcfPtNOzCvnnxF/yMGp/9fUv/oZr6Gr558Rf8jBqf/X1L/6Ga5sTsj1cp+KRnUUUVxnthWD4 y/5BkX/XYf8AoLVvVg+Mv+QZF/12H/oLVFX4GXT+JHG0UUVwHaFFFFABXqFeX16hXTh+pz1+gUUU V0nOec6r/wAhS8/67P8A+hGqtWtV/wCQpef9dn/9CNVa857netgooopDCtTwz/yHLb/gX/oJrLrU 8M/8hy2/4F/6CaqHxImfws7yiiivQOErap/yDLz/AK4v/wCgmvOK9G1X/kF3n/XF/wD0E15zXLiN 0dNDZhRRRXObhRRRQB6NpX/ILs/+uKf+girVVdK/5Bdn/wBcU/8AQRVqvRjsjge4Vwfib/kOXP8A wH/0EV3lcH4m/wCQ5c/8B/8AQRWOI+E1ofEZdFFFch1BVrSv+QnZ/wDXZP8A0IVVq1pX/IUs/wDr sn/oQpx3QnsejUUUV6JwBXl9eoV5fXNiOh0UOoUUUVzHQFFFFAHo2lf8guz/AOuKf+girVVdK/5B dn/1xT/0EVar0Y7I4JbsK4PxN/yHLn/gP/oIrvK4PxN/yHLn/gP/AKCKxxHwmtD4jLooorkOoKKK KAOy8G/8gyX/AK7H/wBBWt6sHwb/AMgyX/rsf/QVrervpfAjiqfEwrl/G3/Ll/wP/wBlrqK5fxt/ y5f8D/8AZaVb4GOl8aOXooorhOwKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvUK8vr023lW eCOZAQsihwD1wRmunD9Tnr9B9FFFdJzhWv4b1+78P3jT2exg42yI4yGH8xWRRTTad0TKKmuWSuj3 Lw14x03W9sQf7NeH/ljIep/2T3/n7V0tfNI4ORXZeGvHt/pmyG/ze2g4+Y/vFHse/wBD+YrqhiOk jx8RljXvUfuPZKKzNE1zT9ag8zT51cgZaM8On1H+RWnXSmnqjyZRcXaSswpsiLIjJIqsjDBVhkEU 6imI4LxL8PLW73z6OwtZzz5Tf6tvp3X+XtXmOqaZeaVcmC/t3hk7bhww9QehH0r6LqrqNha6lbNb 30CTxH+Fh09wex9xWE6ClqtD0cPmM6ek9V+J85UV6H4l+HU8G+fRHM8XUwOfnH0Pf+f1rz+aKSCV opkaORThkcYIPuK5JQcNz2qNeFZXgzD1bQbe88yWH91cHJyPusfcf4euea5W9sLvTpQZkZMH5ZFP Ge2D68Z9a9DpssaSxlJUV0PVWGQa550VLVbnXCq46dDk9M8SyQokd6hlRRjzF+/36569vT8a6m2u IbmISW8iyIe6nOO+D6H2rn9V8NKV8zTvlbvEzcHjsfX6+vaueVrrTbs7S8E6cH/PcfpUKc6ekti3 CM9YnoF3aw3cJiuYw6Zzg8c/WuW1Tw3LAvmWJaZO6HG4DH6//q61f0vxJFOfLvgsL9nGdp5/T/8A X0rfRldVZCGVhkEHIIq2oVVczvKmzz2yv7vTZSInZMH5on6Z75Hrx9a63Stdtr5hG/7ibsrHhueg Pc9KsajpVpf8zR4k/wCeicN/9fp3rkdS0S7stzbfNhHO9OcDnqO3A+nvUWnS21RpeFTfRnpWkate 6RcifT7h4X7gcqw9COhr0/w18QrO+2wasFs7jp5n/LNvx/h/Hj3r5p0vXbmxGxv38PZWPK8dj2HT iut07UrbUEzA+HGcxtgMPfHpXRRxPY4sVgYVfiXzPYvEvxFt7bfBoiC4l6Gdx8g+g6n+X1ry24mk ubiWeZt0srF3bGMknJNR0Vc6jnuTQw1OgrQQUUUVBuFYPjL/AJBkX/XYf+gtW9WB4zZRp0KkjcZQ QM8kAH/EVFX4GXT+JHHUUUVwHaFFFFABXqFeX12ui65DdJFBcOVujheRgOfb36enJ4rooSSumYVo tpNG3RRRXUcxnS6Jp8srySW+XdizHe3JP40z+wNN/wCfb/yI3+NalFTyR7Fc8u5l/wBgab/z7f8A kRv8aP7A03/n2/8AIjf41qUUckewc8u5l/2Bpv8Az7f+RG/xqW10ixtZ1mgg2yLnB3scZGO5q/RR yR7BzS7hRRRVElXVf+QXef8AXF//AEE15zXpV7E09nPChAaSNlBPTJGK8/1CwuLCUJcptznawOQw 9q5sQnozooNaoq0UUVzHQFFFFAHo2lf8guz/AOuKf+girVct4a1mGG3W0uiIwp+R+xyeh9OvXp/X qEZXUMhDKwyCDkEV305KS0OKcXF6i1QutIsbqdpp4N0jYyd7DOBjsav0VTSe5KbWxl/2Bpv/AD7f +RG/xo/sDTf+fb/yI3+NalFLkj2Hzy7mX/YGm/8APt/5Eb/GnxaJp8UqSR2+HRgyne3BH41o0Uck ewc8u4UUUVRIV5fXaa5rsdqjw2jB7rO0nGQn+J/ya4uuXESTaSOmjFpNsKKKK5zcKKKKAPRtK/5B dn/1xT/0EVaqrpX/ACC7P/rin/oIq1Xox2RwS3YVwfib/kOXP/Af/QRXeVwfib/kOXP/AAH/ANBF Y4j4TWh8Rl0UUVyHUFFFFAHZeDf+QZL/ANdj/wCgrW9XD+HtVGnzNHNk28hGTz8h9cfz/D0rs7a4 huYhJbyLIh7qensfQ+1dtGScbHJVi1K5LVW+sLa+2faovM2Z2/MRjPXofarVFatJ6MyTtsZf9gab /wA+3/kRv8aP7A03/n2/8iN/jWpRU8kexXPLuZf9gab/AM+3/kRv8aP7A03/AJ9v/Ijf41qUUcke wc8u5l/2Bpv/AD7f+RG/xqDUNE0+KwuZI7fDpEzKd7cEA+9bdVdV/wCQZef9cX/9BNKUI22Gpyvu ec0UUVwHaFFFFABRRRQAUUUUAFFFFABXaeFL4XFl9mYnzYB3bO5STjH06flXF1JBNJbzJLC5SRTk MKunPkdyJx5lY9MornNJ8SJJ5cN8Nj8DzR90n1Pp2/8ArV0SMrqGQhlYZBByCK7YzUldHJKLjuLR RRVEhRRRQBNa3M1pOk1rK8MqnKujYIr0Tw18Riu2DXk3DoLmNef+BKP5j8q81oq4TlDYxrYenWVp o+kLO7t723We0mSaFujocip6+edG1m/0a487T7hoifvL1VvqOhr1Dw14/sdR2QamFsro8bif3bH6 9vx/OuuFeMtHoeJiMvqUtY6o7aikBBAIOQehFLW554Vj6/4d07XIsXsA80DCzJw6/j3+h4rYopNJ 6MqM5QfNF2Z51pvwzhjvnfULwzWqn5I4xtLD/aPb8PzFdPqXhLRr6xS1azjhEYxG8I2uv49/xzW9 RUKnFKyRtPFVptSctjxTxL4I1HR980AN5ZjnfGPmUf7S/wBRx9K4y8s7e8j2XMSyAdM9R9D1HSvp 6uU8S+CNO1jfNABZ3h58yMfKx/2l/qOawqYa/wAJ6OGzS2lX7z5i1Hw3cQbntD58YydvRwOfz/Dk +lZ2m6pc6eT5DAoTkowypOP89PSvWfEHh7UNCmC30X7tjhJk5Rvof6GuY1PSba/Ri6BJiOJVHIPH X16d/wBK86dBxd46M92niI1FrqiLS9ctb4BXIhnJx5bHr6YPfr061q1wWqaNdaeC7ASQA/6xe3PG R2/lz1qfStfuLQpHOfOtxgEH7yj2P+PpjiiNa2kypUk9YG5qfh+2uVZ7ZRBNjjbwhPuO34eveuVv bK602dRMpRs5R1PBweoP+TXc2Go2t8ubeUFsZKHhh07fj16VZljSVCkqK6HqrDIP4U5Uoz1iTGpK GjOW0zxLIHWPUAGQnBlUYK+5A69un6101tcQ3MQkt5FkQ91PT2Pofaue1TwyCTJp7BeP9Ux/kfy6 /nXPpJdaZeNtLQzp8pH+eCKhTlT0kW4RnrE9GormrPxSmzF5Awcd4uQfwJ47dzU//CUWX/PK5/75 X/GtVVh3MnTl2N6uH8TX63t8EiYNDCNqkcgk9T/Ifh70uqa/cXqGKJfIhYYZQclvxx0/+vWNWFWq paI3pU+XVhRRRWBsFFFFABRRRQBraXrlzY4RyZ4AMbGPTjjB7fTpXWadqtpf4WGTEv8Azzfhu/59 M8V57RWsK0o6GcqSkeoUV5fRWn1jyM/YeZ6hRXl9FH1jyD2HmeoUV5fW3pniC5tnRLljPBnndy4H se/Xv6dqqOIT3QnQaWh2tFVLDUbW+XNvKC2MlDww/D8evSrdbpp6oxatuFNljSVCkqK6HqrDINOq K5uIbWIyXEixoO7Hr7D1ND8xHPap4ZBJk09gvH+qYn07H8uv51zNxDJbzPFMhSRDgqa3tT8SyTI0 dkhiQjBkb734Y6d/X8K592Z2LOSzMckk5JNcNTkv7p2U+a3vDaKKKzNAq9puqXWnkiBwYycmNxlT /h+FUaKabWwmk9Gd3Ya9ZXSfPIIJMcrIcD8D0P8AP2rVry+it1iH1Ri6C6M9Qory+in9Y8hew8z1 CivL6KPrHkHsPM9B1HVrSwyJpN0n/PNOW7fl171ymqa5dX2UUmGAjGxT145ye/06Vk0VnOtKWhpG lGIUUUVkaBRRRQAUUUUAejaV/wAguz/64p/6CKtV5fRXSsRZWsYOhd7nqFcH4m/5Dlz/AMB/9BFZ dFRUq86tYqFLkd7hRRRWJqFFFFABVizvLizcvbStGT1A6H6joetV6KNg3Ox0vxHDOFS9xDMTjcB8 h9Pp+PHHWt2KRJUDxOroejKcg15jRW8a7W+pjKinseoUV5fRVfWPIn2HmeoUV5fRR9Y8g9h5nqFV dV/5Bl5/1xf/ANBNec0UPEXVrDVC3UKKKK5jcKKKKACiiigAooooAKKKKACiiigAq7pupXOnyboG ypzmNslTnvj16VSopptaoTSejO60rXba+IRv3E3ZGPB57Hv24rWry+tfS9dubFRG/wC/hHRWPK8d Ae3aumFf+YwnR6xO5oqpYaja3y5t5QWxkoeGHTt+PXpVuuhNPVGDVtwooooEFFFFAHReG/F2paGV SOTz7QdYJTkD/dP8P8vavVfDnizTddVUhk8m6xzBIcN+Hr+FeEUqkqwZSQQcgjtW0K0oadDixGBp 1tdn3PpaivIfDXxBvbDZBqoa8thxvz+9UfX+L8fzr0/SNXsdYtvO0+4SVf4lHDL7EdRXXCpGex4l fC1KD95ady/RRXN+JfGGm6GGjZ/tN4P+WEZ6H/aPb+ftVuSirsxp05VHywV2dG7KilnYKoGSScAC uF8S/EK0st8GkKt3cDjzT/q1/wDivw4964HxF4p1LXXK3Mvl22eII+F/H1P1rBrlniG9InsYfLFH 3quvkXtW1W91a5M+oXDzP2BPC+wHQVRoormbvueqoqKsgrD1Tw7BdEyWpEEuPugfIePQdO3P6VuU VMoqWjKjJx1R51dW11plzhw8TgnbIpIB9wfxrb0vxKykR6iNw7SqORz3H+Hp3rqJI0lQpKiuh6qw BB/A1zOpeGPvPYP7+U5+vQ/kOfzrD2c6esDdTjPSR0NteW1zj7PPHISu7arDIHuOoqHVVsGhA1Hy tuCV3nB4wTt7+nSvPnUqxU4yDjg5H5im1Lr3VmhqjrdMsXy2y3DCyeR4exkAB/8A1flVeiiudm6C iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAfFI8Th4nZHHRlOCK2oPE17GEEqxSgH5iRh iPw4/SsKiqjJx2ZLipbm/ceKLpy4hiijUjAzlmHvnp+lYtzcTXMpkuJGkc92PT2HoKioolOUt2Ci o7BRRRUlBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAORmRg yEqynIIOCDXRaZ4lkVkjvwHQnBlUYI9yB17dP1rm6KqM3HYmUVLc9LtriG5iElvIsiHup6ex9D7V LXm1pdT2cvmW0hjfGMjv9R3rqtL8RwzgJe4hlJ+8B8h54+n48cda6oVlLRnPOi1qjfopEZXQMhDK wyCDkEUtbGIUUUUAFWLK8uLG4WezmeGZejocGq9FMTSaszqtS8da1fWKWxmSDjDyQja0n1Pb8MVy x5OT1pKKbk5bk06UKatBWCiiipLCiiigAoqG7uYbSEy3EgRAcZPr6Vy2q+JJZx5diGhTu5xuIx+n /wCrpUzmoLUuMHLY6LUtUttPA89iXIyEUZYjP+evpXJaprl1fEqhMMBGPLU9eOcnv16dKy3Zndmd izMckk5JNNrknVlI6YUlEKKKKyNAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAv6dq13YcQyZj/55vyvf8uvauu03W7S+2oG8qY/wP3PHQ9+v19q4KitYVXD0M501 I9Qori9K8Q3FqwS6LXEPufmXnrnv9D7dK6rT7+3v4i9s+cY3KeCv1FdUKkZ7HNOm47lqiiirICii igAoorK1TXLWxBVSJpwceWp6c85Pbp060nJRV2NJvRGo7KilnIVVGSScACuf1PxLHC7R2SCV1ODI 33Pwx17+n41zuo6lc6g+Z3woxiNchR749evNUq5p129InRCilrIlubia5lMlxI0jnux6ew9B7VFR RXObhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAU+KR4nDxOyOOjKcEUyigDp9L8S7QI9QUsc/wCtUD9R+fI/KunikSVA8Tq6HoynIP415jUk M0sDFoJXjYjBKMQcfhW8K7W+pjKinsemVUv9RtbFM3EoDYyEHLHr2/Dr0rhP7Rvf+fy5/wC/rf41 VqniOyJVDuzY1PX7q9Vo0AhhYYKrySPc/wCGOtY9FFc7k5O7N0ktEFFFFIYUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFAH//2QplbmRzdHJlYW0KZW5kb2JqCjE0CjAKb2JqCjw8Ci9DQQoxLjAKL2NhCjEu MAo+PgplbmRvYmoKNDUKMApvYmoKPDwKL1N1YnR5cGUKL0ltYWdlCi9XaWR0aAoxMDIxCi9IZWln aHQKODAxCi9Db2xvclNwYWNlCi9EZXZpY2VHcmF5Ci9CaXRzUGVyQ29tcG9uZW50CjgKL0xlbmd0 aAo0NwowClIKL0ZpbHRlcgovRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7d2NQtNIFwbgKQiLKAIi AgqI/HXv/wq/VT93VVpoziQzyeR5LmAttGdJmvPOmxIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANGKx8/rg6P3J 6enJydG7/b+2a78eYHg7hx8v7/7+w8P1+fHeovZLA4ayc/T5/s+5/8/j9Ye92q8Q6N/uh5v1g//T /fmb2q8T6NP20ZeXJ///83+6W/vVAj3ZOXvcdPS/+/K29isGerD3udPkf/f1Xe1XDWTaOe8++t/H /6D2KwcybJ8tY7P/j2vf/cNULY4ewqP/zeed2j8BELH/NWv0//H4weYPTM5u4Hu+p+4Oa/8cQCdb H+I3+7+7/qv2zwJs7vCZNd7OLgR/YCL2Nl7n28zDiVt/mIBXF/2O/je3dv5g7BYn3VZ5N3Vl4x9G 7e2TrH5flmdbtX84YJ2966FG/5uH49o/H7DS9tmQo//NzX7tnxF4YnE8zM3+7y5t/MLIvMne5d3M 46lbfxiR3csyo//NvY1fGIvt0752eTdz87r2Twx8c5gX3I24eFX7hwbyg7sRwr5Q2c4Au7ybuXXO F9TTX3A34krYFyo5GGyXdzPLc2FfqKDv4G6EjV8o7lXwSO6+3er3gpLK7PJuxsYvlDNccDdC2BcK 2b2qPe5/uj+q/TuBGRg+uBth4xcGllvCMxz1PjCkUsHdCBu/MJh+SniGo94HBlF3l3cz6n2gf72W 8AxHvQ/0awy7vJtR7wM9GqKEZzjqfaAnWwOV8AxH2Bf6MK5d3s3Y+IVsw5bwDEfYF7KMc5d3M+p9 IGxMwd0IYV+IGfMu72aW6n2gu5IlPMNR7wMdlS7hGY6wL3RRoYRnOOp9YFN1SniGI+wLG6lXwjMc 9T7woikEdyOEfeF5tUt4hqPeB54xneBuxMOxW39YaSwlPMNR7wMrTH2XdzM2fuFPUwzuRgj7wm/G V8IzHPU+8K8pB3cjbPzCd+Mt4RmOeh9oIbgbYeOX2Rt7Cc9whH2ZtXaCuxE2fpmviZTwDEfYl3na v6k9e/Wp92GGplXCMxz1PsxMq8HdCPU+zEm7wd2I5ZmwLzPRdnA3Qr0Ps9B+cDdCvQ/Nm0dwN0LY l7bNJbgbod6Hhs0puBth45dGbZ95vPcSYV8aNMfgboSNX1rTWgnPcIR9acp8g7sRd279aYVd3q6E fWnD7IO7ERc2fpk8u7wxwr5MnOBunLAvE7Y4scub42q39jsIMXZ5c6n3YZL2rmuPTguEfZmcuZXw DMfGL5MiuNsnYV+mY54lPMN5FPZlGnYvaw9Le4R9mYB5l/AM54tbf0buUHB3KMK+jJng7pCEfRmt Hbu8A7s9qP0ewwqCuyWo92F8lPCUsTwX9mVUBHfLsfHLiCjhKev2Te13HL6zy1uejV/GQHC3BmFf qlPCU8v9Ue33nllTwlOTsC/VKOGp7bNbf6oQ3K3Pxi8VKOEZB/U+FGaXdzzU+1CSEp5RUe9DKXZ5 x0a9D0Uo4Rkj9T4MTgnPWAn7Miy7vONl45cBKeEZN2FfBqKEZ/xu9mt/SmiQ4O40CPvSN7u8U7FU 70OflPBMiXofeqOEZ2qEfemHEp4JUu9DPiU80yTsSyYlPNOl3ocMgrvTZuOXKCU8U6fehxDB3RY8 HLv1pyMlPK1Q70MndnlbYuOXzQnutkXYlw0p4WmPeh82ILjbJhu/vEAJT7vU+/Acwd2W2fhlLSU8 rRP2ZaXFiV3e9qn34anFp9qfS4qw8ctTO8cWeudAvQ+r7Jwq4ZsBG7+ssjiw4jMDl7u1P2iM0l8X vvlrno1fVts5M/7Ne7Dxy0oSvTOg3ofV/rLx0z5hX1Z7c1v7s8nQlh/c+rOKlM8M2PhlNfneGRD2 ZTXHeM6Aeh9Wc6ZX+4R9WU11xwzcvq39MWOcXintap+wL6u59W+feh/WOJT3a556H1Zz6z8Dbv1Z zRl/M2Djl9Wc7ts+YV9Ws/E7Aw/HtT9mjNO2rH/7bPyymi6/GXDr35LF7pujk48Xn//x6fz0/bu9 jIe6BzZ+m2fjtw2L18efbp9erD9efzwIJjoWJ48VPo8UdXfQ78eQ4naOr567Sb/9+Cb0f3gbvzNw vdf3p5FyXp1s8Gzu8SJ0lpuN3xmw8TtVmx/Bf3cSeZNt/Lbv4b1b/+nZOu70rdzyPFDjsHXqsV/z bPxOzeJ992Wci8DTnR0bv+27Uu8zJYehZ3HLj4GL/30bv80LfTCoYu8m+i6HMp02ftun3mcaFlnR 28gd3rZb//Zp9p2C15/zRvFz4Nbfxu8MRD4YlLZ1eJnzJi9PA5nOt+p9mhf6YFDcq5Oc9ftIplPY dwbu3fpPwuIgZwMvkunc1uzbvi82fqfhdc7VfyTT6dZ/Btz6T8RexviHMp3Cvu17PLHxOw2vMy7+ IwWui2Nh3+bdafadiJw/xpFM56tP/X3KGKkr9T7TkPXHOFLgKuw7Axc2fqch5+QNt/6s9ODWfyJy /hjfBo5zUu8zA8K+U3GYsYMTucPbcc5X+9z6T0RO/CZU4Crs2z71PlORs4MTanHJudpgGtT7TMXb jC/iIplOYd8ZuAmd/0pxWQfuBxY7D5zxOQOfbPxOw6uM+E3XOzy7/jMh7DsVOY/9umQ6VXrOSGQV nBpydnA2DfvK98+MZt+JyNrB2ejW33O++YmsglNBzg7Oyxu/u47znyPNvlOR87f5+Uyn3d7ZiqyC 083Wznd5X7EujofZ+FXhN2fqfYay2Hv34dPN/b9/WJf3Xz+fvtuLXmzlfB+/PFu98fs63BhCE9Z9 MMiweHN6vWZDZ3n94U3sfwB/ZW38Pv03neSBep+ebR9cvLCat7w8DN0FvMm49f8z05m1P0g71Pv0 581mJTzLz5Et68X7jIm9/PUOzxEe/OSM315sd+nfuD0O/PnP2vj9d7Fz7zr+X6E5Nn7zbZ92/Lv8 cBL4pWdt/H5/7Kexgz/Y+M2z/TFwSf7wPvDl37usjd+sWwdade2xX1x0Pf4udOpexvx6ss8qSyt/ QTnX4teRU/c8pqNvN/74ByxO8nZkHbjPGCwd89XZTvYchm79j1zA07MLl/7dvOvjC7TIqsXWR6Ec +vVF1LeLDz392i8Dd1y7OcXe8NSd4/03tujvm7fQgfs5G7/w1INTfja01evXbpGURVbYF554dLz3 RhZ9r8lGzlW3sEevlqZ/A4sBbrkvAykLx27Tp0dX/i8bZNMmVKmWU+8Df3jwrd9Lhrrcvn/X/bWI 59OjOyf8PO94uN995Fz1nLAv/O6LbZ/n7A26YRM5YMHGL7256H9i2rE98F126Fx15/PQFwn/9Ybf rXv+wP3VHMNPTx5l/NZ5X+L3/8yB+2vtKOChF27719gp89166Fz1t/7404eT/uemCcUCNQ8nXf// q4SHfiyd6rvKQcG34M8D95/nG396czXU/EzZVtk/rpuHfZ3uRZ9UeT71sfB7sPy40cbvIudcT3ji 1nd+f9ouP2MPG5yuZr+fvmny+9NpjbfhpY1fJTz0716Vz+8q/OH/7rmw7/ZZnddE45zn+7u+Du3r bG2l2uLYzT6DuCs7W2O3VfHYrLuVYd+3t/VeEY3zhf+vBkzybuDL3p+vxzE+DOhLjRkbrdrH5f5e 77N9apmXIcn3/Od17Tfj78df6n2i9aCwodOKwzY2Y/ha/efG737tqxDad1933kZlHLGZb82+Oxe1 XwVz4CDvn+pf9f+wPHOzTxEfa8/caFR7yA913NaeudGwRMvc+L7/hy3X2syNdM8Pb2q/EVCaU7x/ qBLog5rs9//gkCzm59XLgzEH0nPMz5vaYzcKO7XfBihPqP+bt7XfBijvvPbcjULdOC9UcV177kah 9LG9MAJ2/L5xLD4z9Fh77kbBoTnMkTN8/3FT+12ACpT2/UMtBnMUqIpvj+Fnjp6cGjtHTsxjjl5o i5oHw88c2e9Nhp95MvzJ8DNPhj8ZfubJ8CfDzzwZ/mT4mSfDnww/82T4k+Fnngx/MvzMk+FPhp95 MvzJ8DNPhj8ZfubJ8CfDP7zbA+3D42P4k+Ef2uOHRUqvLmq/DP5g+JPhH9jF/6thXitGGhfDnwz/ oG5+SY0f3td+NfzC8CfDP6D7w99+01sf3PqPh+FPhn8wy9MnB8Tufq79ovjJ8CfDP5TLlcfDvvla +3Xxg+FPhn8YN/trft2LI7/wUTD8yfAP4eG5Dtjts9ovj78N/3eGv2/LsxfaYHa1JNVn+JPh793V BnUQb7Ul1Gb4k+Hv2e3bjX7ri+PH2q905gx/Mvy9ejhZbPp7f3Ve+8XOm+FPhr9PF9tdfvN7Nn4r MvzJ8PfnunP344Fb/2oMfzL8vXk86P7L3xL2rcXwJ8Pfoy+B8scdYd86DH8y/L36GeDtYt/Gbw2G Pxn+fn0/uqOrQ+9BeYY/Gf6+3QZu/bfd+hdn+JPh798mK35/2r2s/arnxvAnwz+A5Xmn5/0/CPuW ZfiT4R/Es7G+NWz8FmX4k+EfyG3gwyXsW5DhT4Z/MKuP8nne3nXtVz0bhj8Z/uG8mOtfRdi3EMOf DP+Q7o+6vx+LE7f+JRj+ZPiHdRPY+FXvU4LhT4Z/aJ8jt/7CvoMz/MnwDy628aveZ2CGPxn+Au4O X34b/qTeZ2CGPxn+Irqf85HSjnqfIRn+ZPg7uM74Y2zjd2QMfzL8G7t5nRW/6XC257/U+wzH8CfD v6H/b+vn/DHe8FTv3wj7DsXwJ8O/kf+W9bLiN8K+42H4k+HfxNXuL7+wnPhNaOP3zW1/Pwk/Gf5k +F/25HI9J34j7DsShj8Z/pes/KIuJ36ztr37GcK+vTP8yfC/YE0JT1b8Rth3BAx/MvzPemY5Jyd+ szwV9q3N8CfD/4wX1nJz4jf3kY1fYd8eGf5k+NfaIJCTE78R9q3L8CfDv85GUdys+E2k3kfYty+G Pxn+1Tb+u7ybEb8R9q3I8CfDv0qn47dyuvYi9T7Cvr0w/MnwP9X1u/is+E0k7JtztcH/Gf5k+J+4 6f4Ufvss/sd4eRYJ+9r4zWX4k+F/KnLq3u5V/N97OBb2Lc/wJ8O/QuiLuJwdnFi9j1v/HIY/Gf6V IqfuZcVvIhu/OVcbGP5k+NeIfBH36jz+76n3KczwJ8O/1ppIz7OyNn4j9T7CvlGGPxn+9SKn7uWF fSMbvxlXG7Nm+JPhf07k1L2s+I16n2IMfzL8z4ucupcTvwk9aDhw69+d4U+G/wWhL+Jelw772vjt zPAnw/+iyKl7WfGb673u/56wb1eGPxn+DURO3Sse9t2/6e8HngPDnwz/RkI7OBnxm9CDBmHfLgx/ MvybCZ26p95nxAx/MvybinwRlxW/Ue8zKMOfDP/mIjs4efU+mn2HY/iT4e8i8kVcXti3+7+3OPaO bsLwJ8PfSfGwr3qfoRj+ZPg7ipy6J+w7QoY/Gf7Oiod91fsMwfAnw9/d8rx02Lf00SJzYPiT4Y8I 7eDkxG+EfXtn+JPhjwmFfXM2foV9e2b4k+GPutrt/rveEfYdDcOfDH9YKOybU+8TOVVU2Hcdw58M f4ZY2LdwvU/O1UbLDH8y/FlCOzg58ZvIqaI5VxvtMvzJ8GcK7eBkxG9iYV9v8hOGPxn+XI/CvpNk +JPhz1d8ByfyoEHY9w+GPxn+PpQP+xa+2miQ4U+Gvx+RsO/edfzfi4V9bfz+x/Anw98TYd+JMfzJ 8PcmFPbNqfeJPGjIudpoi+FPhr9Hxet9hH3jDH8y/H2aRtg352qjHYY/Gf5+PRwXPnD/SyTsa+PX 8H9n+Pt1G/hUFa/3EfY1/N8Y/r6VrvcJPWiYfb2P4U+GfwDFd3AiDxrmHvY1/MnwD+L+qPsbUb7e J+NqY/oMfzL8A4lt/Mb/GIceNMw57Gv4k+EfTOTUveL1PjlXG9Nm+JPhH07xjd/Ig4acq41JM/zJ 8A+peNhXvc/GDH8y/MO63uv+jmTV+0QeNMxy49fwJ8M/tNI7OKEHDTMM+xr+ZPgHp95nlAx/MvwF qPcZIcOfDH8RkR2c4vU+87r1N/zJ8JdRfAcnVO8zp7Cv4U+Gv5RJ1PvMKOxr+JPhLye0g1O63uf1 XG79DX8y/CVNo95nHmFfw58Mf1Hlw76lHzRMhuFPhr+w4js4wr6rGf5k+ItT7zMKhj8Z/gpCOzil 631aD/sa/mT4a1DvU5/hT4a/jsgOTvF6n6bDvoY/Gf5aSu/gLNX7/MbwJ8NfT2QHp3i9T7NhX8Of DH9FxXdwhH3/Y/iT4a+q+A6Oep+fDH8y/JWV3sEJPWjIOVpkrAx/Mvy1hXZwcsK+6n2+M/zJ8NdX fAcn8qAh52iRUTL8yfCPQWwHR71PDsOfDP84lN7BeTiOPGho6bNi+JPhH4niOzjFjxYZGcOfDP9o TKPeJ+NokXEx/Mnwj0jpHZxZh30NfzL8o6LepxjDnwz/uBTfwSl9tMhoGP5k+Mem+A5O6aNFRsLw J8M/PqXDvvOs9zH8yfCPUGwH5yb+D4YeNEy83sfwJ8M/SrEdnIyw7/Ve939v2vU+hj8Z/pGK7OAI +3Zg+JPhH63QDk5G2Dd0tMh0w76GPxn+8VLvMyTDnwz/mBUP+0aOFplo2NfwJ8M/buXrfeYS9jX8 yfCPXfmwb+BDNMGwr+FPhn/0HkuHfUNHi0wu7Gv4k+GfAGHfARj+ZPgn4UvpsG/kamNaYV/Dnwz/ REQ2fl/nbPy+6/7vTWrjN3Bv057JbmnMjLBvvwL7zO25rf0usCFh3z4Ffrb2TOpGbeZK7+C0HPYN 3Ea1Zyr/p+bv4A5Ozhdxd81u/Aa+0WzPp9rvAl0UP3C/9NEipXT/qRr0sfa7QDfFD9y/CFxtjD7s e9f9Z2rQ+9pvA11Fvoj7q3S9z1HG0SIFXHX/iRp0UPttoDNh32xn3X+gBu3WfhsIKH7g/tVu4KOV cbTI0CLxpQaN+f/PrFU+7NvUxq/t3u9G+/7wvOL1PqF80UjXx+34fJeR/6Cq4js4obDv2RgvLe+7 /yBNOqz9RhAW+WO8lRO/KX20yFA+df8xmrRT+40gQ/F6n9JHiwwj8H1pm0b3ztBF6Xqfu0C+aHRh X7f8/+emf9pCB+7n1PuUPlqkf/b7fnpb+60gU6je52PGF3GRq40xbfyed3/5jVqM7JKM7iJh35wd nOJHi/TLMT7/GvEiFhtafozs4GSc5BLa+B3JGb+u+v/jur8Fk6j3GUfY97T7C2/XuANYbKj0Ds6y 9IOGvgT+r9Wu09rvBv0IhX0zznJ6iDwvz7na6MVN4EW3a2cct2JkC8VvcnZwih8t0oPAqeQtc5ZX M4qHfUMbvzW/Y74LPKho2V7F94KeRcK+WfU+Ewv7Wu39wwizF4RFwr6vc8K+kXqf95Vu/f3h/9Ne nTeCYaj3Wc8ZPk9Y9GnLXSTsW7rep0bY99Yf/id2feHfmFC9T87GbyRfVH7j1/ldK3jW35zIgfv7 OfU+oXO+yiZLPnd/iTOwNZrUBX2JhX1L1/uUDPs+CvKv9Kbge0AhkfhNy/U+77u/unkYReaCnl1G DtwvXe+Tc7RIF19827fGVkbAk9FS7/OvBxf9a+35xr9JobBvVr1P5EFDgQvPwP+V5uNk+N8/NRTf +I0cLZLzoGEjYvzPEvBp1afAFe9eRtg3ki8aOOx77Yb/WYsRnLTAIJalD9wPHS0yYNj3a+A5xLy8 8rS/WXeB+M3Wh4xb/8jVxmAbv3eBsNPc7DjSq12hW/+ML+JCVxvDhH0fAk885+ev2ocsMaBpNPv2 v/H7GPjf3hztmf6GPb4vXe+z1/3f633j99FB/RvadeXfsttA117WDk7oaiPjQcNT94H/Ac3VjlW/ poXqfS7j/17oauNdf189f7XY18G2U72atjwLPPYqvfG7yHnQ8KvLwLeOsybd37ZI/Car3icU9u1j 43f5ofs/PHeH2jvb9jVy4H5OvU/kauN19tLZna/5A3Yt+zUuVO+TE/aNbPxmhn0/WesLWYykUpWh hHZwck7d+xp44pbT7BupE+KHv8qdsEIVoR2ck4w7wtAZv8EHDctTSZ4c1TsVGdgkNn5fB576L88t 82fK+YqHSfg0gY3f9KbjN1DLC8/2e5Cz3cEUPJa+9Y9cbaS9i83/DD2cGv2evLXw17i7yMZvzvfB kauNtPNhow/i8vKde/3+LN576N+468D2e/F6n3/+/H98Yf6XV0ce7vVsu2SxAjWcl673CVxtfLNz +GnNHcfjl9N9f/OH0G/MivEJxW9Kb/z+sLV/fHZ58+/6z/L2+uL0wGkdA+oxZsUohep9Pmbc+keu Nn612H61s+0yv4Ss7Q6moHTYN1QmSBW9xKwYsWXkj3HpsC91FOxUpIpYvU/GrX/kaoM6SnUqUksk DrN9Fv/3QmFfqijTqUhFl4XrfSJXG9Sxm7HdwRSEmn1L1/tQx+CdilQW6drLOnA/crVBFVnnuTEF xZt9I/kiqhD2bV7k5I3iYV+qyDnPjSkIxW+y6n0ctzkZOV/xMAV3gT/GWY+D3PpPxhCdioxKJH6z k7EJ+vjBxu9U2PhtXumN32jYl/Js/LYuFL85rBL2pbR3Nn4bF9v4LVzvQxU2fptXvNnXU//JyDnP jSlYfoxs/Gac/Xof6BKljn3dfo2LhX0zHgc9fHDxPxU2flsXid9kPQ56/Oix/0S49W9e6bDv339f Hbj6n4ZdG7+NW34I3PrnPQ66P7P0Ow3qfVp3/677pyL3mvDupP9PKv0T9m1e6Wbfv//+7Ju/iVDv 07yLQNde/HHQXWDFiFrU+7QuFPY9CC38P0SahKgop8GZKQjFbw47fyweT13xT456n+ZFNn4Xh53+ +t+fGP1JevVpqE8d4xCL37y53PSb/+tDF/yT9drGb+MeQvv328cbfDBuP1jumzb1Pq37Gvsmfufo 8zO3hY9XxyZ/+rZObfw27nI39tFY7B2d3zz5P8DjzcXxnqv9Rgj7ti7rwP1Xr98dn3w8/8fZh+N3 +4H9AcZMvU/rdO2xVs55bkyBrj3W2Xbr3zoH7rNOznluTIGuPdbKOcqdKdC1xzrqfZoXCfsyD9tn tT+dDCwS9mUehH1bp2uPtTT7tu5W1x5rOOO3eZGwL/Og2bd5bv1ZR7Nv60LNvsyDsG/rIs2+zINb /+bZ+GUdG7+ts/HLWjZ+W+fWn3XU+zTPU3/WUe/TvBvjzxqafZt3FzrklzlQ79O8+1Pf/LOSep8Z uDrw559VXrn1b9/DxVvzzwqvbfzOwK2rf1ax8du65Ue9m6xm47dtkr48Y0fYt1m3b2t/uhg59T5t sufLBtT7NMjhHmxEvU9rrvdqf6aYDGHflujyoBNh31Y4ypuu1Pu04bOtHrpT7zN96rsIUu8zbfdH tT9BTJh6n+lanjnAjxzCvlPl6F6yqfeZIof20wv1PlPz4Ngu+iLsOyXLc8Fd+iPsOx3Xgrv0a/dz 7Q81m3BMPwMQ9h0/u7wMQ73P2AnuMpjtM7f+42WXl0Gp9xkrwV0GZ+N3jJRxU4Kw7/jY5aUQ9T7j crNf+xPBjNj4HY+H49qfBmZGs+84CO5Sno3fMVDCQxXCvrUp4aGa/ZvaH/85U8JDVcK+1VwI7lKX ep86BHcZAfU+5d3Z5WUc1PuUJbjLeAj7lqSEh1FR71OK4C6jI+xbghIeRknYd2h2eRkrYd9hCe4y YsK+w1HCw8gJ+w5DCQ8TIOzbPyU8TIOwb98Ed5mMHWHfHinhYVLU+/TFLi+Tc2jjtw9KeJggYd98 dnmZKGHfPEp4mDBh3zglPEybjd8ou7xMnrBvhBIemrB3XXuUpkYJD80Q9u1CcJeWbJ249d+UXV4a o95nM0p4aJCw78uU8NAo9T4vUMJDs4R9n6OEh6btfq49YmOlhIfm2fhdRXCXOVDv85QSHmZi+8yt /68Ed5kR9T7/UcLDzNj4/cEuL/Mj7PuN4C6zpN5HCQ+zNe+NX8FdZm2+9T5KeJi7uW78Cu7CLOt9 lPDAd3Or97HLC/+aVb2PEh74xXzqfb7Y5YXfzaPeRwkPrNB+2PdRCQ+s1PrGr11eWKvleh/BXXhW q/U+grvwohbDvoK7sIlFc/U+bvZhQ23V+wjuQgfthH0fju3yQidt1PsI7kJ3LYR9lfBAyNTrfQR3 IWzKYV/BXcgx3XofwV3INM16H7u80IPp1fsI7kJPprXxuxTchd5MKexrlxd6NZV6n5v92r8paM4U Nn6V8MAgxl7vI7gLQxn3xq8SHhjQeMO+t29r/26gcfs3tcd8lYcTu7wwuBGGfS8Ed6GEsdX7CO5C MWOq97HLC0WNpd5HcBdKWxyPIez72S4vlFe/3kdwFyqpW++jhAcqqhf2tcsLddUK+wruQnU1wr5K eGAUSod9lfDAaJQM+yrhgTEpF/YV3IWR2SkS9lXCAyM0fL2PXV4YqcNhN36V8MBoDRn2tcsLozZU 2FdwF0bvzW3/o6+EB6ag/41fu7wwEf2GfZXwwIT0F/ZVwgMT00/YV3AXpmfrJP/W3y4vTFJuvY8S HpisnHofwV2YtHfBW//lmeAuTNviODL+nzzZh+lbvOt48b+88D0fNGL/0+bf/D+cCu9BQ7aOrjYJ /C0/v/U1H7Rm+92n5/P+9+cHVnqgUbuHFzer7gCWX88P3ehD63beHn24uLy6+Xp7c/Pl8uL0/Rvf 7QMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALDK/wAeQ2T+CmVuZHN0cmVhbQplbmRv YmoKNDYKMApvYmoKPDwKL1N1YnR5cGUKL0ltYWdlCi9XaWR0aAo3NzUKL0hlaWdodAoyNjIKL0Nv bG9yU3BhY2UKL0RldmljZUdyYXkKL0JpdHNQZXJDb21wb25lbnQKOAovTGVuZ3RoCjQ4CjAKUgov RmlsdGVyCi9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJzt3Xl0FEUeB/BJTALhUA45wi1H5PDgRhCF SFRUor51oz6P+NB9+DzjW11Z3y5unosa1AfEYx94oAaUQyFilFUDghdnUFxUDhVXQFyUgKLhSCDZ hCEhU9U1U3f1zHw/f2p3V3Ux30xP96+rAgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAiFZtLs+b++6aZQun5/R23RUAJxrdXHKkut5XeR1ddwjAtpQ7d1SHOvQMggDx JfOLalp5fjPX/QKwJv0tjxDU2pGT4LpvAFa0yD/MSEGN1cNcdw/AvMSc3ewQ1Dha2M51FwEMy/g8 bAhq/ZbXyHUvAQzqXBgxBLW2ZrvuKIApTfMOcqWgxtIzXHcWwISE7O95Q1CjcuaprjsMoN2QTwRC UKssN8l1nwG06jDzqGAKamwa67rbAPqkTtwvHoJaxd1ddx1Ak6xtciGocbjgZNe9B9BgwAfSIai1 a0Ki6zMAUNS64Ejkj3p4pSNdnwSAiuTcX1RDUKNqQVfXJwIgzbOcWkZ5XqrrcwGQwiynloESbIhG YcupZaAEG6JNpHJqGSjBhuiSsUF7CGqhBBuiB2c5tQyUYEN0ECinloESbPA/sXJqGSjBBr8bLFpO LQMl2OBnUuXUMlCCDX6VkitZTi0DJdjgSwrl1DJQgg3+03+F1RDUQgk2+IuGcmoZpee6PnGAOnrK qWWgBBv8Qls5tQyUYIMfpBc7DEEtlGCDa9rLqWWs6O96GCCemSinloESbHBntJlyahkowQY3DJZT y0AJNtjXxGw5tYwSlGCDVebLqWVUoAQbLLJSTi2jLPck12MD8WLUXtcfd7YNo12PDsSLxtnLXX/c 2V4/zfXwQNwYrTZBr0kHH8Yq42BL1jeuP+9MP6AEG2xp9MBvrj/vTJjiDqxJs/XusbiqBV1cjw7E jUEfuf68M5XnNXY9OhB7krv27t6B+q8J1+9w/Xln2naVg2GC2NXmT69sr6r9ZO37ePIg4v81feiA 68870/KznQwXxKKBcw41/GxtupGYLavrfFcf84iOzGjjZswgxpxK/w7eeiWxzfmfuviMc9l3T7KT YYPYkppdUkV9uN4/K3SjxJz/OfiI89kyzs3AQYzpW0h9IRwtbBu6TdO8Q16fQV8o6WdoYBqde/fz RStKuax5Z96Uq9Un0ujDOPwjXHufxth7Gnf7nVZ7u1f2hOr0uv7x+e+t5RvLOgNUGxXUfyn12Sq7 i/iJ4PzlfLaKqS0MDErGi/uEe7L+fsVi8MGMA8/l2rsfY+/F3O33ZBzhadkTOqbDg1LTm5yv1KiM rG+pTmy+jNhmzH9kzsUK/SXYYyQfmfw2pbVKs2oxOIOxt9sYpD0p+Q6X/RgEUieVU914s1foNsl/ oX9G+MVno3SORs8F8j3ZNzFFvuHYi0FK7q+yI+kgBjXfXIXUh7yi4JSGW/i43K5a5yzYqj+EtpDf o/zUYnAmY+83uNvXHgOPywxuTmIQCAxZSfVkz4mrjd5L5E/IisMFzXWMQmLOj8pdkf7VHmMx6P1v lVE0G4PU0bkvFJWUFE6+lryMTRy/i+rL+pHH/lfrZypVzsiOnTeoT3E3dJWOnhDfo9zUYnAWY+8i 7va1xqBVgdpnxmQMMl48ca12ZNV44jq2eT51PVA1r0sg+W4fv5nZ0KqhaqPTkb4ylLRH6ld7DMUg acLPikNoLgbDyIUKduYSj2F7FFHdKZ/6leIJ2VP1L4WX05pM1PmOxacS/4xqMTibsbeLGIzZqDyA pmKQ8rTH37rNl+o/AZe2SX8hZH2nuSvFwi9Oq8WgP2PvRdzt64pBL4VbbfUMxaDzau/mlvQO3S7p jj0aTsKZ8iukRmfgh/q7ciBf8Fd7bMSgmZ6aAzMx6MhcvqxiGvEYttWTUfCDmOmIxJsISVPMvGq3 bbBQN9RiMICxt+UYZKjfajvGSAyahXug/dOtxA+6vu/qORUnDgwXHZzEt0315dAYkX6YicFC7vZ1 xOBaXUuEGYnBK+Hb3JBBbJ+1VdPZOPBDS8HBmWSuL7vbC/RDLQYDGXtbjUG6ttsMJmJwZcRWiZmw mjyq63QceFlscJpLP/DnMFmgI2oxGMTY22oMZmkYsiADMWjEMTtvw5mwEq7z71vIPMQui8ab7MoO gY6YicHr3O2rx6ARXZsmy0AMbuNquH4x4oH+nZOCzxKh0XnMaF8EVjpXiwFrb5sxSNcwYMcZiMFm zqbXnFOzcdos385QxE2oqme20a6czt+R6I/BKPXxqqM/BsO5266a3X3ifn2n4ozIFXlgjtGu9I7c gTpqMRjC2Ps17vbVY5ChYcCO0x+DaP65K2eLyPDESAyGMvZGDI5jPD+OZSJzt5iNgbWLIlYMFnC3 H9sxSNT38z1qjBUYnxiJwTDG3ohBUGd9fYsadwmMDysGYjNnz2McBTGo8Sz3Ecxh1VzFsn8IjI+e GLCm90vnP4RaDM5h7D2fu/3YjsFIRt9i2VSB8dETA1ZxsbUYsO4HIgZB5zP6FssKBMZHTwxeYxwF MahGDFyxH4PXGUexFoMRjL3ncbePGMQa+zFYyDhKr8i71kEMTLIeg6p56203SbIfg0WMo1iLwbmM vRGDINsxKB0ZSNAw3Y8S+zGgJzMIch4Dvr1rIQb67Jpw7FU2x7Ng24/BG4yj9OQ/hFoMWDcEEYMg mzGoKKgvLFaZClSZ/RgsZhzFWgzOU9q7FmKgSXGPhg1f4G4WbMSg3qvc7SMGemwmJ3u5q8xa26Hs x+BNxlF6RN61jloMWP/MiEGQxW+DypnEShctFWeylGU/BqyFUJzH4BXu9hEDbcpyiYVyTjc2+0k4 9mPwFuMo1mIwirE3YhBk+YbpJrLIOdPBJKj2Y8BKu7UYjGbsjRgEWX98Rq65kSy/5oks+zFgLQAh sP6ImRjM4W4fMVBBv9XTcLKXY9rbfs3ffgxYa1pYiwHrI4gYBJmNwdHCdsPotzzrJ3upY2Ku3DDs x+AdxlEQg+o4iMHq2jldvFYQLz2X6Ib2mdPDsR8D1rSvAtO7q8XgAsbes7nbRwwk7cg5vtCSx2ze VQuIBbNTta6jEZ79GLzHOIq1GIxh7I0YBBmLQXl+g58AHms7lOelhvZE36pKkSAG9RCDIFMxWN8p tJ2x9I3R7/5I9GVkqaHOEOzHoIRxlG78h1CLQSZj70Lu9hEDKcXEPXGvdd9W9A/dxlIJtv0YLGUc pRv/IRADk8z9NmhQTxrksQro0cJ2ods0zTtorEP17MdgGeMo3fgPoRaDCxl7IwZBJu8UHX+74ASP NaF/y2sUuo2FEmz7MXifcZRu/IcwEwP+1R4QA3mlI4nmsr6lttmaTWxzwedG++QiBssZR+kaedc6 ajG4iLE3YhBk+CkydWM0xaN2ouSM0G2SJvxktFP2Y0CuOV3HWgwuZuyNGAQZrykKuXFaK20mVTtR QZVg5x822CX7MfiAcRTnMXiJu33EQFH9Y7Q6gz6mtinLJX5GmCzBth8DVrFIF/5DqMVgLGPvl7jb RwyUHSuqaCAh+7/UNl9dTPQs80tT3bEfA9ZCWc5j8CJ3+4iBOurGaJO8A9RGdAn2L2Z6E4cxuISx N2IQZOt9g9/JG6Od6NqJw+SThtYFutaTDmE/BvRVYFBn/kOoxeBSxt6IQZC9126+Jm+MjvqM2sZO Cbb9GHzCOIrzGMzibh8x0GXpmaFte5Vgr7NQgm0/BisZR7EWg8sYeyMGQVZfwqycSSw75qYE234M VjGOghhUx2EMPOam8CzBbhy6je4SbPsxYK2z2CnyrnXUYjCOsfcL3O0jBlptuoToQeZGahvqScMQ 1lWFFPsxWMM4irUYZDH2RgyCHKxv4LwE234M1jKOghhUx20MvEqwqRujJkuw7cdgHeMoHfkPoRaD yxl7P8/dPmKg389k7UQfugR730TiSUMPXSXY9mPAeq0OMaiO5xhUV6+XKcHO0FOCHYcxuIKxN2IQ 5G7ts+JuoT3xLMHuF7pNYo6OEmwdMdCjA39HWDFQ8xx3++ZiIKEP/7jxcbgEoLMSbMSgXpTG4Hz+ cePjdCXMneSN0cFWSrARg3r8FySIgUFrXJRg+ycGafwdQQwaiLUYVFcVtg/tUBOPG6OaS7BFYjBb paGIBL4NBhrpwEzu9tVjMEpft2MuBi5KsEVi8JjKqUUk8G2QZqQDk7jbV49Bur5ux2AMvEqwN1Db /ECWYA9gvd8bmUgMxqucWEQCMUjYa6IDV3G3rx6DRvQk/7JiMgbV1cukSrC3SbYmEoPmRhchaR+5 A/WmG2j/58aR2z1OPQaBF7T1W3sMRmjrmpLKJ1uF9qvF1Apym6qXiUvp1Afl/r5MExmgScrnFobA t0Ggi4Gvg1z+5jXEIF1bxbz2GPTT1TNVe6kSbHr5SE0l2A+JDFAia/k+HUS+DQLjqD8MquYmRG61 joYYBK7R9U6t9hh00NQxDTZmEn27dDO1zTbyYnYEq2otjLuFRijpMXNrUpELIoY3fLvWxo/kJUZu s56OGAQyNNUJa49BgqHZH6SUEA/Jkz1KsJefTZxAtvCHQ+zDFwgMZE0soY6sKAnP62ayNHIgI9AS A6/XDWVojwFzXkEnDuU3D+1dm5nU9+iRGUR9RfN8saGtEroUOSaLfqinyQGyoiS8zoWa2t2eIzgE emLg+bqhOP0xeFhDrzT6cTzxTd2fzum+e5JDt+lRJNLElxKj1MTcmlRURUl4o+mbyeJ+J39kRaYr Bp6vG4rSH4P+yn3SbP15RA89SrC3jCO2ESnB/qfUOHk81NNlzXCRjiTm7FZsr2qBwDRhdfTFwPN1 QzH6YxBwsEx9eFWvEhM2NP7b79RGb59ODO3te3gPT+zJbShrfgllVEVJeC0ErwIJa0fInL3GGHi+ bijEQAzMPieVQl0wd9BYgl0kPVJeD/U0EbxKSadvJvOiHsdz0hoDz9cNBRiIQRJ9zeHe99cSF8zn 0JM7/EQuptOXtfxwQ0eIl/2FNNVzo8MLVVESXuYXUq0cLmge+dieNMfA81qXm4EYBMbaWohVyEeD QnuZkPMDtc1no8ih3RrxuE+pDZaWGx3eyIqS8KSqbIsFVqAlaI+B5+uGnEzEQGOth05Hnyfmpmj2 CH3X/LVuxNDeF+HDsUno/qSXTGNPEaiKkvDaPkH/ZAqrhHz/W4T+GNRc6z4l+RzESAyasGaTcuzX +1NCO3raQmqbg5Obhm7T7rlwD31/IV5uljJ6lpFqzxp77kiK3PwJbf5Kz4bM8vMMsVkESCZiUBOE SVJ3T43EINDuG5m+WPD15URPPW6M7ryB+BkxgD0L9gHyKkpSyoi7nitaUUr4qIQmegH8qdAXQiDQ 7Zop895dS/Yk1PJFM24fJpQvD53WeLtP8biBntc9Pv+9deHPgDRAtVFv7S2tTy9u2VmhPfW6a76O vAPIKsEuIx9JmOdVDxIGuRoiWNVsvtSH1ILKp4i/jy2nc5RgT/K6bC6ReGqkTuAeOTUxE9h2tdlF WBWU3Ul8oXutMv4Acd+908uVxCY/ThAqWtCozztc50mtlA4OePyV9YsvLiT6etkWapttfyC26T6j 4U2jL24TrqLRiOMeOTVpKzii9mTPqMU9Q7ua8mf6xuj7xM+IQHLmlMWb9u7dveqlXGISbesi3iMn p/AGhySfTVpQUXBKaFc9Z8Fu62bYeHjUg5xALegAThlbhFXdHnL6Oq8SbHIWbD/xmJIvqDwv1XXf gGBoEVYd6BJs+sYoVYLtIwnZ33ucFbXYG/iCwgxAhlXNJW55pv49cgm2nzR7mKoe+FDoZQOwyGMi UZ8oz2sS2tVOc+gp7p44xfu0/KDT9IaTylQuyXDdIWBLyd1v8bMthJ4Fm157e39+CzfjxqPZ1YWf 174ZcXhL4a1tIm8OLnn8lfWLjweHdjXxpl3UNnsLBnmflz8ktEzzcVChgeGs5RudOzqLeGex2aP0 2zAru3ufFoAQr7+yPrGfvDGaNjX0t/KGG3EjHjTx+ivrE99cQfS11c3Fx3/PVG0skHrpHICh+yK3 n/YwPGqSu12YnX35AMGKfYDIMnRMD2WEr2snIMaoTw9lzN6JKZH7D6BFywLflmB/SS4PCGBMuslJ /tWU9HU9OBA/xtEvuvjEoekia8YAqEi517cl2AempbseHYgbbZ81t+yLqpUqM1EBiPBtCfaum/DQ GOyRXoTVJGrxcACzUif6rgS7GEV0YF3Yd8vt2yS6oB+AFkPoF11cKSNXUwawxfvdcvsqyRVvAGxq qnOFXllLMe8tOKZthV5ZmPcW/EBkEVbtMO8t+IS7EmzMews+wrsIq2ar1dYvAtDMQQk25r0F/8n8 0moIysmlwwH8wOYs2Jj3FnzL2izYpainBh+zUoK9a0Ki6/MECMt4CXYFyqnB/wyXYBe7Xr4MgEuH QmOzYKOcGqLHkJVGQoByaogqCdnbtYcA5dQQdbSXYKOcGqKR1hJslFNDtNJWgo1yaohiekqwUU4N UU5DCfbqc1yfBICq09VKsFFODbFBoQQb5dQQM6RLsItRTg0xRKoEG+XUEGuES7B3TTjJdZ8BtBMq wUY5NcQogRJslFND7OrIV4K96RLXHQUwiaMEG+XUEPMScn4MG4LKmW1cdxHAvLAl2EvPdN09ADu6 sEqwv0Y5NcQRzxLs31FODfEl6ZZviBAcfBrl1BB3kq5ZfOhECLZOTnPdIQAnTr7ogcK3Vy8tKrgF 7xkDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADjzf+OWE2oKZW5k c3RyZWFtCmVuZG9iago0NwowCm9iago4MDk2CmVuZG9iago0OAowCm9iago1MDk2CmVuZG9iago4 CjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250NAoxNQowClIKL0ZvbnQ1CjE2CjAKUgovRm9udDYKMjIK MApSCi9Gb250NwoyMwowClIKL0ZvbnQ4CjI0CjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVj dAo8PAovSW1hZ2UxCjEyCjAKUgovSW1hZ2UyCjEzCjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9BbHBo YTAKMTEKMApSCi9BbHBoYTMKMTQKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VC Ci9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iagoxOQowCm9iago8PAovRm9udAo8PAovRm9udDQK MTUKMApSCi9Gb250NQoxNgowClIKL0ZvbnQ2CjIyCjAKUgovRm9udDcKMjMKMApSCi9Gb250OAoy NAowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKL0ltYWdlMQoxMgowClIKL0ltYWdl MgoxMwowClIKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgovQWxwaGEzCjE0CjAKUgo+ PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRv YmoKMjcKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQ0CjE1CjAKUgovRm9udDUKMTYKMApSCi9Gb250 NgoyMgowClIKL0ZvbnQ3CjIzCjAKUgovRm9udDgKMjQKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9Y T2JqZWN0Cjw8Ci9JbWFnZTEKMTIKMApSCi9JbWFnZTIKMTMKMApSCj4+Ci9FeHRHU3RhdGUKPDwK L0FscGhhMAoxMQowClIKL0FscGhhMwoxNAowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9J bWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjMyCjAKb2JqCjw8Ci9Gb250Cjw8Ci9G b250NAoxNQowClIKL0ZvbnQ1CjE2CjAKUgovRm9udDYKMjIKMApSCi9Gb250NwoyMwowClIKL0Zv bnQ4CjI0CjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAovSW1hZ2UxCjEyCjAKUgov SW1hZ2UyCjEzCjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCi9BbHBoYTMKMTQK MApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+ CmVuZG9iagozNwowCm9iago8PAovRm9udAo8PAovRm9udDQKMTUKMApSCi9Gb250NQoxNgowClIK L0ZvbnQ2CjIyCjAKUgovRm9udDcKMjMKMApSCi9Gb250OAoyNAowClIKPj4KL1BhdHRlcm4KPDwK Pj4KL1hPYmplY3QKPDwKL0ltYWdlMQoxMgowClIKL0ltYWdlMgoxMwowClIKPj4KL0V4dEdTdGF0 ZQo8PAovQWxwaGEwCjExCjAKUgovQWxwaGEzCjE0CjAKUgo+PgovUHJvY1NldApbCi9QREYKL1Rl eHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKNDIKMApvYmoKPDwKL0ZvbnQK PDwKL0ZvbnQ0CjE1CjAKUgovRm9udDUKMTYKMApSCi9Gb250NgoyMgowClIKL0ZvbnQ3CjIzCjAK UgovRm9udDgKMjQKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTEKMTIK MApSCi9JbWFnZTIKMTMKMApSCj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKL0FscGhh MwoxNAowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJ Cl0KPj4KZW5kb2JqCjE1CjAKb2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBlCi9UeXBlMAovQmFz ZUZvbnQKL01VRlVaWStFeG8tQm9sZAovRW5jb2RpbmcKL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRG b250cwpbCjQ5CjAKUgpdCi9Ub1VuaWNvZGUKNTAKMApSCj4+CmVuZG9iagoxNgowCm9iago8PAov VHlwZQovRm9udAovU3VidHlwZQovVHlwZTAKL0Jhc2VGb250Ci9NVUZVWlkrRXhvLURlbWlCb2xk Ci9FbmNvZGluZwovSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzClsKNTMKMApSCl0KL1RvVW5p Y29kZQo1NAowClIKPj4KZW5kb2JqCjIyCjAKb2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBlCi9U eXBlMAovQmFzZUZvbnQKL01VRlVaWStPeHlnZW4tUmVndWxhcgovRW5jb2RpbmcKL0lkZW50aXR5 LUgKL0Rlc2NlbmRhbnRGb250cwpbCjU3CjAKUgpdCi9Ub1VuaWNvZGUKNTgKMApSCj4+CmVuZG9i agoyMwowCm9iago8PAovVHlwZQovRm9udAovU3VidHlwZQovVHlwZTAKL0Jhc2VGb250Ci9NVUZV WlkrQXJpYWxNVAovRW5jb2RpbmcKL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250cwpbCjYxCjAK UgpdCi9Ub1VuaWNvZGUKNjIKMApSCj4+CmVuZG9iagoyNAowCm9iago8PAovVHlwZQovRm9udAov U3VidHlwZQovVHlwZTAKL0Jhc2VGb250Ci9NVUZVWlkrSGFtbWVyc21pdGhPbmUtUmVndWxhcgov RW5jb2RpbmcKL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250cwpbCjY1CjAKUgpdCi9Ub1VuaWNv ZGUKNjYKMApSCj4+CmVuZG9iago1MAowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVu Z3RoCjY5CjAKUgo+PgpzdHJlYW0KeJyFU8tqwzAQvPsrdEwPwZbkRwNGUFIKPvRB3X6ALa1TQy0b 2Tn47yvvNmmSQiLwY7SzM7tiFW6Lx8K2EwvfXK9LmFjTWuNg7PdOA6th19qAC2ZaPf0ifOuuGoLQ J5fzOEFX2KYP8pyF7z44Tm5mqwfT13AXhK/OgGvtjq0+t6XH5X4YvqEDO7EoUIoZaLzQczW8VB2w ENPWhfHxdprXPueP8TEPwARiTsXo3sA4VBpcZXcQ5JFfiuVPfqkArLmIR5RVNwQ94fDLDxH9VTnU kV4nikSkiIb7/Dx/odVIizSx79WpqLgU5RHRjEJEFvKGBU+QxlNiC3W1bm6IVl0XFaQmMvzE8kxU XooKai/eYN2SEwJC1EVyowtJXUjyTcT1g/LlIy1DizhGlPJTC/nPIibtmIpNJeU2pERVpho3Eyom IZfsxpEmJJhtTu2X4VruwHFy9d45P7R4UXBalzltLRzv0tAPSxY+PwmFB/cKZW5kc3RyZWFtCmVu ZG9iago1MgowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjcwCjAKUgo+Pgpz dHJlYW0KeJztWHl01NW9/977my2ZJDO/2SfJrL/JTNaBzEo2CAQ0spNoCPsS1rIKyG6rUNRqRClI eUe2IkXp4qm2eihWj/X4jkufp89T29f6aKXKU591KRSOIGTmfe5vJjGN8F7/f+aeb753+d7v/d7v en9DjIj01Eqchi9duWXJxw9nQ5jZTmS8b9niBYu++MWEHxIVaTCXWoYJw7u6JzFuxji0bNWGzV+0 L/0vjOeDfsnKNT0LHmYPHidyvkqkfXbVgs1rJYVWEnnuAr1/7brFa5fpendhfFQ9VUsTiPhWbsXp WjKQkUxETO/UBiLaOh7QMjkg85XXrvVdZVf7MpcYZYkXZBhjmQ94lH3xt/NFf//o4nnjhczH3Nr3 CbbSiGyUrZBmkxvihhMjeTo1isVLJJuXOx0+pkTZvLDVF7ZE7AU7na01IYsnZAnZCna62iKnH9+5 ZG7gptIiZcemH+3+1tJ5Snt5sWsNeJrAcwx4lhGNZImoJhIexuJeyVbC9ToTU0ayPSGjzVVeVlxq 1IFT9MsTRo16aue8zmnjRjrrLQWeTRt+9oP7l832tToL/dvA10YfsMlsDklE6WTAbmONH2zcCE0k oJMx/AyZyYsVOZFqYjGnwy7bdDUsGE7bMEwl5QQGOnuy57bj9/kL5tx2vGtB74QFFaGxy6t8T7N1 M+at9lVk7ps+a+aadn+ETby5ppyEfsCRR/j7ZCeyJlNxwdemDdgDyZFSIhJWvHsPrUklMh8zW192 6p7pzUWuW/miZaVtrfMf/8+7t6W2d88Z46gWfBzZy9zM36FhsLNSzaJSJBxJx2OpFpaAdpLpkQy9 KFMC6iFe5mE2vQP/dKyzsbgobYu6rV4/yzTUDat/5ZVknafSk7nU8VTA17lw4sT5esYkjaQ1LnHV +qt93LC2UPKFQ2X+wsUexudOTawr92+snj4bV4HfEr3KbVQkLJ5OJqAbnCL0JA8ejHZ1ud1dxmIV mQqcM93umc5itlfFMu5Tlb3Cg/wcBaCXVFrIbB8uLhUsYXqdzRGPjWJ2nRKEA5lnV94cqX9orckd rLING18VLrA1dc6d75+521h0z3q+Y4zdGFjNuSQxqaCsrDFzu46vKmcvsE0k5EXc8HWwrYFkorgc iMk2vU6xQvc1TI7HWlg6s6px+rrG0qqjR+/kZzIPnesexlY+W2PNeFT7ibh7DfslsTsut/TyM32h 3Dzi6AwVqPNgJStMbtnNgr29mT+BT4T9sS/E3srUQoY4aBtV/3LnZBBOIO6pBMMR2arY47F0KhmO s6ZV9XVlEW9kuHJQc/z4cZcpyPiZlvTq1tn1xRYLz/yZz/99ga1jaZ7nNJWnC2KqHPVgaVWkiKzI VnhGAjdk6+cPa2iy2qwPHN6yrffBE5FAKHSCn6lv3PJg1GTQZc4ye4kq7jOVW+vU+9bDz6L8PYoK f02kU+lG5nDaw0ElqINpHWpkCN+C7JGkIwbTwe+EMoOxhsSMokmP1K27V1tXHazdsC5imxFte2bJ 6uNlJd5AsW3t8+z9UctrI8xcvLrQNSxUXT4r2lB/T5XDu9qo0RVXRhJFWlJlCBJJv8HdiiFDvIzF 9QBJMTIl+Mixb++Pb7hn32vHerqOwRJ/4b7nM4/yIFRdm3lL2NubvcLe5V4qp4jwrHgMcaxESjhU DUFTjliymSUT4aDeaoP0o1hSr7MPn3Vgds8aj6ZmojJ+6sTDk4NLDm8tjbXIlrtr2JXQpLmZ3Y16 T/ltI2KtHYyZZVbpNmYue632QuOCQk0sJ3NF9ip7k7vJj1ORBoU/533Zy3LOrBfZBFoLh931zVV7 F8y73VmuK7FWVE7rKIvWjh6uC2um1MVZ4dRVDS7fdJ3GLFd9b4xdz7tdGl2ySdytIvsFJ0mGJyO3 WNSocTiF50VKoJuwRY2btBxG32ut6gzNVHo3uDzdtXOmHpKDoVviiXY3W7/QMdxqZu5rn6Vcoe8w a/v3xvmZ3kY5/lfZZ9yJnFUldBfzSk6HTYiNbB5L26FE4bHmlBb6K+E2uO0zysxY3O81WOTAwpNF fuVge92soDtQ2zOxhVFZh89j2FXLZZ1UIHtsdXd4G5Rqq9Y4TzZwtp057zgR82id0SqN0J+oQ7sk C3I0/A55JQUFRsJ6OF3crsCjTZ3tR5vmR3XSli297ImZcs/4DlcnYz45NGZFpps9AZchJXMeOcVO w2mkqHPpoF112Jy/QvkRuEA6Ci9Ih5OJeMCut3m1uKEaiXqVVE2nESUiiZyfzPm17vVKu/Wx8Z09 nvD+O0LFw5wen6/xFGtr0nINlxjjBW5r3a0P+/wdisNVvrKat44Y6zG5k5GyR5xm45QpDRs8BV2e SFt9UeqmeGHF6udvtTCjttBQVGQoGR6tl6suh5yesojLxSTW0zG5wWyohj4QjZxJJrLk8o5qbHiy nEAg6uXoA+21Ls+R3qbKEX7JlPl1okB7OnOYLWq3uzM7crbE/xf4W8jTZjWSv0zNVrALu5Y7HMuN xdpevrC7tLTbWdR3MlfRKXc2q8HZRaIaxmWbw+mAEYLhaK/D1azfMHbc87yj7+VkdYG9a7pKn81K N/MykctZTj5FjjtHSgiCfqlR6oJ6J3LkuqbKRKB3bbkU9LcoS5W5Cw73Bo0lU2Osly1st7kzO7m1 gbts1nHjnsscZQtTJZpqX+bIgFyc8XKhEzZIGeIw6IctzOkDzG+pcfLyLxUClkmDmltUH+dG7qKS fKQyNYrMIp2JAIKjiylU0kiU6cLmoDe94jvLlz5wXyqxz1BYFmz0lOmKtUXFzk6FsuPmjLYqmzNv rGtpYvpRK5t9BgRtaFtDxGBihTirLnOBG5ATLOIVYEkhWEWWzmV9IbRVpP2E0Izs+P2MWWNtFcOr RdQ+sN51p6vEF1TGxxPsUihccdP2YyMTVlPmD1IgmbnPWLqta5w/c8XWb6vdOKNY9RNnKpd4hIts dEyYVGMunz/Kxa1t7bp7JXcw85PcmwRx/g72KNAAyIekdjWzi8ooCkgQ6IlPhp13m232b9b7m8eP uFZ7VTHZtj/CXWXdZrvLabQGb01PaPVMD7ot5oeiD6nvtyxbxk+SVXgenoN2eI+934tamKnLecem TQ5ns37rDnZysmffvhW/SwlneuGv/bn0c3YFb1QH9ss2URzTuSwnCeUl5aebEiGLo/f2sgK/xVPs qzjMrZmDN1sLZXZn3ycjtDajSVP4HFtA+bzCw+Cly9cSSTHt37Bp/68OYc8etgYur9JItaAZqDdO K+giepB+Y15vRffy/T8+OLX5SG7HQ2fFrhdfxD4z7FuPfSVin9URd8SxT69YgxHz3tmFEYl947un blk0YWsIO3vDjD3aN24JK7lXlUuFq9u2T5tnar5ERulDcfVfd0h9/Tj7VOYv2rHSR6AzwJdyf9gj fZT5Bd6APdmnsqe0Y1VOg/74H/m/ityH3uf49wW2yNTKfkmt/E0y8Uaqkl4iP38cL5GzVMW20AiA if2IKth7FGBa0C4kG8P3CXsV9BspwdaTl08E3EwOvhJzt1IDn0/1vBrjtTQC/TqV3gB4CXx+i/3A qMEmaRHofk5BPpuaeRNV8f3AaWpUYQnG2/GOukTNbBGV8g1YK6NmaQrmT6B/BHtnUlzF84AnA08j Hz+AtZ9QUDoLvncDHgbUUimblJMZ2MTuwvnHUEv+Dnn1kL0WMn6KuVpAMWTci/nhpPAw4uc95MoL VMfrQNNAddIK9DGPdUFfx2tA/32sXSMvuxP7wphP4G6N6DeThY8hM3ubHGw0/OhzGi0wewx7bOh/ gLNvQv8FCvOtWL9Mo7kHen+RKiQ/8GrocCzWP4XuoXd1bg3GDsBFqmYPk5MdQByIe0yksXw0ZBDf jhexXkJF7P7cfukxKpLewUejDWMfzhQ6vw5Ip7Eu7NBvgzzQpewZYQfg/wa8xvdnrw3YYAiwN6ga /pNQ7TAYhB2C0FczQOj8OiCNh/yf5mwwGOj97Bv0PmzxfvZtwGnkeO+ADYYAOw88DvoUdhgMsAPs lVCxuK8+r4fBGHdXz78RFv45T2DcP449Qj9Cxhth4cPCj26E4d88nH2aP0klPJG9At3+B+73KvB5 4Heh8zD8z6LqHvcXcUAXsu+qsQB/5PBHERNsKF4C3EglbDEVqnYSuhqKf5DnIewmdJfH0t+oHnFZ IWJK+HUeVw2MEWfC12+IEYNqHAh8CLid7Gwj8AH13Ip/Fov4VWNI+I2wWX8cI5a+gqflYloF3IFe ysUIvUkhNdb25HIVv4o77kJf5JtaqlTtWZuzl4h5kVvU+BZ5pXbQXfN36pdpKB6QkZGNn0V+k2CD fjhJ6QE4BTlfASSpVYqwSm0P+WHTChXGZH/J/h02fhJxexT+9izgQTKy31AM/aC6JmJ6L2L+IPLJ 0+gf+wpdgC8H/zfIoemgFP8VZPs57rGVavjr6N8PaEKMvQo5RY67gnNPg74P+DVgoTeRmwl3K8P6 egDqgvQZmTTIm9Im7JWRo0TeXwO9T0K+7QK9yPsLqW1o3keO90qLMYccKf0WOewOyP5dKkftdaq5 axeggay4h4vtw1fLE6g7J2HTf0H/r1TOvw1azKu0e4D3AI8AXgNcBT3voTLowgJ7WeBrVvYz4FXk 5IupFrAaUA2IAeyANkAUEM9DNE+34/+kg/z9IE2HP4h8exn6eAnwO/RFDTCjvjyHOroQYwPoHgWv TnKrte+H2NsInS3BXi10eFX1XRPeBg3IZfXsTxjHoLNy2PitfF2ci5oXgn9yxN5kYMpDGuPx+bo4 FTRtwOjzPszPAO4ClqF7gSuAfcAG0HVjbQGVStPQnwzAXtSQUrV2iPoKWuSdfxO8RP1R9+XPYxfg G6Dtrz1ij1pDZ0B+Ied1QFLwHXqJIqr8NEh+ysmOs84BLkAu04DcbXncDx2I0bGY6/4qaDTwD3GW 4C94DPDO/gHw8gDPLnW9WdwX364jKEtN7ClKDYAZdfgY4usQDeM6xNSnsLm4u4BJ1Kne+2JOP+I8 Vdf9d5pCs9Vz+s8SNP0yQufsCvT0MVVLnbC7OB9vV9R3k7YeOVHkqsdy+uSbyCNsqup6av5OXK3D ORD8IA+dQ83XU5vIH8BNAlQf6fcP+IBqX9hfxVPz9vbl5w25OU095Hkdb6mZmAeI/mD4X3PN7i9z zT9JF9QEkAeW5d9NQ0DMsyP/AFV4S4qcasK3esUNwTuoP7TWD4X4oH5N/s22WcV1rCWHB88hVivE vAo9GG/DWLx7AQM5fui4/608ET5mUh/blddtHfTNfLtfbafQzjD/P7SxX2mb2YGBdnygnUY7x85x M+/It7XXaT9G+7NUIk2UVktvSRc1FrVVa+Zq7tI8q/lQ86GWa2PaDu1m7f3aE2gvf92+bl+3r9v/ v5b7DYW/TctJn/vBRJ0Rv6K05n5BOcWyu36qeZD+B9c9dlkKZW5kc3RyZWFtCmVuZG9iago0OQow Cm9iago8PAovVHlwZQovRm9udAovU3VidHlwZQovQ0lERm9udFR5cGUyCi9CYXNlRm9udAovTVVG VVpZK0V4by1Cb2xkCi9DSURTeXN0ZW1JbmZvCjw8Ci9SZWdpc3RyeQooQWRvYmUpCi9PcmRlcmlu ZwooVUNTKQovU3VwcGxlbWVudAowCj4+Ci9Gb250RGVzY3JpcHRvcgo1MQowClIKL0NJRFRvR0lE TWFwCi9JZGVudGl0eQovRFcKMzMyCi9XClsKMApbCjcwOQowCjAKMjUwCl0KNAoxMAowCjExCjEy CjM3NwoxMwoxNQowCjE2ClsKMzU0CjAKMAo2MzAKMAo1ODgKNTgzCl0KMjMKMjgKMAoyOQpbCjI2 MwpdCjMwCjM3CjAKMzgKWwo1NzEKNjYyCl0KNDAKNDMKMAo0NApbCjI0NQpdCjQ1CjQ4CjAKNDkK Wwo2NzgKMAo2MDIKMAo2MDcKNTkwCl0KNTUKNTcKMAo1OApbCjk5MgpdCjU5CjY3CjAKNjgKWwo1 MTkKMAo0OTQKNTU2CjUyNQo0MDMKNTYwCjU1MAoyMjcKMAowCjMxMwo4NzUKNTUwCjU2MAo1NTYK MAo0MTcKNTA4CjM4MQo1NTAKNTY0CjgyNgowCjU3OApdCl0KPj4KZW5kb2JqCjUxCjAKb2JqCjw8 Ci9UeXBlCi9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUKL01VRlVaWStFeG8tQm9sZAovRmxhZ3MK NAovRm9udEJCb3gKWwotNzkKLTI4NwoxMzQ4CjEwMDIKXQovQXNjZW50CjEwMDIKL0Rlc2NlbnQK LTMyNwovSXRhbGljQW5nbGUKMAovQ2FwSGVpZ2h0CjczMgovU3RlbVYKODAKL0ZvbnRGaWxlMgo1 MgowClIKPj4KZW5kb2JqCjU0CjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgK NzEKMApSCj4+CnN0cmVhbQp4nGVSTW+DMAy98yty7A4VCRC6Sghp6jSJwz40th9AE9NFGiEK9MC/ X7DbrrSRwLH9np8VO95Vz5U1I4s/fK9qGFlrrPYw9EevgO3hYGwkEqaNGk8e/lXXuCgO5HoaRugq 2/ZRUbD4MySH0U9s9aT7PTxE8bvX4I09sNX3rg5+fXTuFzqwI+NRWTINbSj02ri3pgMWI21d6ZA3 47QOnH/E1+SAJegLakb1GgbXKPCNPUBU8HBKVryEU0Zg9U2eE2vfkhsA56s4Z9RP47FOGupwnvCS YBhPl/wZ1iJMcEKrcg4K4gqJJuUU3FKwoWBeXssnt/JJjrAsRW6oi972uhlx10xKummGRvKFRHYr kT4STKJERqRckEe5/JQj+Xwhn9zJS3oEKQitkSvpEeQGzSZZ9DRPaF6ky/jV0fswedw2HPk8bGPh spCudzMLvz9Ehs65CmVuZHN0cmVhbQplbmRvYmoKNTYKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVE ZWNvZGUKL0xlbmd0aAo3MgowClIKPj4Kc3RyZWFtCnic7Vh5cNTVHf++99vdX8huNrvZK7u59kh2 yQY2yZ6QQEJICDEEAuEQEuUmYAEBWRWUVgsKqEXRUkGt40UZVEYdcZQWj2np1LMzWloVy2i1h8LA gAcq124/7+0mjUEc/y958+H77u/9fT+WGBGpNIY41Sxetrb34V8duQsz64h0/1qyaN7CM/sm7MOG uZiLL8FEzse63RjvwLh8yfLkmlOh1U9i/CKRvnfZigXz7rFufYvIUk6kfX75vDUrFR9dTVR4GPvd K69ZtHKJ7he3YnxOctXSNCK+gVvAXUs5pKd8IqY6tJ6Adjj3aJnZY+bXnjt3/iw7ez51ilGa+JAU Yyz1KQ+xMyc/N3x59KvP9V+kjnHL+eM4Sm3pnfQHuolsRA6rz1vNYuFEfDTzef2jWbSehW2/nzlE NRjVXL3e6Gwr1E/hPKhVTQV5hglFRThvpRNsEptOClEi5rFZWd2J3l5IVw85m/hhyFeCFXM0jrvs NrNVV8W8/oTVjmHMHMVAZ6uf37Wzp6una+fUecla39rJE2+q8u9hN0/vmduRWjdjxoxFVb6JbMnE UJmQ14N/huNeHajZZ1ZjCTYsee92fvh8OV8UnDgtu4f7+X+oCHaNxSNhh91mVY1c1akemyfWwBPx WNTn3X7fsnitv3JCTdEwN6tNaUbdMrVi8jq+ZkZhc2N3U/P4ySFHReHyxUOv6qyc1QSXcEqk0zzK /4l7g3CuPxpPoOF6m8erSjYlzAqNQsxiLWUOoSIsGfX72i0lrppxbm9yQ+qbhZrlya1WzZ67yxPh pvx8fWHF4gqfz/fAbfu3+Ns13DbzoHWFo/i6h6wRpk4b4zcUFQVnBmBCoZcTQuRndLfEPA7FZ3Gy g95z64/zFcvrzs/mK7AnlD7NPfzfwgaQsIEl4pCvJqQE/F4jU3UmeyTcyGw6H6RsyM/zFNedvtZU VB6010wIBXJtY2dcudg7f1Pb9JG/W7n16jmljaU9jCucc727tCF1er2O97h8jUKWZki0D7LA7xFz xNySFB6AjeKQUfjHLKwfMXuk8Y2K1x/wB8wWny0SjsfQj7P44pqgq2JEoNgVukHdv3//0CrmL+CH R8eWNvRUu7RMY1BSf+WrTkTbpjj0Qn8F9p/F1/GPyUVR5J/UT4F+pYp0sE7VBUJKgU7aPtzAoyGt UFrDdJJ5BJonmnLzncFh7uja+qZhQUNRXWBk5w2tIytd3Vq9ze7f2DDMpFHzjU67ubilLGB3Gtnc 4tH1zoSu1T3SW/nago2rOke4h+TrCtwjApff/vqkmNkxROuuSLCF7cnLR+W7LCMWrGuJDi226BUN V/NdgfOtOSaTt8WfJ/3XnD7Dl8I2XuS6zxsIsYA/BttZHRmJ4Ss5VI2KqmPdxusDBdWGkmRBrsPm 7g5WGYqudRmLq8tLqrROQ7V32o3s16mFvVWFxaohx+mILhPDdY2e2pICjVbYi5MnfZp9yEupmAKI GESozewLGHkmt+N1rDYe9SE8varFag/HG1lM1dkicx94utulxGZWtExqf6ybsQp/+yMLiuOdTuej teycZ2dq02hdadnkunhDp8NRWapPfVxmt+v11xi0McEzmD7LjvFCxGq54Cncw4V7qphQM5wQoec3 aSVbI0M4TCkdPnxVLO7Oc259yWWseKa16/mFE9hET0OnyabbFWHvDs0zaPJcNv+sn09y5OXopxSv ZcPHjXIXOEZ7BD9o+hR/gwxkAr9wJgOFfhEFttzucEzPNRaak/wNV4cjL7fDdT6eqXzCH2EEVTsv EtZhMI056vfqVNCIo0EHwe0OmMyeXYBHvk4GOuqHJ7tdvETnyi00GSyT282zr+rsSvqbnBF2my91 P+sNVNmLUzdwyyhu0eRr9Yqi9XvbFnSlHhBL2pw+vuwML0btJIZC1MdTyXBjG1tDDYKNUlEx1jd1 UpJdNcVRlFrDLfXcabMu6kztyN5xN3eSkahApHi/6PFjY7tMroWtFcnZ9hLOCtVVGqc3dS+3NDtk bYR/PuAZ70BDG9jDZqJWieoF3wRinrCoWlkz7pm4u/Rbt9nhun1cy/qO/U6mVFkKN7eP54UG/USr 011sbB8V22TUd1R6bbbGCaE7wAOeYAv542QBD1vE5rNZ7Q47qBfvSqyRfXTLLU5ni3r1hu5uO9+9 bc6REcNzbO0vf9Pq3Jbxi8R9G55Q5+SPOkV65TMx/WaXkuqj6b2p49om5Sj25SAGMn84oxxN4e3V LkjvTe/VNsmbBvzxQ/w98X5i3yT8cwZH8qmN7aQ2/kcy8XoKKa+Qj+9AvrxDIfYTagRM7BkKshMU YDnYO5+sLBd0L/bfSPVsBXl4JzCBnLwXc5fTGL6IEjyAcZIa0Q/L/QbgTdxzEOdBkZMmpQf79pCf z6Jm3kAhvg00QU0SvRj/FDX2KDWzRVTCF2PNS82K2LcL/YdxtoviknaDdoB2UDl/EGu7ya/8Dfeu AjYB1VTCLsvIDGpiG8D/UcTeF5BXhexVkPEk5qqAPMh4D+ZDFOA+xNj7yK8jFEY+h1mUwspq9DHP I3J/WJyB/cLsLHnYOpzzYT4I3WrRD5KVjyQzdHayMYiJryEDKHsCZ8x0GftM2i3IDlAVX471b+AH D+x+gIJKOehy2HAk1s/A9rC7nFuDcRmQomp2B+7djjoj9JhEHXwsZICtcU+QGSmPbc6cV3ZQnvI+ 5Wn0GJeBp7D590B5CuvCvgkaOxB0NP2e8APop8Cr8BPv98EgsLeoGmt10g8DIfzgh73qAWHz74Ey HfKfzPhgIOhQ+k90CL44lH4XeB71ytPvg0Fg34KOAXyDAD/AV/WSCn3VrB0GUugu+V+MivjskJTz Ghoq7SNkvBgVMSzi6GIU8c196Rf5TvhvWPoUbHsQ+h0APQb6d9i8FPGnl7aH/iIP6Ej6I5kLiEdp T+SEiMvv0CmgMVJZD+VKPwlbDaa/AR0GKvwmbJelGkYJ5TqMkVMirrO0pn+MPBOx/gO0XOaBoFtA W8nFkqAPSr7BH0tF/socEnEjfNaXx8ilC+jkTE5LIN7pQCZH6F2qlLl2W6ZWKQx1Yj36ot5UIU63 SSr9JXJe1BaZ36KuVH1HV6lTn0yDab+M+L8A/wfqmwof9GEXje7HY5DzOSBObUqQUtoF5GMLIZ+A J/0cewc+fhx5+wji7QVgPRnY25DhBfLLNZHTW5Dz9wFPov/ohfsQGyb2LDk1TTSKvwjZXoEeP4P/ /oz+ZmAMcuw1yLkJ8uPbgf0Wc1rQt3BO1GdRmxWs2TG/DHgb/U/IpGkBvQ5n8+kyWfeXSrt7+RUy zk2o8xfUfdR4j3IF5mBj5VWqQBy42FZyI45d7E5gI9BAduhRxH5JbnoI784j8Ond6B+hMn4n9mKe 3SX3u3HWhfrpZqtBh+PcXVTKHiIbn002dj/Gz4GuIhdfQrXAeqAaSAAOYAwQAUYAI7N9se+GQfva L9hXlX0bhB4zEQ/Hoe8Z2OMl4C/oizcgn8bLd3QKxgz7VlMhb4NehJr/NM42wmZX4iy+Sdk52CiA fQ7IVAa/HcY4AZuVwcfvZN/FWXjzfIhPDWpFFyjLAm803tvMu9iJPfWgX2H+c8x3g3aDmmXehmSe u0FV7LsSa1dQidKFfgswHnb+EvVEvB3zJK8w6s7r4i7x/shzWX4M+oq98u0pRV59kX1Du/FOCzm/ B4oT3z5HyS3lZwPkZxnZs2/JST4d/Pvkrs/SPnRRJezWLGUfBA0hPgQvcf90afPs3en35RvVPeAu cQb6omY2Mg1y/Vka1Q/EM/LSzx6En7XIqRM0WuouMJXmSL2/zNhH8JO27tNpKi3L8mnut3efjKo8 Z2LHqFqZD78L/sg3bkUunadCWaueyNiTL6VS4VNp686sThppjwzEfZAHb0At3vcJon6wPOgByBjp iw/EgPQv/C/p+Ky/3dl5NTOn8UCel/EtNQ7zgOgPxI+tNT92n0bUgVXZ76ZBEPPy++l/qOEj4M+b ATtsczF4B/QHv/WDkRjQ7/tmu17SMKvL0IFz8purLrPGujBegrH47gX6a/zgcd+3ciM1iq9//A39 wdaG73DRbqZ76OVsSzHTRVrLgDb5O+1n7MNM4/aLtMnZtjnbdmXbJ4om29xKl3LNpXapXWqX2v9z y/yGwj+gpaRmfjCRM+JXlDGZX1D2sfStz2i20H8BpN6gzAplbmRzdHJlYW0KZW5kb2JqCjUzCjAK b2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBlCi9DSURGb250VHlwZTIKL0Jhc2VGb250Ci9NVUZV WlkrRXhvLURlbWlCb2xkCi9DSURTeXN0ZW1JbmZvCjw8Ci9SZWdpc3RyeQooQWRvYmUpCi9PcmRl cmluZwooVUNTKQovU3VwcGxlbWVudAowCj4+Ci9Gb250RGVzY3JpcHRvcgo1NQowClIKL0NJRFRv R0lETWFwCi9JZGVudGl0eQovRFcKMzE5Ci9XClsKMApbCjcyNwowCjAKMjUwCl0KNAoxNAowCjE1 ClsKMjY0CjM1NAowCjAKNjM1CjM2Nwo1OTEKXQoyMgoyNAowCjI1ClsKNjEzCjU1MQpdCjI3CjM3 CjAKMzgKWwo1NzQKXQozOQo0MwowCjQ0ClsKMjM0Cl0KNDUKNTAKMAo1MQpbCjU5NAo2NzIKXQo1 Mwo1NQowCjU2ClsKNjY5Cl0KNTcKNjcKMAo2OApbCjUxOQpdCjY5CjcxCjAKNzIKWwo1MjUKXQo3 Mwo3NQowCjc2ClsKMjE2Cl0KNzcKNzkKMAo4MApbCjg4Mwo1NDcKXQo4Mgo4NAowCjg1ClsKNDIw CjUwNwozODAKXQpdCj4+CmVuZG9iago1NQowCm9iago8PAovVHlwZQovRm9udERlc2NyaXB0b3IK L0ZvbnROYW1lCi9NVUZVWlkrRXhvLURlbWlCb2xkCi9GbGFncwo0Ci9Gb250QkJveApbCi03Nwot Mjc1CjEzNDUKMTAwMgpdCi9Bc2NlbnQKMTAwMgovRGVzY2VudAotMzI3Ci9JdGFsaWNBbmdsZQow Ci9DYXBIZWlnaHQKNzMyCi9TdGVtVgo4MAovRm9udEZpbGUyCjU2CjAKUgo+PgplbmRvYmoKNTgK MApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo3MwowClIKPj4Kc3RyZWFtCnic fVLJboMwEL3zFT62hwgbA2kkhFSlqsShi0r7AWAPqaViLEMO/H3NTJI2jRpLLDN+m2HibfVQWTOx +NUPqoaJdcZqD+Ow9wpYCztjI5EwbdR0qPCu+sZFcSDX8zhBX9luiIqCxW9hc5z8zG7u9dDCbRS/ eA3e2B27+djWoa73zn1BD3ZiPCpLpqELQk+Ne256YDHSVpUO+2aaV4Hzg3ifHbAEa0Fh1KBhdI0C 39gdRAUPq2TFY1hlBFb/2efEajsqA+D4Ko476rPxqCODDucJLwmGfXnOX2Atwrgi9F2JzQ4rIaip sClIUGT4kEfdf+yTFGGp+G0vLuyTnCzWhJZnovJClFKmGwwkKV4KVFG8jF83lIf4ZJgl108hNwTL r3/E9HBYipcLDBRyIZdy5S02M7LPCLk+t1/+9zKWp2FSe+/DHOHs4gAto2MsnMbbDW5h4fUNhUTm jAplbmRzdHJlYW0KZW5kb2JqCjYwCjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5n dGgKNzQKMApSCj4+CnN0cmVhbQp4nO16eWAUVdbvubduVXe6O0nvIekA1amkE+hOCFlZQtJmgxBC AmFJA0ICIYCGRUSMgIgoygSQzQVlRhHRsFvNjuinjoobfrPhfDjznIVZUNwdx5kRUv3Ore4EBMb3 vffX++Ojqb7nVp269yy/s9wGIAAQB6tAAOuspUtk8Vyfv+OdH+OV07Zozvw/59D7kT6DTDPntN/V 9suhjz0OYMoFSCqYO7ul1dRS9hsAbyvyFM3FG9a/xPXBOX8/fe78JR0NI7aPxvkrANKu9oWzWnLy 8r8ByEJ+YcL8lo5F9JwpH8B/AvnlRYtnL3LBtiycn8P5Gvj+nwOwjl/imwBiN6sB0NLFP0YuSvGs OfKxZgJQIaDKzW3ZKgnIrbL6SoPKfFNUVjW1yat4PZ1NstrQ0ORVgyGPrA7h1JBQSFZNVS2tahaf mqpkNZcTuZzjlYYmuU3u7GxBloamZrwj60ycKuJUUbOnORQKeVTwh0KKCg1Ns0OhbJUGZFyHZbSg CGJFQ5MqKuWqpJR7vN6QSpqzVSGgoDxya1icWS7zJ4dMhA70Ilkhd8qduFw4V8zoHNfU3OBpGR9q UkL4LNjYhA88XPrYVtkqC6hGXNuAF/CrQjVUjGtSjRX+Q0Cgorlcdc9ORT4xgM+4ULRqlkqqZjZX ZqtSzz3wK2GJZTTLVZ1KCzebriV4uCVU2YP79WyoChlKSyW+awiERbFKJS1IGwOok4wmqhjNuZBQ ykOqmc/G48yMs2w1LiCfYDCTf83CXVRLRbPc2SyrFqVcyVZNgTDEV0xsCsfHV+Ci5WqcP8SVoRnl MT3CJqTDZvxSiVuRURCUDTlYRnknWgxXNA70KvhuD+2JvY+XPg+hfCNRqpHN6qqZV+wQBnAolSqp UKH0ECEEt8pWzSiOWDWhCdR4pVxuxlWPJiQQsEB5eWdz2MT86jy/Jw21siCj2Z+txgfChI8JgTDl Y2IgLPDRGggzPtrQXHy0B8ISHx2BsIGPzkDYyEdXIBzHR3dANfj/m3sn4d5ufKcP7s3HZNybjym4 Nx89uDcfU3FvPvbFvfnYD/fmY3/cm48y7s1HbwB3S2iWK9CKzdx0+HdckyKX4FRR7bNTOXqz1bSA 6vWr3oHZqhKQ5ZHyFVMqLUMUuXNi07U3Pfy19F6TEreqDFSJK1fXIuNqjb//yBeQC/VoyQyAKkTX Q6z2LM1JcB/R80JlqTIk7CMulCorIJegBL0CIAxahmSrAwI5SSXZ6sAbPEXnz0IOP9oP3BlyjjxS jyWaUdPZOVIZqbTMVAlG6EBCXE7cIIBh40bc4V/9qSpV+Wd35iiyXNKJy2RfeSzn6AyYCXj4V/ll tZmHR3Bc02EqC7LnMPUJKaHycoRzHMa9onMr1c0qq0CMNvPAjCYfWtHcqqhCRUsrgp5WtHiQbubB iGwtuDEmOaUaDa3gOtXcc3EV+lq4RHQpRQ9ynDRzq4kYESJ/F9/j0mXoq+M3hr1H8YaurIheyOH6 yHhH9MX0UUpQzUH6bTUOMSrL1cpIvj63c66uvsDBE7UOTGjKkUsw+UYRFbOIeJX5MnBWo4cpqZql zIzhJmZQhYNncGyzih6LNvMkjwr0GD0voMg5XPNqzDgloZxwGnEipPN7bzdcfbvg+9w35BmOW7qi SMAMhJ535KhZ6P2Sf3N/BOKbOB3qAKRLA6ofh8KAGvDfUK6awCGAQiRGI0E4URs4RPQ7Y5DQ7xQF 1Gx/J+rH0YN2uH4ddGeOmoasE/lyRUhM4stxYjJfjhNNfDlOFPfCsseNHJEY3XIOhk5UrDq+TjES Y/k6nKjn63Ciga/DiSGYLTDn/j9gfOT/Hay5sjyhlCiYQK6CmDcUk/YmLu0QJMq5tJyo4NJyopJL y4lggCNULUNyKPdGjwOq+LtDkajm73JiJH+XE6P4u5wYxh3gVWIeiBmp1+bj+ArDkBjPV+BEI1+B ExP4Cpwo4zavQs/J1ViUeqwcCqg5vYJM4RM1D6mpOpWP1DTdVTgpwMnNAXVQL/d0PtG5Z+gU527W Kc7aElBze1ln8onOOkunOGurTnHW2QF1cC9rG5/orHN0irPO1SnOOi/gV42zVSG9oYNn5mzMthTa sHd7glVix2gA41GJEaDp/nyb15bhtXnbhILuPDq3exurvPRim9CBBXyO9hV1iP8JZrAHEzFsoA6X MZOgy04T/A4ryQeb056k+OgcYtuuaWuXPX7vFjqJXCQPaQu0fue1glOHyau4Tp32Ffmudx0AUoeL mSHocuA6xEkNSpG9kC9HvtuyetuytVr3dmKnk77SgkdOkTPnyR/Iw1o7rjNfu0ja4CIYQQnKEspD SoGLVaOvSfmNm5A0gtEpxPsdpbQ43yUJ84W+VvbG4Bnaxb7/2hsMnNa+Rm6YRL6io7FDFqBvMOVG qwgg2PgqhV7XJPIN+WrrVv4cVkW+IZ1wGTvvKbW8vQxa+Lv1FLtxCwQ9tWrC9+7Z9XvW6/i+z4LN aNBEQBIhjsQJFr+Y5issKMpzOyUilo6sXlldbakvLBo7tn2s7sf5kY9Zu/h3cIAXRkRXdwGlpB7X jC8DQYB6iG59o/su3O+ou88AK7P6mezz0cKCUiE/z+22u5xUomkSdTnt7jx0SQGlf9O+feuu4Znj 79o9Z9Uby0uHdfz1zJaami38K+mOs8S5Z92nrzxQs+hn2oWDe7RPz7LI09pnR45rF3btIsnHjxCH brMM/HpPPIf+TwkmGSQmRD0H5jIUzEKCNivHQb5NsUmGwlKB5DwVnr3FOnPwaPHcd1li//JBXYaB 7izQ15qCnrmAuqdAbjDbggvZzJJAgfL1ehSlVKhjRBAsQhDvpkBKspIlJvrzM0lRUXFxgU9JM2QW efPcrgRmIF7DbUlULGhxJ3Xec3bZsE5iOvM1sxYOC+VoU+hR8y5aOuxEsGzFj5Y/uvrDkwmD1i7b Mlgb8YTuBwHPMw7xHWDo0uzgQBGdSSiQSWhpc5nEKKUWGhRF5LKIFrMpzmiQkJcZLH5CM3MFIngF heQTYcWv3H+jrx7oPnRYpUPCNJO20dljuuu7nyDva37xne+KUO9FkYvsA/EPkApFwfwUAoLHjOCx EEqEUgxkEOpxVxs3KK1HA9hpkEByUmK8yQipJFXELXXH9qP5ecVJkpKWzv1uL0rPz0sy+ITirq+W Ble9t2bf8b6PaF3aPw5MmXmYWHb9a1/lLnHUTu3zQ2t+++zU0NbpC98lyfufI33eXrRgwyzdBgdR uwV4sjMiGvsFPRCTxNwrCZrAm+5NQ7ARK3gVm1cGBxKYcfKY286Oaq9o//kREUk6GXxSa9M2azXk iZMk/b8W0z+QIpJyaQ7JJJnaY9r94puTw9qfOAaO4dcs3FOI5SXcTI8qHUe4RT6ZdeAAP20iL5ev FOlEHudmjhSCCKPUXEaioeiyuXgkeBWS6XbZ+MtJtNCWL5a+3g15xp2vCjTf8DRbX/XLZy8/J755 aUkVKcsTmnXdtwCwWxDXVugLg4IBK6ECKRWJwKFBJwNjOiBtMensNk+yra89dYDXKiVyMb15/dAj CYKSlpmRVyoUIjC9NjepCJPzCw51jpHHrnxj9ZwNRJy5vtZv2rdVe/dV8VzO9CfnTf5RR312/Hrf kCm1hfd0dP+KclkwO7F/oiwmjLaC4GAvSqHHGGosTMRcScR6EEVzGSO6SwD6YBNkT7SY8Y24mwzx fmLLY/l5RVwKogi+TEnJsOkyii6nZHC63UmkcgAh1S8/umkPzXrrTGNSTav2jzD5YPzKu6c1DE7d +mBWcaI4QrOwezrvWvrda+Tnp3yisXuMeM7oyhg+/raR69/JpJWzvOiT6Zi/7sIYVmBsMBGtRmyo AFVQZKH0+nQWQ5RduCadxe67BExnAzMGeNGJxW6vbCvwZWak2wrSMcAR2j5FdjndSaLb7XIyhH3m lgvESKrmrNV+oz1P0gg8cLE+r+LD27RHFy4kyUde0D75/JD2ybhvFpOs5jvTRk8kjl+9N2zwhoxh lybO8VT6Xzp4/i81eaiDAe1dgbgy8JwmoH1pHXBUxZBos0VBZfNi/fDSFQe1oaxEGyrmPP64nsci l/D93+P7ek406rWMF4PelGizComYEwlPEO6kIoed+U52XzjS/fFJUhMclNjyY/HN74aKb16edHxn LbGRlzkG0K7CSdaMAvjhs1o1m1cdr4cSlogoILTUc9WU0tJQ1NZeLHmYlQi0ImJ1lDjLDHpGMUo0 avda1fV/ZnTpjHzTjBswGokkWWLsUa95gn4gjCIgW1F2RmHmD3HzEtknPp5AvD/en+WT+zlsBknE zEsscRZ/Rl5RcWGaZJAkdLaI4MUMx0toMSb8Qj3h+3yZRUVY5Vw2cubOoyniQtsH++aS04kJU3e0 P3Eq8qV3jbd9yc5nxYGk5u257x1ddN/CkybimHt705RFwdFTq59+bPdOp2AWWpYsarDcTgcMPvxf 3QO5zR9GLM8SuyEe0mDTMTmZck9GDdsXVYkvk1AJWm/AsHNy3wr1vDJdMeoPMOk28l7/nDFLlKnH MkF3YgKBvqmelCRXQlpimsQgnsQb9ZzvsnrzSjHVo/55PAYot0ymQbEV25yGoiK6+qk9ZOS45SOV 4Q9N3XL2lnnvPzz/SIltYxcbdlJ4/7dntbEVd227eeWLS9c9rO3aq2mPTB+3TfybSXvkgebGFp5f pyHm1iDm3BAKJsZhLDtNVKAuLFA9sezuiVlntAVhsbbohg94cxJEZRy2eLNBBDdxi7wdgkI75Ovx rKRxF+tFjM74WvsCD3NfTXwqJ+eO1U+dPL7z3gdd85PIMA2dUDYwbXXZR2+//pfqNViGUM6LLAv9 lAAytB7zJGJAcD8loYCpaNH4Xos6Y8YWiV5FPUH5msfoEEuMJ1poQ0E7Abl/v77JSQhKERJIgkGH pI68BMzxbncGRyS1Fdi5FplofIUOf/bp7Qfqlo7KKFtP1KIjCz/49rtfzn81V3j2obvOvvG7P5Yv fXzqqhcX+RpnkkJi0sjQGQ0zyJ9M3wmg156b0e6X0O4i9jdtQVMfIrJkQkUaM3o/dA0TCZvYkyZ1 uWm91KPVDzG4uE5Wg5TkctjjzVKKIcVuNST4QZYM3gIhDWwFUJyH3aLk8rpjrviPCOxMoBVff6F9 RkwfnPmCdCcKp548+HxKl/Droz955vJPSS4xRsgIQfv4Y0sw4dQvpj3YptfnNFTmp1I8d3xwhIOA 6MRcSEvjMaOO4EbWE4JDL1v6sSGBYwUbOwJ2a7SlwiTgIi5DFO0uzLZYtpTi4kIe7ggYmju3jhi1 f3YdSthFtx+oaDGHxLUdD+evuJwvvLcgYfDZlxPvi4/atFozsVQdyyNg6bE8bwwjPEzTkGSICcac V9KShbeaUj1PVm4JbepDURPKdE74AUZMZElJBJJGJJUU5OfmZCgpfSwmDnU9kWGwFhbkUASOgO2a IGTm55WywkKOnxzsEUopR1Bhvs2ZICp06MRVo5T02rsbq26ryXf3KRi98OXEMxNXTijwxJU8uWz6 U/PrlOFLXlrW/nTwGYMnp/H2vbduLLlldd24hgdvLSmYeNuS4cMWt4/L617+WJ/iilvnjWmZdPNN 7Q9tq+s4s2Nq46Qtl6Xqeaum3Tw0Hf20GetVMsaPCwLBAdbo2YvSK2XYWSYyqpcu/YjhSre5FAkr oI3HACZm3lrpKSdfttmExfPuW3kgJa6ri234mCykjz376MrW2mndx3lqKR864aA2rrs+6pP9CJIJ 2NfwM6s/mKX39thiCbyT0dGg11vGUDwDQzDo5zaJtzOKzeFSCsmE3bt3s5pLx1kN2Xj6tI45rosd dbHCgKAvMcHMuOS8WdLDPKGMCTTWJCGL1Z5k44cHlN6F1aQI6zEWZYNt83NSH8NkcutZbQj56Ofa wmUo++U/rZdSDTPIfC2vew1NnafVRfeLfEp5jbDBwGBmIuZIK+H1t+ewAg1CNCUSSLAgmm3ExqJn QG6xfkyPMHJsx5rnBIvTV5gpT4+b49z/PnvAdOlQ5fj6LK/ZssbG99kIIHUhfgfBxGMD5Fgl4uh1 89aC1UsiZSyhzGgQBN1THjz58htUjzM8a/LK2/MwpB/VB8Egn2J3+Vy+OAd3Zo7Q682raFqYn8TD rZ+QFK2xEhiSsxuGLNjujesypQ4aW9TxTGpcF13vyjtxx4g5VUX9TB3/OL6PDm9oX3TTgKW3jhrf vZfWjZ4/J+hbNrtuSvdRJlb+ZMzcZF9hfuprv3ivuzR69tvIMajHZ+1RQW+2o+o59PLB+/kEjkLd d55gEvA5PorVmJ4nITx7A67hTnfggdOKno0Kz7t/a6avB64b17tueu22/zjWRdi85ffuTzGxmp+M m/X+h93j6cOD1q9eMaticvfuKEaxBrIJKJcZkq6cx6/UiyuVwnOj+zzbHk1PT9ePSLy0ReuGJDpB wcJnxcIHJO7Ac7u6nt2za79Qq3355QWse/YvPiEWmvbaJxdPv33h09ci2mskeAldXqK9xmXaqKWz iSiTA+vdhmNWgWKyv6ov6TGXATNaVDosaYJg/V5fch2Tq5cJ+xLduqIYs+71PNiXOFxOgL4ep+zC Qx84fGk2Y6Lfwe2N5uYFRG9GeE8W7VEU2eZ0b9xq3fTOoz+f1f6L9be8MEQiZWM6Rvue3Kb99BEt Xcp4ZP+jEdi3K7J1xtj2Nu1WOrKq4/HQi19ps39/XsfIw6j8e6wRA3d2rToYFTHzX3QSMKL1Bhhn Qs8sFGWw67/ECNiAcoVi4HGji/RUHm1Leh7ovUm8xRSHLZaVWPmxOi/WlPREAV2enSHlpK1/vous sw5VWaP0hPG1Td3bhK8nv3HzYl3GOVi7W9E36bxnchJslzABCfxXkSs9kyDo1nRekSHWM13/oKdn 6uPW2490kq73TL7MYl6c8TiEoM4siFbDaPuUhB+3S5LIrxe9NNzV9fQ3hrnbGjctJz878sLjg7c/ OO/OSfd6857rpL9OyvVtCO2vmVDQN/ehW+7dO2pVsLE2WBmwWIu23r2ti+uSirntGXEUClEWLMFz puDAs7wT67iA9UGgbTxLC3VRayKiGqSeVGe3xuu/ifSWby6xTSkT9BIea/HIZzvXsmcM24cuIIO1 n42Z5l1guNP5pEq3Lki4xCIrutfd3Wa938XlmBe5IJxnNZAM86ImtNGo32LxFu24k69/ED22eG78 xg2Y8SBy1OfIsGG0IpJt+i8qRYWc4if5HGHe7gF1LWWrN+/OHbf4nppRq25vzCUL6G+7lVGtxX0W /4h+2J0x4YHQsJSU4aEH8BwYwZzGUG4zyMG+Iv/5qDQadELPQR0fmZNsLMHvJfmOXAeWIAeWoN3a 5MNft6aVjNlxSJvCarqXaBdv3fM+OXnpeDRXOrAW5OO6DvAFFauZCryX4bgneo7UqyYyYlQ6HLYk XqlppkQlasADpwN3sCfhLqz8QnH/hpLm5CPamwc+GfzFS58P/Gif9jo9f3RBBE5o/6uO1VxeuYOe 707YINzDdybQH/Uhuj79g6lxksAPdteoZLfbufUIr6R6McW/Ye3ul0kG8b2srSAPndTe1d59meZQ jzad7Oz+U/dZclIbGdVL0BKFv+l6ZQTTLNgNgBkrAY3twKOjAaPDTYNKup0fwbmt8sHAM01mJk+u xUXFQphMIQVhrTKx6vUduYWmIam33ZEzwInKLBQ2XxrmO/C08SHWuHjeUOD/xwLy7/Dm/7VjRmLJ 38Fs1P/h8sy+8DY+vp9n7RsZ0N1sKjE26j8809j/eMD3jMVaX4C45ZHDkV8b/xld6cofsgc7lja9 fOzlPwfgOBp20NOwji2AqewDmG6YCHPEN2Au6YJ7aAvMwauOjYPJrA3ayL9gPt0Bk8jnsEo4AXnI P58uhgw2DaZg7zmPnYJ29jjcxZ6HOSwVWtmTOG7Q+bdQCTrZYzg/A/exbXC70AI1BjcsFDG1iBIc FE2wSPwdHGR34mXD+VG4Tfw5HKSpcIz6IufYb+CA0A0HDcnwvPgpHJSmwCL2IGzhozgctrJ3YTqr BYP4JPyY/SZyyfAhIuIcxLG9kQhDmeku2CjUQgGODWwNVLERUEPvg4lsNL73MjwsvAXTUP5pbALc TH8CaewZqGZNsBlttJ+8FDmMMm2mQ2Gz9BlsxPU2sjDyhnE8Bc30Ir5/Em11GlLZGLSDIRKRqsHB vNBf0BAcm6CRfgi1Qn8ykp6HGewCdPTYno3Ffdqhkd0DxWwhJAtOUi78CzYIFJYaBsMdQiba+iO0 5dswXzgE7QYZ7mA+UIWxqP8hWEovwQP0G7if3gOrWAAP4GfhUToBFtMQLBPug/uEb6BNqoFlUjFe 02EJt7tu8xtcxgBM5H7QfXDVRVMjm3U/pEYu4HVZ/Br69vjg2kv4IyzRfYJ+uPrifhDN6KfTsFS3 +Q0uqRN70reiPrj6IgcjLeQgPIjjMbzeZUcQj1d88P3rFLQwFUfuh6su7gd2FFbwkevK97tuRN35 /v925PhEjHD92Sb0G7cPl/HfjBzDHEf/dkR8c4yJx2Eoji607dOo3yIc9+LYgTa34/gHHJ2IFyP3 AbcDK4djwkZ4CuNiE3kxEuKxwfHJGmArjxGO0xuNLB7HVxB3ddCf+4/b8NpRjyu047Wj4UWYbVgB 43mscbxfM67j8cdjgF89dO+IcanHRmzU8YA++e+OPJb1eEIM6X6MxTSPq2tH4ZeQaloJB+MWwEFj LcqvYC55AQ4K38Jmox3zxx7E7c2w8WqeXn9EcRDqwQP6cd/V/kS/hNAfA3r8cq2NoraIdPfa5ho9 rrUH+u6wIEM7v+jXsIqEI/vx+j0dizHyMYkTBuO97RjHkzHPRjDO/bBJVGEHz5c8Z/XgkedLnrN4 btTzE+ZFPTdds1+PHa8de+wqZsC6uOWwjmhwL/knrMFrpZAH9woeWCPkI90OI4VjcKswC34kvgOr jBGUux066DxYgbmrBPPQNPYC+suJ9eAE5u/h0IjY3oryjmevQKXBAQ/SFyBLTIO1rAtt9hTMxquD LYXJ4gDMuUFwsvcBm3foc8NPCTTrnwdgJ/wZ/kxKyEyy+wc/vyO/owNpa+9nWe9nN34+p58LlcJz wmn8fHmjD9srDhRXin+VRkubDP0MUwz34+dFw5fGZuN+47dxi/HzummgaYHpHdO35jzzTPMT//P5 n8//jx/eCZI9MAYMUAsMO8YsKIJbMNI2xs3k/wxWq741vilMyEOhk0bsKGfJKlEqZVVQFqnOKllW s5rb+H/Xu/I/r1SqVB42mUTmP2y28m+bG79Dh1iWsWp8Jd6TmD8sCZXhdLJ2XJMaXNukz3x8doJB dIqnmtAJElmjsg1hESpRnP8NA5+DygplbmRzdHJlYW0KZW5kb2JqCjU3CjAKb2JqCjw8Ci9UeXBl Ci9Gb250Ci9TdWJ0eXBlCi9DSURGb250VHlwZTIKL0Jhc2VGb250Ci9NVUZVWlkrT3h5Z2VuLVJl Z3VsYXIKL0NJRFN5c3RlbUluZm8KPDwKL1JlZ2lzdHJ5CihBZG9iZSkKL09yZGVyaW5nCihVQ1Mp Ci9TdXBwbGVtZW50CjAKPj4KL0ZvbnREZXNjcmlwdG9yCjU5CjAKUgovQ0lEVG9HSURNYXAKL0lk ZW50aXR5Ci9EVwo2MDQKL1cKWwowClsKNTAwCjAKMAoyNDkKXQo0CjEwCjAKMTEKMTIKMjk3CjEz CjE0CjAKMTUKWwoyNDYKMzI4CjI0MQowCjYwNQozMDUKNTQ0Cl0KMjIKMzUKMAozNgpbCjYzNQow CjYyOQo3MzMKXQo0MAo0MwowCjQ0ClsKMjYzCl0KNDUKNDgKMAo0OQpbCjc0MAowCjU2NQowCjY1 Mwo1OTkKNTM2CjAKNjA2Cl0KNTgKNjcKMAo2OApbCjUzNgo1OTMKNDcyCjU5MQo1NDEKMzI2CjU3 OQo1NDIKMjQ5CjAKNTA4CjI3Nwo4NjUKNTc4CjU4Ngo1ODYKMAozNjQKNDY1CjM0Ngo1MzcKNTAz Cjc4NAo1MTYKNDk5Cl0KXQo+PgplbmRvYmoKNTkKMApvYmoKPDwKL1R5cGUKL0ZvbnREZXNjcmlw dG9yCi9Gb250TmFtZQovTVVGVVpZK094eWdlbi1SZWd1bGFyCi9GbGFncwo0Ci9Gb250QkJveApb Ci0xMDQKLTMyOAoxMjc5CjEwNDAKXQovQXNjZW50CjEwMjYKL0Rlc2NlbnQKLTIzNQovSXRhbGlj QW5nbGUKMAovQ2FwSGVpZ2h0CjAKL1N0ZW1WCjgwCi9Gb250RmlsZTIKNjAKMApSCj4+CmVuZG9i ago2MgowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjc1CjAKUgo+PgpzdHJl YW0KeJxdUEFqxDAMvPsVOu4eFieB0ksIlF0KOXRbmvYBjqykhsY2inPI76s43S1UYKPxaIax9Lm9 tN4l0G8csKMEg/OWaQ4LI0FPo/OqrMA6TL8o3ziZqLSIu3VONLV+CKquQb8LOSde4fBkQ09HpV/Z Ejs/wuHz3Anulhi/aSKfoFBNA5YGMXox8WomAp1lp9YK79J6Es3fxMcaCaqMyz0MBktzNEhs/Eiq LqQaqJ+lGkXe/uOLXdUPO5SBW1veGPwyLD7lI4pP9YB9s4/l981x+/g9Li7MkjRvJ0fcwjlP9wXG EDdVPj+tgXkPCmVuZHN0cmVhbQplbmRvYmoKNjQKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNv ZGUKL0xlbmd0aAo3NgowClIKPj4Kc3RyZWFtCnic7X0JeFRF1vapukt3AiFhCYQk0B2ahCWsQXaG dFaWgOyQMCgBEmQRQYK4jANhkC2Au6iobOOCoNIJiAGdAXVcQAHHARyXUdzGbRTGz2UEyf3eU/fe EBoQnZn/+Z/n/7ub956qU6dubaeqTi1NSBBRFJWTRnFT5s/zb0x+4wtw7icyR0+dc8WsV68vWgv3 CeCqK668fmrctzd9TxRTDJml00onlRxr8uI/4P8U/h7TwGjUrWkrogZ++FtPmzXvuondfxwLfy5R 95IrZ0+ZROY8kyhnM/zTZk26bk6jHTHlRNfHQd4/Z27pnNSjQ/fA34Wo3h+N3dQcSDQeoeZ6GiUQ WZ8AnzKtmW59yuFM5eeIXe2AaDM9LqbT47SHnhMnEGsb7aId9DI1o1yU60a6k5aRSePBWUEj8TXA v1M0t3ZQZ9qIethIByA7jhbQbmoqEqzPaCEt0f6CWEsohlpRFg2n2bRaDLGuoQn0nr6YetIQuorm iHKr0LrZut16kB6iXdrL1mmqR4k0Bd8D1lfGX613qCNi3EX30nvi9qgnKYhUyiH5AM2ltdplurCu sE4iByl0LfKg01A6IPbKdLy9lD4RCeJGLQdv+b0Vsv4EqWS6jKbRWtotuosBMsWYYA21DlBTpHEd 3novVdFOfKvpD/SWqG+csB60TlBz6kCDUJ4ddFDs1WpOL6rJRI0ZqKV21Bshs+mP9BK9JgLiWTnb qG9kGEHjBuswNaGuNAa5fQQx/y6+lwvwXai9qOdb2dQA9XIb1za9QO+LRNFZDBNjZTs5W67T5pIX KXbFt4Smo77vwdvfFelip6wvD2m/17fqp8wWNcesBmiRNLqPHqBnRQxK6hdl4nfiqPhQ5siJ8j75 gXan/qj+umcSSn05zaLVtJW+F41ELzFC/FpMEzeKZeI2ca84IF4Tn8osOVrOlMe1adrV2h/0bHxH 6WX6YmOpsdL8tKaw5k81f6753sqwltII6MMi5P4uWoeS7aJD9Ca+79EHwhD1RAN8/SJFjBG/wXeB WC02ic3iUbEDqbwmPhCfia/Ft+KUJHxNmSRTZCt8A3KuvFbeKe+Xh/B9Tf5D/qA101pp6Vp3rZ9W pM1GrpZpt+L7pPa+nqgf0i3Uc4axxlhvbDa2Gs8ZJ8z6nt95yfvqj78/3f70uzVUs7xmTU1VzQ7r fYpHGyaiFnzUD7mfhO8MtPcaaNw2+ouoj7pLFO1FfzEENTNRzBBXi+tQkzeJteIhlfcnxDOopTfE ceQ5RiarPHeS3WW2HIbv5bJUXi1vlbfLHfKoPKl5tHparBavtdcGaJdppdo87XptjRbSXtX+pn2g faf9iK+lR+s+vZWepqfrA/SJ+jX6Ov0T/RNjgvGK8bEZbc4yl5rV5j89PTz9PcM9IzyXeW7x7PQc 9hZDO5+nJ+kpqvMRx7RFWp72JN0su+nN5UF5EPo8kUq0oRKaKjeL5fK3YodsbVxn9pV9xaV0Qk9D Xb8o18vvZF9tqCgQo2iG7Gq/zWyibwHppz9PX+rPoGwH8ebrzPpigTxu1qcqQbI30nxB66Kna6/Q W9p7wqNvpLf1aNFMfCkf0YZDC/6g9zcKKUW7n57Qrha/pSdlHlH0Ke8q6PGlYgvGhdEiQ/xLs0iT l0KLemof0mKaKf9KX6IfL6e7RYl+Bd1M3cSN9Ak9jF7RzrjKbG/Gi31yul4hG4sdJPVHUbreorXQ jCZ0k7hMW2sel2/SNXRIj6Z3tceQ+0PyCW2ofsIYKaahB/yWltLV1iK63ijUXxdXkCbGUqp+DKPb jVqGngK6EKPKBIxpO9G7d2McyNKGgpMAzRkCvRiDEWItvvdgnNChQdPRx8dhFDtIO8zRspquMBoI jDpE+is1I2m89TDda11BV1m3U0eMB8usG/HGzfQx3UKbxZKa39Acaome864YYuTLQ0a+1VFWyDfl KLnm7PZFbaeKBPoc3yfg6W88TRX6GzSKMq1V1hFod1uMsPfSZBpMH6GUXyGFgdpe6lZzqay08rU5 KO97NMJ6xPKJaJpmXUnD6Bl6yGPQJE862jgkXkd5f0OlcqQ1TyutmY56uAW1EERtXYPxZ0UwZ8zo rGBm/1/169und6+e3S/pltG1S+dOHTukt2/Xtk1aautAqxS/r2WL5KTE5gnNmsY3adyoYVxsg5j6 9aKjvB7T0DUpqENeIL/YH0orDulpgYEDO7I/MAmMSXUYxSE/WPlny4T8xUrMf7ZkEJJTwySDtmSw VlLE+ftRv44d/HkBf+hAbsBfLcaPKIR7dW6gyB/6UrmHKvetyh0Dd0oKIvjzEqbl+kOi2J8Xyp8/ rSKvOBevq6wXnRPIKY3u2IEqo+vBWQ+uULPAnErRrL9QDtksr0+lJG8MMhVKDOTmhZoHcjkHIS01 b1JJaPiIwrzcpJSUoo4dQiJnSmByiALZodh0JUI5KpmQmRPyqGT807k0tNJf2WFvxarqOJpcnF6/ JFAyaUJhSJtUxGk0TEe6uaFmN3yUcMaLlzfKKVxWNzRJq8hLmO5nb0XFMn9ow4jCuqEp/CwqwjsQ V6bmF1fkI+lVqMSCUX6kJpcUFYbEEiTp55JwqezylQbymFM8wx+KCmQHplXMKEbTJFaEaOT1KVWJ icFd1jFKzPNXjC4MpIQykwJFk3KTK5tQxcjrtzcP+pufHdKxQ2VcQ7tiKxvEOo76MXUdpbVhyqXE 2VUwsrZmBecoMAgKEfJP8SMnhQGUqRc/SntRxZReEMOnSCBWqAQtMj0UlVNcEdeH+Rw/ZKTGBfwV 3xI0IPDlP87mTHI4Zmrct8RO1pNaVUO46w6lp4fat2cV8eSgTZHH/srfvWOH+dUyEJgT5wdB9dFw 1O2koj6dUf0pKdzAK6uDNBmeUPmIQtvvp8lJVRTsnF4UksUcstcNiR/DIeVuSG304gA0eQexuRof 8qbV/ouNa9o4b1qfkGj6E8GldnjBqEDBiPGF/ryKYqduC0af5bPDe9WGOa5Q45xCLUk6LpmkqVAo 5YRaYfYU1g/pqfhnKqUuqfZ4oZWKI/z5objigfazKDol5WdGqrZOcCxFzkRzshnqk362v+9Z/rOy V79CQ4YxVRaMHl9REX1WGFTNTnCQQ6DxNLowxZ8TojHoman4V23t7cUoSgoFUWU5LAD9s1mO9yzB JMddhA9rZ8cO+RjoKiryA/78iuKKSdVW+eSAPy5QsUs+J5+rmJNX7CpOtbV7ZVIof1UR6mqa6INO ISm7MiCWj6gMiuWjxhfuwmLBv3x0YZUUMqc4u6iyNcIKd2HJEVRcyVxmssfPHioQKGSV9Cr5pF1B onIVqiuG8k+pFqR4XpcnaEq1tHlxLk+Cp9u8oOLxh8eYnNGFdbVHdcmijtBGKZSBbRAsdg9RSsOU hql4CEy6P/q1vT8GDTpFfn0vJDETr9AD2kmsMpIwT2Y0xfRDgVbU/ZIePZq1Ms34Jk27ZfTofkla mpwx+/D8mpqdT9XUzD88+7InJh+9++4jk5/QTs49PBc8IZ8q+8vcIZeHLr/76NG7QXja5Ww0X/vF fWnaxNh+33qTvGo23vRhm/ZMXxned+fJbaeviCNvfbUiFCqGiufpX3Mp5cTRyW0nb4gjh1/7iSky HRbbUg5C8g26XC+jeGCQpwVda4ylQrGMxsstdCNDa0FB/TGaC9kt8GeB7ua4kB8DvAf0A8YCiQ5v KDAJGMV+yO7iuHjHHH6PomU03uuj2cZY6zTSW2O8RFOBdXBv0j+kzWZvmgX/g4i3RyfqyTKIs8bc QveAfz/Cp4C3DrQQ/o1wT0C8Lo47yrMa61FQwAS/Hd6z0ilvG+1Z6qGXWe+jLEV452BgKdIYDpoP FECmMWg2sEy8RMvFS9YmhIPSYqS/jPlArkMH4j1LEJ6JeK3hXwx3IvJhgsYCKUBb+Rj1lk3oGdDO KP84u9zASzSNy1xbJuTfydO5sPNYUBdI8w9AQPa2PgaNqpO3cCwOwyCtG5WDzgSSgBHyAM3Sh5BA fd1rfEwaA5rH9fQu8Cu9hC6FXyCfo4wdtJb9wFCFMuu0fj9t0L6hXgi7wVyDcpSgvmHdy++os/wH dTRTaSH0KxfvXwSswzs/VfpQQqORfifQbvrHSoeWAquQ1nG3nrhu4F+Edh2JtH7kHoH4o4ABaJdy 4ErOD9LvzHXO7S7G1vSG7EeQmcAAv5kCys46yXE4Pt6V6ujhpjOUNkFmNer1GKgOxHMeXCg9c4Cw F/Ge5oAJtAA6AR8Dm4CZQB+gAGiLtAnpakpfoTOsm0o/oBvGS6hD5E3prF2Gdao97T6z0XkXp5Ni PkYzHaTwO7m/sM4iL5Xuu7lPsc64VOn3TKX3X3E5WadqKfqe/gUN4DyoPgjdcin3O+SZ+8MaOYaW g66FHi9mneX8uZTrhXVN1Qn6hEP71SlrF9VHQDWigKPri13q1kUtnUYP4p3F5mSMKRtooD4P64vb aLJ+gnK1dtTJ6AIeygPZkPyCRnqx9kBbDoP/3jB6D8NzRMww9qKcW1GfR+gB1OnV+hHZSj8iDGOr 9ZlBYp+xVS5Q7nNoOMReO4wpo27YL+X/O5BHja0YM7danxtHLAvluZ37hOcL0QXwuxT8KqAcaO9N F/d4Z4pqzxiKM4m+AWbrQepjBKknJrVMPR7jPPoC+GOM92mPthpz3BHrTVFO5fIILfXE0ySsEWM5 LXmUFjP4/aBz6ujRWToXrksudfU1nPKY7+iUD9RE/zvo4CMH3wHfQo8KoJPNeW7g8VnNDxijgaW2 vlona/VzHz0EutLVzzA9nRmmn/XD9TKcqrkF47vbT5GPFW75eXzkMY7HSB7neJxx5cNpnfgVcgv0 mMfhAzTe6detHAxGHj9w+j7GYbT3OMsy861HzB3WZq2RtdnMgPuvgGE9gnJfVzunFlo1znzazp1L bT7Vc+dRoxvNcsazB9V48zXdqebRsSp/UeY2WmicQrtjDFT53eD0QdQn8j1TL0adr6VVKEdzbRn6 I/jABK4T1RZECTwv8Jyo3YV65rloNS3W3oa9wHG7UUM1X2TSOOR9n+JhTmXKPGMcbTK/oAx9DMba vVTCbcXl4Pxw23uvoRhvPMaJI9RVfxQy8RQNuQ2qDoL0iNILjjsTJhXqwjOFPNDZSyHD79uo4gSp kVMfD6q6UPFhi7AOc13gnWY8jVT2xBe03hhD49CHNnrKaaM5Bn0unjbjHQ8h3hjOC+Ilqvn6Lvo1 +tdyjE3LMeaQ0v/x1iltK8pzHcZ1QCtHHW2lBKMcdThTlT1Xt8fYZdx/tC2Uxjpi3oVxmO2Ju6hC T6c8cyatBm81bNW2SHcleDeh/3ZB312B+D5n3CakvQJ8jpvJtgzbCNxfPEFqbJYrO4BUHthOQfra Z7RRG0zLocdZ3rtQD0sIlrFgo7El0NWG8i9wsMqG4sXZVKRocfRb5stu9DpSqEdk8Ry6S19E0/Wx lKF1Rd9tSB31P6Ov/kD3abE0Ud9P9+nVtIr9emNqq2GVoe2Abcn8QzSc+fJ1+O+h8Xo/xF9OV+kT qUyrhO4dpmh9Ktoa8YyboSetEf9rvNeB+JDGa2PRt5bC/YP1GMupNHZY4xj6QOqo4tWByquLsDzL ApRqMNoU+WX3WflFXmvz6ebxPPlT5eT3Ih7L6PdRP9TTO0CqTWtGyNW0Fdgg36IcbShdLzZbu1Gv +WEYWNevdxc3Ap307vQUsAjuDqB/BLbZfthu3eltYAne/Szodl4XMGQ29WAK3jrgHuAVN6wuOJ3z 8evCSLJ2n+V/EnMNIL6xdjPC5VHPPZBeD/1X1m4GdHEww1xITTzzqYnWBvyWiBfmN5LQn56k1hpZ 318sTz8FfLrUqcdg3TK67QHa9GfgnTrUz9SZG/7tvP27QPsuBC5T9fsVxds6RA3EUesd0LHiKMVp 10AHAfg7wt/YrU+3ncC/Q/HD2g+6Qlzn4fxwf3i7Xswvt9PEunD1oFYfbqf+DD0T8kC437uP+jPM FxD2wrl+/ZGLYDy119ZynqCDbc71m8OoDUO2Rl4TOQ76HFDrP4QxAmBZFT+GBjC47zLkDqzXgNrw 7pTHqFOvPbhetbV2uNs+bruEtw/yF9QP0iDQNNDeoKNAB7u0bp8N77fhPHcsOZ9MWN/ocqF3/r8E 9J39wEvAi/+n0xIEXQXiAPMd2CGZsCOPwD75NS0mOo2x5MfOwMMYh0aDvgEeZu+adkAM3A3BuwL0 AaJT38I9F/wjNiypJ9EGx65sDt5OJ67Xed8oO/6pl4lOfgNss+Of2gLMgPufAObzU38DfRb0Hsh/ jng3gT5nh5+eCP984Bn4v4D/SqAQ7ltB40E7AI2BRoi/hsH2yDnr0P86Pf/64+dS2CxTkE8f73mB 3hi+hvjZ1G3Pi9DwtYbb/hejdfYMwqhdD1gzfQC7L1R37fNTaxyXoj1r6kIfY52GTVmf7Wi2Zdl+ VvajQ9X6TdmxSJeoiUvZdmb7lW1ntl9BN6o9A0PlZwyv81W+nHmj7tgqvqF1QByQ5NCZkPlBtrEO YuyJhX5/i7XRgwz4GwBjbViHMHfFYq7bg3H3W9AD8LcA/dad09yx9Zwx9iJz2n/b/0vnyH9jTs1w MDEMF+K76OVgECN8Lv6luNjc/W/P5ReYo+vO0/+p353nXUT1pwyGJ2jtZoTbpefYARfxX8zO/aX+ cLvjF/vD7BLXH45zwsN1z7VnEimxFmH97peC1xb6k2dsfzcP4f24tr85ftRRXl1gHGjrzKGbMF7A /rdaAJijrNvBW+D9kTK8j1MG/E8CmDdrvgQt4TDQ9WI1729bp+H/Hfxx+gElW+ig5GL6HK63bJ8r +xB1psbBWzn/1BnoCzQCKoFZblvzGhJpvykx6/I6Vx9vfasfBMJswIvS7nQ18Dj8sfDHYixuYjbE uB2kR3g/HjQaNBrj+4gze3zWafMGJTNY7S3Po4EY56/Sj/Del/UntadXQ7Ge+uocZTHmUJ+7Twd/ PO8Nefy8X2JVO/tzxebXmAfHYT6M4rkD6Y5VZ0Izdd7H/Zru1OpRrrOH3MTdS+b9KZ6vzE4Up/Yx 6u4jf0hd9QmUC2Tq9jnVGN5/0T5WZzXLeN9du5Secc63QtFbaF3US7TOW0L53oXqvGmNdj8tBu9+ z810v5muzlfGuPMqz4nn2fvjvczE2j1Np8zhNoHK3wQawvsxddN143nzMZd+rfah7H3Mi9g2mOMr gBL7vML67vz7ndarzr7nNGeOn18754fv00+gEdoCrPvcPdmHQY/S5fpSwKnj8Ly4aaFeTl/IFnJt E7jHqb0++7yH96Aa1zmHy1f1/Jlqr0HcZkYM+nAst7+1S7fP57L16yAvqbl+HLD3HtX5HO8NA+Pk m5Bfhz56FfoKdFC/Q53h3eQAstbDKt6V9rmZOQrIRL6mIt4WPjtyQUvOwPpIH0MVCmpfzdokm1i7 QOfKV9QZY6xzFthcX0Wj1Z7mmTPBBL2t2rduq48G0P7A9fC3VmV3qKqrIOLFYl3HZeS9uU5ECPNq fZ09UkfW8xTle4LQ13qUb2yn1tps2C97MdYlo+0Go11jabH2AbXUe9EUrSGVMES+dVB8AQpLnSE/ B/9N0Nvg57PfN+hy91zN3p+mUwr7YSsAzlkuo5Qht4gU55ywyHG3sN3g9aadCu47ttDDdQA56wPg lLwTaWdTiaxGGhuQF6SjxaH/hQFxJjto66QzQB+HPnY2csKBuEw7hwN8pqnhcPiJ4QCfaXY4wM8+ Tz4uJHehfFyInxYO8NP+C/m40HsD4QA/8BP5KwgH+AW/IB8XqufW4QC/9U/k49JwgH9peD4wPmEd W/Mi1qaPgf7Vme8/Ax0CCu2r+RPcWF9YUx3/Xx25uwGsf617AayVrWwHGPMsXgMvA/0HgHW1NeIM avaBJtv3MNx0rDuA9sBYOy2OW/O0nbaCk2bNdjv+6cdBXw7zNwX+bqen0uaxdzdoAFjrlG+5k27I znvNHWfka5LtMqp4oTOwNGAk4vtAR51BzZM2rOdBnwB4X/QlJ1/sbunUB5f5KX7XmXGBTuprMWYU E2GubuLZYlP9NzREjbmHzpqr5qjx8EParMY7C2NfP8owY2CHPEDZbDfwGG6UKvmVRgnmJoJ9Mlad 583Uj5Ghv0DNjY9pon4V5Wo7YRcPwHiLNNS5DN7N4zbbHNoKGgqos0p1JsRnJ9fRsugdyn6Jg0wT /RPk917agzXbcqOQBOKbnk7w34p5fSNdZ/yGbvDOoj3mCeT1CE3FfOUzJ1Jv43c00F3bmrMoyqgP u8Ch3ntoiqcD+FvIr/+dkqOWwa57jYajznq6adee3XuoCfgP2/srSv+AH9OBISrPyC/sMB1r6ybu vQHjMtRJicrPperM6VHSsUYn4zjm7kHU1hMF26szLY9KoA3mdyiHCTs1XZ3LT3XqvgufP3muoK7G Mkpz1+7mR6jn0RTtUj6Pc/cDYLtt1Kcpe7GROtdy9gNqqfsOPm8rp1V8VyLcrnHtqFqbwtkjqN1z cMsDyvNnbfkdWsfesPcU9sI+jad0PsdTeyLh1MmTOsfbC11y7FnPHhrs0UAfpqnmUhplDEW9NKZR nuepkWcAJbB95vEou24Wz9HGD7BFR1Ea2ibH6e/XAtyXBjh9fB74bwCP2f2R+xfzVd8E7/Rahz8D uBGYbodzmLXQdp8+br9fhd1oy59GP7T4DE7W2at5z4Zah/jr2qnOXaql59AzZ/esP/kXpT9zD437 MN+pOs8Zfzi9A3Sa64ed9x766O2I6wdM144Op7p9P2WBTZVtyPQhh/6edY1tvXAafn/lQvdZfsKO tfuZS8++9+LSyx2aVnsv5yK07j2ZM9SyHH+Dn7t35+y5Jbr0PPcP7D25M9Q8Z/1Ul6o2Ic2xY9l+ H6zO+fluzk+g9g7X76ADZ2Msg+8TnA8mZhKG58qz4dj5F4R5C+IBXl84rP9hIM+LbFj3OfjCwSaG JrCWBvTbwmH9j8L579flmg8gXcDb0YZnnw1l//8EUAfkQQ/2NlLU5LnwJwErg+E57mClC8tiuPXu 1qNbLyjb31HuabV5dtN33vuftuN/2i7/rXL/VN7rwrmj51K+u2eeN99oH4X/saHu0myhxg5M1OvT wFZgv4M7GOgriXxXSSuFPpWq+4q1cc7Rg9VYmzIcv3P/xjRh2XkS7H7Ad39sUNH56sdTauufp41d T+rejm17fYxyxDh3bKc6Y1/rqOG00bkn6+OxBfMu9/Mu+rM09Wybzxplr6etTZgnDcg3NOZRvnzF +r1xA8aEE9bLxkLYAgDSusnBPgcbbNvP2ubcgzTVfeAt9GhdYG3bksEySK8MeMixt9mOnWuj5hOb fyZf7tir/QvlOEXN1f3SoFpfD9enY00/nZprXyAc9gKfN2mTKIvnDK0HbCu+c3Odc1+W9x7eBbUR g3oZrm2u07/5fg3fqwHUnRxupxcxB7D8iyq+u75vq/aXZmIcf5t86u4PwtSdHryD7zqxXaRhRWEM g16MgOwI68/aPaADHfwLuAr5HUvT5U3UUZuK9fBrsHfiwb8amA13AmgsUATcD8ynrop/CnpyEvKA psP/KqiBtb0B3g8OVtngcLXe3kklsIlL8D5b7oiKY8OkEvGcSqtEy8b7ICexUtJgUWjxjttE+BLE 22Ov33lfgeVVmCsTdUbG+JLyo6dSvtkYWGHtNrKs3eIz6qePp4Zo0xigO9r6oLN+YDvqEIDastbB v1+G3wtwz8kdajxO041fUUfjNOyDd6AHx6if8R3dZ2RSW3M45rHHiHWpL8Bru6l8n1jdJT5iHXT3 vl2YhRQf9QINQBsS399wqdzKPwJAeceo+cj+bSJbb1tti0zdn7b7mrJzPbm0GP04Hxjo3Pueap+P wQZF39Pte6pt9YeohW3H8RqqBrVlcX8YhbGhdu+VKd9pY91ybEFEtR6Tr/O61urJZxVyON/XUnF/ ba9LLd6vvhPgPcv765w/rWH83z7fkmHnUBc6L7rY3YyL3dU4x/8Lz1TC725c7C7HRf1hZy4XOy+D rrKNnI95ZY+5xToC/1PAbRhfH2ToZFlqf9S211Zo9dC352ENOohaO3uivE/aEuNXS32V2tNfar+P GmNsyrb35q0fnd85qP1U3ptju1RLUL+DSHR+18DvH+zs36rfTdTu015CY3is5TFVzRl8txvrNIw3 JTy2yH3UTf5oj0HiiALxWKT2JbORx2xFlVu2d8aUbIqS3VCWO2xosdY+NSY1sMcsjfC+ah7PMP/a 41ULLdEev+RhewyS70LGxTfA53xWw+tptabm+xCPqrnppD1OqrGQ9yHhVr9HsddPsdwH+XcwF7OX HNtyaxh92qUXswudOFudOOfKO2c3mEsaqzn5JWrHd3tr111E3dTd6L+r9cpAhLMNcsbOd/fbVTuh jeyzfRG+LuDzHG5bd01v75vVHK5DJ9pQ8zTX4yewy6Ix7w5RaWCMU+c9ZdY3Tj55fdIcerqydu3n ruXctQZRX30dPahdAVuoC99JUvP9M3XWtw8y1B2SffSQussMCt4ByA205w01h7wAvAb8GfgKOGrv U51+k387xPVSux5az/cHanYZ76C+XqQo7xBqbu627RWtnObyvjiDf1fAUL+dcrEF/YrH8TLev1Gf 9hFEEEEEEfx/gaURRBBBBBFEEEEEEUQQQQQRRBBBBBFEEEEEEUQQQQQRRBBBBBFEEEEEEUQQQQQR RBBBBBFEEEEEEUQQwXkg+C9a0dfUjx4gD0mKo878v77qj9X7Ixkkd9Fore32tATfa89o7egYILV2 VektfLu0NlqLqr6+YLUW2N4oPiM2q6Pmx9s6q6cfz9nANmAPoNNErSX4cXguBMqBbcAe4DXAJMKT Q/3AbGA9cIxDtBZacpXfF5fVRmuOuM2Rx1itGR0HLEAjH56dgWHAROAWYD1gKjnmzAYWAnuAEyok qDWrur0b8t6saqUi22dcmaG8k2zvhMuUd/u4IpsOHWHT3EG2WB9brOslNrtTtk3bdLBpo9SMcqbR MRl7s5pqTVHIpsj4HDyF/BPFCkE+2qDFUwiQmulwglqj7a3TMtbv0XQSmtQElZDP2quJqpiGGVnR 0pLHqRH55FfySztEfrm9QcOM9VmD5Qe0DdgDaPIDfN+X79NCeYzrHM9MYD2wBzgEHAdMeQzf9/B9 V75LsfJv1BnIBCYC64E9wHHAI/+GZ5x8h7VFPdmdCUj5Dp5x8m0U6208Y+VbcL0l30LW/lLVs3fG LuVI7+w4fKmOo1mS42jUNKNavl71QztoVBpaGhr1tNaK+lM3rVVValdftZZQ1W+6r1p+uN2f7tuQ 1UUephAgkZPDSPkw+YHhQDEwBzDhOgrXUSoHbgU2ACEAWoZnHOCX+4FXgaPUBQgCwwGvfK0KyVTL Q1Vp2b6spvKgfImaocYPyJcVfVW+qOgr8gVF94G2BN0vX6xq6aOseggnxIkDjQPtjHBDPru9dSOf ldVQ7kHd+fDsDGQCw4CJwC2AKffIVlUlvkZ4ydO030uQrKLPFH2YNnkpOMMXTMuBAvr5kdbnV3Dh sd6/Pk0G09bcCy8/0m6+HS5+pN20Ci5+pN2wCC5+pF05Hy5+pJXMgIsfaeMnwsWPtGGj4cKjWq57 qnUbX89hM4U/K1Zei1q6FrV0LWrpWtLltfylH3TO231V7dujxtYG09u195XvFuXPiPKRonyTKC8V 5QtE+SJR3k+UXy7K00V5sihvKcqDovxp0QtVUS6CO87y9g4miPL9ovxxUV4mytNEeaooby3K/aJn sFqmVA3qpkieItuzuNOB/qo/Rp9YmYIaTYHOp2BM2IPnIcBSviCE/K1s4eYtmbba3j7T9nfqkzE7 a6B8HhGfRzM8T+8BOhroeajR83jJ83hBLJ6ZwERgL3AcsAAT0q2Q8VvUMxbPzkAmMBFYCBwHTJWd 44Ck2U4Wt6mMdXYyPYx98nl8+Q9qp8iUYIu45Lj0uIHaLckitqUY1tJqKXtS06YYshs19DasFjE7 v4/51/cxFJUVJW+Wt1ALNMStDr2l6ocWvmpxT1Xa076seHE3tdShdaI3pYlU0F5UpvzdKdnL9BJK lltBM6qSxyJabFVaB99u0YBj7fT9kPyR77Pkagnnp8lP+97wV+uiyncEnK07fYeTV/j2da72gvNM WrUA2e1XoruSe/ke369EFyFgbZVvAZOdvt8mD/DNTFYBpXbA5WXwBWN9I9PG+wbifbnJk33BMrxz py8z+XJfP1uqO8fZ6euCLKTbzvbIbLtklWigpXrhmJ7VYlqwg2eNp9AzzNPDk+Hp4Enx+DwtPEme Jt5G3jhvA299b7TX6zW9uld6yduk2joWTOe/8NjEVH/okX/SLUhX7jjJT/X/U/BftfRKGkyhxlqB LBiVLQpCe6dQwWR/6LtRgWoRPWJ8yAhki1CjAioYnR3qlV5Q7bFGhnqmF4Q8w39dWCnEzUXghuTy akGjC6uFxawlSfx3fneREA2XrE5i2nbJ6qIiSmg6PzMhs1H/hr3zc8/zKHae6Wc+CWe5W4TWFIwq DG1pURTKYIfVoqggdAf/IeBd4mtxIi93l/gnk6LCXVp/8XXeSOZr/XOLigqqxVglR37xT8hBY/6p 5LyYmFmO/N6WttxaWy4V8SHXmgnkoqIoVcmlRkUpOV2wXGVZ67zcytatlUwzP5UpmbJm/roy+1Mh k5qqZJqW034ls79pOcuE+iuR5GSItExWIiKRkpVIskhUImPPiHR2RFbUiqxQKWnijEyyLRNzzJWJ OQaZ9J/7Kc1OTxfb+xZNmcB/RLk4kFcKFIdWzp+WECqf7PdXTily/rpyWvHkKdOYTioNFQVKc0NT Arn+yr4TzhM8gYP7BnIraULe6MLKCcHS3Kq+wb55gUm5RdsHDL+k51lprahN65Lh53nZcH7ZJZzW gJ7nCe7JwQM4rZ6cVk9Oa0BwgEqLlI4PL6z0UnZRzgSbbpf1oqGvxUkpRdlN4+b0V8rbNyVhQdJu WCubqV56Uah+IDsUA3BQx6yOWRyEPsVBDfgvZTtBCQv6piTtFpudoDiwGwayKX3eNWXXUELe9Fz7 Xxk+YM27hivcfqaXXeiDsLxQcFJu2TyiglD7UQWhzBHjCys9HnCLuUihPi6vXr28amuvzewEZh9m alqtIPP6MS8qyhE8t/2vcWgO94Jy+fR2EWwp5lFZkRZqWTBaYigY7fxJ4t2wpXh6KCtCActEuihz 3+FkOz2dbD9xmV3Mu8ZxOXUxz6F2TEQpc6uk9sOVlV5bY/PwQvpffW4kzwplbmRzdHJlYW0KZW5k b2JqCjYxCjAKb2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBlCi9DSURGb250VHlwZTIKL0Jhc2VG b250Ci9NVUZVWlkrQXJpYWxNVAovQ0lEU3lzdGVtSW5mbwo8PAovUmVnaXN0cnkKKEFkb2JlKQov T3JkZXJpbmcKKFVDUykKL1N1cHBsZW1lbnQKMAo+PgovRm9udERlc2NyaXB0b3IKNjMKMApSCi9D SURUb0dJRE1hcAovSWRlbnRpdHkKL0RXCjU1NgovVwpbCjAKWwo3NTAKXQoxCjM3OQowCjM4MApb CjYwNApdCl0KPj4KZW5kb2JqCjYzCjAKb2JqCjw8Ci9UeXBlCi9Gb250RGVzY3JpcHRvcgovRm9u dE5hbWUKL01VRlVaWStBcmlhbE1UCi9GbGFncwo0Ci9Gb250QkJveApbCi02NjQKLTMyNAoyMDAw CjEwMDUKXQovQXNjZW50CjcyOAovRGVzY2VudAotMjEwCi9JdGFsaWNBbmdsZQowCi9DYXBIZWln aHQKNzE2Ci9TdGVtVgo4MAovRm9udEZpbGUyCjY0CjAKUgo+PgplbmRvYmoKNjYKMApvYmoKPDwK L0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo3NwowClIKPj4Kc3RyZWFtCnicXVDLasMwELzr K/aYHoJs55KDEZSEgg9NSt1+gCytjaCWxFo++O+zltP0sSDtDrMzDCtPzbnxLoF8o2BaTNA7bwmn MJNB6HBwXpQVWGfSHeXfjDoKyeJ2mRKOje+DqGuQ70xOiRbYPdvQ4ZOQV7JIzg+w+zy1jNs5xi8c 0ScohFJgsWejVx0vekSQWbZvLPMuLXvW/Gx8LBGhyrjcwphgcYraIGk/oKgLLgX1C5cS6O0/vthU Xb9BXvgey78MG1VHNuJmcjtU6vf6ar1e4JHbzEQcOZ8pZ11TOo+PS8YQV1V+N5QaeuQKZW5kc3Ry ZWFtCmVuZG9iago2OAowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjc4CjAK Ugo+PgpzdHJlYW0KeJztWHtwVOUVP999bnY35MVuIBvkbi5JSHY3QAhJgAwNm4SQoGMSQHch1V1C Ij5iomIFpRUE1IkVHGWEVqcYoDxD/RaQodqO1kfFajt2puNYtR1arNpOLahgfbHb33d3NwQEW//w r7rJ2fO45zvv8+VOiBFRBq0mmbK7vrfcGOvTP4DkUcDknv5remevTGwG/QqR3nLNDSt7nI8ceoHI NoZI2bSsO7q06PYHzxA5h6BTvQyC3IftH4J/G/yEZb3LV0g5u4JEmTYi7bEb+rqiT7x4CLbzdhPJ Hb3RFf3SZv2vRO4voG/039zdz5rKfUT5heAjNPLzER2jjxDsMfqLGkycVF9VyhKfxu8UtOZJ0pz8 xlJuRHpMTm2h7nCAMwgM/kwbV0oWcaVpcchrej0DIYO3tYW8vD7sMXitoGrDYYPbm6JL+UTB2psM PlkQk4XGM20ho8cYGIhCpS0UgcSwlARVLajqiCcSDoc9nHzhcMo3nEt+rptBrgFIQAPXGtpDXG/w HSBGDZEgd3cXQk/245kBl1JTF2dNSyKNAa6kZeQzY5pSHDGaBsyoSMbyTR4RHzc8yCHtkcvFZrQR Z1V/TFWbOIuC1vycRQyDZzS0Ci0QZjDM7YLrAGcHF+C6cMal4mAqrlgG6JgdX5y5TQOG4QsaSnFw YMBAHFwr95pwkKY9qfMAiw/DXzO8NEf46iVn84qh8WYjZw2cZh1gjMFVgNv8MVKbFoTIiMDiQYeD UXAgEtMln6cIsWX4uer7Sg27H3JHxGhARBERBn7bQ6ZRB9bkud2FHq8Xag4/t/u4vTzAnX7DaDbO hmVGa01jYGHofKFHHMtMh4dScGc5Z67JltdRI+I671GW35gG3wGe7ScuJ+2hj2nTgiT3IWuoG2eZ tbEs5kJUOX6jDhEMB4CSRmsDPNdfkV8X4HkXeIpCdkFjtD8mkbvYqDCarTmTilsGBprNZjO6hDMz eCCPMddoOHChy270EL/WU8583QMVpmHUDcCK++xTo8J6bnAV1pjP4BExOPXtoYOyoRieg3KJUhAO BjEYtgZMgKVszolwtQHdjoiRTS6L3BBZanKlIboU4yM3RD2gI2JMoRaFXyylOQdlNmFnjuibrcGy BRNJU6Y1/mAiomYqZksVZ3EO1rETsC7jGwvhMb3hsxbRg3yRjgGJWpJKx6xDlmMsMbeZQTybYzYL +6LKY63sZTE6ydrQglCFUYfLIjlP6YKcLZ5WDK7FGnjW1GUuSU1Nqp6mGJ2ClLOGdEEj4m5CAuma e/ymUSEyn4NdrAtXxBxstC/AC4fFbSPF487VvqDOJXDpSs4Bdhl9z6vgOej9+IvIDUw3G53Hc0F7 /VyMSYmfu3wXjKvMz92+AcQuBgM5flkHrargDqiWDk9TuvwYJKykUYF5T1qb4I/ZcKF8/alr/nqD JkIUC15nYqFHNN0bTgVi+sU88CKQxSL3dLoTRbpeM5VvKu7hDItEhk2ogTEHl2A6qXI/zx824BMM 94DyW1QhqIBVGDDjwFT4+Zhh7UmCsbQnW5TQnmJRQrXSz8cOq04VjKVaZVFCdZpFCdVqPy8YVq0R jKVaa1FCdbpFCdUZfnzNTN1wfMbwFSauJkbzEx8oZeo8Mqmm3m4ahQW52TZNsfnqizMZsUuckkSS V2gyKsWXs4gkSSbQspwtmyqf6WPVNdXTqkrMIl3T9TwwUyvz3a7RgvNWVtfky6UTVKlsk1u/8Zro sqsnZtpCP5kS+GLVdXNndT/PGoPzCvSW3vjfznwuhX7RWzS+JTR1Up3E/NMLMlZ271l+d/9dHzpG y/ETWvYoRCFRR+JdJYx4p1AVDdVnT630l5tFBfl5OZkOXdVtvnk8ry1UP7uMKerEUklWqtwkS7Jr tD1DYZINKalejckkMVliVEaKoorEVBWJIUVB40WGTM1T33rWBtNkN/LWRpjRvKTBsBag/25MD4sy WTXxGqVyjdtrTKsqFRUrRbVQLhStqqS0pEhD0UrlVAE1tbJGXvbB1l3x9+P/HlTsK1g56+zpvH33 Is2+cn1Voac+TysomL5xSUXXFNU5+M4TK++aG//h2BzZ3nPq2dX33MEczu3vzp9UPl3/p1cqudTl C+SUZmd5pyDGq+YverhjrV1BPSfhHe8RtZKclEXX1+dmZmZmZWY5HRk2XVMVRlZFZ6KiE0ZhEhQ7 0pK8miqRzJiEDCWRtTUU2ZKpeM5RI4WUmnN1k2pWOSpr8nUzx8zxlrJiOYfJP96yVG05kjizRZHK WDARPyFNLdDfi29jV7XK90pnGHsjXgIjj6P/R9UOKqb76kcVm+PHjcnPyXJkSEwTkX4HkdYQ+luY iTF1wq/sNZgyHn2QRRxokirSKk1HnRrrTGbqnvppFzqpkEqir2UjbIw8p1nZVFe6k0NvJhtcKXYi 1dEcr8hVM73seNe/Xmq4d+euePz4Tod9A5uxYeHC/TNW9027ca50yzOmMsa/Nb5cvt4VrO3nxx7Y OMA8+nPBYM+u6XkOu6tUes2QT7nQs9tQg3ewAwa6d1n9qIBP1MHtysrM0FGF+hpRfqcDQeYyVfJi ihUvTqmKZKUxPJkogKLIzNrlTNnUkEd1SdUsydrgfD250RjNEanlud1TU6mJp0/PndB682U733v8 BxnKja8N3tpvrvpl7Za9dat3Dv49/v6jK71bbr37ysV1s/vuv7br1NvHnty9oapv5sdae++121dN sNfVrvj1Ww9uPMLG9d05t3XVd+tmtzZbd5KA5y99bt2TV2fVnTYybNZb1Ms7Y3cJ/MqVm+cn+s5U OU7qU8HakFnyg3N61Zkq5LUj0Ze4yXHSsjTiw3bTN/SRdgGG6PeKRE+pCfqHsocesO2kTeoCmgX5 6/IgHQbsg3wNZMdZnKLyJ3QAuFe+kgiy66QY/RHP5wM6AJMgexxwm6KTB/hqwM1CX9KoW13AQsKO ejm7Aj47MtrpYWV/4rSyn4aUHVSFZ09DPiTHaQh0C+Aw4nhZ7iQnbA/B55AmU0y9nJ5AvAuh+yNg 4XcIsBq8Tw3RdtBF2s/IBjxB2ZP4VPkpdSKPZ0XMwL+CvF1tSRyXTVpnndtOWF/Y208hQBQ+VciD gP24IW+RWKIP9DbQa2B3B3R2AZqFDNAD/QGcb4X9WeDXKnriC8SlowZ2bK1HIarF8z/Lg+xS4D/h 2d3siFX7V5HjZuRzGLKjgN1CB7JNcjd16gtpP+ytAP+SmmCa8lvMShvtQw53WrmjlvDZBegHfAT+ HcByq96DtBf238T5xyA7qn9Mn+mfMxf6+zrOtifr/mXQ9uIvK3oh+pCCPQLD1hVJSLwJOAGbnek+ fAkWsCwLoxcjwepFslczrLpfAJDz91O9iI4E9OA51H8m8DrAFuguHu7DeSDqkurP2nNA9EL0TGCR r/B5Pk7mvvBiWMyo+hCJOe5U3sC8iBqJGC+O9wgs5lnM1Ffgw2LegEVtIqjxJ8hzEDgBOA14D3Ac PQhC/j7wIOqxWrPRy/Bxi9gRSU7clKrvNmUvbRP7Ap2SFF4s/wF4F60R+yXPp5h8J42VOqlA9FHU 8qI4YfWj+Xysf05zAd8RPq0dSOKbUrgztZOtF8XYV2tngHHXz0rx1akdXvu/YrHr1r6J+bJ6nNx5 a+/Ow6hTWMy4NWepOETdZI677TTdp7xIW6QdtEc6Cf4yWiffQcsh/416ih6Cj8fgc711X+HOsO4r 3BminuLOEHeTdT9gN1N3wzl5puM8H6fjVltoq7YV98wQvZAGnN0I2CDmCDbWW9BJ29TPqNe5w+rx YfTyaZw9CFvttn3WPIUR51HA78R9jT769FZ6C+eWIOaAdW900kLAIpwbhJ6KPCxgb+M+QR0kJ+Um IbEZsA9wAnBI1EfUA/RTok7sY1rzDfxpCuGvfYi9IbV++/Ptz//fD1nvhXjzu4705KsaFVGA6kDd o7eId8d5/PaOUIyxDeGf2/A22WVwZjYaXDb7uavJMPjESI/4v+HZfwJxyWw8aHfIku+gM0d85+bj O3xAmag3dTRCpki+Iyyxniv3x1Rq/A/ck2t5CmVuZHN0cmVhbQplbmRvYmoKNjUKMApvYmoKPDwK L1R5cGUKL0ZvbnQKL1N1YnR5cGUKL0NJREZvbnRUeXBlMgovQmFzZUZvbnQKL01VRlVaWStIYW1t ZXJzbWl0aE9uZS1SZWd1bGFyCi9DSURTeXN0ZW1JbmZvCjw8Ci9SZWdpc3RyeQooQWRvYmUpCi9P cmRlcmluZwooVUNTKQovU3VwcGxlbWVudAowCj4+Ci9Gb250RGVzY3JpcHRvcgo2NwowClIKL0NJ RFRvR0lETWFwCi9JZGVudGl0eQovRFcKMjQ1Ci9XClsKMAozOQowCjQwCjQyCjU4Mgo0Mwo0NAo2 NjYKXQo+PgplbmRvYmoKNjcKMApvYmoKPDwKL1R5cGUKL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFt ZQovTVVGVVpZK0hhbW1lcnNtaXRoT25lLVJlZ3VsYXIKL0ZsYWdzCjQKL0ZvbnRCQm94ClsKLTcw Ci0zNDkKMTQ5Mgo4OTkKXQovQXNjZW50CjkwMAovRGVzY2VudAotMzQ5Ci9JdGFsaWNBbmdsZQow Ci9DYXBIZWlnaHQKNjQ5Ci9TdGVtVgo4MAovRm9udEZpbGUyCjY4CjAKUgo+PgplbmRvYmoKNjkK MApvYmoKMzY1CmVuZG9iago3MAowCm9iago0MDc2CmVuZG9iago3MQowCm9iagozMzcKZW5kb2Jq CjcyCjAKb2JqCjMxMzgKZW5kb2JqCjczCjAKb2JqCjM0NQplbmRvYmoKNzQKMApvYmoKNzAxMwpl bmRvYmoKNzUKMApvYmoKMjM0CmVuZG9iago3NgowCm9iago5OTMzCmVuZG9iago3NwowCm9iagoy MzIKZW5kb2JqCjc4CjAKb2JqCjMwMzYKZW5kb2JqCjEKMApvYmoKPDwKL1R5cGUKL1BhZ2VzCi9L aWRzClsKNgowClIKMTcKMApSCjI1CjAKUgozMAowClIKMzUKMApSCjQwCjAKUgpdCi9Db3VudAo2 Cj4+CmVuZG9iagp4cmVmCjAgNzkKMDAwMDAwMDAwMiA2NTUzNSBmIAowMDAwMTAyMjg5IDAwMDAw IG4gCjAwMDAwMDAwMDMgMDAwMDAgZiAKMDAwMDAwMDAwMCAwMDAwMCBmIAowMDAwMDAwMDE2IDAw MDAwIG4gCjAwMDAwMDAxNjAgMDAwMDAgbiAKMDAwMDAwMDIwNyAwMDAwMCBuIAowMDAwMDAwMzcz IDAwMDAwIG4gCjAwMDAwNjczMTYgMDAwMDAgbiAKMDAwMDAwMTAxNSAwMDAwMCBuIAowMDAwMDAx MDM0IDAwMDAwIG4gCjAwMDAwMDY1OTEgMDAwMDAgbiAKMDAwMDAwNjYyNSAwMDAwMCBuIAowMDAw MDQwMzMwIDAwMDAwIG4gCjAwMDAwNTM3MjUgMDAwMDAgbiAKMDAwMDA2ODg2OSAwMDAwMCBuIAow MDAwMDY5MDE0IDAwMDAwIG4gCjAwMDAwMDEwNTQgMDAwMDAgbiAKMDAwMDAwMTIyMyAwMDAwMCBu IAowMDAwMDY3NTc0IDAwMDAwIG4gCjAwMDAwMDIxNDQgMDAwMDAgbiAKMDAwMDAwMjE2NCAwMDAw MCBuIAowMDAwMDY5MTYzIDAwMDAwIG4gCjAwMDAwNjkzMTQgMDAwMDAgbiAKMDAwMDA2OTQ1OCAw MDAwMCBuIAowMDAwMDAyMTg0IDAwMDAwIG4gCjAwMDAwMDIzNTMgMDAwMDAgbiAKMDAwMDA2Nzgz MyAwMDAwMCBuIAowMDAwMDAzMDg3IDAwMDAwIG4gCjAwMDAwMDMxMDcgMDAwMDAgbiAKMDAwMDAw MzEyNyAwMDAwMCBuIAowMDAwMDAzMjk2IDAwMDAwIG4gCjAwMDAwNjgwOTIgMDAwMDAgbiAKMDAw MDAwNDE2OSAwMDAwMCBuIAowMDAwMDA0MTg5IDAwMDAwIG4gCjAwMDAwMDQyMDkgMDAwMDAgbiAK MDAwMDAwNDM3OCAwMDAwMCBuIAowMDAwMDY4MzUxIDAwMDAwIG4gCjAwMDAwMDU0NjUgMDAwMDAg biAKMDAwMDAwNTQ4NiAwMDAwMCBuIAowMDAwMDA1NTA2IDAwMDAwIG4gCjAwMDAwMDU2NzUgMDAw MDAgbiAKMDAwMDA2ODYxMCAwMDAwMCBuIAowMDAwMDA2NTUxIDAwMDAwIG4gCjAwMDAwMDY1NzEg MDAwMDAgbiAKMDAwMDA1Mzc2MyAwMDAwMCBuIAowMDAwMDYyMDE5IDAwMDAwIG4gCjAwMDAwNjcy NzQgMDAwMDAgbiAKMDAwMDA2NzI5NSAwMDAwMCBuIAowMDAwMDc0MjEwIDAwMDAwIG4gCjAwMDAw Njk2MTcgMDAwMDAgbiAKMDAwMDA3NDcxNiAwMDAwMCBuIAowMDAwMDcwMDU4IDAwMDAwIG4gCjAw MDAwNzg1NDEgMDAwMDAgbiAKMDAwMDA3NDkxNCAwMDAwMCBuIAowMDAwMDc5MDI1IDAwMDAwIG4g CjAwMDAwNzUzMjcgMDAwMDAgbiAKMDAwMDA4NjczNyAwMDAwMCBuIAowMDAwMDc5MjI3IDAwMDAw IG4gCjAwMDAwODcyMzcgMDAwMDAgbiAKMDAwMDA3OTY0OCAwMDAwMCBuIAowMDAwMDk3NzU5IDAw MDAwIG4gCjAwMDAwODc0NDAgMDAwMDAgbiAKMDAwMDA5ODAwMiAwMDAwMCBuIAowMDAwMDg3NzUw IDAwMDAwIG4gCjAwMDAxMDE2MTkgMDAwMDAgbiAKMDAwMDA5ODE5OSAwMDAwMCBuIAowMDAwMTAx ODc0IDAwMDAwIG4gCjAwMDAwOTg1MDcgMDAwMDAgbiAKMDAwMDEwMjA4NCAwMDAwMCBuIAowMDAw MTAyMTA0IDAwMDAwIG4gCjAwMDAxMDIxMjUgMDAwMDAgbiAKMDAwMDEwMjE0NSAwMDAwMCBuIAow MDAwMTAyMTY2IDAwMDAwIG4gCjAwMDAxMDIxODYgMDAwMDAgbiAKMDAwMDEwMjIwNyAwMDAwMCBu IAowMDAwMTAyMjI3IDAwMDAwIG4gCjAwMDAxMDIyNDggMDAwMDAgbiAKMDAwMDEwMjI2OCAwMDAw MCBuIAp0cmFpbGVyCjw8Ci9TaXplCjc5Ci9Sb290CjQKMApSCi9JbmZvCjUKMApSCj4+CnN0YXJ0 eHJlZgoxMDIzODMKJSVFT0YK --089e0821c1c4bdee2305514759bd-- From nobody Tue Jun 6 02:56: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 14759128B44 for ; Tue, 6 Jun 2017 02:56:55 -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 idcB5cHXr6Lg for ; Tue, 6 Jun 2017 02:56:53 -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 9A026129BF8 for ; Tue, 6 Jun 2017 02:56:53 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id u19so65173226qta.3 for ; Tue, 06 Jun 2017 02:56: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=/chcCftwt2kZupeObTPxCsRm3dCk9QCZB25fQ2ZcTBo=; b=BTD7m5Qu0grXX7VrO/0bCYkuhZ27jJ1kGnI8N11Q1MSuITi62/2LNTnFNBLlRJETt4 ZFItP25Y526xQMAAQ2bueKjKo63xp5N9q2KmDXoAWY6g8J8d1XtRAxsukP2a1s5hQGWD YPJYJOrxXxURDF1IgY8cXR6sUv2HW1o/THfSBNpXnmzOfmeRQruV6YRgy0oLAUYGWOov Ossq2B0pfUqTl8k4Lnm8jYEIbBl3/BfbkWKpxU1F+pg5nHvOXRThKAB7xbexaIkZ/k7W zqOEycCG4zVCxD9NxagSi/10xkKR4zyy2DrY1xWRO8an7IO3wxFHfv7f52qyomRHSib2 JeKA== 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=/chcCftwt2kZupeObTPxCsRm3dCk9QCZB25fQ2ZcTBo=; b=FM89ZRsj1TBw5q8TUCv4qBJo7AlIVK6VfaMpPh/Cet0fchW+wWorqyyI41O80m43Ii 9lyJEE+G023qFjSxmszZLLX+ANnaBcHBOd94l3qKv4vvUXrujdamLtue0yVtCuXa5aw4 wjE7UMITgFbr/4uxetWD3CZoHUZJYfBCpDL9ABuP7JNlfHk/pyurlJw8T+cccdMHovKK jQVicTvchb6AqsSulk9J7iXmpl5GcX7BvIDAKDzCShqO+x/rCLPtP9heF44VWzvRENMg ibhj8elUY4DzhPQzdbhWaAlR50DgXU1m/IgaxFX++bIm+13gEoMoIYrFLzDmrCsz8ZwE NRBw== X-Gm-Message-State: AKS2vOyOw8WOXbc3udhkABgyHMVJsS6csdPPSedwmDKxGdEPGKP2MXa5 HA6UUrGdHAkNry/aub+jsTCXhKfCBH1k X-Received: by 10.55.175.67 with SMTP id y64mr30277096qke.130.1496743012589; Tue, 06 Jun 2017 02:56:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.65 with HTTP; Tue, 6 Jun 2017 02:56:51 -0700 (PDT) In-Reply-To: <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> From: Victor Vasiliev Date: Tue, 6 Jun 2017 05:56:51 -0400 Message-ID: Subject: Re: Comparing HTTP over QUIC header compression schemes To: "Eggert, Lars" Cc: Alan Frindell , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c070136967730055147a368" 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, 06 Jun 2017 09:56:55 -0000 --94eb2c070136967730055147a368 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 4:59 AM, Eggert, Lars wrote: > > (2) simulating loss rates much above 1% is likely going to be pretty > uninteresting, given that QUIC (and TCP, FWIW) have congestion controllers > that will struggle to even deliver useful throughputs in these cases > On networks with traffic policers, loss rates are usually 20% or higher (Flach et al, "An Internet-Wide Analysis of Traffic Policing", SIGCOMM 2016). This normally does not work well with TCP congestion control, but some of the more recent work (like TCP BBR) tries to address that. -- Victor. --94eb2c070136967730055147a368 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 6, 2017 at 4:59 AM, Eggert, Lars <lars@netapp.com> wro= te:
(2) simulating loss rates much above 1% is likely going to be pretty uninte= resting, given that QUIC (and TCP, FWIW) have congestion controllers that w= ill struggle to even deliver useful throughputs in these cases

On networks with traffic policers, loss rates are u= sually 20% or higher (Flach et al, "An Internet-Wide Analysis of Traff= ic Policing", SIGCOMM 2016). This normally does not work well with TCP= congestion control, but some of the more recent work (like TCP BBR) tries = to address that.

=C2=A0 -- Victor.
--94eb2c070136967730055147a368-- From nobody Tue Jun 6 04:37: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 058CB1294A1 for ; Tue, 6 Jun 2017 04:37:11 -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 Fje7ddnRLdEW for ; Tue, 6 Jun 2017 04:37:09 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002: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 3238A129432 for ; Tue, 6 Jun 2017 04:37:09 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id r66so40728653yba.2 for ; Tue, 06 Jun 2017 04:37:09 -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=Lzw2s26Qc3NL7mdDaf+NiSHhHGbiQXHXdlcncyPR3MY=; b=DmcdGcjLAZHWvGsra+qld9sWd1/dlGPzgl4UbiKHoJrWV+OHwlGUUkPDU3mxaCNYoF aRk+tTuaRxA9556DhXJ1clVyvyy3y+BBGQu+8o1BrvRoSGNLcLudawEeF020F5BX+uso 2FhohNm1WFYLGNfB6qrIIgpDDVz5ysF0mrtWoaXBaULMqJwIeImdo8ghZeNBVjb/ISVP gF8/p839mJ7RKVglZvl5bqxagr/zjPnszB8h/xD15mKa/cmp/diU+9xBozr/vVeJA+M0 ek+u/YuPc850ZzdPzIdwdh0B6lqvSPPXXdayCqdzgLIQizyP/arCdfiYvc+qW+HV3enl 6QjQ== 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=Lzw2s26Qc3NL7mdDaf+NiSHhHGbiQXHXdlcncyPR3MY=; b=Om4odm9FQcYI4IzKJo1wpNcY/mZ1/ZV2NbSkMz9UH3SwFiwRV9Uq197VRBxwljTwGm cVo97F5itL24p1hwwpqxNZrpl1h0yxtaIZjStIoo2t0LyBLCQhameMgddocMLLHS4/3O pcTvcTVVk6l+/2t+0z0BHzjJb3Uk0w1zb3DGGwm5CqPsm4EubpkT48ky89s7U9Pto0Cf BLcRTItyNaXtbIa3aT2/v8X7Vl3MFrmdIocu80luWXoOPIv+F6Q0g/tMmFxoD1JNA3GJ 5N9riXhunU9L/nc1+g0uTYb2XyO4LnqhwhSAY8ktn4/RM5e/K02kuPw7KGbuMOZz5DzC rBJg== X-Gm-Message-State: AODbwcBhyKes6cyzPahkrMQ7BcjpcPxK1lW1FyQpiLSK5AtbPSpvhYzD Cc4Ruiudt4v6/5TS5eZzLcvhtb7qxlV2 X-Received: by 10.37.97.66 with SMTP id v63mr2197220ybb.226.1496749028200; Tue, 06 Jun 2017 04:37:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.204.134 with HTTP; Tue, 6 Jun 2017 04:36:47 -0700 (PDT) In-Reply-To: <5aacf198-c433-e8a2-0aa6-70d453c05f75@ericsson.com> References: <5aacf198-c433-e8a2-0aa6-70d453c05f75@ericsson.com> From: Ian Swett Date: Tue, 6 Jun 2017 07:36:47 -0400 Message-ID: Subject: Re: New Issue: Loss detection: Overloading of is_retransmittable To: Magnus Westerlund Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1142e684255fa70551490a91" 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, 06 Jun 2017 11:37:11 -0000 --001a1142e684255fa70551490a91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the thorough review and filing in issue for this. On Tue, Jun 6, 2017 at 4:11 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > In draft-ietf-quic-recovery-03 there appear to me to be an overloading of > the use of the "is_retransmittable" flag. It appears to be used both for > the purpose to indicate if there is a frame that can and need be > retransmitted and if that frame should be counted as lost and impact > congestion control. I think these two purposes should be separated and > clarified as being two different ones. The reason is that if we create > extensions that will not require retransmission of frames but needs to be > included in the congestion control response a significant rewrite would b= e > needed. I also think it would clarify things for some of the control fram= es > also if they should be included or not, even if not regularly retransmitt= ed. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a1142e684255fa70551490a91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the thorough review and filing in issue for thi= s.

On Tue, J= un 6, 2017 at 4:11 AM, Magnus Westerlund <magnus.westerlund@e= ricsson.com> wrote:
Hi,

In draft-ietf-quic-recovery-03 there appear to me to be an overloading of t= he use of the "is_retransmittable" flag. It appears to be used bo= th for the purpose to indicate if there is a frame that can and need be ret= ransmitted and if that frame should be counted as lost and impact congestio= n control. I think these two purposes should be separated and clarified as = being two different ones. The reason is that if we create extensions that w= ill not require retransmission of frames but needs to be included in the co= ngestion control response a significant rewrite would be needed. I also thi= nk it would clarify things for some of the control frames also if they shou= ld be included or not, even if not regularly retransmitted.

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
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =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
-----------------------------------------------------------------= -----


--001a1142e684255fa70551490a91-- From nobody Tue Jun 6 10:19: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 364DE129AEE for ; Tue, 6 Jun 2017 10:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 s1dlz-nWdR9r for ; Tue, 6 Jun 2017 10:19:50 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 97E47129B16 for ; Tue, 6 Jun 2017 10:19:49 -0700 (PDT) Received: from dhcp-207-152.erg.abdn.ac.uk (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9D6A01B014AC; Tue, 6 Jun 2017 20:14:25 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk Subject: Re: On the passive measurability of QUIC To: Mike Bishop , Spencer Dawkins at IETF , Brian Trammell Cc: Eric Rescorla , IETF QUIC WG References: From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Tue, 6 Jun 2017 18:19:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 17:19:54 -0000 See my little postscript at the end. On 06/06/2017 10:19, Mike Bishop wrote: > Regarding the billing question…. For mobile devices, I believe the > major OSes support pushing policies to the clients that > differently-billed traffic should be sent over a different APN. We’re > doing work in RS3 to enable more apps to hook into these policies and > have their traffic correctly routed to the right APN. (In previous > versions, it was implemented in our HTTP stack and required extra work > if you were using your own stack.) This might just be a problem that > gets solved at a different layer, rather than via traffic inspection, > and not something we need to cater to in QUIC (or TLS). > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Spencer > Dawkins at IETF > *Sent:* Tuesday, June 6, 2017 6:33 AM > *To:* Brian Trammell > *Cc:* Eric Rescorla ; IETF QUIC WG > *Subject:* Re: On the passive measurability of QUIC > > So a couple of things, while wearing a couple of hats. > > On Jun 1, 2017 10:07, "Brian Trammell (IETF)" > wrote: > > hi ekr, > > > > On 01 Jun 2017, at 15:55, Eric Rescorla > wrote: > > > > I like the general framing of these questions, but it's pretty > hard to address them in > > the abstract. Rather, I think it would be more useful to start > not with the specific properties > > but rather with the *services* that collecting these measurements > is intended to facilitate > > and then work forward to the various baskets of measurements you > would need to > > support said services and from that try to make a cost/benefit > analysis [0]. Do you or > > someone else have such a list of services? > > Sure. Here are the ones I know about off the top of my head. Note > here, for "services", I understand "higher-level measurement > activities", or what would be called "solutions" on the > marketing-heavy websites of the vendors who build these boxes. > Please correct me if I'm wrong here. "Service" is unfortunately so > overloaded a term as to be unclear in many cases, even with context. > > As AD: this thread, like the spoofing thread, is the type of discussion > on the management deliverable I was hoping the working group would have, > when I agreed to approve the QUIC charter. Thank you. > > I know this conversation isn't easy, and so does the rest of the IESG, > and so does the IAB. We had high level discussions in this space on the > joint IAB-IESG day of our retreat a couple of weeks ago, and the ADs > continued that discussion during both days of the IESG retreat. > > 1. Access network performance measurement. This is largely the > problem the LMAP WG is chartered to address, using IPPM metrics. > Here, peak achievable throughput (of an access link), loss, latency, > and (sometimes) jitter are the metrics of interest, both in > controlled testing (active measurement) as well as passive > measurement of user traffic, on the theory both that accidental and > intentional differential treatment of measurement traffic will make > active measurement unreliable, as well as to reduce network load due > to unproductive active measurement traffic. Loss/congestion and > latency are the primary passively measurable metrics of interest > here. This measurement activity is used by network operators for > capacity planning and troubleshooting purposes, as well as by > national and supranational regulatory agencies to hold network > operators within their jurisdictions accountable. The deployment > location changes depending on who's performing the measurements, but > it's generally run as close as possible to the access link (for > broadband access) or on the handset itself (for mobile measurements). > > > 2. Interdomain troubleshooting of network performance issues. See > https://github.com/quicwg/base-drafts/issues/166 > . > Though it proposes a mechanism, it clearly calls out the key metrics > as packet loss and congestion, with the ability to localize > congestion using multi-observation-point measurement as important. > > > 3. Service performance monitoring (my example here was Boundary, > which is apparently called bmc TrueSight Pulse (tm) now) uses > passive network-level latency and throughput measurements to augment > information collected by agents running on servers themselves to > isolate performance issues on those servers. > > > 4. Perimeter security monitoring of access and enterprise networks. > Related to work in the DOTS WG, which focuses specifically on the > DDoS mitigation aspect of this broad topic. This is largely > concerned with detecting and blocking attack traffic. Most of the > measurement task in this case is classifying traffic as benign or > not, and it uses any input available to make that determination. > None of the metrics I talk about in the previous message are really > relevant here, though -- spoofed traffic detection is more useful in > this context than latency. It's relevant to QUIC, though, in that > one of the inputs to this classification is whether traffic is TCP > or not: the more likely QUIC traffic is to be classified as > default-benign, the better its deployability on networks employing > this monitoring. > > As a possibly helpful individual, this list seems to include implicitly > what Erik mentioned explicitly in the spoofing thread - thinking about > what trusts what, and what controls what. I thought that explictness > would be helpful. > > The obvious one mentioned in our charter, for completeness: > > -1. Billing, both for metered consumer-grade access as well as > transit contracts. This is -1 because it's not really relevant to > transport protocol design, as it generally doesn't require anything > beyond byte/packet count per billable user, where the billable user > is usually associated with something that happens below layer 3, > zero-rating and other such practices notwithstanding. > > As AD: this would be an especially useful assertion to converge on > (after the interim, of course). > > If QUIC isn't able to help with billing(*), that needs to not be a Late > Surprise (tm). > > Spencer > > (*) Back to speaking as an individual, one of the responses that would > not surprise me is "applications using QUIC aren't much harder to bill > for than applications using TLS or TCPINC, so, whatever you do for > those, do it for QUIC". If something like that turns out to be the > answer, people who care about billing need to be figuring out what Plan > B is ... > > > -Ekr > > > > [0] Where the cost clearly has to include future unknown privacy > risk. > > Evaluating an unknown risk is a pretty cool trick. ;) > > Seriously, though, I'd really appreciate any suggestions you would > have as to how to concretely evaluate this risk, at least for > purposes of comparison of proposals. Information theoretic metrics > seem to me to be not very useful here, since they make the implicit > (and false) assumption that all bits of entropy are equally > potentially dangerous to privacy. > > Thanks, cheers, > > Brian > I wrote this draft also: https://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-transport-encrypt-01.txt - It's not so much about middleboxes that change things, as about boxes that look at things. Some of this may be relevant to this thread. It's not specifically about QUIC, but I suspect that was what I had partly in mind as I tried to understand the implications of encrypting teh cntrol information. Gorry From nobody Tue Jun 6 23:40:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B465A127077 for ; Tue, 6 Jun 2017 23:40:50 -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=lz3aHYIQ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ciNfGKjT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIzyihcvb01g for ; Tue, 6 Jun 2017 23:40:48 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6062012EA5A for ; Tue, 6 Jun 2017 23:40:46 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v576cOLf022252 for ; Tue, 6 Jun 2017 23:40:46 -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=O22N3J6polPc37XRLb0z34RFoAnnW/ZXRz41sWudPxU=; b=lz3aHYIQESrlLIhlh+bTNRSwrD4n/Yuw+r4EMVQ9NC/3fgogMKhlNVCEDcrla9elP3Ws g5Ilxcp6l/D6XnuQdQRi6a649WWxQWfu7VLF3QpCgFMmHur+xBGDH0IKpaRwTnV5tI/b TAXMZ7XkoG26yLPx9hY8tWPAQFGfjhPSX18= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2ax3c11cx2-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 06 Jun 2017 23:40:46 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.25) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 7 Jun 2017 02:40:44 -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=O22N3J6polPc37XRLb0z34RFoAnnW/ZXRz41sWudPxU=; b=ciNfGKjTMTdYcfVp3ZFj9VgWd62+dB5GgZINDF1AtmJsaekm5vg5+d2TEc+MZUExjLIWr3liWvW6cW8MpbTUboPb0zV/vscQfdAFGgcKrwq87jZXHHXeakDIp9y7P1tpgLDBSP1mpPze6oql5sM93zI2bgN4XGb5Ttq4lU3Nr+U= Received: from BN6PR15MB1299.namprd15.prod.outlook.com (10.172.206.137) by BN6PR15MB1297.namprd15.prod.outlook.com (10.172.206.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Wed, 7 Jun 2017 06:40:42 +0000 Received: from BN6PR15MB1299.namprd15.prod.outlook.com ([10.172.206.137]) by BN6PR15MB1299.namprd15.prod.outlook.com ([10.172.206.137]) with mapi id 15.01.1157.012; Wed, 7 Jun 2017 06:40:42 +0000 From: Alan Frindell To: IETF QUIC WG Subject: Re: Comparing HTTP over QUIC header compression schemes Thread-Topic: Comparing HTTP over QUIC header compression schemes Thread-Index: AQHS3pDkbL6XmOk6K0ms9bs9UuyP16IXiUoAgAAQBICAAOYxAA== Date: Wed, 7 Jun 2017 06:40:42 +0000 Message-ID: References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fb.com; x-originating-ip: [2620:10d:c092:180::1:b44d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR15MB1297; 7:kZZ7xiJCWPdkhyPN+jFKD268cGEuVWpfbjApSrYZsQQYtRqW8g8OolkMRdUOpqFANdMNYzGjwGTPogoK79sXv7vO4pubUpo/OrH71bW9J2PXtVIXkQvuiz0BjMorpSznKNe/gmt9mB/wDVie2PI8aLjc3CSG8Bk7D/0dVpGHgYrwNV4aQSxlbD8+YvByJHjzRGphXXzu5NjW0TpLFCdzpUqHm2nB15EaWMTER5QjV5g2SzGLpnDinISToA6nHYtApVCn8zuJxkaj5W3xk2jZbvz1LsIMNv7gl/ekIvp2iRwkYcoP/iAJBa+Igq+Com0WmD9b5YBdYJUo0mz8gpYqkA==; 20:aF56+dSCoRbAhHLC5sB+Gt5TDqnhLCLsdxBRQ56a/gf/Urn6hYWmd2XPFTRz6gZYGIhi5Jay+Y/s/3mBV1ZDpKvGi0twfbNGZ16Hh7tBTY7rGTCHWx6QGZENtPPkBUwEOmbc7KDv66BIYNZN2GcJ6RBMSDNp5kWGFKlAAIM9Jqg= x-ms-traffictypediagnostic: BN6PR15MB1297: x-ms-office365-filtering-correlation-id: 487ca946-37ab-4f77-60dd-08d4ad701ebd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR15MB1297; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67672495146484)(211936372134217)(21748063052155); 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)(10201501046)(3002001)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR15MB1297; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR15MB1297; x-forefront-prvs: 03319F6FEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39400400002)(39850400002)(39410400002)(377454003)(24454002)(51914003)(6506006)(2900100001)(7736002)(36756003)(5660300001)(3280700002)(2950100002)(478600001)(3660700001)(229853002)(6916009)(8676002)(8936002)(81166006)(83716003)(6486002)(122556002)(82746002)(83506001)(110136004)(86362001)(6436002)(6246003)(38730400002)(53936002)(6306002)(99286003)(236005)(54896002)(6512007)(189998001)(4001350100001)(77096006)(54356999)(33656002)(102836003)(53546009)(25786009)(14454004)(2906002)(6116002)(50986999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR15MB1297; H:BN6PR15MB1299.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BF99D17D766F4500A845E57EA50828B0fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2017 06:40:42.7877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1297 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-06-07_05:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 06:40:51 -0000 --_000_BF99D17D766F4500A845E57EA50828B0fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgaW5pdGlhbCBmZWVkYmFjayBldmVyeW9uZS4gIEZvciBhbnlvbmUgaW4g UGFyaXMgdGhhdCB3YW50cyB0byBkaXNjdXNzIFFQQUNLIHZlcnN1cyBRQ1JBTSBpbiBtb3JlIGRl dGFpbCwgTWlrZSwgQnVjayBhbmQgSSB3aWxsIGJlIHRhbGtpbmcgb3ZlciBsdW5jaCB0b2RheS4N Cg0KLUFsYW4NCg0KRnJvbTogVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+DQpE YXRlOiBUdWVzZGF5LCBKdW5lIDYsIDIwMTcgYXQgMTE6NTYgQU0NClRvOiAiRWdnZXJ0LCBMYXJz IiA8bGFyc0BuZXRhcHAuY29tPg0KQ2M6IEFsYW4gRnJpbmRlbGwgPGFmcmluZEBmYi5jb20+LCBJ RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQ29tcGFyaW5nIEhUVFAg b3ZlciBRVUlDIGhlYWRlciBjb21wcmVzc2lvbiBzY2hlbWVzDQoNCk9uIFR1ZSwgSnVuIDYsIDIw MTcgYXQgNDo1OSBBTSwgRWdnZXJ0LCBMYXJzIDxsYXJzQG5ldGFwcC5jb208bWFpbHRvOmxhcnNA bmV0YXBwLmNvbT4+IHdyb3RlOg0KKDIpIHNpbXVsYXRpbmcgbG9zcyByYXRlcyBtdWNoIGFib3Zl IDElIGlzIGxpa2VseSBnb2luZyB0byBiZSBwcmV0dHkgdW5pbnRlcmVzdGluZywgZ2l2ZW4gdGhh dCBRVUlDIChhbmQgVENQLCBGV0lXKSBoYXZlIGNvbmdlc3Rpb24gY29udHJvbGxlcnMgdGhhdCB3 aWxsIHN0cnVnZ2xlIHRvIGV2ZW4gZGVsaXZlciB1c2VmdWwgdGhyb3VnaHB1dHMgaW4gdGhlc2Ug Y2FzZXMNCg0KT24gbmV0d29ya3Mgd2l0aCB0cmFmZmljIHBvbGljZXJzLCBsb3NzIHJhdGVzIGFy ZSB1c3VhbGx5IDIwJSBvciBoaWdoZXIgKEZsYWNoIGV0IGFsLCAiQW4gSW50ZXJuZXQtV2lkZSBB bmFseXNpcyBvZiBUcmFmZmljIFBvbGljaW5nIiwgU0lHQ09NTSAyMDE2KS4gVGhpcyBub3JtYWxs eSBkb2VzIG5vdCB3b3JrIHdlbGwgd2l0aCBUQ1AgY29uZ2VzdGlvbiBjb250cm9sLCBidXQgc29t ZSBvZiB0aGUgbW9yZSByZWNlbnQgd29yayAobGlrZSBUQ1AgQkJSKSB0cmllcyB0byBhZGRyZXNz IHRoYXQuDQoNCiAgLS0gVmljdG9yLg0K --_000_BF99D17D766F4500A845E57EA50828B0fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <17361B013CB2F147A9862B9426CB8763@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlRoYW5rcyBmb3IgdGhlIGluaXRpYWwgZmVlZGJhY2sgZXZlcnlvbmUuJm5ic3A7 IEZvciBhbnlvbmUgaW4gUGFyaXMgdGhhdCB3YW50cyB0byBkaXNjdXNzIFFQQUNLIHZlcnN1cyBR Q1JBTSBpbiBtb3JlIGRldGFpbCwgTWlrZSwgQnVjayBhbmQgSSB3aWxsIGJlIHRhbGtpbmcgb3Zl ciBsdW5jaCB0b2RheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4tQWxhbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8 L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPlZpY3RvciBW YXNpbGlldiAmbHQ7dmFzaWx2dkBnb29nbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVz ZGF5LCBKdW5lIDYsIDIwMTcgYXQgMTE6NTYgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O0VnZ2Vy dCwgTGFycyZxdW90OyAmbHQ7bGFyc0BuZXRhcHAuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+QWxh biBGcmluZGVsbCAmbHQ7YWZyaW5kQGZiLmNvbSZndDssIElFVEYgUVVJQyBXRyAmbHQ7cXVpY0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IENvbXBhcmluZyBIVFRQIG92ZXIg UVVJQyBoZWFkZXIgY29tcHJlc3Npb24gc2NoZW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs IEp1biA2LCAyMDE3IGF0IDQ6NTkgQU0sIEVnZ2VydCwgTGFycyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmxhcnNAbmV0YXBwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7 IHdyb3RlOg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KDIpIHNpbXVsYXRpbmcgbG9zcyByYXRlcyBtdWNoIGFib3ZlIDElIGlzIGxpa2VseSBnb2lu ZyB0byBiZSBwcmV0dHkgdW5pbnRlcmVzdGluZywgZ2l2ZW4gdGhhdCBRVUlDIChhbmQgVENQLCBG V0lXKSBoYXZlIGNvbmdlc3Rpb24gY29udHJvbGxlcnMgdGhhdCB3aWxsIHN0cnVnZ2xlIHRvIGV2 ZW4gZGVsaXZlciB1c2VmdWwgdGhyb3VnaHB1dHMgaW4gdGhlc2UgY2FzZXM8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIG5ldHdv cmtzIHdpdGggdHJhZmZpYyBwb2xpY2VycywgbG9zcyByYXRlcyBhcmUgdXN1YWxseSAyMCUgb3Ig aGlnaGVyIChGbGFjaCBldCBhbCwgJnF1b3Q7QW4gSW50ZXJuZXQtV2lkZSBBbmFseXNpcyBvZiBU cmFmZmljIFBvbGljaW5nJnF1b3Q7LCBTSUdDT01NIDIwMTYpLiBUaGlzIG5vcm1hbGx5IGRvZXMg bm90IHdvcmsgd2VsbCB3aXRoIFRDUCBjb25nZXN0aW9uIGNvbnRyb2wsIGJ1dCBzb21lIG9mIHRo ZSBtb3JlIHJlY2VudA0KIHdvcmsgKGxpa2UgVENQIEJCUikgdHJpZXMgdG8gYWRkcmVzcyB0aGF0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgLS0gVmljdG9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BF99D17D766F4500A845E57EA50828B0fbcom_-- From nobody Wed Jun 7 00:45:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF40912EAF3 for ; Wed, 7 Jun 2017 00:45:47 -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 CCMFgRWdLYUJ for ; Wed, 7 Jun 2017 00:45:46 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425AB12EAF0 for ; Wed, 7 Jun 2017 00:45:46 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 141so1495173ywe.2 for ; Wed, 07 Jun 2017 00:45:46 -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=gYMNySUBha/MbLoMj9Jg9tvqI8yVWH04y+lbh0mt84g=; b=PrA/nvwXNy4x36EhC8rfP/P42terUVWGZHaY7gz/0oKjl2NCwqoXwAGWaucpco6aZD gdkHip100CZVj9h16nT7Rhg74zggC+SQpjgctt9uI1ICd8iCH5K/ck+NTD2XbF/49vFb iF5QzvRZ34q6z+RifdC507AYK22CJKmlBQc8TZepd9C6fchITVw9+18fVddRjEj1y7Ut iePEkSLNmZuVG0Nrsx0znv9f0NuzHiNX1z6L7+ACWoJcV1SSnZ3hTzUIX43oUgIqXF29 bvzCv+sQC43ZB/RDFIhbDvZPPALnra99XzJaCWWwRLAUgTLAfGGzFNB7uI5bKYfN7D6J 4M6Q== 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=gYMNySUBha/MbLoMj9Jg9tvqI8yVWH04y+lbh0mt84g=; b=peQXVlW8xQuFhj8I80LmB1dMB5dqA8q+IiDoruXnkfBsSvxy9kKpcPj2cMAH7e8pfi gnL03Zp4Aufr9EkGFSsnVMawR6y3oASBd+GZVScW1yJ8azY8CQNJ8V4rqCw4y+qlnhIl 0UAcWJUtKECHhoZgU9ehYmZ/fmHDai2axslWmVHyiLiUKdcOvB7tO6PNk8xH+pBn0muI B2Z8eoVMQkwd3f5yK6TJwb7AhrxHQen/eP+ZDXVtvDaM/oqAIjQ6qunWvwbVHgcLDXxz ZaUJR6zboOeJziqMDxar8RDZ1l6zD5gmmebJXM9sp845n5asj/wY3QqWlNZjEUII6YcF a3+Q== X-Gm-Message-State: AODbwcCHt+Y0cm4FnwUExWVM4eQFgCdGEQ6eHRqdROW8aWqIRTD6fWxS hU1ozYpkMudS7zv5j6gKcnlmFbhP2OkatjGLGA== X-Received: by 10.129.57.138 with SMTP id g132mr5650287ywa.312.1496821545256; Wed, 07 Jun 2017 00:45:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Wed, 7 Jun 2017 00:45:04 -0700 (PDT) From: Eric Rescorla Date: Wed, 7 Jun 2017 09:45:04 +0200 Message-ID: Subject: Privacy for connection IDs To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114c76b47f5d0a055159ecbc" 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, 07 Jun 2017 07:45:48 -0000 --001a114c76b47f5d0a055159ecbc Content-Type: text/plain; charset="UTF-8" [Also filed as https://github.com/quicwg/base-drafts/issues/598] I and some others have been looking at how to protect the connection ID from correlation between any two packets. The basic threat model here is that it's possible to have unknown network transitions and so if you just have the client initiate non-linkage events, then you might have unknown linkage. Thus it should be, to the extent practical, impossible to link any two packets. We can -- and I'm sure will -- debate whether this is the right threat model, but the topic of this email is just techniques. There are two main sources of potential inter-packet linkage: - The conn_id (which is the same) - The packet number (which is sequential) The current design, which allows you to occasionally change the conn_id and then has a random PN increment, doesn't scale well to this scenario. I'm aware of two primary overall designs here, either of which will work but neither of which is a complete no-brainer. 1. Omit the connection ID and then directly encrypt the packet number with a per-connection key. This basically forfeits the automatic connection mobility feature that the conn_id provides, because the server/LB needs to use the 5-tuple to recover the key. 2. Have the server provide the client with a pool of connection tokens, each of which is actually a wrapped version of the (conn_id, PN) pair. The client uses one token per packet, and the server/LB then unwraps the pair upon packet receipt. In order for this to work, the server has to periodically replenish the pool, though it's not a disaster if the client runs out, because we can probably invent some way to reuse a token with a PN delta, though at some privacy cost. Neither of these designs is 100% ideal. The first isn't at all consistent with automatic mobility or recovering from NAT rebinding, which was the motivation for connection ID in the first place (basically, you have no connection ID). It also may come at some additional bandwidth cost because the PN is used to compute the per-packet nonce, but at absolute worst it's 16 extra bytes per packet. The second doesn't require giving up mobility/rebinding resistance, but comes at some additional costs, specifically (1) some protocol complexity (2) bandwidth overhead because you need to send the tokens in the reverse direction [best estimate is 16-24 overall additional bytes on the wire in both direction] (3) the LB will have to do some crypto to recover the connection ID (most likely one AES operation). We have detailed designs for both of these, though it's possible they can be optimized further. Happy to go into these, but I think it's more useful to discuss this at a high level rather than going into the detailed mechanisms at this time. -Ekr --001a114c76b47f5d0a055159ecbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I and some others have been looking at how = to protect the connection
ID from correlation between any two pac= kets. The basic threat model
here is that it's possible to ha= ve unknown network transitions and so
if you just have the client= initiate non-linkage events, then you
might have unknown linkage= . Thus it should be, to the extent
practical, impossible to link = any two packets. We can -- and I'm sure
will -- debate whethe= r this is the right threat model, but the topic
of this email is = just techniques.

There are two main sources of pot= ential inter-packet linkage:

- The conn_id (which = is the same)
- The packet number (which is sequential)
=

The current design, which allows you to occas= ionally change the
conn_id and then has a random PN increment, do= esn't scale well to this
scenario.

I= 'm aware of two primary overall designs here, either of which will
work but neither of which is a complete no-brainer.


1. Omit the connection ID and then directly encrypt = the packet number
=C2=A0 =C2=A0with a per-connection key. This ba= sically forfeits the automatic
=C2=A0 =C2=A0connection mobility f= eature that the conn_id provides, because the
=C2=A0 =C2=A0server= /LB needs to use the 5-tuple to recover the key.

2= . Have the server provide the client with a pool of connection
= =C2=A0 =C2=A0tokens, each of which is actually a wrapped version of the
=C2=A0 =C2=A0(conn_id, PN) pair. The client uses one token per packe= t, and the
=C2=A0 =C2=A0server/LB then unwraps the pair upon pack= et receipt.=C2=A0 In order for
=C2=A0 =C2=A0this to work, the ser= ver has to periodically replenish the pool,
=C2=A0 =C2=A0though i= t's not a disaster if the client runs out, because we can
=C2= =A0 =C2=A0probably invent some way to reuse a token with a PN delta, though=
=C2=A0 =C2=A0at some privacy cost.

Neit= her of these designs is 100% ideal. The first isn't at all
co= nsistent with automatic mobility or recovering from NAT rebinding,
which was the motivation for connection ID in the first place
(= basically, you have no connection ID). It also may come at some
a= dditional bandwidth cost because the PN is used to compute the
pe= r-packet nonce, but at absolute worst it's 16 extra bytes per
packet.

The second doesn't require giving up = mobility/rebinding resistance,
but comes at some additional costs= , specifically (1) some protocol
complexity (2) bandwidth overhea= d because you need to send the tokens
in the reverse direction [b= est estimate is 16-24 overall additional
bytes on the wire in bot= h direction] (3) the LB will have to do some
crypto to recover th= e connection ID (most likely one AES operation).

<= br>
We have detailed designs for both of these, though it's p= ossible they
can be optimized further. Happy to go into these, bu= t I think it's
more useful to discuss this at a high level ra= ther than going into
the detailed mechanisms at this time.
<= div>
-Ekr



<= div>

--001a114c76b47f5d0a055159ecbc-- From nobody Wed Jun 7 00:59:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF4B12EAF5 for ; Wed, 7 Jun 2017 00:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vlU4KS8Z3Bx0 for ; Wed, 7 Jun 2017 00:59:49 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535C3126CBF for ; Wed, 7 Jun 2017 00:59:49 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l14so1586941ywk.1 for ; Wed, 07 Jun 2017 00:59:49 -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=h0OM9IHucraFrPfKsRXybLSIZSc+Zu6weQD+ANBh7QI=; b=JPRt850hNDJU0aOh/YC+t7QZsgAq5m5HzxeIfEv8iQsimjMS3cueZ2w13p3U8HU+0T 8WtSlEWVFVwBt4L1X/kdUn01TA48hOzZcE7buVwCXUejVzO0SUgFIBoPuPO2CILgqv8E dulA0R+rxtz5yTODqCxUreon6+6HpORoYRi0Oel1yI/luZEk5fjrg/hVl1tvSsQkNAQr WBKRFQF5lZNYJyOZDaMRBlIbGN9Em8oJJcpZn26IzXIQVJ8IfLtSej7mePugkuZ3doKW 8/h4wzD1tVO2PYB1vdoUDUVBSxqtVKjy4uAG3rpuvazYk0fZCddwPKepT4I1PzJ/iwfG hggg== 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=h0OM9IHucraFrPfKsRXybLSIZSc+Zu6weQD+ANBh7QI=; b=a26zOOOs7dz6AkEkIrDlMDKvvG0oMUuU38orbEKbLxD+lDYRgLG1bgvWnEhymrV6Km buVMek8ucFwFCKnE5WGrTUD+n0ZXAwFU0JW95uWKt0TAu8ljhvwcJLbbhICPZVHfLERC MZGSNuMxmkl4T5Hbd7pOimuTQutSCPj33im+ZqayyhnednV32e/+5fc9uxcv0AbQXd+W QeQ7A1SdcuqpSZSl+t3F8mkcgl9AxUgLj68r4jb0EbJwzsDXn0/MzQlDJUrU1O5rj8Tw JgtBvLarXzHTr/vF7toMqGe4y7J1Zs2JMZwk0nwWkyhqMRfBBTCzoZ2xg9CeJKAbJrGT /FXA== X-Gm-Message-State: AODbwcCYLuYPmiJUNdVCtbvbrDwFnFszf7kti44UO15VqmIi7SEb+1/T vE1YZQACFVq6R01+mFFhFC9pILgUEk++ X-Received: by 10.13.214.87 with SMTP id y84mr5797588ywd.303.1496822388433; Wed, 07 Jun 2017 00:59:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.204.134 with HTTP; Wed, 7 Jun 2017 00:59:27 -0700 (PDT) In-Reply-To: References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> From: Ian Swett Date: Wed, 7 Jun 2017 03:59:27 -0400 Message-ID: Subject: Re: Comparing HTTP over QUIC header compression schemes To: Alan Frindell Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114fa5cac1b02305515a1e2d" 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, 07 Jun 2017 07:59:50 -0000 --001a114fa5cac1b02305515a1e2d Content-Type: text/plain; charset="UTF-8" Thanks for doing this analysis! Two questions: 1) Is it possible to simulate how this impacts page load time for your simulated workload? 2) How do the results change if you extend the simulation to 20% loss? As Victor noted, 20%+ loss is not that uncommon on public networks. On Wed, Jun 7, 2017 at 2:40 AM, Alan Frindell wrote: > Thanks for the initial feedback everyone. For anyone in Paris that wants > to discuss QPACK versus QCRAM in more detail, Mike, Buck and I will be > talking over lunch today. > > > > -Alan > > > > *From: *Victor Vasiliev > *Date: *Tuesday, June 6, 2017 at 11:56 AM > *To: *"Eggert, Lars" > *Cc: *Alan Frindell , IETF QUIC WG > *Subject: *Re: Comparing HTTP over QUIC header compression schemes > > > > On Tue, Jun 6, 2017 at 4:59 AM, Eggert, Lars wrote: > > (2) simulating loss rates much above 1% is likely going to be pretty > uninteresting, given that QUIC (and TCP, FWIW) have congestion controllers > that will struggle to even deliver useful throughputs in these cases > > > > On networks with traffic policers, loss rates are usually 20% or higher > (Flach et al, "An Internet-Wide Analysis of Traffic Policing", SIGCOMM > 2016). This normally does not work well with TCP congestion control, but > some of the more recent work (like TCP BBR) tries to address that. > > > > -- Victor. > --001a114fa5cac1b02305515a1e2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for doing this analysis!=C2=A0 Two questions:
<= br>
1) Is it possible to simulate how this impacts page load time= for your simulated workload?
2) How do the results change if you= extend the simulation to 20% loss?=C2=A0 As Victor noted, 20%+ loss is not= that uncommon on public networks.
On Wed, Jun 7, 2017 at 2:40 AM, Alan Frindell = <af= rind@fb.com> wrote:

Thanks for the initial feedback everyone.=C2=A0 For anyone in Paris that w= ants to discuss QPACK versus QCRAM in more detail, Mike, Buck and I will be= talking over lunch today.

=C2=A0

-Alan

=C2=A0

F= rom: Victor Vasiliev <vasilvv@google.com= >
Date: Tuesday, June 6, 2017 at 11:56 AM
To: "Eggert, Lars" <lars@netapp.com>
Cc: Alan Frindell <afrind@fb.com>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Comparing HTTP over QUIC header compression schemes<= /u>

=C2=A0

On Tue, Jun 6, 2017 at 4:59 AM, Eggert, Lars <lars@netapp.com> w= rote:

(2) simulating loss rates much above 1% is likely go= ing to be pretty uninteresting, given that QUIC (and TCP, FWIW) have conges= tion controllers that will struggle to even deliver useful throughputs in t= hese cases

=C2=A0

On networks with traffic policers, loss rates are us= ually 20% or higher (Flach et al, "An Internet-Wide Analysis of Traffi= c Policing", SIGCOMM 2016). This normally does not work well with TCP = congestion control, but some of the more recent work (like TCP BBR) tries to address that.

=C2=A0

=C2=A0 -- Victor.


--001a114fa5cac1b02305515a1e2d-- From nobody Wed Jun 7 04:50: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 A2D95129508 for ; Wed, 7 Jun 2017 04:50:26 -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, 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=mnot.net header.b=R+qpDFTT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Lb6OhlQP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 873-y9oU1G-d for ; Wed, 7 Jun 2017 04:50:24 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F69B129B41 for ; Wed, 7 Jun 2017 04:50:24 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 9358BB85; Wed, 7 Jun 2017 07:50:23 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 07 Jun 2017 07:50:23 -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=Mn7EttxUKTTDDugHKvswvUYbEzqC0z6Qjxq/t5bro m0=; b=R+qpDFTTgFauCqPR1UZ8rKLQwnqxjQ7uMg7klqPhMCECxfdcQ8bNO5Ua7 xYEhsM/c1MDMO1Ph1kWH4C2i537Zk9hHyTBoCvSZUDNtkmh+A33NgOIaomDH/3pK Y9apVhwK8u4KJD8Ff5bHMMI7abREqt+ydUGeRIsD6lCGXnVB2rsqsCxNr/PwkEAt alItQDuXmNRkWdVFDE63ps0aHPU4XKR+G4DUe18OUOpVruJ3/TylTihAC4RcaxqM mP7NucHCt2NG/Nhf7/rqj85SYP1oMxWuWjCptdVfG7Zzi0MCkerfBnxqbimBrLah V+sy7u8rsqQ2dr2pJAvcSW6z6Il5w== 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=Mn7EttxUKTTDDugHKv swvUYbEzqC0z6Qjxq/t5brom0=; b=Lb6OhlQP091niqbSN7ZvbToLWhYU2nvOxP oXrRhJA7my8ZoNwbitQsIgP6dKEYnIVgjHxtrzwas+u/JZVzh4tYju6yN48kondj u6TqJmmZAZW9HDHlT73Bg0XIMbNYSKHy7uptdV8uxSf5FYoHH1hSDgYpCd0ToQc0 /IW0xdTWHdODkWovUKbHiMeyQhF2xk00pCoDf9C3w83MSucEAtuHwlIuXhpcqmeA q14xJd4rWbBzckzs4Bca63ladUcE5O/F5ZzOmUXSCwlfcXs52gK0bXPHohNramou sPUpVhMiLy6kCbEZAm3R4DLnxOMldjY183jwLqV+xT8XZN8a0tNg== X-ME-Sender: X-Sasl-enc: I6Z0ZY3uSEaHgEmMCjTvoEUdQl4xGeI8EwzacCK/oTFB 1496836223 Received: from [10.243.36.178] (unknown [89.202.203.52]) by mail.messagingengine.com (Postfix) with ESMTPA id CFFF6249D2; Wed, 7 Jun 2017 07:50:22 -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: Adoption of the Applicability and Manageability Statements Message-Id: Date: Wed, 7 Jun 2017 13:50:21 +0200 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, 07 Jun 2017 11:50:27 -0000 In Chicago, we discussed these two documents: https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/ https://datatracker.ietf.org/doc/draft-kuehlewind-quic-manageability/ ... and there was general support in the room for adopting them to meet = our chartered deliverable in this area. Please comment on-list if you have concerns or wish to express further = support; barring any showstoppers, we'll adopt them. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jun 7 05:01:18 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 D062412EBCE; Wed, 7 Jun 2017 05:01:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The QUIC WG has placed draft-kuehlewind-quic-manageability in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149683687584.2640.4992928936253535800.idtracker@ietfa.amsl.com> Date: Wed, 07 Jun 2017 05:01:15 -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: Wed, 07 Jun 2017 12:01:16 -0000 The QUIC WG has placed draft-kuehlewind-quic-manageability in state Call For Adoption By WG Issued (entered by Mark Nottingham) The document is available at https://datatracker.ietf.org/doc/draft-kuehlewind-quic-manageability/ From nobody Wed Jun 7 05:01:36 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 579BC12EBD2; Wed, 7 Jun 2017 05:01:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The QUIC WG has placed draft-kuehlewind-quic-applicability in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149683689535.2779.9880770697589242890.idtracker@ietfa.amsl.com> Date: Wed, 07 Jun 2017 05:01:35 -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: Wed, 07 Jun 2017 12:01:35 -0000 The QUIC WG has placed draft-kuehlewind-quic-applicability in state Call For Adoption By WG Issued (entered by Mark Nottingham) The document is available at https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/ From nobody Wed Jun 7 05:27: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 4046112EBF6 for ; Wed, 7 Jun 2017 05:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 PiBMs-gpuPWv for ; Wed, 7 Jun 2017 05:27:06 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D4512EBF5 for ; Wed, 7 Jun 2017 05:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2188; q=dns/txt; s=iport; t=1496838426; x=1498048026; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=UaZIYnxOzVbAMzEdo4bRUa2BrTMaNCiTTmiDHkH+UVU=; b=M8CSye0vsyRZzOFlyy7FktFrJjGDM0tpczbGRGXHVpZ+IAE0WlcMz4ZM jB83jzRVgHAy4G8B1UWPtpBu0CCFpBbXiC+sU5M7ZpFL6qDGqNJ6ApAZl 7JtXHekO183qUR68gKMcnOeKNM8hXKsbY+r50jfqM70f7+c7ij08VTPTe U=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAACk8DdZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqFAIoYc5B1lgCCEAclhXgCgy4YAQIBAQEBAQEBayiFGQEFI1Y?= =?us-ascii?q?QCw4KKgICVwYBDAgBAYonEK5UgiaLfQEBAQEBAQEBAQEBAQEBAQEBAQEQCgWIb?= =?us-ascii?q?IJ1gVCGLIJhAQSeOYQPghx7gzeIW4FuiSGGcZRnHziBCjAhCBsVHIc0PooIAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="asc'?scan'208";a="694974415" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 12:26:46 +0000 Received: from [10.61.210.131] ([10.61.210.131]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v57CQk6R019788; Wed, 7 Jun 2017 12:26:46 GMT Subject: Re: Adoption of the Applicability and Manageability Statements To: Mark Nottingham , IETF QUIC WG Cc: Lars Eggert References: From: Eliot Lear Message-ID: Date: Wed, 7 Jun 2017 14:26:45 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PeUSuqru3G93Lc6lmplMKj3brBGAbkQaj" 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, 07 Jun 2017 12:27:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PeUSuqru3G93Lc6lmplMKj3brBGAbkQaj Content-Type: multipart/mixed; boundary="iQgXEtqEc9J1aEM9M326iLHWQoQTFQtKV"; protected-headers="v1" From: Eliot Lear To: Mark Nottingham , IETF QUIC WG Cc: Lars Eggert Message-ID: Subject: Re: Adoption of the Applicability and Manageability Statements References: In-Reply-To: --iQgXEtqEc9J1aEM9M326iLHWQoQTFQtKV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Marc, Referring just to this draft: On 6/7/17 1:50 PM, Mark Nottingham wrote: > In Chicago, we discussed these two documents: > > https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/= > I'm fine with this as being adopted. I would point out as a comment, however, that Section 4 is entitled "Stream versus Flow Multicasting", where that is the first and last use of the term "Flow". The text that follows in Section 4 seems to compare "Flow" to transport connections, and I suspect that a title change for that section is in order, rather an an exploration into what a flow is in this context. Eliot --iQgXEtqEc9J1aEM9M326iLHWQoQTFQtKV-- --PeUSuqru3G93Lc6lmplMKj3brBGAbkQaj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZN/EGAAoJEIe2a0bZ0nozQ2gH/ieLd3+m1Mhgt3Gn1Y3fb3Fr /8a79JyKvKYsOefl4F2DaWzjEufOgOfSF05BLpi3junppajJpu0s6JJFLm4by9ai 53Ws42x269kPKlaRcPESfH5EpVFzXhtycFODux6ESbspSJQK4pSvkwVn9c5Rff76 8YmnxkZMTZiwn45z6T+qWhbJ7q9/eZnHwoy7G4aqVI4P66gU8i7VXm2FU39v9xfl GbDcos4PQSsVVoAFjSYR5AAnQyCGQ7hQpD9fzTMlcfe9ajAtCDyV8zu8dMPKC/nL YB3hYWqK2/dzpqD2pHwD6dvI5W/I0B4KXkrRlGjPvoZqctAIRt5/2qXDqZfJYmQ= =IeS6 -----END PGP SIGNATURE----- --PeUSuqru3G93Lc6lmplMKj3brBGAbkQaj-- From nobody Fri Jun 9 04:00: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 6F6DE124E15 for ; Fri, 9 Jun 2017 04:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=netapp.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 dizVkYwpto4U for ; Fri, 9 Jun 2017 04:00:16 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C1A124217 for ; Fri, 9 Jun 2017 04:00:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,317,1493708400"; d="asc'?scan'208";a="207896733" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx141-out.netapp.com with ESMTP; 09 Jun 2017 03:38:56 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Jun 2017 03:55:12 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 9 Jun 2017 03:55:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wEK8richAxita3HR/FW3ZBOMLByLrxPLD49MzGEHPGw=; b=Q+8dUwBUunQXHviYNg3e5rkr5S+uAmnxqPMOVWtCMJ4tW47BrxN6NNXO5OHksR9wOBTyPmA5gBwIUKVpoXk0NyBHs+Y+gxlXb9WyGdgZp0ng772K6sKGun1WJhtsVIsu6rQFxaRqWWsu0RMHmeUBZn9yYu2IcqDTBkaQWPMhDgw= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Fri, 9 Jun 2017 10:55:14 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1157.014; Fri, 9 Jun 2017 10:55:14 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: October interim Thread-Topic: October interim Thread-Index: AQHS4Q7f27rKVT+gCESYfuoCZa1cCQ== Date: Fri, 9 Jun 2017 10:55:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 7:eVEDOqsrGPfpFo0mKaNFf/H4sZMKgap1j4BuNRHfT5q0sUnPOICgBJxpX2Y2A4pmYxm/hgI+waUy1cBnptKMOH2FbYdjDxBLoqrzdC5Gzv+LUVM5B8FbU7H43dxmwBqi54QAUY+zhsUVNgiJgBuMUhuYZTVV1kBPI0axp/UkGIC8UY5AGUFz8PRj3XtrSLbbX469werEoSAbMBzcpy+bYFyFrrpQdDwkMzbYfnxxp3DMWJ/COpsrGo4OuGJCLUNIjj6EVUG4A14Lswe1jw7eob35qPXP6YBfBX90osEsnBbxlAN4n5sEFz6+/eeLwDvuOoN7R9qcELmjLN9vIkXjcQ== x-ms-traffictypediagnostic: BLUPR06MB1763: x-ms-office365-filtering-correlation-id: f2a6514c-bf2c-46e9-f93d-08d4af260215 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1763; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(966005)(36756003)(221733001)(6916009)(14454004)(57306001)(82746002)(478600001)(110136004)(83716003)(66066001)(2900100001)(25786009)(38730400002)(7736002)(3480700004)(99936001)(8936002)(50226002)(81166006)(50986999)(77096006)(6486002)(6436002)(3660700001)(6506006)(305945005)(189998001)(122556002)(102836003)(33656002)(3846002)(86362001)(6306002)(2906002)(7116003)(53936002)(99286003)(8676002)(3280700002)(5660300001)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_A06991D2-BA5A-4B20-B30B-C1F811AB29A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 10:55:14.3913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.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, 09 Jun 2017 11:00:18 -0000 --Apple-Mail=_A06991D2-BA5A-4B20-B30B-C1F811AB29A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, as mentioned during the Paris interim that just ended, our plans for the = next QUIC WG interim have solidified. We'll be meeting October 3-5, 2017 (Tue-Thu) in Seattle, WA, USA(*), = hosted by F5 Networks. Do note that it is likely that there will be an = interop event before the interim, most likely on Mon, Oct 2. I've uploaded placeholder information at = https://github.com/quicwg/wg-materials/tree/master/interim-17-10 and = will formally request the meeting shortly. Lars (*) In an email from Apr 18 titled "Questions regarding fall interim = location", we asked whether meeting in the US would be difficult for any = participant, but did not receive any indication that this was the case. --Apple-Mail=_A06991D2-BA5A-4B20-B30B-C1F811AB29A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlk6fpEACgkQVLXDCb9w wVfBBw//bVOl09bpwTC2Zw1YCzQTuCHV/YYJnHf3J2TFXJN/PRpenT32lCf7UGPS L/FvR+2xxSUWSYPfZ5tOkJHCWSCKvSfep30ZNbjlw1v6jpZFnxPlKfDIJVrlYnZN l+47C5w0JjI4HcYCKQyjz3W/OgKYXKDs+gCIQr/xyZ6i9vwiimC3sxOw6PejpQjD pBgEP1fP/l41GGGTiQ2pj+UxuzIoIieo2btnN7SzzmrqCmyGOObHUGlCo8SdMKiY 3PKEj7kR7kvIrNpHz4ob0H7HsuYXIg8X7CbqXFzYQhg/H0CyoU4N6eHhu1VnVjwe 7UqIf3V+n/YI0K4cmKg9+0v6QllaFVLhCrOkjSIKeWSRTUdBkun0rjgOnsQrhI+i fGRLZdM+BWF68ukj5fAUXEYWADiwo9fAb5IN4XvM3HnDZ37Rx4s1DPc1cmBN12lT gXrU/1WlnoS07oHT3wB9p61/g4H+6GnhrZRWUQCdYY+xAVjXhfEBQO820Fd3KSWL fvw/TFT66q+V2SBUfa7F9XVe3TN0NhfClDRxwLNz4V+cG0jGFj7Vxxm2scptXTmR 24y+lsJgBLgWgcCGNrWJBUJ/j9tXdGCsGV/Aoz3kj32a1/PSevVvQZ19UyAp0BMb RP50Ww/tygSxZnSLVyEQj6UWN9wPWfa0/PlVcd23fCnZG9FLpTg= =eQae -----END PGP SIGNATURE----- --Apple-Mail=_A06991D2-BA5A-4B20-B30B-C1F811AB29A1-- From nobody Fri Jun 9 07:46: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 B40CD129B51; Fri, 9 Jun 2017 07:46:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - New Interim Meeting Request X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149701960267.30067.14807847724736707572.idtracker@ietfa.amsl.com> Date: Fri, 09 Jun 2017 07:46: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: Fri, 09 Jun 2017 14:46:43 -0000 A new interim meeting request has just been submitted by Lars Eggert. This request requires approval by the Transport Area Area Director The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2017-quic-03 --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert City: Seattle Country: US Session 1: Date: 2017-10-03 Start Time: 09:30 US/Pacific Duration: 08:00 Remote Participation Information: tbd Agenda Note: Session 2: Date: 2017-10-04 Start Time: 09:30 US/Pacific Duration: 08:00 Remote Participation Information: tbd Agenda Note: Session 3: Date: 2017-10-05 Start Time: 09:30 US/Pacific Duration: 08:00 Remote Participation Information: tbd Agenda Note: --------------------------------------------------------- From nobody Mon Jun 12 11:52:28 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 59D05129576; Mon, 12 Jun 2017 11:52:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: quic@ietf.org Subject: QUIC (quic) WG Interim Meeting: 2017-10-03 X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149729354179.10253.14118349865927391836@ietfa.amsl.com> Date: Mon, 12 Jun 2017 11:52:22 -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, 12 Jun 2017 18:52:22 -0000 The QUIC (quic) Working Group will hold a multi-day interim meeting. Session 1: 2017-10-03 09:30 to 17:30 US/Pacific Session 2: 2017-10-04 09:30 to 17:30 US/Pacific Session 3: 2017-10-05 09:30 to 17:30 US/Pacific Meeting Location: Seattle, US Agenda: (No agenda submitted) Information about remote participation: tbd From nobody Tue Jun 13 06:43:22 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 CF4EE127201; Tue, 13 Jun 2017 06:43:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149736140081.17623.17274895832586659257@ietfa.amsl.com> Date: Tue, 13 Jun 2017 06:43:20 -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: Tue, 13 Jun 2017 13:43:21 -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 : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-04.txt Pages : 76 Date : 2017-06-13 Abstract: This document defines the core of the QUIC transport protocol. This document describes connection establishment, packet format, multiplexing and reliability. Accompanying documents describe the cryptographic handshake and loss detection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-04 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 13 06:43:40 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 D092C131736; Tue, 13 Jun 2017 06:43:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149736141082.17579.6139898831686851573@ietfa.amsl.com> Date: Tue, 13 Jun 2017 06:43:30 -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: Tue, 13 Jun 2017 13:43:31 -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 : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-04.txt Pages : 37 Date : 2017-06-13 Abstract: This document describes how Transport Layer Security (TLS) is used to secure QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/tls. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-04 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 13 07:07: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 3A1B3127B52 for ; Tue, 13 Jun 2017 07:07:42 -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 UZ2InkpwU9AQ for ; Tue, 13 Jun 2017 07:07:40 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 E387B1242F7 for ; Tue, 13 Jun 2017 07:07:39 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id v20so72444108lfa.1 for ; Tue, 13 Jun 2017 07:07:39 -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; bh=1QZGmDofjEe6S3TCezU+XI5D2kdj8VASBL4XrUE2tW4=; b=Cc2uY5QuEusZF4sSQpF9YHlu1bAUrU3XzFyTDY+KEpkStMQL/yPtKEWxtDc8VfSjsk F/5T896X20Tma5PY3jD2sz2wZiTFJbPobK1ACdJT3QHaGRGaP+oyFS3roIzBNoVI+0es hXQQayaiOzSgmSiVHBTv3s2NQ/wiRl5qaLORIdMXaTdC4kJcq5kMtdBkTh4SNs9TMwK5 VSytwjfumE4xG1MUcsg60AcK17ZcbI+73Dkl6BmBajJ2KacIv9iXO/wsyztXNIpxwq+f /wlJaU6B6IXtGlwPvCQCas4vf7jlNkWNi7613GoBKd7uEikOjJFv6UYu0sJm8m2bNKxM fGMA== 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; bh=1QZGmDofjEe6S3TCezU+XI5D2kdj8VASBL4XrUE2tW4=; b=FrZWeKmXaVcgFM+pg/vSrog7JBQ5mL2DXBTe7NgRKsoVwfJNRqyzEdOCd8UnlijnRW +5+ZNNZC0HnptqXim1ZywPe0rJb7gOmpQkSPz1nt17WhGaqOGdQc4fPI9OFFNfH0G9cN N0umOwS3Kh8Pcwv5hXQ36M6G9YefmqScPFnmq/bQOMSYmOxqXhXqDRjOX75eKH51IYdZ VGIjd3EfuhYwxqvsycewh7ZgduKnFnV9brcWj5pVnQFDRn2M7sLJJgGWxD8AfcOlZkgr ZbMHulImtbgvjAMkSVnb5g6C3EDOtt4I2qDlaTg9PHli1xilDcjPaTfne3OGcC8+A51G 4xjA== X-Gm-Message-State: AODbwcBqGXxyEjbkXJuLRvFaoW9iAws7WmtUAdDsMV1uSXTP0JjzCT7H D7V3y+YR/SsyUxToZbQl+PTmkIol7KKOs0Y= X-Received: by 10.25.166.15 with SMTP id p15mr9329343lfe.43.1497362857466; Tue, 13 Jun 2017 07:07:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Tue, 13 Jun 2017 07:07:36 -0700 (PDT) In-Reply-To: <149736140081.17623.17274895832586659257@ietfa.amsl.com> References: <149736140081.17623.17274895832586659257@ietfa.amsl.com> From: Martin Thomson Date: Tue, 13 Jun 2017 15:07:36 +0100 Message-ID: Subject: Re: I-D Action: draft-ietf-quic-transport-04.txt 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: Tue, 13 Jun 2017 14:07:42 -0000 Folks, you should see new versions of drafts over the next 24 hours (I can't approve the other drafts). Expect our chairs to say something about how this relates to our implementation targets. In addition to what we agreed would change in this version, there are some changes to streams. The layout of STREAM and RST_STREAM have changed, and there is a change to the closed state. I want to explain the last of these in more detail.. The previous draft was a little inconsistent about the transition of a stream to the closed state. Prior to the addition of MAX_STREAM_ID, we landed a change that made the transition only occur after all data was received and *acknowledged*. That was considered necessary to ensure that stream close was precise and consistent between both endpoints. At Jana's request, this version moves back to the state prior to that change which says that data only needs to be *sent*. As I understand it, Google's implementation removes stream state once the last byte is sent for the first time, and that retransmissions are managed at a connection-level. So this version gives implementations more flexibility in how they manage the state of streams. With MAX_STREAM_ID, a crisp close for streams is not critical, so we can afford that flexibility. And it's not clear to me that requiring acknowledgment would make the transition any more precise than what we have now given the need to retransmit acknowledgments. I opened https://github.com/quicwg/base-drafts/issues/628 to track this. On 13 June 2017 at 14:43, wrote: > > 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 : QUIC: A UDP-Based Multiplexed and Secure Transport > Authors : Jana Iyengar > Martin Thomson > Filename : draft-ietf-quic-transport-04.txt > Pages : 76 > Date : 2017-06-13 > > Abstract: > This document defines the core of the QUIC transport protocol. This > document describes connection establishment, packet format, > multiplexing and reliability. Accompanying documents describe the > cryptographic handshake and loss detection. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-quic-transport-04 > https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From nobody Tue Jun 13 07:39:25 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 BB06D131904; Tue, 13 Jun 2017 07:39:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149736475872.7628.5012919130081218680@ietfa.amsl.com> Date: Tue, 13 Jun 2017 07:39:18 -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: Tue, 13 Jun 2017 14:39:19 -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 : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-04.txt Pages : 18 Date : 2017-06-13 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/recovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-04 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 13 07:45: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 174A812E03B for ; Tue, 13 Jun 2017 07:45:12 -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 UjcNB2PaaD3Z for ; Tue, 13 Jun 2017 07:45:10 -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 C6BE91319AF for ; Tue, 13 Jun 2017 07:38:53 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id l89so68974517pfi.2 for ; Tue, 13 Jun 2017 07:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VwL0w/XIdxOdXojEK6fgmXxFuiwNxNec6LK+0hj46V4=; b=eYBOdQWrfn37k56I3+50H6CRp/C9w4LT0chKKCQpT+2as333Y8YCUMlpsMwxZ0rc93 wapaRTdHpzk5ziYpYbN8kCZyfqPym4FoG1hrI5Rj7Fcp0olHgdQk5+mDvQgjne8tvsAF 7ONXTqTybQH9+89n7vRNtUjJ6F+Hs5K8zqqQhbRnVsk+wssIWCOGAEXCUceom3wPAfs8 ahfZ6kad5yrtkK9cvEZ2HFwYX8wzjNE8tB+vZ63vay7WqaH4RawkNKTtV6/So5XEes5n Lr0Wq4+Nyk1/VptNnhEvia2fDlOjC4XeL1C8By3X1XI+fOkEXW1yDkjZRZ5ftPWnmW7R v01A== 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=VwL0w/XIdxOdXojEK6fgmXxFuiwNxNec6LK+0hj46V4=; b=gEQrh3WAssctyPhEgIMC9i8vlanuv8V6VHUC161lgnkhz814IzRiLXZwEvHy9MrS5F gyjeKO8A/1c2fD841edrzQrXI+FyLK4vIr99HYaQkiff1Lzpjb+VTDcyzWSCH/K8+a9o MJv6ukUjNkayoiNBkz+HllB3JyFoRUj/ou2y05U37FZYn90Sek75EDm7DTDtATE80AzP sw0afICWHdRoEZkBpgeIIF4Zzaiv4U9vers/N81NbrWpMYDxO7M5NQcMi6D/cKIVrEJ4 BWygYtiB21nK2yAwTWpSC177OYIKp6kN5LATmp7b4mByT5vNzdOiXXsKPfA9bmHBLfIe UJeg== X-Gm-Message-State: AKS2vOzngs3Sab08NsHo00D+PhTxmzzhvO8RljRC5de9OWi8EcaIuQqs MgJHd0iz/3YGcr51OBxZkL3CSYGnQHxjPEs= X-Received: by 10.84.224.74 with SMTP id a10mr157517plt.173.1497364733092; Tue, 13 Jun 2017 07:38:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Tue, 13 Jun 2017 07:38:52 -0700 (PDT) From: Jana Iyengar Date: Tue, 13 Jun 2017 15:38:52 +0100 Message-ID: Subject: Please move discussions from PRs to Issues To: IETF QUIC WG Content-Type: multipart/alternative; boundary="f40304373814042e9b0551d8655f" 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, 13 Jun 2017 14:45:12 -0000 --f40304373814042e9b0551d8655f Content-Type: text/plain; charset="UTF-8" As discussed at the interim, I'd like to request that we all please move all discussions (modulo editorial nits) to Issues. Discussions on PRs are difficult to follow, and generally end up getting limited by what the PR offers. --f40304373814042e9b0551d8655f Content-Type: text/html; charset="UTF-8"
As discussed at the interim, I'd like to request that we all please move all discussions (modulo editorial nits) to Issues. Discussions on PRs are difficult to follow, and generally end up getting limited by what the PR offers.
--f40304373814042e9b0551d8655f-- From nobody Tue Jun 13 08:06:35 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 341C21318B4; Tue, 13 Jun 2017 08:06:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149736638616.7481.4018079561937189211@ietfa.amsl.com> Date: Tue, 13 Jun 2017 08:06:26 -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: Tue, 13 Jun 2017 15:06:26 -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 : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-04.txt Pages : 28 Date : 2017-06-13 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-04 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 14 02:41: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 8C10912717E for ; Wed, 14 Jun 2017 02:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caa3C-8K9cgg for ; Wed, 14 Jun 2017 02:41:55 -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 28B10128CDC for ; Wed, 14 Jun 2017 02:41:53 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v5E9f7uD005763 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 11:41:07 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dL4nO-0004Jp-PD; Wed, 14 Jun 2017 11:41:02 +0200 From: "Philipp S. Tiesel" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E429527C-A672-4A13-8F9F-CC629FBE35FA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Adoption of the Applicability and Manageability Statements Date: Wed, 14 Jun 2017 11:41:06 +0200 In-Reply-To: Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert To: Eliot Lear References: 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, 14 Jun 2017 09:41:57 -0000 --Apple-Mail=_E429527C-A672-4A13-8F9F-CC629FBE35FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > On 6/7/17 1:50 PM, Mark Nottingham wrote: >> In Chicago, we discussed these two documents: >>=20 >> = https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/ >>=20 >=20 > I'm fine with this as being adopted. >=20 > I would point out as a comment, however, that Section 4 is entitled > "Stream versus Flow Multicasting", where that is the first and last = use > of the term "Flow". The text that follows in Section 4 seems to = compare > "Flow" to transport connections, and I suspect that a title change for > that section is in order, rather an an exploration into what a flow is > in this context. >=20 I think =E2=80=9CFlow=E2=80=9D makes sense in this context as it is more = general and=20 analogous to the definition of IPv6 flow labels in RFC 6437 and its discussion on flow vs. 5-tupel. I see this uncertainty of flow vs. association vs. connection vs.=20 stream arise in many contexts at the moment and try to put this into a draft (not sure yet what the right for that one scope will be). AVE! Philipp S. Tiesel / phils=E2=80=A6 --Apple-Mail=_E429527C-A672-4A13-8F9F-CC629FBE35FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 6/7/17 1:50 PM, Mark Nottingham wrote:
In Chicago, we discussed = these two documents:

 https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicab= ility/


I'm = fine with this as being adopted.

I would = point out as a comment, however, that Section 4 is entitled
"Stream versus Flow Multicasting", where that is the first = and last use
of the term "Flow".  The text that = follows in Section 4 seems to compare
"Flow" to transport = connections, and I suspect that a title change for
that = section is in order, rather an an exploration into what a flow is
in this context.


I think = =E2=80=9CFlow=E2=80=9D makes sense in this context as it is more general = and 
analogous to  the definition of IPv6 flow = labels in RFC 6437 and
its discussion on flow vs. = 5-tupel.

I see this uncertainty of = flow vs. association vs. connection vs. 
stream arise in = many contexts at the moment and try to put this into
a draft = (not sure yet what the right for that one scope will be).


AVE!
  Philipp S. Tiesel / phils=E2=80=A6
= --Apple-Mail=_E429527C-A672-4A13-8F9F-CC629FBE35FA-- From nobody Wed Jun 14 09:50:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432F21293F9 for ; Wed, 14 Jun 2017 09:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 M7UIKzvhfObz for ; Wed, 14 Jun 2017 09:50:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25741293E3 for ; Wed, 14 Jun 2017 09:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11251; q=dns/txt; s=iport; t=1497459020; x=1498668620; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=UEshSjcQ9GrTe3qnKuD4NZs//vJQPHt3m2Z4S4SP4+0=; b=ITx5b501ihXCIX3IUY7wmix3SNeLVBeX3gVUepUpO0V7B0mWl5g7dC4I lS9ecY3keDiN5tu44anlJ4J4llqnUGKBgDrloQRtbozsIBGSq5KeBGOW4 Z7HDcwZPQf7ripzQpeJHCa1NeEBtvHo6VQi92mD2MzE8dCOFkeXJBvnwm 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTAAALaEFZ/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1hihQOKGJF2kEyFOoIRByWFeAKCUD8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECASNEEgULCxgqAgJXBg0IAQGKIAgQrgCCJiuLFwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQ4KBYhCK4J2gVCGLIJhBZE+jQmEEoIefIM6iGyLFoZzlHofOIEKMCE?= =?us-ascii?q?IGxUehTYcggYgijEBAQE?= X-IronPort-AV: E=Sophos;i="5.39,341,1493683200"; d="asc'?scan'208,217";a="255928871" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 16:50:19 +0000 Received: from [10.41.32.177] ([10.41.32.177]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5EGoJAQ011984; Wed, 14 Jun 2017 16:50:19 GMT Subject: Re: Adoption of the Applicability and Manageability Statements To: "Philipp S. Tiesel" Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert References: From: Eliot Lear Message-ID: <9df361fe-67dc-c72d-1dda-6a75102451e0@cisco.com> Date: Wed, 14 Jun 2017 09:50:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J7CErj0ViFmTAWUuxo7c04JtqARjh5Rng" 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, 14 Jun 2017 16:50:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J7CErj0ViFmTAWUuxo7c04JtqARjh5Rng Content-Type: multipart/mixed; boundary="W69MOebOuiFAPKnVcU2D0VoaA8wPshBGA"; protected-headers="v1" From: Eliot Lear To: "Philipp S. Tiesel" Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert Message-ID: <9df361fe-67dc-c72d-1dda-6a75102451e0@cisco.com> Subject: Re: Adoption of the Applicability and Manageability Statements References: In-Reply-To: --W69MOebOuiFAPKnVcU2D0VoaA8wPshBGA Content-Type: multipart/alternative; boundary="------------87AE7277A7EF04C3B929F865" Content-Language: en-US This is a multi-part message in MIME format. --------------87AE7277A7EF04C3B929F865 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Philipp, If that's what the document is intending it should say so, but I don't think it is. See below. Also, I made a mistake down below. Sorry I was in a rush (I was also on a small interface), but I gleaned that what was really being discussed was stream versus connection MULTIPLEXING (good heavens, did I fat finger). Section 4 reads: > QUIC's stream multiplexing feature allows applications to run > multiple streams over a single connection, without head-of-line > blocking between streams, associated at a point in time with a singl= e > five-tuple. Streams are meaningful only to the application; since > stream information is carried inside QUIC's encryption boundary, no > information about the stream(s) whose frames are carried by a given > packet is visible to the network. > > Stream multiplexing is not intended to be used for differentiating > streams in terms of network treatment. Application traffic requirin= g > different network treatment SHOULD therefore be carried over > different five-tuples (i.e. multiple QUIC connections). Given > QUIC's ability to send application data on the first packet of a > connection (if a previous connection to the same host has been > successfully established to provide the respective credentials), the= > cost for establishing another connection are extremely low. I think, and Mirja should really correct me if I'm wrong, that the point if this text is this: If you want differentiated treatment by the network, separate via 5-tuples and do not expect the network to tease out QUIC streams for separate treatment. That would be a statement with which I would strongly agree, as the physics of the situation would tend to support it. Eliot On 6/14/17 2:41 AM, Philipp S. Tiesel wrote: >> >> On 6/7/17 1:50 PM, Mark Nottingham wrote: >>> In Chicago, we discussed these two documents: >>> >>> https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability= / >>> >> >> I'm fine with this as being adopted. >> >> I would point out as a comment, however, that Section 4 is entitled >> "Stream versus Flow Multicasting", where that is the first and last us= e >> of the term "Flow". The text that follows in Section 4 seems to compa= re >> "Flow" to transport connections, and I suspect that a title change for= >> that section is in order, rather an an exploration into what a flow is= >> in this context. >> > > I think =E2=80=9CFlow=E2=80=9D makes sense in this context as it is mor= e general and=20 > analogous to the definition of IPv6 flow labels in RFC 6437 and > its discussion on flow vs. 5-tupel. > > I see this uncertainty of flow vs. association vs. connection vs.=20 > stream arise in many contexts at the moment and try to put this into > a draft (not sure yet what the right for that one scope will be). > > > AVE! > Philipp S. Tiesel / phils=E2=80=A6 --------------87AE7277A7EF04C3B929F865 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Philipp,

If that's what the document is intending it should say so, but I don't think it is.=C2=A0 See below.=C2=A0 Also, I made a mistake do= wn below.=C2=A0 Sorry I was in a rush (I was also on a small interface= ), but I gleaned that what was really being discussed was stream versus connection MULTIPLEXING (good heavens, did I fat finger).

Section 4 reads:

=C2=A0=C2=A0 QUIC's stream multiplexing f= eature allows applications to run
=C2=A0=C2=A0 multiple streams over a single connection, without head-of-line
=C2=A0=C2=A0 blocking between streams, associated at a point in t= ime with a single
=C2=A0=C2=A0 five-tuple.=C2=A0 Streams are meaningful only to the= application; since
=C2=A0=C2=A0 stream information is carried inside QUIC's encrypti= on boundary, no
=C2=A0=C2=A0 information about the stream(s) whose frames are car= ried by a given
=C2=A0=C2=A0 packet is visible to the network.

=C2=A0=C2=A0 Stream multiplexing is not intended to be used for differentiating
=C2=A0=C2=A0 streams in terms of network treatment.=C2=A0 Applica= tion traffic requiring
=C2=A0=C2=A0 different network treatment SHOULD therefore be carr= ied over
=C2=A0=C2=A0 different five-tuples (i.e.=C2=A0 multiple QUIC conn= ections).=C2=A0 Given
=C2=A0=C2=A0 QUIC's ability to send application data on the first= packet of a
=C2=A0=C2=A0 connection (if a previous connection to the same hos= t has been
=C2=A0=C2=A0 successfully established to provide the respective credentials), the
=C2=A0=C2=A0 cost for establishing another connection are extreme= ly low.


I think, and Mirja should really correct me if I'm wrong, that the point if this text is this:

If you want differentiated treatment by the network, separate via 5-tuples and do not expect the network to tease out QUIC streams for separate treatment.

That would be a statement with which I would strongly agree, as the physics of the situation would tend to support it.

Eliot


On 6/14/17 2:41 AM, Philipp S. Tiesel wrote:

On 6/7/17 1:50 PM, Mark Nottingham wrote:
In Chicago, we discuss= ed these two documents:

=C2=A0https://datatracker= =2Eietf.org/doc/draft-kuehlewind-quic-applicability/


I'm fine with this as being adopted.

I would point out as a comment, however, that Section 4 is entitled
"Stream versus Flow Multicasting", where that is the first and last use
of the term "Flow". =C2=A0The text that follows in Section = 4 seems to compare
"Flow" to transport connections, and I suspect that a title change for
that section is in order, rather an an exploration into what a flow is
in this context.


I think =E2=80=9CFlow=E2=80=9D makes sense in this context as = it is more general and=C2=A0
analogous to =C2=A0the definition of IPv6 flow labels in RFC 6= 437 and
its discussion on flow vs. 5-tupel.

I see this uncertainty of flow vs. association vs. connection vs.=C2=A0
stream arise in many contexts at the moment and try to put this into
a draft (not sure yet what the right for that one scope will be).


AVE!
=C2=A0 Philipp S. Tiesel / phils=E2=80=A6

--------------87AE7277A7EF04C3B929F865-- --W69MOebOuiFAPKnVcU2D0VoaA8wPshBGA-- --J7CErj0ViFmTAWUuxo7c04JtqARjh5Rng Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZQWlKAAoJEIe2a0bZ0nozSfQIAM5pV5aeAwK4U7MMRCobsKzw sFt6hAi9vXw7VvcLTtmDQm1ZZ/G3T1O14yfGcmyoKzsetBXzseg1PxAmdga6kVhL Aervl/WDmuRS85VCE2if2s9xxPI1vW+BOAYqGpWjyA4lwF8I14ZeetdNDgtZeY+b ksaibR6rvokyH9rNQcqo9Apl1bQ5BVHfuWuj9tMnmd3Tjxp6N2lIBK64SFjm4HKt q9uvEqdcyQNyh0XM8XXiLwN818vMMjOAUCxt8tvkVlqzy7VX89vgl+atZPyhb8PF WiVjGMov7e7s70udeTIZDWTdZ48ufQtzbb86ScQZtRgZVboP/CDJ7NZwsvg8JYg= =JN9Q -----END PGP SIGNATURE----- --J7CErj0ViFmTAWUuxo7c04JtqARjh5Rng-- From nobody Wed Jun 14 12:43: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 9ABA212EB23 for ; Wed, 14 Jun 2017 12:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH459KYDCnqX for ; Wed, 14 Jun 2017 12:43:52 -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 D3B35129562 for ; Wed, 14 Jun 2017 12:43:50 -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 v5EJh5Y8007374 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 21:43:05 +0200 Received: from [2001:bf0:c801:101:7966:6435:8d2a:972b] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dLEBw-00073n-PH; Wed, 14 Jun 2017 21:43:00 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Adoption of the Applicability and Manageability Statements From: "Philipp S. Tiesel" In-Reply-To: <9df361fe-67dc-c72d-1dda-6a75102451e0@cisco.com> Date: Wed, 14 Jun 2017 21:43:15 +0200 Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <083704A8-3BFC-42C4-A2B7-B9D0AF60C02A@in-panik.de> References: <9df361fe-67dc-c72d-1dda-6a75102451e0@cisco.com> To: Eliot Lear 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, 14 Jun 2017 19:43:55 -0000 Hi Eliot, I totally agree regarding the take away "If you want differentiated = treatment by the network, separate via 5-tuples=E2=80=9D. For me the only dispute was wether =E2=80=9CFlow=E2=80=9D is the right = term in the heading. I think so as the network should forward all packet of one flow the = same. So if you want different handling for your streams, put streams in a = different flow. Different flow means different 5-tupel for UDP. The complexity of the argumentation of Section 4 (as I read it) has the = purpose to make one thing clear: There is no need to expose anything about the = streams to enable someone to do something different on streams in some middelbox. If you want = different treatment, use separate QUIC connections. > On 14. Jun 2017, at 18:50, Eliot Lear wrote: >=20 > Hi Philipp, >=20 > If that's what the document is intending it should say so, but I don't = think it is. See below. Also, I made a mistake down below. Sorry I = was in a rush (I was also on a small interface), but I gleaned that what = was really being discussed was stream versus connection MULTIPLEXING = (good heavens, did I fat finger). >=20 > Section 4 reads: >=20 >=20 >> QUIC's stream multiplexing feature allows applications to run >> multiple streams over a single connection, without head-of-line >> blocking between streams, associated at a point in time with a = single >> five-tuple. Streams are meaningful only to the application; since >> stream information is carried inside QUIC's encryption boundary, = no >> information about the stream(s) whose frames are carried by a = given >> packet is visible to the network. >>=20 >> Stream multiplexing is not intended to be used for differentiating >> streams in terms of network treatment. Application traffic = requiring >> different network treatment SHOULD therefore be carried over >> different five-tuples (i.e. multiple QUIC connections). Given >> QUIC's ability to send application data on the first packet of a >> connection (if a previous connection to the same host has been >> successfully established to provide the respective credentials), = the >> cost for establishing another connection are extremely low. >=20 >=20 > I think, and Mirja should really correct me if I'm wrong, that the = point if this text is this: >=20 > If you want differentiated treatment by the network, separate via = 5-tuples and do not expect the network to tease out QUIC streams for = separate treatment. >=20 > That would be a statement with which I would strongly agree, as the = physics of the situation would tend to support it. >=20 > Eliot >=20 > On 6/14/17 2:41 AM, Philipp S. Tiesel wrote: >>>=20 >>> On 6/7/17 1:50 PM, Mark Nottingham wrote: >>>> In Chicago, we discussed these two documents: >>>>=20 >>>> = https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/ >>>>=20 >>>=20 >>> I'm fine with this as being adopted. >>>=20 >>> I would point out as a comment, however, that Section 4 is entitled >>> "Stream versus Flow Multicasting", where that is the first and last = use >>> of the term "Flow". The text that follows in Section 4 seems to = compare >>> "Flow" to transport connections, and I suspect that a title change = for >>> that section is in order, rather an an exploration into what a flow = is >>> in this context. >>>=20 >>=20 >> I think =E2=80=9CFlow=E2=80=9D makes sense in this context as it is = more general and=20 >> analogous to the definition of IPv6 flow labels in RFC 6437 and >> its discussion on flow vs. 5-tupel. >>=20 >> I see this uncertainty of flow vs. association vs. connection vs.=20 >> stream arise in many contexts at the moment and try to put this into >> a draft (not sure yet what the right for that one scope will be). >>=20 >>=20 >> AVE! >> Philipp S. Tiesel / phils=E2=80=A6 >=20 AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' From nobody Thu Jun 15 16:42: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 5BC7C127735 for ; Thu, 15 Jun 2017 16:41: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, 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 fQG9tdhCcXLu for ; Thu, 15 Jun 2017 16:41:56 -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 3E2BB127601 for ; Thu, 15 Jun 2017 16:41:56 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 83so14253402pfr.0 for ; Thu, 15 Jun 2017 16:41:56 -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=ro4oM1fxlfzaMpQgusWv4FOzZd8x0NMKynzejyG3spc=; b=YS6DgnFLvKO8+RdIUoLap9xmEc4vCRW8Ed+C8pbR02wFY4P2+W48FM8JHbmp6LQZqO HUrQJxeUgK0aPZpwLnpRd8USphYjEky/lPk9L2kh5zzDTSY1hPDp5qVaek66ikPgpvJy D2358BWCrB0GZ99CtZo/RJZtzViWJgKHn3rXmxlrpw4J0WgR5bDKhQg8JN1yveC2ZE74 Xegyo2OPnw/m0rpaUX2yTtuRad+FxPLqZUqzl2zf6RqdnXUhfpDQU8gikT0ChOjxEtIT d7k8xN6PzJLeg2Nv5br/P9PNdWnhWYFPbXUJQkkF6O68Dt4yd8ImkccWHmawusHCpuSK inrg== 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=ro4oM1fxlfzaMpQgusWv4FOzZd8x0NMKynzejyG3spc=; b=aZOc0VvhqOAcvvzxGn+RWYfEUjT4WRRZEnn0y595Tpv6GmaEVFDVlBneVosg+nnrBM PiKsgbN9fFVJ//F3uw8jbziIeODEhdU92vV1L9kHEzYZEd5jhSElYpgRvrCV2aoHpFVt WVdQqTV69NVGcNw2KhZ24YYbQUzkEHbtgArTQ6BMEf2Ma4VxBeWrCOmXKqZ6P2bOtKtC SKdMYOFEb6LRoB66jBR3ZahfKJeoaoHBEmQaZWXd9m+rGIIZnMEBbc7FwcqRCaj7CuvG 0dLfNfsfqraHaI29jlVwUHGi/vuK7VpAlwP34jh5Y8gFAJP8z3A/enRBeR0bCQHEyUVz yNPg== X-Gm-Message-State: AKS2vOx/LfXWlMUe4mLMttRXxyQ7eCzpPOiayESa07idvk76la5FYUWS mAIzPTjAIvSpBX1vW2KJdwtXXIz7CsLiu7k= X-Received: by 10.84.175.65 with SMTP id s59mr9059907plb.20.1497570115703; Thu, 15 Jun 2017 16:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Thu, 15 Jun 2017 16:41:55 -0700 (PDT) In-Reply-To: <592ee006.d5a0370a.621c9.06bf@mx.google.com> References: <592ee006.d5a0370a.621c9.06bf@mx.google.com> From: Jana Iyengar Date: Thu, 15 Jun 2017 23:41:55 +0000 Message-ID: Subject: Re: Why mandate stream creation order? To: Dmitri Tikhonov Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c119722c63275055208361d" 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, 15 Jun 2017 23:41:58 -0000 --94eb2c119722c63275055208361d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the issue, Dmitri, I've created Issue #634 to track this. On Wed, May 31, 2017 at 3:23 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > Hello, > > > > Section 10.1 of draft-ietf-quic-transport-03 states that =E2=80=9CStreams= MUST be > created in sequential order.=E2=80=9D My question is: why mandate stream > creation order, since the other side may receive out-of-order packets? L= et > the implementation do what it wants with Stream IDs =E2=80=93 as long as = it does > not go over the limit, all should be well. > > > > This phrase is a holdover from the previous version; this requirement > seems to be unnecessary since issue 435 > has been resolved. > > > > - Dmitri. > > > > P.S. I have read CONTRIBUTING.md > and > decided that mailing list is the way to ask this question, rather than > opening a GitHub issue. If this is incorrect, please let me know. > > > --94eb2c119722c63275055208361d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the issue, Dmitri, I've created Issue #634 to track t= his.

On Wed,= May 31, 2017 at 3:23 PM, Dmitri Tikhonov <dtikhonov@litespeedte= ch.com> wrote:

Hello,

=C2= =A0

Section 10.1 of draft-ietf-quic-transport-03= states that =E2=80=9CStreams MUST be created in sequential order.=E2=80=9D=C2=A0 My question is:= why mandate stream creation order, since the other side may receive out-of= -order packets?=C2=A0 Let the implementation do what it wants with Stream I= Ds =E2=80=93 as long as it does not go over the limit, all should be well.<= u>

=C2=A0

issue 435 has been resolved.

=

=C2=A0

  • Dmitri.

=C2=A0

P.S.=C2=A0 I have read CONTRIBUTING.md and decided that mailing list is the w= ay to ask this question, rather than opening a GitHub issue.=C2=A0 If this = is incorrect, please let me know.

=C2=A0


--94eb2c119722c63275055208361d-- From nobody Thu Jun 15 20:19: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 3F56F12894A for ; Thu, 15 Jun 2017 20:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=o1Dg8zFv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mrEjfl3n Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzcuf2Au3SH6 for ; Thu, 15 Jun 2017 20:19:22 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4735127BA3 for ; Thu, 15 Jun 2017 20:19:22 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 111C8131D; Thu, 15 Jun 2017 23:19:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 15 Jun 2017 23:19:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=Nsol9FwZRkitP9X4F6WjsnRRwAJeQc+NMSbqFILaV Yg=; b=o1Dg8zFvaEDs3nrGvH9pItnB1SNUu/1XUjrgT4dCQLwptwQUKwEWYDcEL IXQGe1pOztilR8+xqRoOLbZO7k/Uwi6PP9pYQ8qk/9g1k2+2dFBWeHWzNQynW932 AYqAIlvSlAeZp/1HYm13shi9HGP7R2nsfbKiugJMoSg08weUhuOB2l0hHwyQI1xf fwjmaSQ2anoM0JLMQ0oKV+ICg2rRXukl9gtGLrnjCJoeZLQHqyGJsUuDuq2fHdUS k/4GDc2s+lpSPKqFBQI10IL9xZjHBJyMgUJSnBb6X+hB0ieWTrxsLyykHyG5pT0p FF7cK83p4hLE6ndSOXTXWkHmzfk3w== 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=Nsol9FwZRkitP9X4F6 WjsnRRwAJeQc+NMSbqFILaVYg=; b=mrEjfl3nua9YQFuGPfO5RKJBcNwHlbZlwf fLwul79sSHFx3Ysa+9SsoXfywrYhToSsVlwbaq6gVlJIRENAnnJSka39gmTw71w6 IPIyqQ+z129sbq0utyHRmD0gji7qUautD3wVayhXliMfZyefW+i4HWyru349bcCs NjNlCd2kKgVb1Fho1fphnOiK2OAcULBDco1dM9OpXZE+LhovCOf0TUQWHB+5VZYE 8rfFjIDXifLXdpDBCkuOhVNg5vN5Zp1xkRLzIsB47i84vaGojOokMOgZUlh8dKu5 cyZ7nOdgrz0RuGRsYhdosi1wSSzdY27En88hXOrSajwYJX1rFZUw== X-ME-Sender: X-Sasl-enc: aXB2t6v0ar4g28SWL+Q2EnJZVObpTRTvQcBC3cdgHNOV 1497583161 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 C62E524766; Thu, 15 Jun 2017 23:19:20 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: DRAFT minutes from the Paris Interim Message-Id: Date: Fri, 16 Jun 2017 13:19:17 +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: Fri, 16 Jun 2017 03:19:25 -0000 ... are at: https://github.com/quicwg/wg-materials/blob/master/interim-17-06/minutes.md Please have a look and comment here or submit PRs. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jun 15 23:14:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C96012943B for ; Thu, 15 Jun 2017 23:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Qhb8mjp3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mf/FvYQ+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20kepIB8z9FQ for ; Thu, 15 Jun 2017 23:14:41 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4AA128AFE for ; Thu, 15 Jun 2017 23:14:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id A6C2910F1; Fri, 16 Jun 2017 02:14:40 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 16 Jun 2017 02:14:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=h8Fb//lJpkaZwVhpQL GTWaOiKTe92jd5OgbMEn36+p0=; b=Qhb8mjp3IXzLym+p7HMXyPNDZm+sHXZiLR HoV0MyK8d7Af93b8wV0Cit4D0cMNZYC7LaBkeKKV4oVDa7d9DSIjFxDsZYibWNBz YuDg5LiITgX1qGr2HpuFee2rhc1u3R0SnRcmJFjjs0Iupfnzad0ShAr6+k+wKK6d XKdf0jArpVLOwWYOySp2nnwR7/iw2X1WhYPG+cvabZUX64oNXl0eV5Vyb6lFFAPw HuMyqVpV38A3QhvJ2np4YSt1qmhhRXtVQgNyvm3jHqGPgv0leRZdSvPRV8XKGgsr WiBbobI7TdT50A9d9Eqc8f8VZr63OfWpLH5pFAW+q9cMuiWdQIaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=h8Fb//lJpkaZwVhpQLGTWaOiKTe92jd5OgbMEn36+p0=; b=mf/FvYQ+ a9von4gjmBHvt//4zO2mzeiOQdbCiJfcOPa5bRryxLGQYcBS6JRo+09lugzQXI9p mojmE4hkpJwhPwE4MNrwe2Iz8AVwkoV79rBvmq9nHOJDSzJkV7Ms3yb/lxhOOsox 0OPvUS3p6ME0vshtG41HrKL/YWHVs4JdcJetyGVOT6Q+gjXWspr6vHQbZLSLf0IB 4c4hN0L0aYnmNgZDBjxiQ+o4klmHPHZ6j48yGBaREY5bQXO3psc9C4HUrXNdIW9r Njpy3yu04cTXFhWhGfVjDMhBuXzCDzEJ3Zg5hLoGeMk54YowfFVLk+B80n0RHRD5 hD8pAQkqfBE5qA== X-ME-Sender: X-Sasl-enc: XNY8P3FKnAifEpryhc20vcl12U4BxoTyQAMAeIMv41t3 1497593679 Received: from [192.168.66.109] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 64CC424922; Fri, 16 Jun 2017 02:14:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Adoption of the Applicability and Manageability Statements From: Mark Nottingham In-Reply-To: Date: Fri, 16 Jun 2017 16:14:35 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <6618BA51-4EE5-4740-BB9B-FB88FA4DC625@mnot.net> References: 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: Fri, 16 Jun 2017 06:14:45 -0000 Adopted. > On 7 Jun 2017, at 9:50 pm, Mark Nottingham wrote: >=20 > In Chicago, we discussed these two documents: >=20 > https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/ > https://datatracker.ietf.org/doc/draft-kuehlewind-quic-manageability/ >=20 > ... and there was general support in the room for adopting them to = meet our chartered deliverable in this area. >=20 > Please comment on-list if you have concerns or wish to express further = support; barring any showstoppers, we'll adopt them. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sat Jun 17 18:20: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 85661126FDC for ; Sat, 17 Jun 2017 18:20: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, 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 (2048-bit key) header.d=mnot.net header.b=MrcXRzd3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z9/8zhuV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkBtEGTa4B-A for ; Sat, 17 Jun 2017 18:20:48 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF4F1242F5 for ; Sat, 17 Jun 2017 18:20:48 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 5D216925 for ; Sat, 17 Jun 2017 21:20:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 17 Jun 2017 21:20:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=myzGUh2awzHFgCILmof1gecurp4WOAxWrFe7gy7OfIQ=; b=MrcXRzd3 kATEo79VYhwEZRmtGASHkFFiajAVXdLlcNFmPs4dAzn5lZ3RRHCZqCE5VjE/AoTg Cv2udrKtRjFLxqNAxDBk12CyaZAAlbagAAj64geu2Nbb6Je0xiOqfiIMBx4uNGZD 7bDgkDTo0fStMXjDj7O5Mtz9BTm+7mL9Q8j9PZI+ZQWWN8F8AZpauxpOkC8HFxlx WybVy2T4Fh+3qK7lLTbO19/icbqBHpfDEwLjwp0TM6dNm9sDBWIGQqWSAF13D3vQ ZZxMYxCw6Ws/owYXXOyg/1b5FggAaRwMml+Okrokkh20Mu7/E7dFq0GmJ19P4I0Q FRJOfwVxnZKKdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc:x-sasl-enc; s=fm1; bh=myzGUh2awzHFgCILmof1gecurp4WOA xWrFe7gy7OfIQ=; b=Z9/8zhuVnK10k7e4yh5gpFAERUbK+kBDuuITykdBnduPry RP2OgeF351sEyTBJ8I9JjXfjrJBMGBSR99wdr0mc2vzFC5TlQxX05cyouNe5VXG8 v+r8BfIg4OnIT5Mk+k8PLC3Y+4FudGoqrGtIM/gFUsojR5dAv2pd02ge8F/07cvQ imVTvBNrcI2wtxRMj77/rzSfU0mN23I0oAxkO7vKVZlVP5G7kUBLhfDd9AHvx5Ga Sk6Jba6dO2u/peNNZvh8nTj/T6Heru7xDtUnjIbJUuUG05QA+GOXY/WbMMKpI89F ZTlYTIeP/B/QOHqz/WEP5HV2rJ2SAwQMHdKF7I4w== X-ME-Sender: X-Sasl-enc: FLpjEJvXsyJ5bm2SvXFF/xU25ucszUpeTnsETXP1fI+z 1497748845 Received: from [192.168.66.109] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F91F7E9ED for ; Sat, 17 Jun 2017 21:20:45 -0400 (EDT) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_BCCC631A-500C-4C2E-8F87-221973D1018A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: IETF 99 Preliminary Agenda Message-Id: <817579E6-78E5-4FA7-A997-CD8C485F6F2D@mnot.net> References: <149765596926.24039.3258268821492667190.idtracker@ietfa.amsl.com> To: IETF QUIC WG Date: Sun, 18 Jun 2017 11:20:44 +1000 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: Sun, 18 Jun 2017 01:20:51 -0000 --Apple-Mail=_BCCC631A-500C-4C2E-8F87-221973D1018A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI. We have a session on Thursday and one on Friday. Also, the HTTP = Working Group is going to use one of their sessions on Wednesday to = discuss HTTP-over-QUIC; more details soon. Cheers, > Begin forwarded message: >=20 > From: IETF Agenda > Subject: IETF 99 Preliminary Agenda > Date: 17 June 2017 at 9:32:49 am AEST > To: "IETF Announcement List" > Cc: 99all@ietf.org, ietf@ietf.org > Reply-To: ietf@ietf.org, IETF Agenda > Archived-At: = >=20 > IETF 99 > Prague, Czech Republic > July 16-21, 2017 > Host: Comcast/NBCUniversal and CZ.NIC >=20 > The IETF 99 Preliminary Agenda has been posted. The final agenda will = be published on Friday, June 23, 2017.=20 >=20 > https://datatracker.ietf.org/meeting/99/agenda.html=20 > https://datatracker.ietf.org/meeting/99/agenda.txt >=20 > IETF 99 Information: https://ietf.org/meeting/99/index.html > Register online at: https://ietf.org/meeting/register.html >=20 > Don=E2=80=99t forget to register for these exciting IETF 99 events! >=20 > Social Event > Date: Tuesday, 18 July 2017 > Time: 18:30 - 22:00 > Cost: $20 USD per ticket, limit two per attendee.=20 > Children 10 and under are free.=20 > Hosted by: CZ.NIC, Comcast, and NBC Universal > Location: Kafka museum at Hergetova Cihelna >=20 > More information: https://www.ietf99.cz/#socialevent > Link to purchase Social Tickets:=20 > https://www.ietf.org/registration/ietf99/eventticket.py >=20 > Hackathon=20 > Signup: = https://www.ietf.org/registration/ietf99/hackathonregistration.py > More information: http://ietf.org/hackathon/99-hackathon.html=20 > Keep up to date by subscribing to:=20 > https://www.ietf.org/mailman/listinfo/hackathon >=20 > Code Sprint > Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF99SprintSignUp > More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF99Sprint >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_BCCC631A-500C-4C2E-8F87-221973D1018A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI. We have a session on Thursday and one on Friday. Also, = the HTTP Working Group is going to use one of their sessions on = Wednesday to discuss HTTP-over-QUIC; more details soon.
Cheers,


Begin forwarded message:

From: = IETF Agenda <agenda@ietf.org>
Subject: = IETF 99 = Preliminary Agenda
Date: = 17 June 2017 at 9:32:49 am = AEST
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: 99all@ietf.org, ietf@ietf.org
Reply-To: = ietf@ietf.org, IETF Agenda <agenda@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/ryvGnr5qu_C= IhocWAcOO1-c1EDs>

IETF 99
Prague, Czech = Republic
July 16-21, 2017
Host: = Comcast/NBCUniversal and CZ.NIC

The IETF 99 = Preliminary Agenda has been posted. The final agenda will be published = on Friday, June 23, 2017.

https://datatracker.ietf.org/meeting/99/agenda.html
https://datatracker.ietf.org/meeting/99/agenda.txt

IETF 99 Information: = https://ietf.org/meeting/99/index.html
Register online at: = https://ietf.org/meeting/register.html

Don=E2=80=99t forget to register for these exciting IETF 99 = events!

Social Event
Date: = Tuesday, 18 July 2017
Time: 18:30 - 22:00
= Cost: $20 USD per ticket, limit two per attendee.
= Children 10 and under are free.
Hosted = by: CZ.NIC, Comcast, and NBC Universal
Location: = Kafka museum at Hergetova Cihelna

More = information: https://www.ietf99.cz/#socialevent
Link to = purchase Social Tickets:
= https://www.ietf.org/registration/ietf99/eventticket.py

Hackathon
Signup: = https://www.ietf.org/registration/ietf99/hackathonregistration.py
= More information: http://ietf.org/hackathon/99-hackathon.html
= Keep up to date by subscribing to:
= https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF99SprintSignUp
= More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF99Sprint


--
Mark Nottingham   https://www.mnot.net/


= --Apple-Mail=_BCCC631A-500C-4C2E-8F87-221973D1018A-- From nobody Sun Jun 18 04:37: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 3FDCF120724 for ; Sun, 18 Jun 2017 04:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 541juutweaNX for ; Sun, 18 Jun 2017 04:37:36 -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 C1E1C120454 for ; Sun, 18 Jun 2017 04:37:36 -0700 (PDT) Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by linode64.ducksong.com (Postfix) with ESMTPSA id 70AA13A019 for ; Sun, 18 Jun 2017 07:37:35 -0400 (EDT) Received: by mail-qk0-f174.google.com with SMTP id r62so17223365qkf.0 for ; Sun, 18 Jun 2017 04:37:35 -0700 (PDT) X-Gm-Message-State: AKS2vOzHL21L1pRGSQyhJXd3N3bATalHEA0PeGdk4d1OzYFdIre7kz09 AoAooQQAbSD3O6hrkKbrtsCflC4OAA== X-Received: by 10.55.91.70 with SMTP id p67mr22825246qkb.237.1497785855219; Sun, 18 Jun 2017 04:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.85 with HTTP; Sun, 18 Jun 2017 04:37:34 -0700 (PDT) From: Patrick McManus Date: Sun, 18 Jun 2017 07:37:34 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: IETF 99 QUIC First Implementation Draft hackathon To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114cad4cd9a03005523a71b1" 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, 18 Jun 2017 11:37:39 -0000 --001a114cad4cd9a03005523a71b1 Content-Type: text/plain; charset="UTF-8" QUIC-folk, We have been added to the prague hackathon https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=99hackathon&#technologies_included_in_hackathon_more_can_be_added . The first implementation draft https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft is clearly in scope - but if you have more, bring more! This event happens the weekend before IETF week - July 15 and 16 at the Prague Hilton. All are welcome - I have confirmed you do not need to be registered for the week. However you should register (the link to register is on the above link). If you can come, it would be great if you could send me an email to let me know. We'll presumably use the quic jabber space as well. If you haven't been to one of these before, its pretty simple. Space and power for like minded folks to work on their code and try some interop. There are some very brief presentations and report outs. You don't have to be done to attend, indeed its a great forum to make some progress and test our your understanding of the specification to help us make the text stronger The contribution guidelines are helpful to know - your code remains your code, but discussion of the protocol is an IETF contribution. "IPR and Code Contribution Guideline All hackathon participants are free to work on any code. The rules regarding that code are what each participant's organization and/or open source project says they are. The code itself is not an IETF Contribution. However, discussions, presentations, demos, etc., during the hackathon are IETF Contributions (similar to Contributions made in working group meetings). Thus, the usual IETF policies apply to these Contributions, including copyright, license, and IPR disclosure rules" -Patrick --001a114cad4cd9a03005523a71b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
QUIC-folk,

The first implementation draft https://g= ithub.com/quicwg/base-drafts/wiki/First-Implementation-Draft is clearly= in scope - but if you have more, bring more!

This= event happens the weekend before IETF week - July 15 and 16 at the Prague = Hilton. All are welcome - I have confirmed you do not need to be registered= for the week. However you should register (the link to register is on the = above link). If you can come, it would be great if you could send me an ema= il to let me know. We'll presumably use the quic jabber space as well.<= br>

If you haven't been to one of these before= , its pretty simple. Space and power for like minded folks to work on their= code and try some interop. There are some very brief presentations and rep= ort outs. You don't have to be done to attend, indeed its a great forum= to make some progress and test our your understanding of the specification= to help us make the text stronger

The contributio= n guidelines are helpful to know - your code remains your code, but discuss= ion of the protocol is an IETF contribution.

"IPR= and Code Contribution Guideline

All hackathon participants are free to work on any code. The rules=20 regarding that code are what each participant's organization and/or ope= n source project says they are. The code itself is not an IETF=20 Contribution. However, discussions, presentations, demos, etc., during=20 the hackathon are IETF Contributions (similar to Contributions made in=20 working group meetings). Thus, the usual IETF policies apply to these=20 Contributions, including copyright, license, and IPR disclosure rules"

-Patrick


--001a114cad4cd9a03005523a71b1-- From nobody Sun Jun 18 11:47: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 40C67127B52 for ; Sun, 18 Jun 2017 11:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DbuwpIfAoclo for ; Sun, 18 Jun 2017 11:47:23 -0700 (PDT) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.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 F0DCC124217 for ; Sun, 18 Jun 2017 11:47:22 -0700 (PDT) Received: from BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v5IIlKuk024995; Sun, 18 Jun 2017 19:47:20 +0100 (BST) Received: from BGB01XI1015.national.core.bbc.co.uk (10.161.14.78) by BGB01XI1005.national.core.bbc.co.uk (10.184.50.55) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 18 Jun 2017 19:47:20 +0100 Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1015.national.core.bbc.co.uk ([10.161.14.78]) with mapi id 14.03.0319.002; Sun, 18 Jun 2017 19:47:20 +0100 From: Lucas Pardue To: Patrick McManus , IETF QUIC WG Subject: RE: IETF 99 QUIC First Implementation Draft hackathon Thread-Topic: IETF 99 QUIC First Implementation Draft hackathon Thread-Index: AQHS6CdPpe/DTYZdyEOJbc06diqJ36Iq8cnR Date: Sun, 18 Jun 2017 18:47:19 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A37723CBB@bgb01xud1012> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] X-TM-AS-Product-Ver: SMEX-11.0.0.4255-8.100.1062-23140.001 X-TM-AS-Result: No--17.923300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 X-EXCLAIMER-MD-CONFIG: 1cd3ac1c-62e5-43f2-8404-6b688271c769 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, 18 Jun 2017 18:47:25 -0000 =EF=BB=BFHi Patrick, Thanks for setting this up! As a non-implementor I might be interested in the support tooling side of t= hings, for instance how to bring up to speed Wireshark to decrypt and disse= ct IETF QUIC. (Hint: key logging) I attended the 98 Hackathon and would like to emphasise how the event is ve= ry much focused on cooperation and communication. For those that cant attend in person, remote working is feasible but don't = expect typical IETF remote capability. We are talking more like Jabber and = GitHub, however it works rather well when people in a suitable timezones ca= n contribute when the room is locked up.=20 Lucas ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Patrick McManus [pmcmanus@m= ozilla.com] Sent: 18 June 2017 12:37 To: IETF QUIC WG Subject: IETF 99 QUIC First Implementation Draft hackathon QUIC-folk, We have been added to the prague hackathon https://www.ietf.org/registratio= n/MeetingWiki/wiki/doku.php?id=3D99hackathon&#technologies_included_in_hack= athon_more_can_be_added . The first implementation draft https://github.com/quicwg/base-drafts/wiki/F= irst-Implementation-Draft is clearly in scope - but if you have more, bring= more! This event happens the weekend before IETF week - July 15 and 16 at the Pra= gue Hilton. All are welcome - I have confirmed you do not need to be regist= ered for the week. However you should register (the link to register is on = the above link). If you can come, it would be great if you could send me an= email to let me know. We'll presumably use the quic jabber space as well. If you haven't been to one of these before, its pretty simple. Space and po= wer for like minded folks to work on their code and try some interop. There= are some very brief presentations and report outs. You don't have to be do= ne to attend, indeed its a great forum to make some progress and test our y= our understanding of the specification to help us make the text stronger The contribution guidelines are helpful to know - your code remains your co= de, but discussion of the protocol is an IETF contribution. "IPR and Code Contribution Guideline All hackathon participants are free to work on any code. The rules regardin= g that code are what each participant's organization and/or open source pro= ject says they are. The code itself is not an IETF Contribution. However, d= iscussions, presentations, demos, etc., during the hackathon are IETF Contr= ibutions (similar to Contributions made in working group meetings). Thus, t= he usual IETF policies apply to these Contributions, including copyright, l= icense, and IPR disclosure rules" -Patrick ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and=20 may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in=20 error, please delete it from your system. Do not use, copy or disclose the=20 information in any way nor act in reliance on it and notify the sender=20 immediately. Please note that the BBC monitors e-mails=20 sent or received. Further communication will signify your consent to=20 this. -----------------------------= From nobody Mon Jun 19 19:55:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0F131915 for ; Mon, 19 Jun 2017 19:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=I6Ozdc/B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GgqF5UeS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_wnAkPimhbW for ; Mon, 19 Jun 2017 19:55:01 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146B913190F for ; Mon, 19 Jun 2017 19:54:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 642FB14E2 for ; Mon, 19 Jun 2017 22:54:57 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 19 Jun 2017 22:54:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= 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=55zRA1vxeM3mk5gSuiVDVMmz7yLZ2mJp1k8ncLu7O C0=; b=I6Ozdc/Bbc/1u+VqbsTOg3eCDys5uQFp8iNHoTT4nsdurX1bhjF6C835J W6LWUUhxoLjrERIVgGLwIvSvr7TCvMiu4sv9gcwMI7gjt0bQPtHiVGExb+SM6/mx aZLKGaTJxz3TQjYOIVoM7XYY7Hx7XQBq3/DzrsuzIkSBW72f2Ic6XTAI+CJOW4K2 AziUZUWyckKmz5SVsYq7vqUKx7i9bqBnKYm4EpetgkskPFyrm3W/rftT49L9jpPz t5XvRfPdqtBWvbZ3r39Y56KsozNOfhBA0p5UE1idNffRfMfx/28IPOgZcjnKhhGV TAJWPh9q/7XQ2AWbZ1n8azpagP59g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=55zRA1vxeM3mk5gSui VDVMmz7yLZ2mJp1k8ncLu7OC0=; b=GgqF5UeS2qb0AlYKqO1PpfA7o0uvcbUigL DZL8XiCbp6zQ01zfC0v4kySMFRjYTY1cwOtpn+FzgNX4IfGCwnLuxr8EWix1n/8M MSEs1zJq87mzsSJSFfLP6UdPXCR1blqkQYb7GkU1LUEujwJCEjRTsIY2n5ZIZzc2 iwnROp/eN2lHzQqiNet0R3Fqb5fcUFq7F1nl+pjnQDmJZil0T+TfaJ7ie1h0K/I3 /dappKyRsXW0r/IOVntz+oW2Q/r64cH9/gA6nPA8aMMFIXznzIbQwqes+uuUIgUZ O2Mo61WN595lVPsrWYaOcuKe7jCaXMMyg3/qcnYHERf6NU2kPSNQ== X-ME-Sender: X-Sasl-enc: Y2NJYu+m4M0UBR0eV9/qqkMjMwcv8ZIyEfz94dV138oq 1497927296 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 5CECC7E7B1 for ; Mon, 19 Jun 2017 22:54:56 -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: Architecture issues Message-Id: <090B11E1-32FA-4574-8CBE-9AA959E2E7B7@mnot.net> Date: Tue, 20 Jun 2017 12:54:53 +1000 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, 20 Jun 2017 02:55:04 -0000 One of the things we discussed in Paris was an attempt to clarify our = (large) collection of issues by teasing out the higher-level concerns = into "architecture" issues. We've started collecting these here: = https://github.com/quicwg/base-drafts/issues?q=3Dis%3Aopen+is%3Aissue+labe= l%3Aarch If there's an existing issue that you think fits this description, = please bring it to our attention (in e-mail). If you'd like to raise a = new architectural issue, please discuss it on the mailing list *before* = opening an issue in Github, to make sure it's appropriately described. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 20 01:37:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1E71277BB for ; Tue, 20 Jun 2017 01:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=JUjeC5bm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LGfppdKr Received: 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-JtL1yyqrv for ; Tue, 20 Jun 2017 01:37:30 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B722128DF3 for ; Tue, 20 Jun 2017 01:37:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id F25D61242; Tue, 20 Jun 2017 04:37:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 20 Jun 2017 04:37:29 -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=wsEAoShE66/CT96DcFFozz5M5ujjV05ylwF1xw+RS /0=; b=JUjeC5bmfEBTD57VDeu6WvvjU1zh8/FoYDaTdekH6vCIpSxetgkylIiO9 8GI7TiSDQRgxaxPaw4/AWr3T2O38EvwvXzeuBCkph4fvCZFbh3CatjO3inM4oOpW fV7ZqueV0QduxRF1CAJgBNe3T9i3F0ZXr1XlbG0ByIcujRfiqWmdc2+W0KPF3zp2 ogBYHdglyrjhwrbeOpYSKscy/J/lt3xA1RrtVJKtax1ix25K9uyvZ85gL7WbVYRj ukGriPjOf+nCnwX77jK1pIj0cjx79veA3NMQ+Ky9TBleJZMYX9SDaWmh73koCHUQ sCImlDj7MzY9gO+fzncmiGvcwRx8A== 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=wsEAoShE66/CT96DcF Fozz5M5ujjV05ylwF1xw+RS/0=; b=LGfppdKrBv+cPxcrik/oVQ3K84C48l5IvO sjyhctu5SJ+EknyKs6yETTF87kFEo2CIvy2EnQPa+OUDsMdHVFNxcSeCmryhkuxt D0m7i2fc8mpaFxWp8jtUFYlJxVYkBgdFY/pT0fTRjSYQbeH1JaNXvaAF9mk7EN/N JrQGtfE21hqE5piaY0wv0OqaZ6HMlCp6jFv7WqIeocU4aukjAqI56aMj4YaNGBxv U7gn/U4z8bQdu69Sd5yQgsHvVORHW6R9rsAB3E4H0gwQMF3Xh0ZwTi9jzosmawgg rd473ZT8vrRFMF2FBD0jamfY36+1F86dr6uZyajJYSS0S3Ekzpow== X-ME-Sender: X-Sasl-enc: tTYl9GZVme3alHHTK3DMj6LZt4uziYBxOikuUV8DY9eR 1497947849 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 CEFFA7E51B; Tue, 20 Jun 2017 04:37:28 -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: First Implementation Draft Message-Id: <37C225D2-D7E3-44F7-BC9A-1E137025F4E1@mnot.net> Date: Tue, 20 Jun 2017 18:37:25 +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, 20 Jun 2017 08:37:33 -0000 Hello everyone, As discussed on-list and at the Paris Interim, we're designating the -04 = drafts as the First Implementation Draft set.=20 This means that implementers should target that set of specifications = for their first implementation efforts. For specifics of what = implementations should focus on, see: https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft As Patrick mentioned, there will be an opportunity and the Prague = Hackathon to work together and do some interop. If you plan to do that, = please fill out this form: https://goo.gl/forms/BvHFMB6vVNC5dur03 Cheers, =20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 20 03:47:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F1812952D for ; Tue, 20 Jun 2017 03:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmXJVvg32zAe for ; Tue, 20 Jun 2017 03:47:12 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 7FB3E127867 for ; Tue, 20 Jun 2017 03:47:12 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id t7so35881163yba.3 for ; Tue, 20 Jun 2017 03:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ykTdjJ0TjdaaZgpODEzTwe/PCPzz5UOKpptJEd1XnCw=; b=XUDSCI2BWiQszGdU3fvDEDVipyaB3Fc7n+hstmaSZLZ2BZzQTa8AtjC6gDd/IC430G et5s5kj4JkXiICweSPatjgbUlG0sBpCL8DsSmq7brP8CeQvr5QdQyTz1KUgSZ0h9EXbn HIsm46x1YBGyQZcLdeXUpgugWLh6goDUBswSg9o+sC0mzC2viKQO45fez8Oit5PrA8ZA kTD5k5ud2vBZVk7XQKoTpbZShpii8YkTjR/RSmxVzzP07jJi/QsYCfDIG+Cf4S0NZYYK Sy9L3uaXDarZdl7dU18N3ReEArjj6RBfB2f3iXch5wxQCWe2yM6ttTGCDae3IuHw2JED +DxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ykTdjJ0TjdaaZgpODEzTwe/PCPzz5UOKpptJEd1XnCw=; b=eFEKgixBNLlAE4dD9kVjpQ4zyqORmNL9wuzj28o7AO0j7RKspv65jAr5Ij6vWv4XTS JVPCe9YQWpvYVctlo1Ewx6Y9evcCmhvsTr/+YrXFXpOLgCsQ+41yy0KBLKB2bZs5be3w rC9IckCrr9tPEceYdwboSe0sf18AiNs7igKI4l23z9E7d9gfDG79f1hAR04U1Hv9IBPK zqJkgk30APfHI0shDdKYCPX8MMhrs5LgBYHoGKcWau3RvAS35Tql5xD9moIfs3JwHlaR fE2pZhBJGkIJX5lp0DCfcFVbM20AurZB3MhbET1qxydy0w8RGv6Jfe3LDIyOEVle+bCz ugOg== X-Gm-Message-State: AKS2vOw6YnfLIBCdrc1sE9ipkW5rxYzTf/2e0XXTXW7EcPRCHErwB6LE gb1lPwVYWQ/p68aLJBHm5qBL5K+n7g== X-Received: by 10.37.172.22 with SMTP id w22mr21133437ybi.82.1497955631676; Tue, 20 Jun 2017 03:47:11 -0700 (PDT) MIME-Version: 1.0 References: <7CF7F94CB496BF4FAB1676F375F9666A37723CBB@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A37723CBB@bgb01xud1012> From: Lucas Clemente Date: Tue, 20 Jun 2017 10:47:00 +0000 Message-ID: Subject: Re: IETF 99 QUIC First Implementation Draft hackathon To: Lucas Pardue , Patrick McManus , IETF QUIC WG Cc: Marten Seemann Content-Type: multipart/alternative; boundary="f403045dae9250c408055261f9d2" 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, 20 Jun 2017 10:47:16 -0000 --f403045dae9250c408055261f9d2 Content-Type: text/plain; charset="UTF-8" We (quic-go) won't be able to make it to Prague, but I'm open to remote-attend the hackathon. We probably won't start working on our -04 fork until then though :/ On Sun, 18 Jun 2017 at 20:47 Lucas Pardue wrote: > Hi Patrick, > > Thanks for setting this up! > > As a non-implementor I might be interested in the support tooling side of > things, for instance how to bring up to speed Wireshark to decrypt and > dissect IETF QUIC. (Hint: key logging) > > I attended the 98 Hackathon and would like to emphasise how the event is > very much focused on cooperation and communication. > > For those that cant attend in person, remote working is feasible but don't > expect typical IETF remote capability. We are talking more like Jabber and > GitHub, however it works rather well when people in a suitable timezones > can contribute when the room is locked up. > > Lucas > ________________________________________ > From: QUIC [quic-bounces@ietf.org] on behalf of Patrick McManus [ > pmcmanus@mozilla.com] > Sent: 18 June 2017 12:37 > To: IETF QUIC WG > Subject: IETF 99 QUIC First Implementation Draft hackathon > > QUIC-folk, > > We have been added to the prague hackathon > https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=99hackathon&#technologies_included_in_hackathon_more_can_be_added > . > The first implementation draft > https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft is > clearly in scope - but if you have more, bring more! > > This event happens the weekend before IETF week - July 15 and 16 at the > Prague Hilton. All are welcome - I have confirmed you do not need to be > registered for the week. However you should register (the link to register > is on the above link). If you can come, it would be great if you could send > me an email to let me know. We'll presumably use the quic jabber space as > well. > > If you haven't been to one of these before, its pretty simple. Space and > power for like minded folks to work on their code and try some interop. > There are some very brief presentations and report outs. You don't have to > be done to attend, indeed its a great forum to make some progress and test > our your understanding of the specification to help us make the text > stronger > > The contribution guidelines are helpful to know - your code remains your > code, but discussion of the protocol is an IETF contribution. > "IPR and Code Contribution Guideline > > All hackathon participants are free to work on any code. The rules > regarding that code are what each participant's organization and/or open > source project says they are. The code itself is not an IETF Contribution. > However, discussions, presentations, demos, etc., during the hackathon are > IETF Contributions (similar to Contributions made in working group > meetings). Thus, the usual IETF policies apply to these Contributions, > including copyright, license, and IPR disclosure rules" > > -Patrick > > > > > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and > may contain personal views which are not the views of the BBC unless > specifically stated. > If you have received it in > error, please delete it from your system. > Do not use, copy or disclose the > information in any way nor act in reliance on it and notify the sender > immediately. > Please note that the BBC monitors e-mails > sent or received. > Further communication will signify your consent to > this. > ----------------------------- > --f403045dae9250c408055261f9d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We (quic-go) won't be able to make it to Prague, but I= 'm open to remote-attend the hackathon. We probably won't start wor= king on our -04 fork until then though :/

On Sun, 18 Jun 2017 at 20:47 Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
Hi Patrick,

Thanks for setting this up!

As a non-implementor I might be interested in the support tooling side of t= hings, for instance how to bring up to speed Wireshark to decrypt and disse= ct IETF QUIC. (Hint: key logging)

I attended the 98 Hackathon and would like to emphasise how the event is ve= ry much focused on cooperation and communication.

For those that cant attend in person, remote working is feasible but don= 9;t expect typical IETF remote capability. We are talking more like Jabber = and GitHub, however it works rather well when people in a suitable timezone= s can contribute when the room is locked up.

Lucas
________________________________________
From: QUIC [quic= -bounces@ietf.org] on behalf of Patrick McManus [pmcmanus@mozilla.com]
Sent: 18 June 2017 12:37
To: IETF QUIC WG
Subject: IETF 99 QUIC First Implementation Draft hackathon

QUIC-folk,

We have been added to the prague hackathon https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=3D99hackat= hon&#technologies_included_in_hackathon_more_can_be_added .
The first implementation draft = https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft i= s clearly in scope - but if you have more, bring more!

This event happens the weekend before IETF week - July 15 and 16 at the Pra= gue Hilton. All are welcome - I have confirmed you do not need to be regist= ered for the week. However you should register (the link to register is on = the above link). If you can come, it would be great if you could send me an= email to let me know. We'll presumably use the quic jabber space as we= ll.

If you haven't been to one of these before, its pretty simple. Space an= d power for like minded folks to work on their code and try some interop. T= here are some very brief presentations and report outs. You don't have = to be done to attend, indeed its a great forum to make some progress and te= st our your understanding of the specification to help us make the text str= onger

The contribution guidelines are helpful to know - your code remains your co= de, but discussion of the protocol is an IETF contribution.
"IPR and Code Contribution Guideline

All hackathon participants are free to work on any code. The rules regardin= g that code are what each participant's organization and/or open source= project says they are. The code itself is not an IETF Contribution. Howeve= r, discussions, presentations, demos, etc., during the hackathon are IETF C= ontributions (similar to Contributions made in working group meetings). Thu= s, the usual IETF policies apply to these Contributions, including copyrigh= t, license, and IPR disclosure rules"

-Patrick




-----------------------------
http:= //www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specif= ically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
--f403045dae9250c408055261f9d2-- From nobody Tue Jun 20 03: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 7AB78127867 for ; Tue, 20 Jun 2017 03:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ZixwH1uONS6b for ; Tue, 20 Jun 2017 03:49:08 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0B0131984 for ; Tue, 20 Jun 2017 03:49:07 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id 2FE8E1C136E; Tue, 20 Jun 2017 12:49:06 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 7EAE01C135D; Tue, 20 Jun 2017 12:49:03 +0200 (CEST) (Extended-Queue-bit tech_hyykg@fff.in.tum.de) Subject: Re: IETF 99 QUIC First Implementation Draft hackathon To: Lucas Clemente , Lucas Pardue , Patrick McManus , IETF QUIC WG References: <7CF7F94CB496BF4FAB1676F375F9666A37723CBB@bgb01xud1012> Cc: Marten Seemann From: Joerg Ott Message-ID: Date: Tue, 20 Jun 2017 06:49:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 10:49:10 -0000 I am chairing the Applied Networking Research Workshop on that Saturday, which runs 9-17. So I won't be able to participate either. But maybe there is a chance to continue on Sunday? Jörg On 20.06.17 06:47, Lucas Clemente wrote: > We (quic-go) won't be able to make it to Prague, but I'm open to > remote-attend the hackathon. We probably won't start working on our -04 > fork until then though :/ > > On Sun, 18 Jun 2017 at 20:47 Lucas Pardue > wrote: > > Hi Patrick, > > Thanks for setting this up! > > As a non-implementor I might be interested in the support tooling > side of things, for instance how to bring up to speed Wireshark to > decrypt and dissect IETF QUIC. (Hint: key logging) > > I attended the 98 Hackathon and would like to emphasise how the > event is very much focused on cooperation and communication. > > For those that cant attend in person, remote working is feasible but > don't expect typical IETF remote capability. We are talking more > like Jabber and GitHub, however it works rather well when people in > a suitable timezones can contribute when the room is locked up. > > Lucas > ________________________________________ > From: QUIC [quic-bounces@ietf.org ] on > behalf of Patrick McManus [pmcmanus@mozilla.com > ] > Sent: 18 June 2017 12:37 > To: IETF QUIC WG > Subject: IETF 99 QUIC First Implementation Draft hackathon > > QUIC-folk, > > We have been added to the prague hackathon > https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=99hackathon&#technologies_included_in_hackathon_more_can_be_added > . > The first implementation draft > https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft is > clearly in scope - but if you have more, bring more! > > This event happens the weekend before IETF week - July 15 and 16 at > the Prague Hilton. All are welcome - I have confirmed you do not > need to be registered for the week. However you should register (the > link to register is on the above link). If you can come, it would be > great if you could send me an email to let me know. We'll presumably > use the quic jabber space as well. > > If you haven't been to one of these before, its pretty simple. Space > and power for like minded folks to work on their code and try some > interop. There are some very brief presentations and report outs. > You don't have to be done to attend, indeed its a great forum to > make some progress and test our your understanding of the > specification to help us make the text stronger > > The contribution guidelines are helpful to know - your code remains > your code, but discussion of the protocol is an IETF contribution. > "IPR and Code Contribution Guideline > > All hackathon participants are free to work on any code. The rules > regarding that code are what each participant's organization and/or > open source project says they are. The code itself is not an IETF > Contribution. However, discussions, presentations, demos, etc., > during the hackathon are IETF Contributions (similar to > Contributions made in working group meetings). Thus, the usual IETF > policies apply to these Contributions, including copyright, license, > and IPR disclosure rules" > > -Patrick > > > > > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and > may contain personal views which are not the views of the BBC unless > specifically stated. > If you have received it in > error, please delete it from your system. > Do not use, copy or disclose the > information in any way nor act in reliance on it and notify the sender > immediately. > Please note that the BBC monitors e-mails > sent or received. > Further communication will signify your consent to > this. > ----------------------------- > From nobody Tue Jun 20 08:23: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 CCDB0131A6B for ; Tue, 20 Jun 2017 08:23:25 -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, 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 WIeNzjp_gkmm for ; Tue, 20 Jun 2017 08:23:24 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8DB131B50 for ; Tue, 20 Jun 2017 08:18:28 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id c189so51296696oia.2 for ; Tue, 20 Jun 2017 08:18: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; bh=ocBrmxs8oOC0CDGV8cKRXDlBKW5/cD0+XxvXsRHfpGs=; b=J6lML5TzReYFWdHT3tqUbLtzdf2IulNmOX76rWsETlq/pyGwhNxGXUCxG8PI6K62rN 0xVcy5dt2yctChAr5jyuL0pa9ShDMrfxU9QNy/bUGWiNpSCGEdskuywIpwpSu+Iv4gyN oGL6z2POHxYpWidHvzjOHVNDmsuqsGH+T/w1SW+djmdXbz9JAFMYulXQdzGm8jUdQAit Y/TMymSREBU/USE2EJIBQgowWnwDPAxvKuFWxdGc/3ONm2FGkaIGbRy4iN8RaEtOqtdT 4ws2m6PlnKZkwh2klV512f7kyeD0N9o1ymh4ZatA7BttEMbgwTMlho4XvLeY3UuMFY+c /HYA== 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=ocBrmxs8oOC0CDGV8cKRXDlBKW5/cD0+XxvXsRHfpGs=; b=PTfSz8TmZi8p0UmT9OnabTj1uXtmDyJ0M4WBNOyJIR5DgkBFORRPR9oZn7rXRWVcpf ghdEOVqCFcePpWBMWMkDa9CL4qrME6TSUx2uz4JaClY1gY7Nk1HTqFQeaAo0mNtJS7Re ubnZ/1kdGzQ6Y2uHYWljaYQrG103MnAYERo4mez5bPtAnZ+ZHBUn+ex3+9fvSvRtKgAa yx7tNDzKSdrInsvOZlTKobPgGcIuBVQ7A+cExLLNEbeStW1v7pDwmX6P4Yb3GkHI9yQx YLpEO4WobqIyYnO8oaUBytqFZkJJtvXVAhJdlkoZPuW/8F/kTqy68BqYuTspxlmTO3M6 L0VQ== X-Gm-Message-State: AKS2vOxKvvfGYsPd6eIi1NSlWiBqfqxffbN115lZoXMymjO2P33aFX6o NA52d/uVeNNCK98lRpF80Nh+V/t+Qw== X-Received: by 10.202.75.7 with SMTP id y7mr15246421oia.151.1497971908079; Tue, 20 Jun 2017 08:18:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.83 with HTTP; Tue, 20 Jun 2017 08:18:27 -0700 (PDT) In-Reply-To: References: From: Martin Duke Date: Tue, 20 Jun 2017 08:18:27 -0700 Message-ID: Subject: Re: October interim To: "Eggert, Lars" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113e522c76f607055265c376" 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, 20 Jun 2017 15:23:26 -0000 --001a113e522c76f607055265c376 Content-Type: text/plain; charset="UTF-8" A room is reserved for an Oct 2nd hackathon, pending consent of whomever is organizing it. On Fri, Jun 9, 2017 at 3:55 AM, Eggert, Lars wrote: > Hi, > > as mentioned during the Paris interim that just ended, our plans for the > next QUIC WG interim have solidified. > > We'll be meeting October 3-5, 2017 (Tue-Thu) in Seattle, WA, USA(*), > hosted by F5 Networks. Do note that it is likely that there will be an > interop event before the interim, most likely on Mon, Oct 2. > > I've uploaded placeholder information at https://github.com/quicwg/wg- > materials/tree/master/interim-17-10 and will formally request the meeting > shortly. > > Lars > > (*) In an email from Apr 18 titled "Questions regarding fall interim > location", we asked whether meeting in the US would be difficult for any > participant, but did not receive any indication that this was the case. > --001a113e522c76f607055265c376 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A room is reserved for an Oct 2nd hackathon, pending conse= nt of whomever is organizing it.

On Fri, Jun 9, 2017 at 3:55 AM, Eggert, Lars <lars@neta= pp.com> wrote:
Hi,

as mentioned during the Paris interim that just ended, our plans for the ne= xt QUIC WG interim have solidified.

We'll be meeting October 3-5, 2017 (Tue-Thu) in Seattle, WA, USA(*), ho= sted by F5 Networks. Do note that it is likely that there will be an intero= p event before the interim, most likely on Mon, Oct 2.

I've uploaded placeholder information at https://github.com/quicwg/wg-materials/tree/master/interim-17-10 and will formally request the meeting shortly.

Lars

(*) In an email from Apr 18 titled "Questions regarding fall interim l= ocation", we asked whether meeting in the US would be difficult for an= y participant, but did not receive any indication that this was the case.

--001a113e522c76f607055265c376-- From nobody Wed Jun 21 00:42: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 DF1C813173B for ; Wed, 21 Jun 2017 00:42:26 -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 04h52u_EMB2a for ; Wed, 21 Jun 2017 00:42:24 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 09C951316FC for ; Wed, 21 Jun 2017 00:41:39 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id m77so88293955lfe.0 for ; Wed, 21 Jun 2017 00:41:38 -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=BQgcnxp9XNcZW9J4UkThmRtgv0HwJ3puZUyxsp3hluA=; b=aou8qEayW61FSaMfxV32RNTjU88wgE6cZNqvIhBx60MT4+fbpTtGVsduxNv/n8pvfG 3T0TrGM486KP4zjDfaqAzpJknktC1FT330+lIuTmByKah8bPVmBl6D/97jo3rwuV2WLY yyLZE7cE44UU8gSWmgsg2klARjg9S4uJBs6vElMlQouQgdbh4YpGU6yzPC2X5xsvKg04 KcBlVHrlZGZdyfopHIudAZe17aiqqv/HvXH76X3+R6E25fmI28RNBj4ildcB4fvBFBgJ QeJMd7jZBwFn0Gu0UnwUp/8Gloasrig8rIY6ILTjlOav8vNFEmbZ29roK0M2ean6zq+O MAtA== 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=BQgcnxp9XNcZW9J4UkThmRtgv0HwJ3puZUyxsp3hluA=; b=unTG3BzfdcZ9qPNq76Ds0UPSSNrFA3Q2dtVvjQmu5Fv4wLUt17wNR85nvYE7UWP92n NXQfA1b9/g0F38x1klxfw0KjhMNcLDI7XB0w5sqTMhDzrwWkh4rXPTPtzVT9CoOnE1FD RHZoUYPj4zoadmKgbzjoa/L5+smRBl6e+UBIUme0uO/DzOxfEC21NybfgqGaqSgQ8dIp rnNkNrXIeYrDiFJGVswI4IE0DN2eX9rScMaWXAswYQ5TyDZhJ0zI8i121nroSQx9rmgQ TbaHhflPRqwEN4QzSVpbnKRCPIgBEQHx5Vv6WZqhwMDtjDMY6xnST0fO63XcZ2TfxMjp G84w== X-Gm-Message-State: AKS2vOwdgOopCbFLiQW+LuWibuXSLst0dzur8UdUjfiYtfXTxHOIloSG Jf0hpNDB0SeGa5vhfSp4JYB82+Rsk4sXvJ8= X-Received: by 10.46.77.70 with SMTP id a67mr589265ljb.103.1498030896900; Wed, 21 Jun 2017 00:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Wed, 21 Jun 2017 00:41:36 -0700 (PDT) From: Martin Thomson Date: Wed, 21 Jun 2017 17:41:36 +1000 Message-ID: Subject: Unidirectional streams PR 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: Wed, 21 Jun 2017 07:42:27 -0000 I've created a pull request unidirectional streams. https://github.com/quicwg/base-drafts/pull/643 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. From nobody Wed Jun 21 02:49: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 86EA3131CEC for ; Wed, 21 Jun 2017 02:49:04 -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 ng_KjSzweI3K for ; Wed, 21 Jun 2017 02:49:01 -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 8ED94131CED for ; Wed, 21 Jun 2017 02:49:01 -0700 (PDT) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id 324BA3A0A0 for ; Wed, 21 Jun 2017 05:49:00 -0400 (EDT) Received: by mail-qk0-f175.google.com with SMTP id p21so5813567qke.3 for ; Wed, 21 Jun 2017 02:49:00 -0700 (PDT) X-Gm-Message-State: AKS2vOymZ4J4r3+6MIb60lsDBEkG6JpH6o92ysL3MKzEhFUfprJ0YPzp lsoVeO9nxXV5zcUZYR40LLiWvzOybA== X-Received: by 10.55.214.154 with SMTP id p26mr7056368qkl.188.1498038539500; Wed, 21 Jun 2017 02:48:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.85 with HTTP; Wed, 21 Jun 2017 02:48:58 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Wed, 21 Jun 2017 10:48:58 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a1147a57a01c4c4055275475e" 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, 21 Jun 2017 09:49:04 -0000 --001a1147a57a01c4c4055275475e Content-Type: text/plain; charset="UTF-8" I have come to strongly support unidirectional streams. I'm writing because I think we can take this just a tiny bit further and get a pretty big architectural win. the PR adds a stream-header to the http mapping.. a key feature of that is a few bytes indicating what stream # a reply (or a push, etc..) is associated with because its not implicit in the stream # anymore. I love the removal of some transport IDs from the HTTP mapping. If we take that just a touch further and include this label explicitly in the request as well then there is no reason to require the use of transport stream ids for the labeling at all (though you could!) - and now you can imagine quic http being implemented on a quic transport api that looks a lot like existing transport apis without having to resort to inventing something like quic_getpeerstreamid(). Relatedly the mapping defines a very short stream header to identify the control channel so I don't think there is any reason to lock it onto stream 1 (and let the transport-id leak into the application mapping in the process). Its not like putting it on stream 1 guarantees it will arrive first anyhow. -Patrick On Wed, Jun 21, 2017 at 8:41 AM, Martin Thomson wrote: > I've created a pull request unidirectional streams. > > https://github.com/quicwg/base-drafts/pull/643 > > 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. > > --001a1147a57a01c4c4055275475e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have come to strongly support unidirectional stream= s. I'm writing because I think we can take this just a tiny bit further= and get a pretty big architectural win.

the PR ad= ds a stream-header to the http mapping.. a key feature of that is a few byt= es indicating what stream # a reply (or a push, etc..) is associated with b= ecause its not implicit in the stream # anymore. I love the removal of some= transport IDs from the HTTP mapping.

If we ta= ke that just a touch further and include this label explicitly in the reque= st as well then there is no reason to require the use of transport stream i= ds=C2=A0 for the labeling at all (though you could!) - and now you can imag= ine quic http being implemented on a quic transport api that looks a lot li= ke existing transport apis without having to resort to inventing something = like quic_getpeerstreamid().

Relatedly the mapping= defines a very short stream header to identify the control channel=C2=A0 s= o I don't think there is any reason to lock it onto stream 1 (and let t= he transport-id leak into the application mapping in the process). Its not = like putting it on stream 1 guarantees it will arrive first anyhow.

-Patrick


On Wed, Jun 21, 2017 at 8:41 AM, Ma= rtin Thomson <martin.thomson@gmail.com> wrote:
I've created a pull request unidirectional = streams.

https://github.com/quicwg/base-drafts/pull/643

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.=C2=A0 Each has three states: idle, open, and closed.=C2=A0 I separated the transitions for sending and receiving because=
that turned out to be easier to explain.=C2=A0 The reordering thing makes them different in subtle ways.

That's all.=C2=A0 The changes in transport are relatively small and the= y
simplify streams a lot.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 First, request and response correlation can't use forwar= d
references because that would mean the client would be exerting
(uncoordinated) control over server streams.=C2=A0 Second, that gives the server the most flexibility in terms of how it answers requests (see
#281).=C2=A0 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.=C2=A0 This empty frame
indicates that another stream will include the body of the message -
or a promise for a body.=C2=A0 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.=C2=A0 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<= br> create a way to cancel them between the time that the PUSH_PROMISE is
sent and when the push stream is created.=C2=A0 That's called RST_PUSH.=

## Things That Need Improvement

I haven't based this on #171.=C2=A0 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.=C2=A0 (That's a taste thing.)=C2=A0 This really assume= s that we
accept something very much like #171.

This really needs QPACK/QCRAM.=C2=A0 Right now, it is impossible to cancel<= br> some types of request using RST_STREAM because not all messages will
have a body (#176 again).=C2=A0 On balance, given that bodies are what you<= br> really want to kill, it's not disastrous, but it's a problem
nonetheless.=C2=A0 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 .=C2=A0 It
doesn't exactly need that, but merging the streams would make things a<= br> lot easy, both conceptually and structurally.

I chose the simplest possible encoding for all of the fields that I
touched.=C2=A0 That means that stream IDs are all 32 bits in size and the HAS_BODY frame takes an entire 9 octets.=C2=A0 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.=C2=A0 Use of an as-yet-not-created push ID as a node in the priority tree would allow
for prioritization to use "empty" nodes.=C2=A0 We'd need to e= xplicitly
allow that though.

# Fixes

Closes #515, #240, #281, #175.


--001a1147a57a01c4c4055275475e-- From nobody Wed Jun 21 14:11: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 D42C6128B4E for ; Wed, 21 Jun 2017 14:11:55 -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 2ZWb-hBSUReo for ; Wed, 21 Jun 2017 14:11:54 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 3977A1289B0 for ; Wed, 21 Jun 2017 14:11:54 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id p66so64654396oia.0 for ; Wed, 21 Jun 2017 14:11:54 -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=z/u/rN373aVCgckZ/zfGargFv2cZqkekhLJy13fH1Aw=; b=oSHPHtApeuoDLsRQ9xOm5I6WRJdWVfzDNR19blDCr8fG7ghGEEz0adUBJEH5z7SJXr LkG2Dq5voUvkMmwkYJx87MQtcPV+xLQ8QTKdHmxL7GLyc6hVsYJTCyuCT/GENdVgrU7d T7GioITXuw02ww0HP5SNdXjI4XE1RfEaq+k8xUPn9CR0LhhJSy3xqD+ccL33GEdBrGoU I74kPMYIo8FTKQ495/F68YpHc/UHcuY9belizLDe3bI8Fgzp3ANKloWnc6QB2RTVKvGD mPKMEwyIUpl7q95S/lRSEajSOeVdpuvDkXllhtjNxzZkJLtL2yRbSQzUcITrfZT2kNuO Wgqg== 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=z/u/rN373aVCgckZ/zfGargFv2cZqkekhLJy13fH1Aw=; b=KULH1GaWxkBMua73I6snlUi1VGYTmht5Zbf+JeoiCumo25Gt+FVte2gaEt4AbLgbd9 jsEsHduc0jGBVD9FOV0nbfbpJbX/6qNCFiJhAIWzj73IeUID9JT/yxNIbJxkHbwKy63/ OJfJCNaTgsB3RWmkMDsZAkuvFBP0aOevVbHu9YO3n3q0f8qbWmzHrzbD5aHFV4WQj8xl 4MEDeQWEQg/5egXSp1wTm/9RYNJmIjnh80N7frI1kvQU+3efKhCO5AaHY3m5f6m2Zurm ftYu2IbjAY5lpok99KteFCQ3y+o4KWxCIMKioZ/masUhjyHxGJFxK9KZhfdecTMaYM2s yCfg== X-Gm-Message-State: AKS2vOyxkT1fI58sSz4HWnsA53GJsevPzmBGbGFXtpIomphw0NrpkeqX UHfMyfpcrc40XBdshY7GqPZefUfF7RrE X-Received: by 10.202.215.133 with SMTP id o127mr6730380oig.136.1498079513511; Wed, 21 Jun 2017 14:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.83 with HTTP; Wed, 21 Jun 2017 14:11:53 -0700 (PDT) From: Martin Duke Date: Wed, 21 Jun 2017 14:11:53 -0700 Message-ID: Subject: Second Implementation Draft Guidelines To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113d5a9e3f906e05527ed198" 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, 21 Jun 2017 21:11:56 -0000 --001a113d5a9e3f906e05527ed198 Content-Type: text/plain; charset="UTF-8" All, As promised, I've created a set of guidelines for what should be in the Second Implementation draft. If deadlines hold, I believe we will actually start implementing this draft after Seattle in October. Once we've reached reasonable consensus, this should serve as a basis for prioritizing issues to resolve through Seattle. The current version is very much a starting point for discussion. I've presented some items I think are important to include, and others that we could bring in depending on our appetite for work. The final version will simply have "Must Include" and "should not include". https://github.com/quicwg/base-drafts/wiki/Second-Implementation-Draft I look forward to your comments. Martin --001a113d5a9e3f906e05527ed198 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

As promised, I've created a se= t of guidelines for what should be in the Second Implementation draft. If d= eadlines hold, I believe we will actually start implementing this draft aft= er Seattle in October.

Once we've reached reas= onable consensus, this should serve as a basis for prioritizing issues to r= esolve through Seattle.

The current version is ver= y much a starting point for discussion. I've presented some items I thi= nk are important to include, and others that we could bring in depending on= our appetite for work. The final version will simply have "Must Inclu= de" and "should not include".


I look forward to your comments.

Martin
--001a113d5a9e3f906e05527ed198-- From nobody Wed Jun 21 14:22: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 3991A1289B0 for ; Wed, 21 Jun 2017 14:22: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, 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 8rlttmkG4yUH for ; Wed, 21 Jun 2017 14:22:32 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 7ADDD127977 for ; Wed, 21 Jun 2017 14:22:32 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id e187so29810115pgc.1 for ; Wed, 21 Jun 2017 14:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XVs2eBrNtMlFCq8cm6UyEFRkxRUc+0iEEwEO9v6f+7M=; b=V5HopoQrNwhLtmxiVbFO9qEnEUX1lUo1PA4A65C052FgWPuUeN74cm26AOPZc9NpPW xtnVFfP7xgcciLU/jV6m8/R/RzF/h1W7krys/N6lILeFV0IgeEXeGJdv8aBLrhiPG1CT qSdYTP+k3oh2eBeEP9IBzUNZh5nJMoitkw4OtyNnr6XPUYFxDsZwZhmf6BzmitPTuZt2 75DGVHuXy7Cs1BMKPYcfB861mC18cJ3BOdZ+WGiU6d+md0O4u0QKMq0AX11RhS184y8h bBc/nsBFRVYD97KkJj0JhlEu0IkMqUb9al0JBa3XEsATJzttbwZ5rSJFdMJgJSTi+dzo 9Gzw== 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=XVs2eBrNtMlFCq8cm6UyEFRkxRUc+0iEEwEO9v6f+7M=; b=E+HriDOizxXOOMn9eM72KAbjtJj7fC+yV0kTkfGrdfYLgWPTSt6CP9Yvhm9cNSx1b9 RNgUjm63Fr4+7rBLcoulBUQDM8yfWinkm82G3DPq2y/EGmZXCjohrP3N0bd3mb5DrpZ3 7OpAcZDCkVCBJjUTKDAL3PDPhrMm6m0mo9izhqmQogvG9YO5C9SJoCjL2IGfpl6S14RP uRyxHGBwA1UeqWjKh2eJXV1a8HWy+L1i+qJkP9ceeqlaDeEQjWBmeiJNpQcdKUKvV0oz WOkvOWAbMKFkCFXhAsdiVfXYE9MR+sTWMKFjdGGccNIsEUrRlnl3JIgOZ8OYYWE18p+H 0LLw== X-Gm-Message-State: AKS2vOz0j/XL4oFV1ahbvWpVWbsGg/dl2nyofaM0e9/bEhPp3XExwNn2 ZJuKRGHB/pmIwHaSGc2kX4Cg6gFoHyguuHE= X-Received: by 10.99.121.1 with SMTP id u1mr14716563pgc.20.1498080151837; Wed, 21 Jun 2017 14:22:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Wed, 21 Jun 2017 14:22:31 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 21 Jun 2017 14:22:31 -0700 Message-ID: Subject: Re: Second Implementation Draft Guidelines To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0ef2604c1a9705527ef761" 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, 21 Jun 2017 21:22:34 -0000 --94eb2c0ef2604c1a9705527ef761 Content-Type: text/plain; charset="UTF-8" This is a great start, thanks for getting it going. Just one thought: You may want to explicitly "include" fixed-time RTO-recovery. It appears right now as a side note in what's not included. On Wed, Jun 21, 2017 at 2:11 PM, Martin Duke wrote: > All, > > As promised, I've created a set of guidelines for what should be in the > Second Implementation draft. If deadlines hold, I believe we will actually > start implementing this draft after Seattle in October. > > Once we've reached reasonable consensus, this should serve as a basis for > prioritizing issues to resolve through Seattle. > > The current version is very much a starting point for discussion. I've > presented some items I think are important to include, and others that we > could bring in depending on our appetite for work. The final version will > simply have "Must Include" and "should not include". > > > https://github.com/quicwg/base-drafts/wiki/Second-Implementation-Draft > > I look forward to your comments. > > Martin > --94eb2c0ef2604c1a9705527ef761 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a great start, thanks for getting it going.
Ju= st one thought: You may want to explicitly "include" fixed-time R= TO-recovery. It appears right now as a side note in what's not included= .

= On Wed, Jun 21, 2017 at 2:11 PM, Martin Duke <martin.h.duke@gmail.c= om> wrote:
All,

As promised, I've created a set of guidelines = for what should be in the Second Implementation draft. If deadlines hold, I= believe we will actually start implementing this draft after Seattle in Oc= tober.

Once we've reached reasonable consensus= , this should serve as a basis for prioritizing issues to resolve through S= eattle.

The current version is very much a startin= g point for discussion. I've presented some items I think are important= to include, and others that we could bring in depending on our appetite fo= r work. The final version will simply have "Must Include" and &qu= ot;should not include".

https://github= .com/quicwg/base-drafts/wiki/Second-Implementation-Draft
<= /div>

I look forward to your comments.

Martin
=

--94eb2c0ef2604c1a9705527ef761-- From nobody Wed Jun 21 16:48: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 531771200CF for ; Wed, 21 Jun 2017 16:48:11 -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 98o-OJ6brOX0 for ; Wed, 21 Jun 2017 16:48:08 -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 4343B12426E for ; Wed, 21 Jun 2017 16:48:08 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id f127so367868pgc.0 for ; Wed, 21 Jun 2017 16:48: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=ySgRHAVhCxfTMsjnto1OIcgq7Yr2QnZ0ARB/W50hml8=; b=g6aDhCkfO98GilzX2ra2eO89DQAehomn0lUiOvJVKHpEOsNann3K5ZiVnZdps/10ta Nk8gTef2T4ymZf87BNBcn+OMFPVEdqpsqdZQVva6TNApBJ/+KGFTPeHetWFCWwJTZWVX UUMty7NXTgpX7u8z2wh+4WyM6y3CsCiP8J9/BCSQJ5sCimrCunBPSYMuG5a9Lish0w2d pqn86ZC9HBHjPH6AkxDho+fQ4XsO3JxpDIFr49IN55acORmGh426SE0VWcfbVHnKDyAs D8fMSevuugmLWdM1s+mVTt3tInr4Y7typFYavro7L29EBoimyOm+KXMiirnjfwHlyljh hCrA== 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=ySgRHAVhCxfTMsjnto1OIcgq7Yr2QnZ0ARB/W50hml8=; b=LpezSQV1PiIGB5HeI8k78mdSzYPg8LSOl9Ktrt8RfO44GnzkLXH10RdDrcDRpLWsNB TfjVQ2dyh6c69pOGD0yHe5nxX/AdETl9LjiaCElnSgyX/QqhyZMUn676xmvqEEyYEO9g 27TaZVZFKp4j2LkTmOvmUnhayGvmJ0jN2C/Gl1zfc+Ic1fMkbk7x3tuNqCKamgCnvCeU D1+vCR7EQCjCgnyyQwssK+l3x5AJHTKQMuC+FesEoMwCGHglFdCClLFFEimKshfADyFP 4rCrpviEUn1DV/NPz4l45pxu5cEhHzDKkvZ3spb/g5CSUSpcB7gyf3lbSis238BOo1Ev KAGw== X-Gm-Message-State: AKS2vOy/oMLMfNFi1w2WletOhh/PFPI5ClB462Vj7v1rwlSU1UD+TeqV gqtwLhFOYzZ48kBW8rRPMLCVBE8SJDgb X-Received: by 10.99.122.13 with SMTP id v13mr27963740pgc.156.1498088887565; Wed, 21 Jun 2017 16:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Wed, 21 Jun 2017 16:48:07 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 21 Jun 2017 16:48:07 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Patrick McManus Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="f403045c60fafcdf25055280ffb2" 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, 21 Jun 2017 23:48:11 -0000 --f403045c60fafcdf25055280ffb2 Content-Type: text/plain; charset="UTF-8" Thanks for writing up the PR, Martin. It does help to see the details laid down. I have a few thoughts. First, there are issues that unidirectional streams raises, some of which we can articulate, and some which we don't know yet simply because we have no production experience with them. In the former category, here's an issue that isn't handled right now. Google maps uses map-tiles for displaying parts of mapped region. As a user moves to a different region, the client cancels all pending requests, since those map-tiles are no longer relevant and those responses are no longer needed. Let's say that the requests were completely sent (FIN and all), but the responses hadn't started yet. In the bidirectional world, a client would achieve this by sending a RST_STREAM on all streams that have responses pending, causing the server to send a RST_STREAM back. In the new world, the client would have no way of canceling a pending request until the server started responding. (And right now in your PR, I don't think there's a way for an endpoint to RST a peer-initiated stream.) Of the issues we don't know about yet, we'll only know with deployment experience. I'm wary of standardizing something where we have no deployment experience, no production experience. (Server Push is an overused but classic example of this: it was standardized before there was any significant deployment experience, and we continue to struggle with actually deploying it. Also, see HTTP/2 Priorities.) Second, your key premise is that unidirectional streams makes transport logic simpler. I agree with that, and the PR clearly simplifies the transport stream machinery. However, HTTP requires bidirectional streams, and this PR moves that complexity to HTTP. This is useful if HTTP were the only application that did request-response, but request-response is an incredibly common design pattern, and one that is naturally facilitated by bidirectional streams. Making every application reimplement bidirectional streams atop QUIC's unidirectional streams *adds* complexity overall. My design sense says to optimize for the common case and to allow for the exceptions. Given that our scope is to really get things rolling for HTTP ASAP, I'd argue that request-response is the common case that we need to optimize for. This PR makes it even clearer to me that we need deployment experience with unidirectional streams before going down this path. We have that with bidirectional streams, which makes it worth standardizing. To be clear, I'm not saying that unidirectional streams aren't interesting. FWIW, the original input draft , which is still how GQUIC works right now, has app read_close and write_close transitions in the stream state machine which would allow a stream to become unidirectional, but the application endpoints have to know that these streams are unidirectional. We can explicitly specify a separate bit in the STREAM frame that indicates uni/bi-directional stream, allowing for unidirectional streams as "always half-closed" (bidirectional) streams. Implementations can obviously optimize code for uni streams separately, but the spec would be straightforward. I'm happy to write this up as an alternative, since I think this is valuable. - jana On Wed, Jun 21, 2017 at 2:48 AM, Patrick McManus wrote: > I have come to strongly support unidirectional streams. I'm writing > because I think we can take this just a tiny bit further and get a pretty > big architectural win. > > the PR adds a stream-header to the http mapping.. a key feature of that is > a few bytes indicating what stream # a reply (or a push, etc..) is > associated with because its not implicit in the stream # anymore. I love > the removal of some transport IDs from the HTTP mapping. > > If we take that just a touch further and include this label explicitly in > the request as well then there is no reason to require the use of transport > stream ids for the labeling at all (though you could!) - and now you can > imagine quic http being implemented on a quic transport api that looks a > lot like existing transport apis without having to resort to inventing > something like quic_getpeerstreamid(). > > Relatedly the mapping defines a very short stream header to identify the > control channel so I don't think there is any reason to lock it onto > stream 1 (and let the transport-id leak into the application mapping in the > process). Its not like putting it on stream 1 guarantees it will arrive > first anyhow. > > -Patrick > > > On Wed, Jun 21, 2017 at 8:41 AM, Martin Thomson > wrote: > >> I've created a pull request unidirectional streams. >> >> https://github.com/quicwg/base-drafts/pull/643 >> >> 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. >> >> > --f403045c60fafcdf25055280ffb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for writing up the PR, Martin. It does help to= see the details laid down. I have a few thoughts.

First, there are issues that unidirectional streams raises, some of which = we can articulate, and some which we don't know yet simply because we h= ave no production experience with them.

In the for= mer category, here's an issue that isn't handled right now. Google = maps uses map-tiles for displaying parts of mapped region. As a user moves = to a different region, the client cancels all pending requests, since those= map-tiles are no longer relevant and those responses are no longer needed.= Let's say that the requests were completely sent (FIN and all), but th= e responses hadn't started yet. In the bidirectional world, a client wo= uld achieve this by sending a RST_STREAM on all streams that have responses= pending, causing the server to send a RST_STREAM back. In the new world, t= he client would have no way of canceling a pending request until the server= started responding. (And right now in your PR, I don't think there'= ;s a way for an endpoint to RST a peer-initiated stream.)

Of the issues we don't know about yet, we'll only know with= deployment experience. I'm wary of standardizing something where we ha= ve no deployment experience, no production experience. (Server Push is an o= verused but classic example of this: it was standardized before there was a= ny significant deployment experience, and we continue to struggle with actu= ally deploying it. Also, see HTTP/2 Priorities.)

S= econd, your key premise is that unidirectional streams makes transport logi= c simpler. I agree with that, and the PR clearly simplifies the transport s= tream machinery. However, HTTP requires bidirectional streams, and this PR = moves that complexity to HTTP. This is useful if HTTP were the only applica= tion that did request-response, but request-response is an incredibly commo= n design pattern, and one that is naturally facilitated by bidirectional st= reams. Making every application reimplement bidirectional streams atop QUIC= 's unidirectional streams *adds* complexity overall. My design sense sa= ys to optimize for the common case and to allow for the exceptions. Given t= hat our scope is to really get things rolling for HTTP ASAP, I'd argue = that request-response is the common case that we need to optimize for.

This PR makes it even clearer to= me that we need deployment experience with unidirectional streams before g= oing down this path. We have that with bidirectional streams, which makes i= t worth standardizing.

To be clear, I'm not saying that unidirectional st= reams aren't interesting. FWIW, the original input draft= , which is still how GQUIC works right now, has app read_close and writ= e_close transitions in the stream state machine which would allow a stream = to become unidirectional, but the application endpoints have to know that t= hese streams are unidirectional. We can explicitly specify a separate bit i= n the STREAM frame that indicates uni/bi-directional stream, allowing for u= nidirectional streams as "always half-closed" (bidirectional) str= eams. Implementations can obviously optimize code for uni streams separatel= y, but the spec would be straightforward. I'm happy to write this up as= an alternative, since I think this is valuable.

- jana



On Wed, Jun 21, 2017 at 2:48 AM, Patri= ck McManus <pmcmanus@mozilla.com> wrote:
I have come to s= trongly support unidirectional streams. I'm writing because I think we = can take this just a tiny bit further and get a pretty big architectural wi= n.

the PR adds a stream-header to the http mapping= .. a key feature of that is a few bytes indicating what stream # a reply (o= r a push, etc..) is associated with because its not implicit in the stream = # anymore. I love the removal of some transport IDs from the HTTP mapping.<= br>

If we take that just a touch further and inclu= de this label explicitly in the request as well then there is no reason to = require the use of transport stream ids=C2=A0 for the labeling at all (thou= gh you could!) - and now you can imagine quic http being implemented on a q= uic transport api that looks a lot like existing transport apis without hav= ing to resort to inventing something like quic_getpeerstreamid().

Relatedly the mapping defines a very short stream header to= identify the control channel=C2=A0 so I don't think there is any reaso= n to lock it onto stream 1 (and let the transport-id leak into the applicat= ion mapping in the process). Its not like putting it on stream 1 guarantees= it will arrive first anyhow.

-Patrick


On Wed, Jun 21, 2017 at 8:4= 1 AM, Martin Thomson <martin.thomson@gmail.com> wrote= :
I've created a p= ull request unidirectional streams.

https://github.com/quicwg/base-drafts/pull/643

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.=C2=A0 Each has three states: idle, open, and closed.=C2=A0 I separated the transitions for sending and receiving because=
that turned out to be easier to explain.=C2=A0 The reordering thing makes them different in subtle ways.

That's all.=C2=A0 The changes in transport are relatively small and the= y
simplify streams a lot.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 First, request and response correlation can't use forwar= d
references because that would mean the client would be exerting
(uncoordinated) control over server streams.=C2=A0 Second, that gives the server the most flexibility in terms of how it answers requests (see
#281).=C2=A0 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.=C2=A0 This empty frame
indicates that another stream will include the body of the message -
or a promise for a body.=C2=A0 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.=C2=A0 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<= br> create a way to cancel them between the time that the PUSH_PROMISE is
sent and when the push stream is created.=C2=A0 That's called RST_PUSH.=

## Things That Need Improvement

I haven't based this on #171.=C2=A0 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.=C2=A0 (That's a taste thing.)=C2=A0 This really assume= s that we
accept something very much like #171.

This really needs QPACK/QCRAM.=C2=A0 Right now, it is impossible to cancel<= br> some types of request using RST_STREAM because not all messages will
have a body (#176 again).=C2=A0 On balance, given that bodies are what you<= br> really want to kill, it's not disastrous, but it's a problem
nonetheless.=C2=A0 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 .=C2=A0 It
doesn't exactly need that, but merging the streams would make things a<= br> lot easy, both conceptually and structurally.

I chose the simplest possible encoding for all of the fields that I
touched.=C2=A0 That means that stream IDs are all 32 bits in size and the HAS_BODY frame takes an entire 9 octets.=C2=A0 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.=C2=A0 Use of an as-yet-not-created push ID as a node in the priority tree would allow
for prioritization to use "empty" nodes.=C2=A0 We'd need to e= xplicitly
allow that though.

# Fixes

Closes #515, #240, #281, #175.



--f403045c60fafcdf25055280ffb2-- From nobody Wed Jun 21 17:02: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 A82F3128B37 for ; Wed, 21 Jun 2017 17:02:15 -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 yCxN33W4EOzU for ; Wed, 21 Jun 2017 17:02:13 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 E072812426E for ; Wed, 21 Jun 2017 17:02:10 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id h22so389025lfk.3 for ; Wed, 21 Jun 2017 17:02:10 -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=cAJK1yuKH6hkAQRQq1/QLHmAZ4GckAP2nce9x5Hm8zc=; b=bQPrSpFYbwOYnKPCxxvJ5Fzntt0SmVbx2wv9WhDaDr/NLhsRvEhIxrrTUbQWM0Z/zi qHUaw+uBQVoiB36x2pvcODdthGgYUeuWd6/yYM9r8Rxe6hm+QKWHXcayTGLEX9ar+ja7 aF4+cbxhQFGR4PAPcVxUTWFQ5Q0DSsMgtJJ48CqKMinrnVxCEvl5hlua3N467/gSOBMv WKsqwvdF3ZeoApuySXGTDkqb63tNwfOnMLePZmfoWq8zinTilDuBysibcwDxuB2Tx57k Sy2pO1+r7weCi7DgScmOowTxdSL81HOGEBWyt3TAoMRvHu5FHTSJoheFIsTxUEy1P7cy 0x8A== 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=cAJK1yuKH6hkAQRQq1/QLHmAZ4GckAP2nce9x5Hm8zc=; b=mnyjBpMcZJ1cBETejCcz2Q3RCiXAWh2yaUVIV4RzKPClBDYv2CHBw5IWbhQ2Pa1ljo cVxVqhEPNuoITcewg1WRBRwKaIjY1qsB/C3SWqjJSEoEf0GqV18PRUacYcZRYREAWH52 qElovDbt3EUZFvYqkJrDnALtOymDFWS1aPlssXjC61wswlXjBMj05S4Yo6osn/ckIEtm nRaHjQZFooYKhHjKSsXFLp+/IAqHXH+/XPdNHL791fMIn6s0fWjYfpxrOY1Ca2/3KSmA PtGeGCj8dXPJRSQXHcYFhDRECXINGUIRrW9E00TuNfwWX+4Jc1s7N+ClUU10THXOi5Mj 06iA== X-Gm-Message-State: AKS2vOyJhvoAZUdxi5bkbZD7lKgvVAWO5F/G2VzJUhwFqglBRlTcMjBr 5nn+2h80n0FH3WVHBJeR397nVeQzPw== X-Received: by 10.46.84.28 with SMTP id i28mr10829125ljb.44.1498089729198; Wed, 21 Jun 2017 17:02:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Wed, 21 Jun 2017 17:02:08 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 22 Jun 2017 10:02:08 +1000 Message-ID: Subject: Re: Unidirectional streams PR To: Jana Iyengar Cc: Patrick McManus , 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, 22 Jun 2017 00:02:16 -0000 On 22 June 2017 at 09:48, Jana Iyengar wrote: > (And right now in your PR, I don't think there's a way for an endpoint to > RST a peer-initiated stream.) Yes, that's clearly an oversight. It's trivial to fix; I'll make the necessary changes for that. From nobody Wed Jun 21 17:08:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A746B126FB3 for ; Wed, 21 Jun 2017 17:08:04 -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 1YT_UfraGAPq for ; Wed, 21 Jun 2017 17:08:02 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 C38BC126D74 for ; Wed, 21 Jun 2017 17:08:02 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c73so572542pfk.2 for ; Wed, 21 Jun 2017 17:08:02 -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=leM/MXCu15ueRZ6gv8MF/H7OOVX5VbokBCwWAFkcXXg=; b=k934USTLQ1o9GnufOp/EzYYDZGUNtQ7CrqMNmM1Dy5zHbDuZde+G9q4nMlk76f0nxJ /GS8UFzM6x8WhnfIr0Jq55KPVZJ8oOfDZ15iuM6oLWnu0ovHdGcGVbczqCzyKzFWYkNF MSrc2Izatb3hNlLPzjNd93IN2WCXsbItoQYAfL28WVccIcjFjOd+oB/fk/h+cQM1cgj9 N/HJoG4KS+BFuVBh+4Qu7Nm6i6EMRCiJEmNCuo8AqoEixK6MLFvdz62qtxNDEipjylNK soTkVbDbDRLGS+ll/RqsCNReZBwtJwUnkPaA+Ir7kJwFczRzc8MaaAOVBSE0udXPgLLS wJ3w== 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=leM/MXCu15ueRZ6gv8MF/H7OOVX5VbokBCwWAFkcXXg=; b=oGfj0WI/1zQTkfYtMVYAYdW40ZiFN+l0VKZaW2LS+AC62nqLzgfWXS6vzJ+Hnn5I3L g1+whBtbReCY+f0ss1HX6if9M+83nfzN5L9SRwv9N4TLnOtoOBIJdi9n1txEppGI5k0T 1fZ8hhOpJD/BgqyNawGyi4jWu+/N7xyyqRHbK0iL6AZ3aPi8xT2MPWQkE/DMbRcp4DBT GAtOQVdmWPHDXxyjUP9zjSYJg9+EEojO8NYOUpOgGFfFFUIUF7AYw3Ro3YFnwwnvOHXK NrpXxEa5CyPQeQ7c0tCpex+2rc2aT75qHIkZzrLsp3s1ZPgkzySZlGT9WkF5HmeBfWvs ZSJg== X-Gm-Message-State: AKS2vOz5Zvaw/oH0JwgE6VWU1AuiddO/BrPLyrKjmowOI6AnAp24wFlO nPJXX9XxaNSmxuJyokzdW8SIbiYkjTD2 X-Received: by 10.84.175.67 with SMTP id s61mr45449261plb.151.1498090082243; Wed, 21 Jun 2017 17:08:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Wed, 21 Jun 2017 17:08:01 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 21 Jun 2017 17:08:01 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson Cc: Patrick McManus , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c11a6d83217a505528147e3" 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, 22 Jun 2017 00:08:04 -0000 --94eb2c11a6d83217a505528147e3 Content-Type: text/plain; charset="UTF-8" (Adding a link to previous discussion on unidirectional streams: Issue #175 ) On Wed, Jun 21, 2017 at 5:02 PM, Martin Thomson wrote: > On 22 June 2017 at 09:48, Jana Iyengar wrote: > > (And right now in your PR, I don't think there's a way for an endpoint to > > RST a peer-initiated stream.) > > Yes, that's clearly an oversight. It's trivial to fix; I'll make the > necessary changes for that. > --94eb2c11a6d83217a505528147e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On = Wed, Jun 21, 2017 at 5:02 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 22 June 2017 at 09:48, Jana Iyengar <jri@google.com> wrote:
> (And right now in your PR, I don't think there's a way for an = endpoint to
> RST a peer-initiated stream.)

Yes, that's clearly an oversight.=C2=A0 It's trivial to fix;= I'll make the
necessary changes for that.

--94eb2c11a6d83217a505528147e3-- From nobody Wed Jun 21 18:27: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 86A05129329 for ; Wed, 21 Jun 2017 18:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nCO2/pDw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MbDWqe67 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy4JWNJAR48P for ; Wed, 21 Jun 2017 18:26:59 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458FC120721 for ; Wed, 21 Jun 2017 18:26:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 91C38C01; Wed, 21 Jun 2017 21:26:58 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 21 Jun 2017 21:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=mu1T765jec26tgZ0rd GbDr58rHIX/6Y2+Iyzrbd44Rk=; b=nCO2/pDwUVjof3RG60G5vCgxELoL/H4/iH 82ArOIIkX3ZZHHlp5qIuyX7akjd8gw63kNwhDzMKaBMtynPXLneWGFTIoPsUn/n7 FNfX7MYV/Yq18GbgPUlbbmo6yckYM89hs0GV89/xuuG6xfH9dt/NppWggGAro69D PnLaGYfkBGr38zIkkzJizU4FR6dLDeOn1X8SNarGiWxQWiLndgnfPYb81qlYDxDE si/nyCzATQ2zNoY1PEMy+q+DP1IWDmihfHZbTqrBbPNHK2ua7dTO03cKlbAuwgPz ZlnIe+UlLN6IL2kgKE0eQWkLv5LyY7LqD9OlnfCj3YgwGmMh883w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=mu1T765jec26tgZ0rdGbDr58rHIX/6Y2+Iyzrbd44Rk=; b=MbDWqe67 cpwNGw7otgAX9z9d7mDMvsFVStgffm2Ixwkz68H4vBvlIOP49J91EIA5bfr04JjK TmM7XAb2GfwZPi2oSss/zwzWOonThztDrEHTLQLKsC/jDYoWoB4pqMGipiOgBouU Pb0fy9LUQ8I6bdFyDo7Acxk7bMz69hWSwXsKxZBveYfM1/dUS1FQIEZ/EIVXKVhM YTAPNwd7F0J8slC4BYvhv/iOH9izLn436pt6w1ct/JUp2DHKtzRg9dHqEWRZHvag M8VKaJWW/j+M7mvA4a7JyAQWasdvyFvwQQmAN7D6He1mtN0dJzA8wZNfyGFiszHY +mHhbCG6KszUiA== X-ME-Sender: X-Sasl-enc: gqVtGRL8Nt9Pf4b1Oh1gtSKW85lQ4JR0ELvr2zE1YB+M 1498094817 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 D90A1245EF; Wed, 21 Jun 2017 21:26:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Unidirectional streams PR From: Mark Nottingham In-Reply-To: Date: Thu, 22 Jun 2017 11:26:53 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <20CE4E18-368A-4376-8812-8AA1010C0C51@mnot.net> References: To: QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:27:02 -0000 [ co-chair hat on ] Everyone -- To add some context -- this is (obviously) a big change, so we've asked = Martin to prioritise it so that people can give it due consideration = early in the process, before people start implementing streams broadly. As our charter says, "consensus is required both for changes to the = current protocol mechanisms and retention of current mechanisms. In = particular, because something is in the initial document set does not = imply that there is consensus around the feature or around how it is = specified."=20 To get to that consensus in *either* direction, we need broad input on = this, so please have a look through and express your support, concerns, = etc. on-list.=20 I'd like to see a substantial amount of on-list discussion before = Prague, so that we can make a decision in that time frame. Cheers, > On 21 Jun 2017, at 5:41 pm, Martin Thomson = wrote: >=20 > I've created a pull request unidirectional streams. >=20 > https://github.com/quicwg/base-drafts/pull/643 >=20 > 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. >=20 > ## Transport Changes >=20 > 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. >=20 > 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. >=20 > ## HTTP Changes >=20 > This is where the bulk of the changes are. >=20 > ### Stream Correlation >=20 > 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. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > ### Prioritization >=20 > 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). >=20 > ### Cancelling Pushes >=20 > 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. >=20 > ## Things That Need Improvement >=20 > 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. >=20 > 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. >=20 > ## Things That Want Improvement >=20 > 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. >=20 > 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. >=20 > 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. >=20 > # Fixes >=20 > Closes #515, #240, #281, #175. >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jun 21 18:50: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 9C978129449 for ; Wed, 21 Jun 2017 18:50:14 -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 IHIUfnihTzev for ; Wed, 21 Jun 2017 18:50:12 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 57CBE12940F for ; Wed, 21 Jun 2017 18:50:12 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id p189so1185851lfe.2 for ; Wed, 21 Jun 2017 18:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xu1IENbZLkMuR2pRxK6gAYZBvQUKcy1kVW82Rp166ao=; b=KmMZaqZyAk8D1elLO1TOyA69zxpWTcu++KVot7sEmXMdT7jBLbxEAFib3GQnvGebee 5R82FwPTJH2yJ283gvr8OC0j+AX85bwN02lA2TqiJSo92AawuSzq9V9ltcbkwEPFjtCI DWSNLDZKCdJ36+GSkTluFIz9+tCTAAcFEp6PcF6xtulT2zcp+AVsrJIvBLWUOR97+zXi HW1vbV04HB4CEPP6V9nneXVTsGUqiHKKQqdZ1VjTj4gDZmh0uQ7ROQDFbL8FWwgX3Qr8 yEIAIzJTKWkMNYlPAi8FhDlkuDPLG5Osh5EhdApCTySMEfpU3vzA0R7Wf3qN6stZC4wr I/YA== 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=Xu1IENbZLkMuR2pRxK6gAYZBvQUKcy1kVW82Rp166ao=; b=Rzrw9lMyHTjqfjSkox4yXsCi+cyNIQRaQxw2obIqoHg2hTNLjlUSbt0VrSIZVvYCs0 pfHbOlzt5q7mwsCraCu6MydsZz7NHGD5epyjRxxv6X2v3bQhvu/JNfTcbsgjoBurrcsb 8fFqmXzQiAa3s6Pxt6jJF/HCEwlwSl9XKDhdMGMgG0v0RDqizbry8Z8EPq5S26Oe/GgW rmu/y0Kj9N+GRK7KjMl6qRC6I4osmItp92ja5IewDLtzJCXTESRNMh7IQQetLb0XpCLH yKGM8cVGQ9BnXTOa5wlF8dlKXnT+ifPqTIbS1BxJB8pVRNxtfAIe/zhM3K0FamwHMvDb xKyA== X-Gm-Message-State: AKS2vOyAVUZX+I9gwRwe4FjbBjhYEe8iXVo2BAFfqc/mqqHViRW2y4zG nu0marEL0IBYTuRLjaMMNkivnY1j7PqbNEM= X-Received: by 10.46.84.28 with SMTP id i28mr39513ljb.44.1498096210583; Wed, 21 Jun 2017 18:50:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Wed, 21 Jun 2017 18:50:09 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 22 Jun 2017 11:50:09 +1000 Message-ID: Subject: Re: Unidirectional streams PR To: Jana Iyengar Cc: Patrick McManus , 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, 22 Jun 2017 01:50:15 -0000 On 22 June 2017 at 09:48, Jana Iyengar wrote: > My design sense says to optimize for the common case and to allow for the > exceptions. Given that our scope is to really get things rolling for HTTP > ASAP, I'd argue that request-response is the common case that we need to > optimize for. I think that this is a fair criticism, and I wanted to address it. My concern is exactly the same as yours: I want get HTTP working. And unfortunately, HTTP/2 is not a simple request/response protocol. This is why HTTP/2 and now QUIC allow the server to initiate streams. And it's that exact gap that motivated me to propose this change. In my view, this change makes it *easier* to finish HTTP over QUIC. The cost is that HTTP is marginally more complex. My view is that the overall protocol (HTTP+QUIC) is no more or less complex than before, there are big savings in transport, and some minor savings in HTTP that counteract the added cost: having to include explicit correlation for request and response, and having to add a way to cancel requests before the response starts. [1] In terms of generality, we've already heard from Christian that this is basically neutral for DNS, possibly with a tiny reduction in complexity related to not having to check that redundant identifiers in a response are consistent. Ted suggested that we aim for a design that supports BOTH unidirectional and bidirectional. Given how trivial it is to add an identifier - as demonstrated by this PR - I don't see how building that facility into the base transport is a net win. Some protocols can still use the stream identifiers as a correlator, for instance those protocols that are properly request/response don't need explicit correlators. That choice - as with your proposal to retain bidirectionality - creates a potential for head-of-line blocking under certain circumstances, something that an explicit correlator at the application layer neatly avoids. [1] I don't consider HAS_BODY to be a cost, I'm now firmly of the opinion that merging headers and body back into a single stream is the right solution and that what I wrote up here is only temporary. From nobody Wed Jun 21 19:18:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9719F120046 for ; Wed, 21 Jun 2017 19:18:21 -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 IZ2JOIg0gZcw for ; Wed, 21 Jun 2017 19:18:19 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7AE129463 for ; Wed, 21 Jun 2017 19:18:19 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id 132so1697868pgb.2 for ; Wed, 21 Jun 2017 19:18:19 -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=nT/FiF+hAijHsvmDK9j4puzRI3vMD4cNZ+FKod+Zeu8=; b=RsP+DEibeeyEyx07fM7y8sdBmVAjjDS7U17jQL89CNvnDcoswI9yaoElQ6tY+kHus3 Bi70Lu3Xf5x1EY8l0Q2Rwzh7qgkF28q6FHJykgs0QrnDMKhU91e7RnmjKMMBF4gH/g2n SNsNYzdblRGf0QvUhbkhNtn455xgL0TWDH9RuKR0zoR3VspR8hu0+snGExDeOt9hpiDi AaQdhH+E3lGbG8qrkJVwOBwyNS+6eSrNf1vq3/1/GbJJgzxIRp0qsPPrYTYlpzU60gdP pFrU/AK80TsNCwr+60YRhZsipfeBbMacMsuORavSQJ5cxOLR4RzV2NuEwnURjr9tljRf bIjg== 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=nT/FiF+hAijHsvmDK9j4puzRI3vMD4cNZ+FKod+Zeu8=; b=bdWcd8ISPYEmln99E5aY1N4bWQV3CuPIu2mlK9p5aumy0Gbni8MrWIRqAD5rh77IHg OOgYUfD8j3BoKngKPpnuUKElUPFfZCvphR69YfQRXWVO0pNrB2pE/XBVHvbTvwKYBdQe NurV5ERzJwhwe7tDi8+hBLvVkf6HkAJM5T1jqySNU6Tv3/ODakIhVvK+kf5dsSKRwsfH QqEmA1DhmpJHZZ/2fe9Bcr7MSZ9o2nASxeOKptGpX1sJrpV6OQilXmjpXy3HTMVVTQEk i7cOfPs+/M7sZcX/wWaG6WwIZjhNsySpHrn0hiNk0/GFG7jJXtTyKZdbRz0C8GV0RVit Xvcg== X-Gm-Message-State: AKS2vOw1O8IgSIiGDm9YbPaSsRzNEqT06XXDyjDq4tAmqDrr10lsN6gg AgyRu94py/OS0OaD0+mM5qI29M3TsYDl X-Received: by 10.84.217.137 with SMTP id p9mr300153pli.80.1498097898293; Wed, 21 Jun 2017 19:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Wed, 21 Jun 2017 19:18:17 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 21 Jun 2017 19:18:17 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson Cc: Patrick McManus , QUIC WG Content-Type: multipart/alternative; boundary="f403045c6f8211621605528319db" 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, 22 Jun 2017 02:18:21 -0000 --f403045c6f8211621605528319db Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 6:50 PM, Martin Thomson wrote: > On 22 June 2017 at 09:48, Jana Iyengar wrote: > > My design sense says to optimize for the common case and to allow for the > > exceptions. Given that our scope is to really get things rolling for HTTP > > ASAP, I'd argue that request-response is the common case that we need to > > optimize for. > > I think that this is a fair criticism, and I wanted to address it. > I'd like to hear your thoughts on the rest of it too (I think all my points are fair :-)) My concern is exactly the same as yours: I want get HTTP working. And > unfortunately, HTTP/2 is not a simple request/response protocol. This > is why HTTP/2 and now QUIC allow the server to initiate streams. And > it's that exact gap that motivated me to propose this change. In my > view, this change makes it *easier* to finish HTTP over QUIC. > > The cost is that HTTP is marginally more complex. My view is that the > overall protocol (HTTP+QUIC) is no more or less complex than before, > there are big savings in transport, and some minor savings in HTTP > that counteract the added cost: having to include explicit correlation > for request and response, and having to add a way to cancel requests > before the response starts. [1] Supporting bidirectional streams is either complex or not: it doesn't matter where you support it. If the complexity reduction is substantive in transport, it can't be that the complexity increase in HTTP is marginal. Your motivation is exactly my concern -- Server Push is a part of HTTP/2 for sure, but it is by no means the common case. Even though Server Push is a part of the design, request-response dominates usage in HTTP/2. We need to accomodate Server Push and make it work, which, as I suggested in my earlier email, was supported in the early input draft (and in GQUIC). The application can "half close" streams that are known to be unidirectional (app read_close, app write_close). These transitions were then removed during revisions as extraneous, since they were local to an endpoint, but it seems that the core idea was lost as well. In the case of HTTP/2, since server-initiated streams are always unidirectional (Push), the application (HTTP) would always half-close them at both endpoints, not requiring any special signaling on the wire. If we want to make this more general, we could have a single "uni/bi-directional" bit in every stream frame, so that we would not require application knowledge of which streams are expected to be uni/bi-directional. In terms of generality, we've already heard from Christian that this > is basically neutral for DNS, possibly with a tiny reduction in > complexity related to not having to check that redundant identifiers > in a response are consistent. > > Ted suggested that we aim for a design that supports BOTH > unidirectional and bidirectional. Given how trivial it is to add an > identifier - as demonstrated by this PR - I don't see how building > that facility into the base transport is a net win. Some protocols > can still use the stream identifiers as a correlator, for instance > those protocols that are properly request/response don't need explicit > correlators. That choice - as with your proposal to retain > bidirectionality - creates a potential for head-of-line blocking under > certain circumstances, something that an explicit correlator at the > application layer neatly avoids. > Creating a new identifier in every application to correlate request/response pairs adds complexity when you start adding applications. Every app has to now explicitly design and implement this incredibly common design pattern. Building common design patterns into the transport _is_ the role of the transport. Otherwise, we could be building HTTP directly over UDP, with no QUIC in the middle. The correlator is a feature, and one that is required even in your design (although you have it in HTTP). I don't see how it introduces HoL blocking, but I don't want to rathole on a minor point. I've made other points as well in my email which I think are important. [1] I don't consider HAS_BODY to be a cost, I'm now firmly of the > opinion that merging headers and body back into a single stream is the > right solution and that what I wrote up here is only temporary. > --f403045c6f8211621605528319db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 21, 2017 at 6:50 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 22 June 201= 7 at 09:48, Jana Iyengar <jri@google.c= om> wrote:
> My design sense says to optimize for the= common case and to allow for the
> exceptions. Given that our scope is to really get things rolling for H= TTP
> ASAP, I'd argue that request-response is the common case that we n= eed to
> optimize for.

I think that this is a fair criticism, and I wanted to address it.

I'd like to hear your thoughts on th= e rest of it too (I think all my points are fair :-))

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> My concern is exactly the same as yours: I want get HTTP working.=C2=A0 And=
unfortunately, HTTP/2 is not a simple request/response protocol.=C2=A0 This=
is why HTTP/2 and now QUIC allow the server to initiate streams.=C2=A0 And<= br> it's that exact gap that motivated me to propose this change.=C2=A0 In = my
view, this change makes it *easier* to finish HTTP over QUIC.

The cost is that HTTP is marginally more complex.=C2=A0 My view is that the=
overall protocol (HTTP+QUIC) is no more or less complex than before,
there are big savings in transport, and some minor savings in HTTP
that counteract the added cost: having to include explicit correlation
for request and response, and having to add a way to cancel requests
before the response starts. [1]

Supporting = bidirectional streams is either complex or not: it doesn't matter where= you support it. If the complexity reduction is substantive in transport, i= t can't be that the complexity increase in HTTP is marginal. Your motiv= ation is exactly my concern -- Server Push is a part of HTTP/2 for sure, bu= t it is by no means the common case. Even though Server Push is a part of t= he design, request-response dominates usage in HTTP/2.

=
We need to accomodate Server Push and make it work, which, as I sugges= ted in my earlier email, was supported in the early input draft (and in GQU= IC). The application can "half close" streams that are known to b= e unidirectional (app read_close, app write_close). These transitions were = then removed during revisions as extraneous, since they were local to an en= dpoint, but it seems that the core idea was lost as well. In the case of HT= TP/2, since server-initiated streams are always unidirectional (Push), the = application (HTTP) would always half-close them at both endpoints, not requ= iring any special signaling on the wire.

If we wan= t to make this more general, we could have a single "uni/bi-directiona= l" bit in every stream frame, so that we would not require application= knowledge of which streams are expected to be uni/bi-directional.

In terms of generality, we've already heard from Christian that this is basically neutral for DNS, possibly with a tiny reduction in
complexity related to not having to check that redundant identifiers
in a response are consistent.

Ted suggested that we aim for a design that supports BOTH
unidirectional and bidirectional. Given how trivial it is to add an
identifier - as demonstrated by this PR - I don't see how building
that facility into the base transport is a net win.=C2=A0 Some protocols can still use the stream identifiers as a correlator, for instance
those protocols that are properly request/response don't need explicit<= br> correlators.=C2=A0 That choice - as with your proposal to retain
bidirectionality - creates a potential for head-of-line blocking under
certain circumstances, something that an explicit correlator at the
application layer neatly avoids.

Creati= ng a new identifier in every application to correlate request/response pair= s adds complexity when you start adding applications. Every app has to now = explicitly design and implement this incredibly common design pattern. Buil= ding common design patterns into the transport _is_ the role of the transpo= rt. Otherwise, we could be building HTTP directly over UDP, with no QUIC in= the middle. The correlator is a feature, and one that is required even in = your design (although you have it in HTTP). I don't see how it introduc= es HoL blocking, but I don't want to rathole on a minor point.=C2=A0

I've made other points as well in my email which= I think are important.

[1] I don't consider HAS_BODY to be a cost, I'm now firmly of the opinion that merging headers and body back into a single stream is the
right solution and that what I wrote up here is only temporary.

--f403045c6f8211621605528319db-- From nobody Wed Jun 21 23:32: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 C49BD128E19 for ; Wed, 21 Jun 2017 23:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 qcMRZT_9YCXD for ; Wed, 21 Jun 2017 23:32:07 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0121.outbound.protection.outlook.com [104.47.38.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF85126557 for ; Wed, 21 Jun 2017 23:32:06 -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=seaEsy+3rgBOwOxIqbkKDxKNJAxkudj3XOEBmneHxLQ=; b=HwmAX/axy4V6uYwxObbHoUzQ4oZ7xVjUAy6wAJZRvApO/9tQZPhvfDBdIdM9HYrcjjJCLYqGLnkc26VlC/s7uZhGYbcQambukVa6OgVa61JeWKzB5tEOR2PWvn9ovMAWeHO3iDf3lxE3iopIbxsPC7uy1pAM2B/PBHqza4CM2Xs= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0126.namprd21.prod.outlook.com (10.173.52.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Thu, 22 Jun 2017 06:32: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.1220.005; Thu, 22 Jun 2017 06:32:04 +0000 From: Mike Bishop To: Martin Thomson , Jana Iyengar CC: QUIC WG , Patrick McManus Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHyIpxR/afFiUiHxd5TQx2M+qIvEnAAgADqdYCAACIZgIAAQhnw Date: Thu, 22 Jun 2017 06:32:04 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8080:5a28:a8c0:c6b3:d9e7:d961] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0126; 7:B1heZ/Qsjt2uNSNQzN2H2Bz3xKTDqN3k1nsXputF5FS8TK8p31MRb9QXzA12FkblZFeg+dc4eXw3xv7fbNi7tzv1JnqlrSfYQZwFVfx0J/lXFMdsBcsHILhYv/GWIQQuIenhSwPIKRioQc8sLzBzQDqH0EWdAz7YeYn5TT1vjr74ye2gJWtJXsLSsYj5oQ9MTawblnq3k1ojAtq3zdQBJztc7LIC2C5AFwtyQZ877+sS5nHhez5qlEukd1KvOfC9B97TdET2N7qwp6EamQY6ftpXU1MoX6rU3scdUtCnPP0t48BHXkBJrQV/5z/LTn5M689cFBBQV05OC+Pnkd39BK8EwekI8iF9UuDsnnTHzXeUs0gtwN1p/gOK4GVrKVKzpYXR1IcyYvyvMy5JCYd3v1esXg41ehjAYQEIWx5WsH3v5DsQO1UPweH+N/ZneH8jS3ftvr9sHMk197vn2f3Qj5N606ByRXqwMMmYvwybM4hEwBGZ1cVfVyDq7JkwHxmaIim4GzhlMMuu/VE4wrDOsSWVshX3QiChBiobi+CiQlmGHiBBJyd8LmLFjY38n6MXyv8c0lZ6Wv4adoydD3Rdid8/GLhCETTVSPWRpsBGYgLbjjiMIu5nNadsoXbmHJEtQEMW53NXKVcJX/a1YU5mzFLRSLfIsYF8khQU3If1XNCZC/88/VtLGmju+Wsl2RzXwldeHkSC+5LQ93HvGAbHQWpUL7q8qa4hNTyjsRibJm76HHwLUCdTbr/jJ6qketzsk0p6YSvA7cIlOm1Ipgr/jzYizB5Xw/2zLhGyX5+n77u1BXA1W4rs0wMdmDrh5Bzj x-ms-office365-filtering-correlation-id: e8b1a171-b3c0-402f-514d-08d4b93865c7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(48565401081)(300000503055)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:MWHPR21MB0126; x-ms-traffictypediagnostic: MWHPR21MB0126: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217); 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)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0126; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0126; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39450400003)(39860400002)(39400400002)(39850400002)(24454002)(13464003)(51444003)(377454003)(3480700004)(8676002)(76176999)(54356999)(189998001)(50986999)(77096006)(93886004)(10090500001)(3660700001)(5005710100001)(561944003)(10290500003)(33656002)(8936002)(81166006)(102836003)(8990500004)(53546010)(86362001)(2906002)(3280700002)(6116002)(4326008)(305945005)(2900100001)(86612001)(25786009)(74316002)(72206003)(53936002)(6436002)(14454004)(5660300001)(7736002)(122556002)(6506006)(6246003)(99286003)(229853002)(7116003)(7696004)(2950100002)(54906002)(478600001)(39060400002)(38730400002)(9686003)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0126; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 06:32:04.1269 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0126 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, 22 Jun 2017 06:32:10 -0000 QXMgd2UndmUgZGlzY3Vzc2VkLCBJIGhpZ2hseSBhcHByb3ZlIG1vdmluZyBpbiB0aGlzIGRpcmVj dGlvbiwgYW5kIHRoaXMgUFIgbG9va3MgbGlrZSBhIHNvbGlkIHdheSBvZiBkb2luZyBpdC4gIFJl dmlldyB3aXRoIGEgZmV3IGNvbW1lbnRzLCBidXQgbm90aGluZyBJJ2Qgc2NyZWFtIGFib3V0Lg0K DQpJJ2xsIHNlY29uZCBNYXJ0aW4ncyBvcGluaW9uIC0tIHRoaXMgZG9lc24ndCBtYWtlIEhUVFAv UVVJQyBub3RpY2VhYmx5IG1vcmUgY29tcGxleC4gIFdoYXQgaXQgZG9lcywgYW5kIHdoYXQgSSBz dXNwZWN0IGdpdmVzIHNvbWUgcGVvcGxlIGhlYXJ0YnVybiwgaXMgbWFrZSBpdCAqbGVzcyBsaWtl IEhUVFAvMiouICBUaGUgbW9yZSBjb2RlIHJldXNlIHlvdSB0aG91Z2h0IHlvdSB3ZXJlIGdvaW5n IHRvIGJlIGFibGUgdG8gZG8sIHRoZSBtb3JlIHRoaXMgbWFrZXMgeW91IHVuaGFwcHkuICBUaGlz IGFsc28gbWFrZXMgaXQgbGVzcyBsaWtlIFRDUDsgaW4gYSB3YXkgdGhhdCdzIHNpbXBsZSBmb3Ig YSBtYXBwaW5nIHRvIGRlYWwgd2l0aCwgYnV0IGl0IG1lYW5zIHRoZSBtYXBwaW5nIGFjdHVhbGx5 IG5lZWRzIHRob3VnaHQuICAoVGhhdCdzIG5vdCBlbnRpcmVseSBhIGJhZCB0aGluZy4pDQoNCkkn dmUgc2FpZCBpdCBiZWZvcmUsIGFuZCBJJ2xsIHByb2JhYmx5IGtlZXAgc2F5aW5nIGl0OiAgSFRU UC9RVUlDIGlzIG5vdCBqdXN0IEhUVFAvMiBvdmVyIFFVSUMuICBJdCdzIHNpbWlsYXIgaW4gc3Bp cml0LCBidXQgUVVJQyBpcyBmdW5kYW1lbnRhbGx5IGRpZmZlcmVudCBhbmQgSFRUUC9RVUlDIGhh cyB0byBmb2xsb3cuICBJJ20gYWxsIGZvciBjb2RlIHJldXNlIHdoZXJlIGZlYXNpYmxlLCBhbmQg Y29uY2VwdCByZXVzZSBhcyBicm9hZGx5IGFzIHBvc3NpYmxlLCBidXQgbGV0J3Mgbm90IGdldCBz dHVjayBvbiBuZXQtcG9zaXRpdmUgY2hhbmdlcyBiZWNhdXNlIHRoZXkncmUgZGlmZmVyZW50IGZy b20gb3VyIGV4aXN0aW5nIGNvZGUgKFFVSUMgKm9yKiBIVFRQLzIpLg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjEsIDIw MTcgNjo1MCBQTQ0KVG86IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+DQpDYzogUVVJQyBX RyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+ DQpTdWJqZWN0OiBSZTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQpPbiAyMiBKdW5lIDIw MTcgYXQgMDk6NDgsIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+IHdyb3RlOg0KPiBNeSBk ZXNpZ24gc2Vuc2Ugc2F5cyB0byBvcHRpbWl6ZSBmb3IgdGhlIGNvbW1vbiBjYXNlIGFuZCB0byBh bGxvdyBmb3IgDQo+IHRoZSBleGNlcHRpb25zLiBHaXZlbiB0aGF0IG91ciBzY29wZSBpcyB0byBy ZWFsbHkgZ2V0IHRoaW5ncyByb2xsaW5nIA0KPiBmb3IgSFRUUCBBU0FQLCBJJ2QgYXJndWUgdGhh dCByZXF1ZXN0LXJlc3BvbnNlIGlzIHRoZSBjb21tb24gY2FzZSB0aGF0IA0KPiB3ZSBuZWVkIHRv IG9wdGltaXplIGZvci4NCg0KSSB0aGluayB0aGF0IHRoaXMgaXMgYSBmYWlyIGNyaXRpY2lzbSwg YW5kIEkgd2FudGVkIHRvIGFkZHJlc3MgaXQuDQoNCk15IGNvbmNlcm4gaXMgZXhhY3RseSB0aGUg c2FtZSBhcyB5b3VyczogSSB3YW50IGdldCBIVFRQIHdvcmtpbmcuICBBbmQgdW5mb3J0dW5hdGVs eSwgSFRUUC8yIGlzIG5vdCBhIHNpbXBsZSByZXF1ZXN0L3Jlc3BvbnNlIHByb3RvY29sLiAgVGhp cyBpcyB3aHkgSFRUUC8yIGFuZCBub3cgUVVJQyBhbGxvdyB0aGUgc2VydmVyIHRvIGluaXRpYXRl IHN0cmVhbXMuICBBbmQgaXQncyB0aGF0IGV4YWN0IGdhcCB0aGF0IG1vdGl2YXRlZCBtZSB0byBw cm9wb3NlIHRoaXMgY2hhbmdlLiAgSW4gbXkgdmlldywgdGhpcyBjaGFuZ2UgbWFrZXMgaXQgKmVh c2llciogdG8gZmluaXNoIEhUVFAgb3ZlciBRVUlDLg0KDQpUaGUgY29zdCBpcyB0aGF0IEhUVFAg aXMgbWFyZ2luYWxseSBtb3JlIGNvbXBsZXguICBNeSB2aWV3IGlzIHRoYXQgdGhlIG92ZXJhbGwg cHJvdG9jb2wgKEhUVFArUVVJQykgaXMgbm8gbW9yZSBvciBsZXNzIGNvbXBsZXggdGhhbiBiZWZv cmUsIHRoZXJlIGFyZSBiaWcgc2F2aW5ncyBpbiB0cmFuc3BvcnQsIGFuZCBzb21lIG1pbm9yIHNh dmluZ3MgaW4gSFRUUCB0aGF0IGNvdW50ZXJhY3QgdGhlIGFkZGVkIGNvc3Q6IGhhdmluZyB0byBp bmNsdWRlIGV4cGxpY2l0IGNvcnJlbGF0aW9uIGZvciByZXF1ZXN0IGFuZCByZXNwb25zZSwgYW5k IGhhdmluZyB0byBhZGQgYSB3YXkgdG8gY2FuY2VsIHJlcXVlc3RzIGJlZm9yZSB0aGUgcmVzcG9u c2Ugc3RhcnRzLiBbMV0NCg0KSW4gdGVybXMgb2YgZ2VuZXJhbGl0eSwgd2UndmUgYWxyZWFkeSBo ZWFyZCBmcm9tIENocmlzdGlhbiB0aGF0IHRoaXMgaXMgYmFzaWNhbGx5IG5ldXRyYWwgZm9yIERO UywgcG9zc2libHkgd2l0aCBhIHRpbnkgcmVkdWN0aW9uIGluIGNvbXBsZXhpdHkgcmVsYXRlZCB0 byBub3QgaGF2aW5nIHRvIGNoZWNrIHRoYXQgcmVkdW5kYW50IGlkZW50aWZpZXJzIGluIGEgcmVz cG9uc2UgYXJlIGNvbnNpc3RlbnQuDQoNClRlZCBzdWdnZXN0ZWQgdGhhdCB3ZSBhaW0gZm9yIGEg ZGVzaWduIHRoYXQgc3VwcG9ydHMgQk9USCB1bmlkaXJlY3Rpb25hbCBhbmQgYmlkaXJlY3Rpb25h bC4gR2l2ZW4gaG93IHRyaXZpYWwgaXQgaXMgdG8gYWRkIGFuIGlkZW50aWZpZXIgLSBhcyBkZW1v bnN0cmF0ZWQgYnkgdGhpcyBQUiAtIEkgZG9uJ3Qgc2VlIGhvdyBidWlsZGluZyB0aGF0IGZhY2ls aXR5IGludG8gdGhlIGJhc2UgdHJhbnNwb3J0IGlzIGEgbmV0IHdpbi4gIFNvbWUgcHJvdG9jb2xz IGNhbiBzdGlsbCB1c2UgdGhlIHN0cmVhbSBpZGVudGlmaWVycyBhcyBhIGNvcnJlbGF0b3IsIGZv ciBpbnN0YW5jZSB0aG9zZSBwcm90b2NvbHMgdGhhdCBhcmUgcHJvcGVybHkgcmVxdWVzdC9yZXNw b25zZSBkb24ndCBuZWVkIGV4cGxpY2l0IGNvcnJlbGF0b3JzLiAgVGhhdCBjaG9pY2UgLSBhcyB3 aXRoIHlvdXIgcHJvcG9zYWwgdG8gcmV0YWluIGJpZGlyZWN0aW9uYWxpdHkgLSBjcmVhdGVzIGEg cG90ZW50aWFsIGZvciBoZWFkLW9mLWxpbmUgYmxvY2tpbmcgdW5kZXIgY2VydGFpbiBjaXJjdW1z dGFuY2VzLCBzb21ldGhpbmcgdGhhdCBhbiBleHBsaWNpdCBjb3JyZWxhdG9yIGF0IHRoZSBhcHBs aWNhdGlvbiBsYXllciBuZWF0bHkgYXZvaWRzLg0KDQpbMV0gSSBkb24ndCBjb25zaWRlciBIQVNf Qk9EWSB0byBiZSBhIGNvc3QsIEknbSBub3cgZmlybWx5IG9mIHRoZSBvcGluaW9uIHRoYXQgbWVy Z2luZyBoZWFkZXJzIGFuZCBib2R5IGJhY2sgaW50byBhIHNpbmdsZSBzdHJlYW0gaXMgdGhlIHJp Z2h0IHNvbHV0aW9uIGFuZCB0aGF0IHdoYXQgSSB3cm90ZSB1cCBoZXJlIGlzIG9ubHkgdGVtcG9y YXJ5Lg0KDQo= From nobody Thu Jun 22 03:58:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCCB126B6D for ; Thu, 22 Jun 2017 03:58:43 -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 bFh9R9nkw4nq for ; Thu, 22 Jun 2017 03:58:42 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA5A127B31 for ; Thu, 22 Jun 2017 03:58:41 -0700 (PDT) Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v5MAwaMI001346; Thu, 22 Jun 2017 11:58:36 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0319.002; Thu, 22 Jun 2017 11:58:36 +0100 From: Lucas Pardue To: Jana Iyengar , Martin Thomson CC: QUIC WG , Patrick McManus Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHxDGnz1kRdokC70fyeY4ZMSqIvAa0AgADqdYCAACIYgIAAB9yAgACbikA= Date: Thu, 22 Jun 2017 10:58:35 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A37724110@bgb01xud1012> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23146.007 x-tm-as-result: No--23.894100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A37724110bgb01xud1012_" 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: Thu, 22 Jun 2017 10:58:44 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A37724110bgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgYXJlIGludGVyZXN0ZWQgaW4gdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhbmQgbGlrZSB0aGUg Y29uY2VwdCwgSSBoYXZlIHJldmlld2VkIHRoZSBQUiBhbmQgbWFkZSBzb21lIGVkaXRvcmlhbCBv ciBuaXQgY29tbWVudHMuDQoNClRoaXMgaXMgYSByZWFsbHkgaW50ZXJlc3RpbmcgZGlzY3Vzc2lv biwgd2hpY2ggSSBkb27igJl0IGhhdmUgbXVjaCB0byBhZGQgdG8gYXQgdGhlIG1vbWVudC4gVG8g YWRkIGEgc3BlY3RhdG9ycyBvcGluaW9uDQoNCk9uIFdlZCwgSnVuIDIxLCAyMDE3IEphbmEgSXll bmdhciB3cm90ZToNCg0KPiBDcmVhdGluZyBhIG5ldyBpZGVudGlmaWVyIGluIGV2ZXJ5IGFwcGxp Y2F0aW9uIHRvIGNvcnJlbGF0ZSByZXF1ZXN0L3Jlc3BvbnNlIHBhaXJzIGFkZHMgY29tcGxleGl0 eSB3aGVuIHlvdSBzdGFydCBhZGRpbmcgYXBwbGljYXRpb25zLiBFdmVyeSBhcHAgaGFzIHRvIG5v dyBleHBsaWNpdGx5IGRlc2lnbiBhbmQgaW1wbGVtZW50IHRoaXMgaW5jcmVkaWJseSBjb21tb24g ZGVzaWduIHBhdHRlcm4uIEJ1aWxkaW5nIGNvbW1vbiBkZXNpZ24gcGF0dGVybnMgaW50byB0aGUg dHJhbnNwb3J0IF9pc18gdGhlIHJvbGUgb2YgdGhlIHRyYW5zcG9ydC4gT3RoZXJ3aXNlLCB3ZSBj b3VsZCBiZSBidWlsZGluZyBIVFRQIGRpcmVjdGx5IG92ZXIgVURQLCB3aXRoIG5vIFFVSUMgaW4g dGhlIG1pZGRsZS4gVGhlIGNvcnJlbGF0b3IgaXMgYSBmZWF0dXJlLCBhbmQgb25lIHRoYXQgaXMg cmVxdWlyZWQgZXZlbiBpbiB5b3VyIGRlc2lnbiAoYWx0aG91Z2ggeW91IGhhdmUgaXQgaW4gSFRU UCkuIEkgZG9uJ3Qgc2VlIGhvdyBpdCBpbnRyb2R1Y2VzIEhvTCBibG9ja2luZywgYnV0IEkgZG9u J3Qgd2FudCB0byByYXRob2xlIG9uIGEgbWlub3IgcG9pbnQuDQoNClRoaXMgc291bmRzIHNvbWV3 aGF0IGxpa2UgYSBsaWJyYXJ5L2ZyYW1ld29yayBkZXZlbG9wZXLigJlzIGRpbGVtbWEuIEhvdyBt dWNoIOKAnGhhbmQgaG9sZGluZ+KAnSBzaG91bGQgdGhlIHRyYW5zcG9ydCBkbyBmb3IgdGhlIGFw cGxpY2F0aW9ucyBhdG9wICh0aGUgbnVtYmVyIG9mIHdoaWNoIGlzIHVuYm91bmRlZD8pLiBTb21l dGltZXMgcHJvdmlkaW5nIHRvbyBtdWNoIOKAnGltcGxlbWVudGF0aW9u4oCdIHdvcmtzIGNvdW50 ZXIgdG8gdGhlIHNwZWNpZmljIG5lZWZkIG9mIHRoZSBhcHBsaWNhdGlvbi4gVGhlcmVmb3JlLCB3 b3VsZCBpdCBzdWZmaWNlIHRvIGRlc2NyaWJlIHRoZSBkZXNpZ24gcGF0dGVybiBpbiB0aGUgdHJh bnNwb3J0LCBwZXJoYXBzIGluIHRlcm1zIG9mIGNvbnNpZGVyYXRpb25zIHRoYXQgYW4gYXBwbGlj YXRpb24gbWFwcGluZyBzaG91bGQgbWFrZT8NCg0KUmVnYXJkcw0KTHVjYXMNCg== --_000_7CF7F94CB496BF4FAB1676F375F9666A37724110bgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2UgYXJlIGludGVyZXN0ZWQg aW4gdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhbmQgbGlrZSB0aGUgY29uY2VwdCwgSSBoYXZlIHJl dmlld2VkIHRoZSBQUiBhbmQgbWFkZSBzb21lIGVkaXRvcmlhbCBvciBuaXQgY29tbWVudHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlRoaXMgaXMgYSByZWFsbHkgaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiwgd2hpY2gg SSBkb27igJl0IGhhdmUgbXVjaCB0byBhZGQgdG8gYXQgdGhlIG1vbWVudC4gVG8gYWRkIGEgc3Bl Y3RhdG9ycyBvcGluaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk9uIFdlZCwgSnVuIDIxLCAyMDE3IEphbmEgSXll bmdhciB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPiZndDsgQ3JlYXRpbmcgYSBuZXcgaWRlbnRpZmllciBpbiBldmVyeSBhcHBsaWNh dGlvbiB0byBjb3JyZWxhdGUgcmVxdWVzdC9yZXNwb25zZSBwYWlycyBhZGRzIGNvbXBsZXhpdHkg d2hlbiB5b3Ugc3RhcnQgYWRkaW5nIGFwcGxpY2F0aW9ucy4gRXZlcnkgYXBwDQogaGFzIHRvIG5v dyBleHBsaWNpdGx5IGRlc2lnbiBhbmQgaW1wbGVtZW50IHRoaXMgaW5jcmVkaWJseSBjb21tb24g ZGVzaWduIHBhdHRlcm4uIEJ1aWxkaW5nIGNvbW1vbiBkZXNpZ24gcGF0dGVybnMgaW50byB0aGUg dHJhbnNwb3J0IF9pc18gdGhlIHJvbGUgb2YgdGhlIHRyYW5zcG9ydC4gT3RoZXJ3aXNlLCB3ZSBj b3VsZCBiZSBidWlsZGluZyBIVFRQIGRpcmVjdGx5IG92ZXIgVURQLCB3aXRoIG5vIFFVSUMgaW4g dGhlIG1pZGRsZS4gVGhlIGNvcnJlbGF0b3INCiBpcyBhIGZlYXR1cmUsIGFuZCBvbmUgdGhhdCBp cyByZXF1aXJlZCBldmVuIGluIHlvdXIgZGVzaWduIChhbHRob3VnaCB5b3UgaGF2ZSBpdCBpbiBI VFRQKS4gSSBkb24ndCBzZWUgaG93IGl0IGludHJvZHVjZXMgSG9MIGJsb2NraW5nLCBidXQgSSBk b24ndCB3YW50IHRvIHJhdGhvbGUgb24gYSBtaW5vciBwb2ludC4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+VGhpcyBzb3VuZHMgc29tZXdoYXQgbGlrZSBhIGxpYnJhcnkvZnJhbWV3 b3JrIGRldmVsb3BlcuKAmXMgZGlsZW1tYS4gSG93IG11Y2gg4oCcaGFuZCBob2xkaW5n4oCdIHNo b3VsZCB0aGUgdHJhbnNwb3J0IGRvIGZvciB0aGUgYXBwbGljYXRpb25zIGF0b3AgKHRoZQ0KIG51 bWJlciBvZiB3aGljaCBpcyB1bmJvdW5kZWQ/KS4gU29tZXRpbWVzIHByb3ZpZGluZyB0b28gbXVj aCDigJxpbXBsZW1lbnRhdGlvbuKAnSB3b3JrcyBjb3VudGVyIHRvIHRoZSBzcGVjaWZpYyBuZWVm ZCBvZiB0aGUgYXBwbGljYXRpb24uIFRoZXJlZm9yZSwgd291bGQgaXQgc3VmZmljZSB0byBkZXNj cmliZSB0aGUgZGVzaWduIHBhdHRlcm4gaW4gdGhlIHRyYW5zcG9ydCwgcGVyaGFwcyBpbiB0ZXJt cyBvZiBjb25zaWRlcmF0aW9ucyB0aGF0IGFuIGFwcGxpY2F0aW9uDQogbWFwcGluZyBzaG91bGQg bWFrZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ THVjYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7CF7F94CB496BF4FAB1676F375F9666A37724110bgb01xud1012_-- From nobody Thu Jun 22 07:32: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 D9E9A129564 for ; Thu, 22 Jun 2017 07:32:30 -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 lbeFw55ymjos for ; Thu, 22 Jun 2017 07:32:26 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 F0EC3129549 for ; Thu, 22 Jun 2017 07:32:25 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id v7so6639053ywc.2 for ; Thu, 22 Jun 2017 07:32: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=tgFFyhxVCXbyuqfGAoN4n9ovqcStjn7Z+BRtxo40uto=; b=uC57MdSvcyRFpdnm1WdG/7IPHcambTXinrHTxh6/eI4U4C3DqUtsjB97m35odm5JX+ DO/5VGApcXHvoAHix0KIn3ZybL4SCQ0Fd+ebfHfuGsQTcWnkIBRtdt+iliygF0oPG2Js jscvpqX2qCVR4AywfvRseRP/cEkVUzdr9gW2YOou/cXJR5tGverU3KuT16creFT7Yzwn ugnYNnJRchpDRXwmnaG3MAOefz0DtoOF+M19RzUCGTKH0bLDgIVYEtS5+yTPYL56Ecj7 izblo23A3Xrfu+T9CDdnna8iWEvP4QYdqJKu2R/vbK3i+FCifZchaY+9ZLoPs+O8YgAf GwRA== 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=tgFFyhxVCXbyuqfGAoN4n9ovqcStjn7Z+BRtxo40uto=; b=OoOH8Lto0VroGNKoPTD4yNN/aYKRigLgJ3d+LzNVCcrSFxDNQlRMD/Gebk6XfOh08s piDCax+iIMyeQTri/ftFyHzAXn29xHGMDQm60kopQQDE16TbTmAWAAW2H6nDV8Smt+HG 5HI6TZhFwwwKkR7OsMHXSh5Zi2pP+FsITSUltPJ5+bvd6ojtpzo97KweCqbSmgGLRYAn n5YkYjzv0l2hZrzAXTnOJ+7/NU5rxpzQCXIHMGfg3GFm3w6ACvdv7zXeftBhMyeeIGnk cSO3cZuoW4rN1xX2YHIA9b1T03V2HFAFp0WBKoHNn5MjDYiO1pIZSvUbw2SfwZifeOLk lqaA== X-Gm-Message-State: AKS2vOzaIMvfjt0KKpvWp8lLHwavr+pWa3Rz+Gwv/BHxPwQq72oFvR6Q 5HxZC8UX00OND0G7ZmrFgQAWEB9RfuTz X-Received: by 10.129.162.86 with SMTP id z83mr2116641ywg.103.1498141944992; Thu, 22 Jun 2017 07:32:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.5.209 with HTTP; Thu, 22 Jun 2017 07:32:24 -0700 (PDT) In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A37724110@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A37724110@bgb01xud1012> From: Jo Kulik Date: Thu, 22 Jun 2017 10:32:24 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: Lucas Pardue Cc: Jana Iyengar , Martin Thomson , QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="94eb2c129a0274fae805528d5aea" 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, 22 Jun 2017 14:32:31 -0000 --94eb2c129a0274fae805528d5aea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > This sounds somewhat like a library/framework developer=E2=80=99s dilemma= . How > much =E2=80=9Chand holding=E2=80=9D should the transport do for the appli= cations atop (the > number of which is unbounded?). Sometimes providing too much > =E2=80=9Cimplementation=E2=80=9D works counter to the specific neefd of t= he application. > Therefore, would it suffice to describe the design pattern in the > transport, perhaps in terms of considerations that an application mapping > should make? I think this is an interesting idea. I'm personally in favor of the unidirectional streams proposal. (Emphasis on personally, this is not some institutional opinion). But this is because I have previous experience with non-request-response protocols, and I think they fit awkwardly over a conventional request-response-modelled transport. If there's a chance that some very simple changes could make QUIC more viable for those protocols, then I think it's worth at least discussing. I feel cautious about the, "Our current goal is HTTP, design for the common case" argument. HTTP is the first goal. But it's not the only goal, is it? To Jana's point about not designing a hammer with no specific nail to speak of, gosh it would be helpful if we had, ideally more than one, non-HTTP protocol in mind that we could discuss concretely. I know that Martin mentioned a few on his interim group slides. But I have no idea whether there were any stakeholders who are planning to invest in those protocols. It would be helpful, when examining the costs/benefit to say, "This is how this protocol fits over the current model, and this is how this protocol would fit over the unidirectional model." Right now, the only concrete protocols that we're discussing are H2 and maybe DNS, is that connect? On Thu, Jun 22, 2017 at 6:58 AM, Lucas Pardue wrote: > We are interested in unidirectional streams and like the concept, I have > reviewed the PR and made some editorial or nit comments. > > > > This is a really interesting discussion, which I don=E2=80=99t have much = to add to > at the moment. To add a spectators opinion > > > > On Wed, Jun 21, 2017 Jana Iyengar wrote: > > > > > Creating a new identifier in every application to correlate > request/response pairs adds complexity when you start adding applications= . > Every app has to now explicitly design and implement this incredibly comm= on > design pattern. Building common design patterns into the transport _is_ t= he > role of the transport. Otherwise, we could be building HTTP directly over > UDP, with no QUIC in the middle. The correlator is a feature, and one tha= t > is required even in your design (although you have it in HTTP). I don't s= ee > how it introduces HoL blocking, but I don't want to rathole on a minor > point. > > > > This sounds somewhat like a library/framework developer=E2=80=99s dilemma= . How > much =E2=80=9Chand holding=E2=80=9D should the transport do for the appli= cations atop (the > number of which is unbounded?). Sometimes providing too much > =E2=80=9Cimplementation=E2=80=9D works counter to the specific neefd of t= he application. > Therefore, would it suffice to describe the design pattern in the > transport, perhaps in terms of considerations that an application mapping > should make? > > > > Regards > > Lucas > --94eb2c129a0274fae805528d5aea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This sounds some= what like a library/framework developer=E2=80=99s dilemma. How much =E2=80= =9Chand holding=E2=80=9D should the transport do for the applications atop = (the number of which is unbounded?). Sometimes providing too much =E2=80=9C= implementation=E2=80=9D works counter to the specific neefd of the applicat= ion. Therefore, would it suffice to describe the design pattern in the tran= sport, perhaps in terms of considerations that an application mapping shoul= d make?

I think this is an interesti= ng idea.

I'm personally in favor of the unidir= ectional streams proposal. =C2=A0(Emphasis on personally, this is not some = institutional opinion).=C2=A0 But this is because I have previous experienc= e with non-request-response protocols, and I think they fit awkwardly over = a conventional request-response-modelled transport.=C2=A0 If there's a = chance that some very simple changes could make QUIC more viable for those = protocols, then I think it's worth at least discussing.

<= /div>
I feel cautious about the, "Our current goal is HTTP, design= for the common case" argument.=C2=A0 HTTP is the first goal.=C2=A0 Bu= t it's not the only goal, is it?=C2=A0

To Jana= 's point about not designing a hammer with no specific nail to speak of= , gosh it would be helpful if we had, ideally more than one, non-HTTP proto= col in mind that we could discuss concretely.=C2=A0 I know that Martin ment= ioned a few on his interim group slides.=C2=A0 But I have no idea whether t= here were any stakeholders who are planning to invest in those protocols.= =C2=A0 It would be helpful, when examining the costs/benefit to say, "= This is how this protocol fits over the current model, and this is how this= protocol would fit over the unidirectional model." =C2=A0
<= br>
Right now, the only concrete protocols that we're discuss= ing are H2 and maybe DNS, is that connect?

On Thu, Jun 22, 2017 at 6:58 AM, Lucas= Pardue <Lucas.Pardue@bbc.co.uk> wrote:

We are interested in unidirectional streams and lik= e the concept, I have reviewed the PR and made some editorial or nit commen= ts.

=C2=A0

This is a really interesting discussion, which I do= n=E2=80=99t have much to add to at the moment. To add a spectators opinion<= u>

=C2=A0

On Wed, Jun 21, 2017 Jana Iyengar wrote:<= /u>

=C2=A0

> Creating a new identifier in every application= to correlate request/response pairs adds complexity when you start adding = applications. Every app has to now explicitly design and implement this incredibly common design p= attern. Building common design patterns into the transport _is_ the role of= the transport. Otherwise, we could be building HTTP directly over UDP, wit= h no QUIC in the middle. The correlator is a feature, and one that is required even in your design (although you h= ave it in HTTP). I don't see how it introduces HoL blocking, but I don&= #39;t want to rathole on a minor point.=C2=A0

=C2=A0

This sounds somewhat like a library/framework devel= oper=E2=80=99s dilemma. How much =E2=80=9Chand holding=E2=80=9D should the = transport do for the applications atop (the number of which is unbounded?). Sometimes providing too much =E2=80=9Cimpl= ementation=E2=80=9D works counter to the specific neefd of the application.= Therefore, would it suffice to describe the design pattern in the transpor= t, perhaps in terms of considerations that an application mapping should make?

=C2=A0

Regards

Lucas


--94eb2c129a0274fae805528d5aea-- From nobody Thu Jun 22 09:16:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C257129AEB for ; Thu, 22 Jun 2017 09:16:48 -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 vJWhGbeVu-yz for ; Thu, 22 Jun 2017 09:16:46 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3FD129AD4 for ; Thu, 22 Jun 2017 09:16:46 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id l75so7832776ywc.3 for ; Thu, 22 Jun 2017 09:16:46 -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=JQEyj5IwbCYUMsLIoT7YxCl9PZp5GDhxDCAIg4KjgMI=; b=tyekWshCc/m8WxHeNSx4CyuoUGpvj6sx/fkOp4ZsvqNU7fSW+4O9gXGqLyQofns5KL YIAm/9Y75XZexCUmC2EvhD2NFitHBgZ4PF8lL6ZuYvKlAMdMozNUMnZP4O2m6QkSl2Mo TflQ/FjzTJ2QkwT0xugcdTD31Do6IQmpPboKCDGIgBjn9G9frJAhxEXiE/TVZu92bPfp hJ4utxo5h70E8gIULOTWnMWXeKzZLjt1l7WEfcRTDV4JgwiSbCcKHWlOoXKqynSCFms5 lfN7AxcV+igc95ckqotgT2RG8FwGFl19F5hS/3RyQq847QrpQp9/ugqtdtL4ND8UONns Kc0g== 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=JQEyj5IwbCYUMsLIoT7YxCl9PZp5GDhxDCAIg4KjgMI=; b=c4DEyTbt4hmko1qym0gimF8m60V2LMDXQ+T/DuSPaBdwcNLdRHhItpDLqNIyKCjVEh w8cu4/hF3Eaw5Oev/xzZ9dxjvqjb8GtxPI6VlwA5cqghq2kjT9ZvcPQ5Kfmsu+bPbYFU EOIs4e1PmOO4nRFE3GLqsatDjognmPQc/TY4cG69sxQDWvpC9VcHrAWhCSkWL9gCPtl7 DREGcWotHmPdNOufGZeGQxpqyJJZ281udCc0wVVSsK7mz92d4VItma6DsaxD0msFfyFB kDDycGxZh54iEYwX5mcZqaf+2G48TTVze0hIHQsI0Qiapcm1mi8WzJmxEjCqC1si3SZq xznQ== X-Gm-Message-State: AKS2vOyaJldRAhfHQEY89E3jTyAj1uRNp850ENkOKvc8+tSNEmHImBxK UfPyKZA/RdiP9Uz6qmBTtQMxklN4SDxe X-Received: by 10.13.203.136 with SMTP id n130mr2364372ywd.131.1498148205188; Thu, 22 Jun 2017 09:16:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.3 with HTTP; Thu, 22 Jun 2017 09:16:24 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37724110@bgb01xud1012> From: Ian Swett Date: Thu, 22 Jun 2017 12:16:24 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: Jo Kulik Cc: Lucas Pardue , Jana Iyengar , QUIC WG , Martin Thomson , Patrick McManus Content-Type: multipart/alternative; boundary="001a11481a4e97c92905528ecf96" 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, 22 Jun 2017 16:16:49 -0000 --001a11481a4e97c92905528ecf96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This proposal does two things, which I don't believe need to be conflated: 1) Adds support for unidirectional streams 2) Removes support for bidirectional streams I want better support in QUIC for unidirectional streams, for the reasons laid out above and quite a few others(ie: RTP). I believe this was the original motivation behind this proposal, but after thinking about it a lot and looking at the PR, I think removing support for bidirectional streams is a huge error, because it just moves work from the transport layer to each application layer. I agree with Ted, that we should support both, and I believe there are simple ways to support both, so I'll send out a PR that proposes one later today. If it's easy in QUIC to open a stream in either bidirectional or unidirectional mode, then it should be easy and efficient to map virtually every existing application written for TCP or UDP onto QUIC. The extra text in the RFC and extra code to support bidirectional streams vs unidirectional is quite small. As evidence that this doesn't result in a net simplification, even if we only care about HTTP over QUIC, the PR adds 212 lines of text. I'm sure that could be minimized some, but I think it's going to be very difficult to end up with a pure unidirectional design that's simpler than one which supports both unidirectional and bidirectional streams. On Thu, Jun 22, 2017 at 10:32 AM, Jo Kulik wrote: > This sounds somewhat like a library/framework developer=E2=80=99s dilemma= . How >> much =E2=80=9Chand holding=E2=80=9D should the transport do for the appl= ications atop (the >> number of which is unbounded?). Sometimes providing too much >> =E2=80=9Cimplementation=E2=80=9D works counter to the specific neefd of = the application. >> Therefore, would it suffice to describe the design pattern in the >> transport, perhaps in terms of considerations that an application mappin= g >> should make? > > > I think this is an interesting idea. > > I'm personally in favor of the unidirectional streams proposal. (Emphasi= s > on personally, this is not some institutional opinion). But this is > because I have previous experience with non-request-response protocols, a= nd > I think they fit awkwardly over a conventional request-response-modelled > transport. If there's a chance that some very simple changes could make > QUIC more viable for those protocols, then I think it's worth at least > discussing. > > I feel cautious about the, "Our current goal is HTTP, design for the > common case" argument. HTTP is the first goal. But it's not the only > goal, is it? > > To Jana's point about not designing a hammer with no specific nail to > speak of, gosh it would be helpful if we had, ideally more than one, > non-HTTP protocol in mind that we could discuss concretely. I know that > Martin mentioned a few on his interim group slides. But I have no idea > whether there were any stakeholders who are planning to invest in those > protocols. It would be helpful, when examining the costs/benefit to say, > "This is how this protocol fits over the current model, and this is how > this protocol would fit over the unidirectional model." > > Right now, the only concrete protocols that we're discussing are H2 and > maybe DNS, is that connect? > > On Thu, Jun 22, 2017 at 6:58 AM, Lucas Pardue > wrote: > >> We are interested in unidirectional streams and like the concept, I have >> reviewed the PR and made some editorial or nit comments. >> >> >> >> This is a really interesting discussion, which I don=E2=80=99t have much= to add >> to at the moment. To add a spectators opinion >> >> >> >> On Wed, Jun 21, 2017 Jana Iyengar wrote: >> >> >> >> > Creating a new identifier in every application to correlate >> request/response pairs adds complexity when you start adding application= s. >> Every app has to now explicitly design and implement this incredibly com= mon >> design pattern. Building common design patterns into the transport _is_ = the >> role of the transport. Otherwise, we could be building HTTP directly ove= r >> UDP, with no QUIC in the middle. The correlator is a feature, and one th= at >> is required even in your design (although you have it in HTTP). I don't = see >> how it introduces HoL blocking, but I don't want to rathole on a minor >> point. >> >> >> >> This sounds somewhat like a library/framework developer=E2=80=99s dilemm= a. How >> much =E2=80=9Chand holding=E2=80=9D should the transport do for the appl= ications atop (the >> number of which is unbounded?). Sometimes providing too much >> =E2=80=9Cimplementation=E2=80=9D works counter to the specific neefd of = the application. >> Therefore, would it suffice to describe the design pattern in the >> transport, perhaps in terms of considerations that an application mappin= g >> should make? >> >> >> >> Regards >> >> Lucas >> > > --001a11481a4e97c92905528ecf96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This proposal does two things, which I don't believe n= eed to be conflated:
=C2=A01) Adds support for unidirectional streams
=C2=A02) Removes support for bidirectional streams

<= /div>
I want better support in QUIC for unidirectional streams, for the= reasons laid out above and quite a few others(ie: RTP).=C2=A0 I believe th= is was the original motivation behind this proposal, but after thinking abo= ut it a lot and looking at the PR, I think removing support for bidirection= al streams is a huge error, because it just moves work from the transport l= ayer to each application layer.=C2=A0 I agree with Ted, that we should supp= ort both, and I believe there are simple ways to support both, so I'll = send out a PR that proposes one later today.

If it= 's easy in QUIC to open a stream in either bidirectional or unidirectio= nal mode, then it should be easy and efficient to map virtually every exist= ing application written for TCP or UDP onto QUIC.=C2=A0 The extra text in t= he RFC and extra code to support bidirectional streams vs unidirectional is= quite small.

As evidence that this doesn't re= sult in a net simplification, even if we only care about HTTP over QUIC, th= e PR adds 212 lines of text.=C2=A0 I'm sure that could be minimized som= e, but I think it's going to be very difficult to end up with a pure un= idirectional design that's simpler than one which supports both unidire= ctional and bidirectional streams.
On Thu, Jun 22, 2017 at 10:32 AM, Jo Kulik <= jokulik@google.com> wrote:
=
This sounds somewhat like a library/framework developer=E2=80=99s dilemm= a. How much =E2=80=9Chand holding=E2=80=9D should the transport do for the = applications atop (the number of which is unbounded?). Sometimes providing = too much =E2=80=9Cimplementation=E2=80=9D works counter to the specific nee= fd of the application. Therefore, would it suffice to describe the design p= attern in the transport, perhaps in terms of considerations that an applica= tion mapping should make?

I t= hink this is an interesting idea.

I'm personal= ly in favor of the unidirectional streams proposal. =C2=A0(Emphasis on pers= onally, this is not some institutional opinion).=C2=A0 But this is because = I have previous experience with non-request-response protocols, and I think= they fit awkwardly over a conventional request-response-modelled transport= .=C2=A0 If there's a chance that some very simple changes could make QU= IC more viable for those protocols, then I think it's worth at least di= scussing.

I feel cautious about the, "Our cur= rent goal is HTTP, design for the common case" argument.=C2=A0 HTTP is= the first goal.=C2=A0 But it's not the only goal, is it?=C2=A0

To Jana's point about not designing a hammer with no = specific nail to speak of, gosh it would be helpful if we had, ideally more= than one, non-HTTP protocol in mind that we could discuss concretely.=C2= =A0 I know that Martin mentioned a few on his interim group slides.=C2=A0 B= ut I have no idea whether there were any stakeholders who are planning to i= nvest in those protocols.=C2=A0 It would be helpful, when examining the cos= ts/benefit to say, "This is how this protocol fits over the current mo= del, and this is how this protocol would fit over the unidirectional model.= " =C2=A0

Right now, the only concrete protoco= ls that we're discussing are H2 and maybe DNS, is that connect?

=
On Thu, Jun 22, 2017 at 6:58 AM, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:

We are interested in unidirectional streams and lik= e the concept, I have reviewed the PR and made some editorial or nit commen= ts.

=C2=A0

This is a really interesting discussion, which I do= n=E2=80=99t have much to add to at the moment. To add a spectators opinion<= u>

=C2=A0

On Wed, Jun 21, 2017 Jana Iyengar wrote:<= /u>

=C2=A0

> Creating a new identifier in every application= to correlate request/response pairs adds complexity when you start adding = applications. Every app has to now explicitly design and implement this incredibly common design p= attern. Building common design patterns into the transport _is_ the role of= the transport. Otherwise, we could be building HTTP directly over UDP, wit= h no QUIC in the middle. The correlator is a feature, and one that is required even in your design (although you h= ave it in HTTP). I don't see how it introduces HoL blocking, but I don&= #39;t want to rathole on a minor point.=C2=A0

=C2=A0

This sounds somewhat like a library/framework devel= oper=E2=80=99s dilemma. How much =E2=80=9Chand holding=E2=80=9D should the = transport do for the applications atop (the number of which is unbounded?). Sometimes providing too much =E2=80=9Cimpl= ementation=E2=80=9D works counter to the specific neefd of the application.= Therefore, would it suffice to describe the design pattern in the transpor= t, perhaps in terms of considerations that an application mapping should make?

=C2=A0

Regards=

Lucas



--001a11481a4e97c92905528ecf96-- From nobody Thu Jun 22 10:07: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 6A30B127599 for ; Thu, 22 Jun 2017 10:07:57 -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 A5Cez0qgJ9Th for ; Thu, 22 Jun 2017 10:07:55 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFF3126D05 for ; Thu, 22 Jun 2017 10:07:54 -0700 (PDT) Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v5MH7qWK005245; Thu, 22 Jun 2017 18:07:52 +0100 (BST) Received: from BGB01XI1015.national.core.bbc.co.uk (10.161.14.78) by BGB01XI1011.national.core.bbc.co.uk (10.161.14.15) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Jun 2017 18:07:52 +0100 Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1015.national.core.bbc.co.uk ([10.161.14.78]) with mapi id 14.03.0319.002; Thu, 22 Jun 2017 18:07:52 +0100 From: Lucas Pardue To: Jana Iyengar , Martin Duke CC: IETF QUIC WG Subject: RE: Second Implementation Draft Guidelines Thread-Topic: Second Implementation Draft Guidelines Thread-Index: AQHS6tMH8cbIPuJ8C0qU7Rsz+tIP0KIvwpGAgAFQ3nA= Date: Thu, 22 Jun 2017 17:07:51 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A377241F8@bgb01xud1012> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] X-TM-AS-Product-Ver: SMEX-11.0.0.4255-8.100.1062-23146.007 X-TM-AS-Result: No--27.933400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A377241F8bgb01xud1012_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:07:57 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A377241F8bgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IGZlZWwgSSBjYW1lIGF3YXkgZnJvbSB0aGUgUGFyaXMgSW50ZXJpbSB3aXRoIGEg Y2xlYXIgaWRlYSBvZiB0aGUgYXBwcm9hY2ggdG8gdGhlIHNlY29uZCBpbXBsZW1lbnRhdGlvbiBk cmFmdC4gVGhlcmUgd2FzIGEgbG90IG9mIGRpc2N1c3Npb24gYXJvdW5kIHdoZXRoZXIgYnVnZml4 ZXMgaW4gbmV3IEktRCBkcmFmdHMgKHRoYXQgYWRkcmVzcyBpc3N1ZXMgaWRlbnRpZmllZCBpbiB0 aGUgZmlyc3QgaW1wbGVtZW50YXRpb24gZHJhZnQpIHdvdWxkIGNvbnRyaWJ1dGUgdG8gYSBmaXJz dC4xIGltcGxlbWVudGF0aW9uIGRyYWZ0IChhbGwgdGhlIHdheSB1cCB0byBmaXJzdC5OKSBvciBp ZiB0aGV5IHdvdWxkIGJlIHB1dCBpbnRvIHRoZSBzZWNvbmQuDQoNClNpZGUgbm90ZTogUGVyc29u YWxseSwgSSBkb27igJl0IHBhcnRpY3VsYXJseSBsaWtlIHRoZSB0ZXJtaW5vbG9neSBvZiBmaXJz dCwgc2Vjb25kIGV0YyBmb3IgdGhlIHJlYXNvbiB0aGF0IGl0IGdldHMgaGFyZCB0byByZXYvaXRl cmF0ZSBvbiBhIHBhcnRpY3VsYXIgb25lLiBIb3dldmVyLCBwZXJoYXBzIGl0IHdhcyBwdXJwb3Nl bHkgY2hvc2VuIHRvIGRpc2FtYmlndWF0ZSBmcm9tIHRoZSBJLUQgdmVyc2lvbnM/DQoNClRoZSBz dHJhd21hbiBzdWdnZXN0cyB0byBtZSB0aGF0IHRoZSBkaXJlY3Rpb24gaXMgdG8gbHVtcCBib3Ro IGZpeGVzIGFuZCBuZXcgZmVhdHVyZXMgaW50byB0aGUgc2Vjb25kIGltcGxlbWVudGF0aW9uIGRy YWZ0LiBJIGRvbuKAmXQgbmVjZXNzYXJpbHkgaGF2ZSBhbiBhcmd1bWVudCBhZ2FpbnN0IHRoYXQg YnV0IHRoaW5rIGl0IHdvdWxkIGhlbHAgdG8gY2xlYXJseSBpZGVudGlmeSB3aGVyZSB0aGluZ3Mg aGF2ZSBiZWVuIGZpeGVkLCBjaGFuZ2VkIGNvbXBsZXRlbHksIGJlZW4gb3ZlcnRha2VuIGJ5IG90 aGVyIGNoYW5nZXMgZXRjLiBVbmRlcnN0YW5kYWJseSBpdCBpcyB0b28gZWFybHkgdG8gZG8gdGhh dCBhdCB0aGlzIHN0YWdlLg0KDQpGaW5hbGx5LCBiZWluZyBzdXBlciBwaWNreSwgdGhlIHNlY29u ZCBpbXBsZW1lbnRhdGlvbiBkb2VzbuKAmXQgc2VlbSB0byBjb3ZlciBub24tY3JpdGljYWwgc2hv cnRjb21pbmdzDQoNClJlZ2FyZHMNCkx1Y2FzDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IDIxIEp1bmUg MjAxNyAyMjoyMw0KVG86IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4NCkNj OiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU2Vjb25kIEltcGxl bWVudGF0aW9uIERyYWZ0IEd1aWRlbGluZXMNCg0KVGhpcyBpcyBhIGdyZWF0IHN0YXJ0LCB0aGFu a3MgZm9yIGdldHRpbmcgaXQgZ29pbmcuDQpKdXN0IG9uZSB0aG91Z2h0OiBZb3UgbWF5IHdhbnQg dG8gZXhwbGljaXRseSAiaW5jbHVkZSIgZml4ZWQtdGltZSBSVE8tcmVjb3ZlcnkuIEl0IGFwcGVh cnMgcmlnaHQgbm93IGFzIGEgc2lkZSBub3RlIGluIHdoYXQncyBub3QgaW5jbHVkZWQuDQoNCk9u IFdlZCwgSnVuIDIxLCAyMDE3IGF0IDI6MTEgUE0sIE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtl QGdtYWlsLmNvbTxtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+PiB3cm90ZToNCkFsbCwN Cg0KQXMgcHJvbWlzZWQsIEkndmUgY3JlYXRlZCBhIHNldCBvZiBndWlkZWxpbmVzIGZvciB3aGF0 IHNob3VsZCBiZSBpbiB0aGUgU2Vjb25kIEltcGxlbWVudGF0aW9uIGRyYWZ0LiBJZiBkZWFkbGlu ZXMgaG9sZCwgSSBiZWxpZXZlIHdlIHdpbGwgYWN0dWFsbHkgc3RhcnQgaW1wbGVtZW50aW5nIHRo aXMgZHJhZnQgYWZ0ZXIgU2VhdHRsZSBpbiBPY3RvYmVyLg0KDQpPbmNlIHdlJ3ZlIHJlYWNoZWQg cmVhc29uYWJsZSBjb25zZW5zdXMsIHRoaXMgc2hvdWxkIHNlcnZlIGFzIGEgYmFzaXMgZm9yIHBy aW9yaXRpemluZyBpc3N1ZXMgdG8gcmVzb2x2ZSB0aHJvdWdoIFNlYXR0bGUuDQoNClRoZSBjdXJy ZW50IHZlcnNpb24gaXMgdmVyeSBtdWNoIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGRpc2N1c3Npb24u IEkndmUgcHJlc2VudGVkIHNvbWUgaXRlbXMgSSB0aGluayBhcmUgaW1wb3J0YW50IHRvIGluY2x1 ZGUsIGFuZCBvdGhlcnMgdGhhdCB3ZSBjb3VsZCBicmluZyBpbiBkZXBlbmRpbmcgb24gb3VyIGFw cGV0aXRlIGZvciB3b3JrLiBUaGUgZmluYWwgdmVyc2lvbiB3aWxsIHNpbXBseSBoYXZlICJNdXN0 IEluY2x1ZGUiIGFuZCAic2hvdWxkIG5vdCBpbmNsdWRlIi4NCg0KPGh0dHA6Ly9nb29nXzMxNDYz NjUyMD4NCmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9TZWNvbmQt SW1wbGVtZW50YXRpb24tRHJhZnQNCg0KSSBsb29rIGZvcndhcmQgdG8geW91ciBjb21tZW50cy4N Cg0KTWFydGluDQoNCg== --_000_7CF7F94CB496BF4FAB1676F375F9666A377241F8bgb01xud1012_ 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 dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGRvbuKAmXQgZmVlbCBJIGNhbWUgYXdh eSBmcm9tIHRoZSBQYXJpcyBJbnRlcmltIHdpdGggYSBjbGVhciBpZGVhIG9mIHRoZSBhcHByb2Fj aCB0byB0aGUgc2Vjb25kIGltcGxlbWVudGF0aW9uIGRyYWZ0LiBUaGVyZSB3YXMgYSBsb3Qgb2Yg ZGlzY3Vzc2lvbg0KIGFyb3VuZCB3aGV0aGVyIGJ1Z2ZpeGVzIGluIG5ldyBJLUQgZHJhZnRzICh0 aGF0IGFkZHJlc3MgaXNzdWVzIGlkZW50aWZpZWQgaW4gdGhlIGZpcnN0IGltcGxlbWVudGF0aW9u IGRyYWZ0KSB3b3VsZCBjb250cmlidXRlIHRvIGEgZmlyc3QuMSBpbXBsZW1lbnRhdGlvbiBkcmFm dCAoYWxsIHRoZSB3YXkgdXAgdG8gZmlyc3QuTikgb3IgaWYgdGhleSB3b3VsZCBiZSBwdXQgaW50 byB0aGUgc2Vjb25kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TaWRlIG5vdGU6IFBlcnNvbmFsbHksIEkgZG9u4oCZ dCBwYXJ0aWN1bGFybHkgbGlrZSB0aGUgdGVybWlub2xvZ3kgb2YgZmlyc3QsIHNlY29uZCBldGMg Zm9yIHRoZSByZWFzb24gdGhhdCBpdCBnZXRzIGhhcmQgdG8gcmV2L2l0ZXJhdGUgb24gYSBwYXJ0 aWN1bGFyDQogb25lLiBIb3dldmVyLCBwZXJoYXBzIGl0IHdhcyBwdXJwb3NlbHkgY2hvc2VuIHRv IGRpc2FtYmlndWF0ZSBmcm9tIHRoZSBJLUQgdmVyc2lvbnM/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBzdHJh d21hbiBzdWdnZXN0cyB0byBtZSB0aGF0IHRoZSBkaXJlY3Rpb24gaXMgdG8gbHVtcCBib3RoIGZp eGVzIGFuZCBuZXcgZmVhdHVyZXMgaW50byB0aGUgc2Vjb25kIGltcGxlbWVudGF0aW9uIGRyYWZ0 LiBJIGRvbuKAmXQgbmVjZXNzYXJpbHkgaGF2ZQ0KIGFuIGFyZ3VtZW50IGFnYWluc3QgdGhhdCBi dXQgdGhpbmsgaXQgd291bGQgaGVscCB0byBjbGVhcmx5IGlkZW50aWZ5IHdoZXJlIHRoaW5ncyBo YXZlIGJlZW4gZml4ZWQsIGNoYW5nZWQgY29tcGxldGVseSwgYmVlbiBvdmVydGFrZW4gYnkgb3Ro ZXIgY2hhbmdlcyBldGMuIFVuZGVyc3RhbmRhYmx5IGl0IGlzIHRvbyBlYXJseSB0byBkbyB0aGF0 IGF0IHRoaXMgc3RhZ2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RmluYWxseSwgYmVpbmcgc3VwZXIgcGlja3ks IHRoZSBzZWNvbmQgaW1wbGVtZW50YXRpb24gZG9lc27igJl0IHNlZW0gdG8gY292ZXIgbm9uLWNy aXRpY2FsIHNob3J0Y29taW5ncw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkx1Y2FzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkphbmEgSXllbmdhcjxicj4NCjxiPlNlbnQ6PC9iPiAyMSBKdW5lIDIwMTcg MjI6MjM8YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBEdWtlICZsdDttYXJ0aW4uaC5kdWtlQGdtYWls LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNlY29uZCBJbXBsZW1lbnRhdGlvbiBEcmFmdCBH dWlkZWxpbmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBh IGdyZWF0IHN0YXJ0LCB0aGFua3MgZm9yIGdldHRpbmcgaXQgZ29pbmcuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBvbmUgdGhvdWdodDogWW91IG1heSB3 YW50IHRvIGV4cGxpY2l0bHkgJnF1b3Q7aW5jbHVkZSZxdW90OyBmaXhlZC10aW1lIFJUTy1yZWNv dmVyeS4gSXQgYXBwZWFycyByaWdodCBub3cgYXMgYSBzaWRlIG5vdGUgaW4gd2hhdCdzIG5vdCBp bmNsdWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gV2VkLCBKdW4gMjEsIDIwMTcgYXQgMjoxMSBQTSwgTWFydGluIER1a2UgJmx0Ozxh IGhyZWY9Im1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h cnRpbi5oLmR1a2VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BcyBwcm9taXNlZCwgSSd2ZSBjcmVhdGVkIGEgc2V0IG9mIGd1aWRlbGluZXMg Zm9yIHdoYXQgc2hvdWxkIGJlIGluIHRoZSBTZWNvbmQgSW1wbGVtZW50YXRpb24gZHJhZnQuIElm IGRlYWRsaW5lcyBob2xkLCBJIGJlbGlldmUgd2Ugd2lsbCBhY3R1YWxseSBzdGFydCBpbXBsZW1l bnRpbmcgdGhpcyBkcmFmdCBhZnRlciBTZWF0dGxlIGluIE9jdG9iZXIuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uY2Ugd2UndmUgcmVhY2hl ZCByZWFzb25hYmxlIGNvbnNlbnN1cywgdGhpcyBzaG91bGQgc2VydmUgYXMgYSBiYXNpcyBmb3Ig cHJpb3JpdGl6aW5nIGlzc3VlcyB0byByZXNvbHZlIHRocm91Z2ggU2VhdHRsZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGN1cnJlbnQg dmVyc2lvbiBpcyB2ZXJ5IG11Y2ggYSBzdGFydGluZyBwb2ludCBmb3IgZGlzY3Vzc2lvbi4gSSd2 ZSBwcmVzZW50ZWQgc29tZSBpdGVtcyBJIHRoaW5rIGFyZSBpbXBvcnRhbnQgdG8gaW5jbHVkZSwg YW5kIG90aGVycyB0aGF0IHdlIGNvdWxkIGJyaW5nIGluIGRlcGVuZGluZyBvbiBvdXIgYXBwZXRp dGUgZm9yIHdvcmsuIFRoZSBmaW5hbCB2ZXJzaW9uIHdpbGwgc2ltcGx5IGhhdmUgJnF1b3Q7TXVz dA0KIEluY2x1ZGUmcXVvdDsgYW5kICZxdW90O3Nob3VsZCBub3QgaW5jbHVkZSZxdW90Oy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHA6Ly9nb29nXzMxNDYzNjUyMCIgdGFyZ2V0PSJfYmxhbmsiPjxicj4NCjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9TZWNvbmQtSW1wbGVtZW50 YXRpb24tRHJhZnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jh c2UtZHJhZnRzL3dpa2kvU2Vjb25kLUltcGxlbWVudGF0aW9uLURyYWZ0PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGxvb2sgZm9yd2Fy ZCB0byB5b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij5NYXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A377241F8bgb01xud1012_-- From nobody Thu Jun 22 12:14:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BF212948B for ; Thu, 22 Jun 2017 12:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZGQ15CHOhUD for ; Thu, 22 Jun 2017 12:14:44 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 8BB86126B7E for ; Thu, 22 Jun 2017 12:14:44 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id v7so9634798ywc.2 for ; Thu, 22 Jun 2017 12:14:44 -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=EZJm+4OG78WgIzKljvH0930fT0ow9SLo+VK0/JTGvO0=; b=gL7EAtrnV0VzCm0HPats3I+qo8KgR0Slb0eOfKQO1N8rHUJQGFYYunhMskWOksSR/F p3gEK7vOCgn+nghi+oWi9liCu7VVg8zIF8P3iiIueM1hGylWrN0W9+wyYczudKW205TW Dcfqs0EhWFQPHOZCSwYWcfyxfrdEev3BaiUDZ7rbNWe1cDPDuDakIm3l0Z/n1ht39QHX zCGj/iOqzQFOYj3X+1f8y1XamlTRpi80sTmf6WxvLSFPo/Ss4EO7Zm/kSSfNrMKXBcLJ DWNLdnQ3CBGbxUh4wswXmnsNg8FGsJUty1VUtSjztFbKuGirD3/T7d6j5Hv8Veov6tZO wYAw== 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=EZJm+4OG78WgIzKljvH0930fT0ow9SLo+VK0/JTGvO0=; b=iHF+7t0f52iUJOAo/KiKp1qO/HzhsO2dO0H/oeBqjBvkmMw1NiV4pw6ls4NZKYkh7J lduKPYhPHKLvosnFo8NiNSOGgbstbUU/cQKBfxzSgFk5Jx8udNmFkVTC/RcoR6ZJcG7p u2wQdXndKMZJdAt17QtzEhJrUy7m9+M9u/DpAiHD5rAnuDm8c/rFJv7EiG0VwIJ8TOO4 qdHDlsmk7sVk7k2O8gUuPj7M8VhjFLVluXP8/e96cpRWUgpc2XHrxcebXAVlICZ7WBAY 5X+TFaeprKd8eFj8OuO7nqmuOb2hvsG2jxCBtE2hnzUAqOCVoBilpDn3cdWBqnMyEuAg 9yRA== X-Gm-Message-State: AKS2vOzWhM+8xlJ2ZIKslFGs1NRQyz5T494f7uGbEj1ujpgzxygGeksK xFvNqfjftcfuUFuCqWRMkXEnm2wrlJkQ X-Received: by 10.129.109.17 with SMTP id i17mr3237217ywc.3.1498158883817; Thu, 22 Jun 2017 12:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Thu, 22 Jun 2017 12:14:03 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 22 Jun 2017 12:14:03 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a114dd50e168b3d0552914c40" 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, 22 Jun 2017 19:14:47 -0000 --001a114dd50e168b3d0552914c40 Content-Type: text/plain; charset="UTF-8" This seems like it's going in the right direction. I've left a bunch of extensive comments on the PR for minor issues. Substantive comments below. On Wed, Jun 21, 2017 at 12:41 AM, Martin Thomson wrote: > I've created a pull request unidirectional streams. > > https://github.com/quicwg/base-drafts/pull/643 > > 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. As I noted, I think it would be good to present the FIN/RST states separately. Now that you have made the state machine simpler, there's room to surface some of the substates upwared. 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. > Yes, I think that would be a good idea. It seems oddly artificial. With that said, if you're not going to do that, I think I would eliminate HAS_BODY in favor of a pseudo-header. 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. > It seems like there are two semantics here: 1. I stop sending me data 2. I don't care about this and I'm not responding. As you say, for headers #1 isn't much of an issue and for #2, it seems like an HTTP response that says "no" is just as efficient. -Ekr --001a114dd50e168b3d0552914c40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This seems like it's going in the right= direction. I've left a bunch of extensive comments
on the PR for m= inor issues. Substantive comments below.


On Wed, Jun 21, 2017 at 12:41 A= M, Martin Thomson <martin.thomson@gmail.com> wrote:
I've created a pull request unidirecti= onal streams.

https://github.com/quicwg/base-drafts/pull/643

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.=C2=A0 Each has three states: idle, open, and closed.=C2=A0 I separated the transitions for sending and receiving because=
that turned out to be easier to explain.=C2=A0 The reordering thing makes them different in subtle ways.

That's all.=C2=A0 The changes in transport are relatively small and the= y
simplify streams a lot.=C2=A0 That it also makes the transport more generic=
is a nice bonus.

some of the substates upwared.


The presence or absence of a message body is signaled after the
initial header block using a HAS_BODY frame.=C2=A0 This empty frame
indicates that another stream will include the body of the message -
or a promise for a body.=C2=A0 I would like to eliminate this stream split.=

Yes, I think that would be a good idea= . It seems oddly artificial.

With that said, if yo= u're not going to do that, I think I would eliminate HAS_BODY
in favor of a pseudo-header.


This really needs QPACK/QCRAM.=C2=A0 Right now, it is impossible to cancel<= br> some types of request using RST_STREAM because not all messages will
have a body (#176 again).=C2=A0 On balance, given that bodies are what you<= br> really want to kill, it's not disastrous, but it's a problem
nonetheless.=C2=A0 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.

It seems like there= are two semantics here:

1. I stop sending me data=
2. I don't care about this and I'm not responding.
=

As you say, for headers #1 isn't much of an issue a= nd for #2, it seems like
an HTTP response that says "no"= ; is just as efficient.

-Ekr

<= /div>
--001a114dd50e168b3d0552914c40-- From nobody Thu Jun 22 12:15: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 1A6AB129468 for ; Thu, 22 Jun 2017 12:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4qROjVSud2z for ; Thu, 22 Jun 2017 12:15:46 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 1037D126B7E for ; Thu, 22 Jun 2017 12:15:46 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id v20so19534177qtg.1 for ; Thu, 22 Jun 2017 12:15:46 -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=18yxO0HvljEc3V4JORZhRsWdbJAMfDioqOH1yijgB8k=; b=MiIisWBR4gHwWaXiT/6wBu+PnzIds0Rmf/JgV9uiGgI/KAYfzz5ZznScUTaxj9fQ/A dxh/lITRRoj7VpQuJ/GIUcSDXoAy+dwctnQtxvrD4gP71u9tb6T7xy0R5zH/jMIzxx80 lCp9mQoAyy+X5cN8lOPFzCs7514T1TLyiAWmfPlwvgxkA+sneyHJhXSLKmEX42VNvMwV GIN8MK3BGSaa/smC5eIw8S7TDiFDYutYsRATzWxop8IrE1rTN9dQdcHpPDSSZNmS5LY3 m2qr6y65il6Kmz8r3/ZnuMcDQVm/vGNP4Co5vWvlOJVlI4BtUF56AeCnxN5gT2jrTlvC PfKQ== 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=18yxO0HvljEc3V4JORZhRsWdbJAMfDioqOH1yijgB8k=; b=ifv/KT15IE+8/xgD4z2spRwZAfxSo/Ls9VKVGBOoTvRZhCBr+TqJOKQ3QZ6V6mi+aQ 7Y+cwL9ADqJqkGiGOOdbm7wyCKqWePT3740pUkKNDhB2/yctqPQxbqJXvUM1bLW6kZOa 1wIZuAD35jTLlT0qcdQF24RcVUuClBAiNdE1xkKxhNxBw2RUoSkiRj9CSLlff+/JCYUX B70rXk1drKLeXJt5uc7lsoG9tEQLhAFr+ZcJeB9cUhzSZAnTGiB9XO/k6n82ZkD9aZAu tAMH4v+ClBz9K9YiI17U9DlLniZh3CiDESfcWfhIkAnTWqAF/Ei1+3PHY+9RckSfs6M0 bjAQ== X-Gm-Message-State: AKS2vOy+fmu2RCJfHqFFA6ZuQNgMSkS/8YQ7hZI7oCS/kkIWp33WWveX RqL2dWDPgxdQmyk7HR+0Pvch11Ft5A== X-Received: by 10.237.41.196 with SMTP id o62mr4818703qtd.240.1498158945031; Thu, 22 Jun 2017 12:15:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.34.9 with HTTP; Thu, 22 Jun 2017 12:15:14 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Thu, 22 Jun 2017 12:15:14 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson Cc: Jana Iyengar , QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="94eb2c125922bc5b060552914f96" 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, 22 Jun 2017 19:15:48 -0000 --94eb2c125922bc5b060552914f96 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 6:50 PM, Martin Thomson wrote: > > Ted suggested that we aim for a design that supports BOTH > unidirectional and bidirectional. Given how trivial it is to add an > identifier - as demonstrated by this PR - I don't see how building > that facility into the base transport is a net win. If you have a protocol that has some unidirectional streams and some bidirectional streams, it provides a simple facility for indicating which streams have which characteristic. In general, you can make a bidrectional stream model look like a unidirectional stream model (the half-closed method is an example of this). You can make a unidirectional stream model look like a bidirectional stream model (correlators are an example of this). Both mean that some of the core characteristics of the base model aren't present in some cases. The key question is: how do you identify when that is the case? My personal take on that right answer there is to support both, with an explicit signal of when each model is in use, even for application protocols that use only bidirectional or unidirectional stream types. It's not like we haven't seen app protocols grow to incorporate bidirectional flows in previously unidirectional stream models (arguably RTCP with RTP) or vice versa (one way to look at server push in HTTP/2). This is a one bit signal of a very basic property, there are lots of better places to optimize than avoiding that spend. It's moderately obvious, that we will use both models in applications running on QUIC; what's th harm to an explicit signal and support? My personal opinion only, Ted > Some protocols > can still use the stream identifiers as a correlator, for instance > those protocols that are properly request/response don't need explicit > correlators. That choice - as with your proposal to retain > bidirectionality - creates a potential for head-of-line blocking under > certain circumstances, something that an explicit correlator at the > application layer neatly avoids. > > [1] I don't consider HAS_BODY to be a cost, I'm now firmly of the > opinion that merging headers and body back into a single stream is the > right solution and that what I wrote up here is only temporary. > > --94eb2c125922bc5b060552914f96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 21, 2017 at 6:50 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:

Ted suggested that we aim for a design that supports BOTH
unidirectional and bidirectional. Given how trivial it is to add an
identifier - as demonstrated by this PR - I don't see how building
that facility into the base transport is a net win.=C2=A0
=
If you have a protocol that has some unidirectional streams = and some bidirectional streams, it provides a simple facility for indicatin= g which streams have which characteristic.

In general, yo= u can make a bidrectional stream model look like a unidirectional stream mo= del (the half-closed method is an example of this).=C2=A0 You can make a un= idirectional stream model look like a bidirectional stream model (correlato= rs are an example of this). Both mean that some of the core characteristics= of the base model aren't present in some cases.=C2=A0 The key question= is:=C2=A0 how do you identify when that is the case?=C2=A0

My pers= onal take on that right answer there is to support both, with an explicit s= ignal of when each model is in use, even for application protocols that use= only bidirectional or unidirectional stream types.=C2=A0 It's not like= we haven't seen app protocols grow to incorporate bidirectional flows = in previously unidirectional stream models (arguably RTCP with RTP) or vice= versa (one way to look at server push in HTTP/2).=C2=A0 This is a one bit = signal of a very basic property, there are lots of better places to optimiz= e than avoiding that spend.=C2=A0 It's moderately obvious, that we will= use both models in applications running on QUIC; what's th harm to an = explicit signal and support?

My personal opinion only,
Ted



=C2=A0<= /div>
Some protocols
can still use the stream identifiers as a correlator, for instance
those protocols that are properly request/response don't need explicit<= br> correlators.=C2=A0 That choice - as with your proposal to retain
bidirectionality - creates a potential for head-of-line blocking under
certain circumstances, something that an explicit correlator at the
application layer neatly avoids.

[1] I don't consider HAS_BODY to be a cost, I'm now firmly of the opinion that merging headers and body back into a single stream is the
right solution and that what I wrote up here is only temporary.


--94eb2c125922bc5b060552914f96-- From nobody Thu Jun 22 14:59: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 76B3F12949D for ; Thu, 22 Jun 2017 14:59:24 -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 sQKNnhcxSWqX for ; Thu, 22 Jun 2017 14:59:21 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 5B3E2129470 for ; Thu, 22 Jun 2017 14:59:21 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id 77so41305213wrb.1 for ; Thu, 22 Jun 2017 14:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6ZU86DhaoufGTL2rre9llAcw1i+88CbYuzsV/eokgKA=; b=Vi4qUsWGvsPQULLschS97BYnAvHpug8kCHoZuetCHAg44JohawnVakrybFIr7p+MU0 C9dx7kSumEAmLgscvuAfwNFOG6jaLhGJvo/bcnXq9A/iI52PlFrOFcfegvWPzg0ZEBI9 /oLTV8Hw7s9f4F5fqZ62ZP/tuRO+KeNQVjpDGMGkyD23yCyvBUM5p91k3gtk4lMXueeU bYWRJSAhuilgFbRIWK8RUarZ+PSKXq8b+2JQ7rAxryY63YO6DDhfCUELlJ69eryhIOCM Y8gxwC+5ikewjkfCqciR/QPekjOFrWYi3ePpwuOtNymTUa+nOxaGKxUNVEspKk6mzqSg 5cag== 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=6ZU86DhaoufGTL2rre9llAcw1i+88CbYuzsV/eokgKA=; b=G9wmnxnfSgqiDHcRGxkOi/bBExLaqW3pjy3BR+VAtdIS57MY6fv+st7SFYrlTov3My f2KCS3HcsgKxDQnflSrgmVPX9i6nZ2NYEaF7oH4PAYTRWvN0cyNlUxpHFQZicN39brq3 678tPcRFtVmSQeRKdh78TaBrgv6aRsS7bpKmnni2fTxXeOgzbawdvEqY4zJaDOjEIxTC ENMhyE7cjb+VcwMJRniSfMZFLmnzpaiJ7pCC6o+FWMFQErp+8mcIKauvrmgOxvbbLDwp OuXDRS61zDXYwbczzet9rTOkH0oz39nhkjiFhjVqlOv01ztdvN75UeiTVteSNRbBCn23 q7bg== X-Gm-Message-State: AKS2vOyJUWulE/3kwWj0C83pUiu3/bLbdX8FZZ2yg+XYQfZGD1+ceJsW XCgugsy6LtUsWfbJRfzXlvTH/wdqFWtu X-Received: by 10.223.171.146 with SMTP id s18mr3422774wrc.38.1498168759489; Thu, 22 Jun 2017 14:59:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.94.206 with HTTP; Thu, 22 Jun 2017 14:59:18 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A37724110@bgb01xud1012> From: Wenbo Zhu Date: Thu, 22 Jun 2017 14:59:18 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Ian Swett Cc: Jo Kulik , Lucas Pardue , Jana Iyengar , QUIC WG , Martin Thomson , Patrick McManus Content-Type: multipart/alternative; boundary="001a113c2ba4b9a76905529398b8" 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, 22 Jun 2017 21:59:24 -0000 --001a113c2ba4b9a76905529398b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My personal opinions. 1) is much harder to add later. QUIC will definitely be used by non-RPC protocols. It would be useful to see a concrete example on how to map something like HTTP request/response to QUIC uni-streams. Could Mike publish two reference versions, before/after the PR is Incorporated to the HTTP mapping spec? Most L7 (application) protocols will keep using HTTP/* as the transport. Other L7 protocols will have their own state machines on top of the QUIC streams to manage the client-server conversation, inc. flow-control. The less state the QUIC layer maintains, the better IMO unless other transport-level features may benefit from the bidi model. I don't have any specific feature in mind. On Thu, Jun 22, 2017 at 9:16 AM, Ian Swett wrote: > This proposal does two things, which I don't believe need to be conflated= : > 1) Adds support for unidirectional streams > 2) Removes support for bidirectional streams > > I want better support in QUIC for unidirectional streams, for the reasons > laid out above and quite a few others(ie: RTP). I believe this was the > original motivation behind this proposal, but after thinking about it a l= ot > and looking at the PR, I think removing support for bidirectional streams > is a huge error, because it just moves work from the transport layer to > each application layer. I agree with Ted, that we should support both, a= nd > I believe there are simple ways to support both, so I'll send out a PR th= at > proposes one later today. > > If it's easy in QUIC to open a stream in either bidirectional or > unidirectional mode, then it should be easy and efficient to map virtuall= y > every existing application written for TCP or UDP onto QUIC. The extra > text in the RFC and extra code to support bidirectional streams vs > unidirectional is quite small. > > As evidence that this doesn't result in a net simplification, even if we > only care about HTTP over QUIC, the PR adds 212 lines of text. I'm sure > that could be minimized some, but I think it's going to be very difficult > to end up with a pure unidirectional design that's simpler than one which > supports both unidirectional and bidirectional streams. > > On Thu, Jun 22, 2017 at 10:32 AM, Jo Kulik wrote: > >> This sounds somewhat like a library/framework developer=E2=80=99s dilemm= a. How >>> much =E2=80=9Chand holding=E2=80=9D should the transport do for the app= lications atop (the >>> number of which is unbounded?). Sometimes providing too much >>> =E2=80=9Cimplementation=E2=80=9D works counter to the specific neefd of= the application. >>> Therefore, would it suffice to describe the design pattern in the >>> transport, perhaps in terms of considerations that an application mappi= ng >>> should make? >> >> >> I think this is an interesting idea. >> >> I'm personally in favor of the unidirectional streams proposal. >> (Emphasis on personally, this is not some institutional opinion). But >> this is because I have previous experience with non-request-response >> protocols, and I think they fit awkwardly over a conventional >> request-response-modelled transport. If there's a chance that some very >> simple changes could make QUIC more viable for those protocols, then I >> think it's worth at least discussing. >> >> I feel cautious about the, "Our current goal is HTTP, design for the >> common case" argument. HTTP is the first goal. But it's not the only >> goal, is it? >> >> To Jana's point about not designing a hammer with no specific nail to >> speak of, gosh it would be helpful if we had, ideally more than one, >> non-HTTP protocol in mind that we could discuss concretely. I know that >> Martin mentioned a few on his interim group slides. But I have no idea >> whether there were any stakeholders who are planning to invest in those >> protocols. It would be helpful, when examining the costs/benefit to say= , >> "This is how this protocol fits over the current model, and this is how >> this protocol would fit over the unidirectional model." >> >> Right now, the only concrete protocols that we're discussing are H2 and >> maybe DNS, is that connect? >> >> On Thu, Jun 22, 2017 at 6:58 AM, Lucas Pardue >> wrote: >> >>> We are interested in unidirectional streams and like the concept, I hav= e >>> reviewed the PR and made some editorial or nit comments. >>> >>> >>> >>> This is a really interesting discussion, which I don=E2=80=99t have muc= h to add >>> to at the moment. To add a spectators opinion >>> >>> >>> >>> On Wed, Jun 21, 2017 Jana Iyengar wrote: >>> >>> >>> >>> > Creating a new identifier in every application to correlate >>> request/response pairs adds complexity when you start adding applicatio= ns. >>> Every app has to now explicitly design and implement this incredibly co= mmon >>> design pattern. Building common design patterns into the transport _is_= the >>> role of the transport. Otherwise, we could be building HTTP directly ov= er >>> UDP, with no QUIC in the middle. The correlator is a feature, and one t= hat >>> is required even in your design (although you have it in HTTP). I don't= see >>> how it introduces HoL blocking, but I don't want to rathole on a minor >>> point. >>> >>> >>> >>> This sounds somewhat like a library/framework developer=E2=80=99s dilem= ma. How >>> much =E2=80=9Chand holding=E2=80=9D should the transport do for the app= lications atop (the >>> number of which is unbounded?). Sometimes providing too much >>> =E2=80=9Cimplementation=E2=80=9D works counter to the specific neefd of= the application. >>> Therefore, would it suffice to describe the design pattern in the >>> transport, perhaps in terms of considerations that an application mappi= ng >>> should make? >>> >>> >>> >>> Regards >>> >>> Lucas >>> >> >> > --001a113c2ba4b9a76905529398b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My personal opinions.

1) is much harder= to add later. QUIC will definitely be used by non-RPC protocols.=C2=A0

It would be useful to see a concrete example on how t= o map something like HTTP request/response to QUIC uni-streams. Could Mike = publish two reference versions, before/after the PR is Incorporated to the = HTTP mapping spec?

Most L7 (application) protocols= will keep using HTTP/* as the transport. Other L7 protocols will have thei= r own state machines on top of the QUIC streams to manage the client-server= conversation, inc. flow-control. The less state the QUIC layer maintains, = the better IMO unless other transport-level features may benefit from the b= idi model. I don't have any specific feature in mind.




On Thu, Jun 22, 2017 at 9:16 AM, Ian Swett <ianswett@go= ogle.com> wrote:
This proposal does two things, which I don't believe need to b= e conflated:
=C2=A01) Adds support for unidirectional streams
=C2=A02) Removes support for bidirectional streams

I want better support in QUIC for unidirectional streams, for the reasons= laid out above and quite a few others(ie: RTP).=C2=A0 I believe this was t= he original motivation behind this proposal, but after thinking about it a = lot and looking at the PR, I think removing support for bidirectional strea= ms is a huge error, because it just moves work from the transport layer to = each application layer.=C2=A0 I agree with Ted, that we should support both= , and I believe there are simple ways to support both, so I'll send out= a PR that proposes one later today.

If it's e= asy in QUIC to open a stream in either bidirectional or unidirectional mode= , then it should be easy and efficient to map virtually every existing appl= ication written for TCP or UDP onto QUIC.=C2=A0 The extra text in the RFC a= nd extra code to support bidirectional streams vs unidirectional is quite s= mall.

As evidence that this doesn't result in = a net simplification, even if we only care about HTTP over QUIC, the PR add= s 212 lines of text.=C2=A0 I'm sure that could be minimized some, but I= think it's going to be very difficult to end up with a pure unidirecti= onal design that's simpler than one which supports both unidirectional = and bidirectional streams.

On Thu, Jun 22= , 2017 at 10:32 AM, Jo Kulik <jokulik@google.com> wrote:
This sounds somewhat like a library/framework develop= er=E2=80=99s dilemma. How much =E2=80=9Chand holding=E2=80=9D should the tr= ansport do for the applications atop (the number of which is unbounded?). S= ometimes providing too much =E2=80=9Cimplementation=E2=80=9D works counter = to the specific neefd of the application. Therefore, would it suffice to de= scribe the design pattern in the transport, perhaps in terms of considerati= ons that an application mapping should make?

I think this is an interesting idea.

I'm personally in favor of the unidirectional streams proposal. =C2= =A0(Emphasis on personally, this is not some institutional opinion).=C2=A0 = But this is because I have previous experience with non-request-response pr= otocols, and I think they fit awkwardly over a conventional request-respons= e-modelled transport.=C2=A0 If there's a chance that some very simple c= hanges could make QUIC more viable for those protocols, then I think it'= ;s worth at least discussing.

I feel cautious abou= t the, "Our current goal is HTTP, design for the common case" arg= ument.=C2=A0 HTTP is the first goal.=C2=A0 But it's not the only goal, = is it?=C2=A0

To Jana's point about not designi= ng a hammer with no specific nail to speak of, gosh it would be helpful if = we had, ideally more than one, non-HTTP protocol in mind that we could disc= uss concretely.=C2=A0 I know that Martin mentioned a few on his interim gro= up slides.=C2=A0 But I have no idea whether there were any stakeholders who= are planning to invest in those protocols.=C2=A0 It would be helpful, when= examining the costs/benefit to say, "This is how this protocol fits o= ver the current model, and this is how this protocol would fit over the uni= directional model." =C2=A0

Right now, the onl= y concrete protocols that we're discussing are H2 and maybe DNS, is tha= t connect?

On Thu, Jun 22, 2017 at 6:58 AM, Lucas Pardue <Lucas.Pa= rdue@bbc.co.uk> wrote:

We are interested in unidirectional streams and lik= e the concept, I have reviewed the PR and made some editorial or nit commen= ts.

=C2=A0

This is a really interesting discussion, which I do= n=E2=80=99t have much to add to at the moment. To add a spectators opinion<= u>

=C2=A0

On Wed, Jun 21, 2017 Jana Iyengar wrote:<= /u>

=C2=A0

> Creating a new identifier in every application= to correlate request/response pairs adds complexity when you start adding = applications. Every app has to now explicitly design and implement this incredibly common design p= attern. Building common design patterns into the transport _is_ the role of= the transport. Otherwise, we could be building HTTP directly over UDP, wit= h no QUIC in the middle. The correlator is a feature, and one that is required even in your design (although you h= ave it in HTTP). I don't see how it introduces HoL blocking, but I don&= #39;t want to rathole on a minor point.=C2=A0

=C2=A0

This sounds somewhat like a library/framework devel= oper=E2=80=99s dilemma. How much =E2=80=9Chand holding=E2=80=9D should the = transport do for the applications atop (the number of which is unbounded?). Sometimes providing too much =E2=80=9Cimpl= ementation=E2=80=9D works counter to the specific neefd of the application.= Therefore, would it suffice to describe the design pattern in the transpor= t, perhaps in terms of considerations that an application mapping should make?

=C2=A0

Regards<= /span>

Lucas




--001a113c2ba4b9a76905529398b8-- From nobody Thu Jun 22 15:32: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 B3082129462 for ; Thu, 22 Jun 2017 15:32:31 -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 PA92MPBdh1np for ; Thu, 22 Jun 2017 15:32:30 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 0951B128B4E for ; Thu, 22 Jun 2017 15:32:30 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id h22so20653449lfk.3 for ; Thu, 22 Jun 2017 15:32:29 -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=Idf2EOZBWvsAGt0pYX9edXUynUzJHKIcYoDO7WUNN/I=; b=U9ZO8QjCyjR0LkiFRspg4MKhaWz0GkeqOBSCj2NCOVtOaBQxdBbPO3pxQIcG4aqCcZ sIva8fGZi9av/TLYrJrQ7sogMuEQ0mMVEA8aJrS7Sx14ftEYmHdtxuR2vY7qB93cxMzX bXGyLuSrr8RDw66QNv50XCTKOtqvkdpdiqpQDRngQoJs5IBMPziJxpREHEuQMb0wEusz CTHzBCNOOpNpTjY9uEcb5flDZTt1IUYSR30DwMup8+G57UksAAjM1RWyZ2POrTJ10oCz AleIr30bPeTyX/55jdfncEyzb/9WjQlXwTGag0tCx5UgpClcYbZDbF+wgPWWTO6n/u6Q XTJg== 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=Idf2EOZBWvsAGt0pYX9edXUynUzJHKIcYoDO7WUNN/I=; b=cGscDAgO50BplRXJ+fKazIbfbajrhs1rDLo6Ggx49xZsguOJm+UbN07fLLrUAma+kr VMZ5w84i6OeyeFjb35nOJUZxvJOGFk0bzQcfbKYLtw6CN0mCmflfG8IKcfZaLvw+/33H XhutpEIrTGBZNVVeROCn4BjdskYQRAkdnNyCv4hNEuelb1y0DHo2BtwJXdSJ0KwGpKxK NUuq7g5YJk2cjiJvyqNAhYT4yjWXELq8BFyy2QpsL9kNZE22j1KqT+vRMIWP3bpuWoMP Iar0GFV5zaawyaqQcuuhXpz/dX2mO3WBHlUi0CHuoxtTv9iE8AtG6lfIKALv3lTkUJ9a MJjw== X-Gm-Message-State: AKS2vOzyznH4NaYqgzoVtkoH4SPgdViADiDNJdBL/o1HjYTrzb4rq87B uNkIgiLpEDKN0u7l010at1lZVo7TRA== X-Received: by 10.25.166.15 with SMTP id p15mr1484047lfe.43.1498170748323; Thu, 22 Jun 2017 15:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Thu, 22 Jun 2017 15:32:25 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 23 Jun 2017 08:32:25 +1000 Message-ID: Subject: Re: Unidirectional streams PR To: Ted Hardie Cc: Jana Iyengar , QUIC WG , Patrick McManus 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, 22 Jun 2017 22:32:32 -0000 On 23 June 2017 at 05:15, Ted Hardie wrote: > My personal take on that right answer there is to support both, with an > explicit signal of when each model is in use, I have heard this request now from several folks at Google. I don't know how to make this work without increasing complexity considerably . I'd be willing to be wrong about this, but would prefer to see a proposal. I don't need a fully-worked proposal with text, just a sketch of how the pieces work in enough detail to understand how this might interact with other parts of the protocol. I think that Jana offered to do this, so maybe I can wait for that (c.f., Mark's earlier statement about priority/urgency). From nobody Thu Jun 22 15:47: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 29083129B95 for ; Thu, 22 Jun 2017 15:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyZjul9K3-8N for ; Thu, 22 Jun 2017 15:47:20 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E5F129B8C for ; Thu, 22 Jun 2017 15:47:19 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id u12so23333012qth.0 for ; Thu, 22 Jun 2017 15:47:19 -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=yPN/gUbWVGyQIENuzZ2y8ksrIq7H+O+H97d2bV9tymw=; b=M6PHNisZiJQXW18MF0w3T+4PwS+bQtwK3TLbDsNnf4gCcRiQavhNwvSXcTxPSdrWe3 5O8d/G7TQr41aXatIG5JNZsWYLsOgkREmw/KqIQQ/wMLTxaN3aLFbpayiE4Q0sO7icD+ XvXuvDJpHfmBqrJEd4kCkoUKC5/Xr5ngoimqKSanJqMZVq5XAIEJMWCHvgLR5b4CYreQ VAFXHTtZUteAqE2ufWt64RKOnsoi+tt5FWqrrAL5+DDSg6aS47xn7Db7kiWoNnn8zmaZ I22AWu758dJR7FpEeB3ExkYeXQLJlxSS4bNb5IfgRJhMqnqHNjkDmCcGePOOHc2Z/qpQ nAzg== 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=yPN/gUbWVGyQIENuzZ2y8ksrIq7H+O+H97d2bV9tymw=; b=pN8a5cjrvGp8UE9dzccqIsJUCcnp8HjmkgHWjlQVPveJmXOJsDvgWz1xdD+z50C2zp Vae2dTCAjP8Hi0YHHFqGTyXlcvjjUAhHxkkeI3RI3sGFzEH6f/sgni7TGVl851IKj2vo maM410CL6ycgNXDktxRfJ6kdbpPi/dTksXLAa5Ss7ewEk7gTWkXbQ0cqvYwnD1iXJDWn jlsUB9+DdYLIukHu6NVUkBYkgO+uTfoLDUh8BbzdOS4qVETUZIU9uZnuCQ1wfhJpAKRM bm0bMq2+6C1dmQk8KhR0Fs55ivuASSDVqhE72/2ihIPU0D0uQJdFGr7633iyHiui7v9R 5Vtw== X-Gm-Message-State: AKS2vOxCnNt520Kut1RSwYM8+FT+kkmB2S4qbNWrzHqtdX9PrcYju0y7 zsM8jV4ekCHnkCgSg2uZTyTmDaKXqw== X-Received: by 10.237.44.7 with SMTP id f7mr6468252qtd.52.1498171638235; Thu, 22 Jun 2017 15:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.34.9 with HTTP; Thu, 22 Jun 2017 15:46:47 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Thu, 22 Jun 2017 15:46:47 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson Cc: Jana Iyengar , QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="94eb2c05df904f46bd0552944447" 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, 22 Jun 2017 22:47:22 -0000 --94eb2c05df904f46bd0552944447 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 22, 2017 at 3:32 PM, Martin Thomson wrote: > On 23 June 2017 at 05:15, Ted Hardie wrote: > > My personal take on that right answer there is to support both, with an > > explicit signal of when each model is in use, > > I have heard this request now from several folks at Google. Please be careful withyour attributions. Several people replied with very explicit statements that the were putting forward personal opinions. Some of those people, including those with different opinions, have day jobs at the same place, but we were not speaking for our employer nor with the same experience (either at that employer or elsewhere). thanks, Ted > I don't > know how to make this work without increasing complexity considerably > . I'd be willing to be wrong about this, but would prefer to see a > proposal. I don't need a fully-worked proposal with text, just a > sketch of how the pieces work in enough detail to understand how this > might interact with other parts of the protocol. I think that Jana > offered to do this, so maybe I can wait for that (c.f., Mark's earlier > statement about priority/urgency). > --94eb2c05df904f46bd0552944447 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 22, 2017 at 3:32 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 23 June 2017 at 05:15, Ted Hardie <ted.ietf@gmail.com> wrote:
> My personal take on that right answer there is to support both, with a= n
> explicit signal of when each model is in use,

I have heard this request now from several folks at Google.=C2=A0

Please be careful withyour attributions.=C2= =A0 Several people replied with very explicit statements that the were putt= ing forward personal opinions.=C2=A0 Some of those people, including those = with different opinions, have day jobs at the same place, but we were not s= peaking for our employer nor with the same experience (either at that emplo= yer or elsewhere).

thanks,

Ted



=C2=A0
I d= on't
know how to make this work without increasing complexity considerably
.=C2=A0 I'd be willing to be wrong about this, but would prefer to see = a
proposal.=C2=A0 I don't need a fully-worked proposal with text, just a<= br> sketch of how the pieces work in enough detail to understand how this
might interact with other parts of the protocol.=C2=A0 I think that Jana offered to do this, so maybe I can wait for that (c.f., Mark's earlier<= br> statement about priority/urgency).

--94eb2c05df904f46bd0552944447-- From nobody Thu Jun 22 15:47:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0E1294AC for ; Thu, 22 Jun 2017 15:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 7bWRGJpJLj31 for ; Thu, 22 Jun 2017 15:47:46 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0101.outbound.protection.outlook.com [104.47.38.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D341288B8 for ; Thu, 22 Jun 2017 15:47:45 -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=1NcwYMSkx8GyBnE9WbtegGzwFw4l2l4nDKHNnFAO8xE=; b=YYXSUxr10E8B2yQtN+RgWGgpkK45T7grrrdbYUzmIe6BATRRgjeemGB4EEtSy2bCpM4rTb/9uFG+eAzrmzeRZmaTi8vkBo55rBmpWOec51x/27nWHQdI/Rw8BWwG6eW4b0/BFJyz1ie1YnWERsP53kzSoXjMx3mI1Bdh4gSBYvk= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0173.namprd21.prod.outlook.com (10.173.52.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.1; Thu, 22 Jun 2017 22:47:42 +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.1220.005; Thu, 22 Jun 2017 22:47:43 +0000 From: Mike Bishop To: Martin Thomson , Ted Hardie CC: Jana Iyengar , QUIC WG , Patrick McManus Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHyIpxR/afFiUiHxd5TQx2M+qIvEnAAgADqdYCAACIZgIABI/4AgAA3F4CAAAIxEA== Date: Thu, 22 Jun 2017 22:47:43 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8080:5a28:1059:aa56:624:b5a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0173; 7:stzIlc01JBDvLvFSwvQZCn48rpp8osmjoHJY+4XQcsu6EqYFo97sP7Eg5rbqEb+t4Ct5Dzs8ddi3fhgBFABAo6tsbOTFQnYvo8s5qgNJ+MQevgnfv0fF8gyNwDD2HH/ScAN35hh2o+VYguJzAAZIfAiRBeTlW1gmk2HOmi8d1+MSaJ3du05lkkKPZxFul/vrXZBH3CRTQvcgq+78nWx6U1dKS4QWbqL8eiVqzJn/cClPWxAY7ztby0iOmGtESAhIA4KNGXn5k6fzLFtovj/+cqJuPwkMoyJaHHZzfXIIeGjveGV1inJMOi9fq+zOJgoOC1U6QTt/t822lESqH3QRt00s3VPK9diSvbo9hdxhjPZ/G3gb5YKeXdgym+Ski2XMz7SlG3vrIRDaOTjUY9z+xlqfs20Ko9xWbY9g9AqVzXa2YJxSViRc7xknjeluxa7sju3o15Gnoz1cBHqvNyceP3DIrfps8S9VGi0eZN0HfB2/I1+EhiAxdmUksZTUXvD7/h9y0lOwDkyzdY2lgWVkQpgpzMayTpyYGPHFUuMoaiUKfvBAOdbVhSf82/9c7wsPkWtB+o/wycLW4Fhy3d8BWrP10dazYhX5hhNAr0Hz4R0IplqpjQQznhftE3ykFpLjEVBj2KiyWJtAqJnU+o0lyqVCojPR7ixmAsNFjvBkf7m04RAN8S15/8XQEmKl2EjNh9JZ0jFqjI9ZCh2ClgfHjEv3maXEg6Sgduv3E75W3WnL8Xd4DUuvECEV0k1O1OTFhjXqgQ1bgnc0E3GhoRFNz/okgtUuwTy0rKVC+aHKr/Awy9Vp7UN8dZRbjNB3cXvT x-ms-office365-filtering-correlation-id: 9b428c57-593a-4162-1cb8-08d4b9c0b1a5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:MWHPR21MB0173; x-ms-traffictypediagnostic: MWHPR21MB0173: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0173; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0173; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39450400003)(39400400002)(39410400002)(39850400002)(13464003)(51444003)(377454003)(24454002)(4326008)(561944003)(77096006)(229853002)(81166006)(93886004)(39060400002)(2900100001)(8676002)(6246003)(3480700004)(305945005)(74316002)(38730400002)(8936002)(9686003)(5005710100001)(3660700001)(54906002)(2906002)(3280700002)(10090500001)(99286003)(5660300001)(53936002)(8990500004)(55016002)(86362001)(86612001)(7116003)(25786009)(33656002)(7696004)(6116002)(7736002)(102836003)(2950100002)(76176999)(6436002)(10290500003)(189998001)(6506006)(54356999)(122556002)(14454004)(478600001)(72206003)(50986999)(53546010); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0173; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 22:47:43.0589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0173 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, 22 Jun 2017 22:47:48 -0000 SSBzdXBwb3NlIHlvdSBjb3VsZCBkcm9wIHRoZSBzdHJlYW0gdHlwZSBoZWFkZXIgZnJvbSBIVFRQ IGludG8gUVVJQyBhbmQgbWFrZSB0aGUgdHlwZXMgImJpZGlyZWN0aW9uYWwgc3RyZWFtLCIgInVu aWRpcmVjdGlvbmFsIHN0cmVhbSwiIGFuZCAibWF0ZSBvZiBiaWRpcmVjdGlvbmFsIHN0cmVhbSI7 IHRoZSBsYXN0IHdvdWxkIGZ1cnRoZXIgbmVlZCB0byBpZGVudGlmeSB3aGljaCBwZWVyIHN0cmVh bSBpdCBjb3JyZXNwb25kZWQgdG8uDQoNCkJ1dCBtYWtpbmcgdGhlbSB0aGUgZmlyc3QgY291cGxl IGJ5dGVzIG9mIHRoZSBzdHJlYW0gZGF0YSBmZWVscyBraW5kIG9mIGtsdWRneSBpZiB0aGlzIGlz IGZ1bmRhbWVudGFsbHkgYnVpbHQgaW50byB0aGUgdHJhbnNwb3J0LCB3aGljaCBtZWFucyB0aGV5 IHJlYWxseSBiZWxvbmcgaW4gYSBkZWRpY2F0ZWQgZnJhbWUuICBNYXliZSBhIGRlZGljYXRlZCBP UEVOX1NUUkVBTSBmcmFtZSwgd2hpY2ggYmxvY2tzIGFueSBkYXRhIHJlY2VpdmVkIG9uIHRoYXQg c3RyZWFtIHVudGlsIHlvdSBrbm93IHdoYXQgdHlwZSBpdCBpcz8NCg0KQWN0dWFsbHksIGlmIHdl J3JlIHBsYW5uaW5nIG9uIGludHJvZHVjaW5nIG90aGVyIHBlci1zdHJlYW0gcHJvcGVydGllcyBs aWtlIHBhcnRpYWwgcmVsaWFiaWxpdHksIHRoZXJlIG1pZ2h0IGJlIHZhbHVlIGluIGFuIE9QRU5f U1RSRUFNIGZyYW1lIHdoZXJlIHdlIGNhbiBkZXNjcmliZSBhIHN0cmVhbSdzIGRlc2lyZWQgcHJv cGVydGllcyBiZWZvcmUgYW55IGRhdGEgZmxvd3MuLi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDIyLCAyMDE3IDM6MzIg UE0NClRvOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+DQpDYzogSmFuYSBJeWVuZ2Fy IDxqcmlAZ29vZ2xlLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBQYXRyaWNrIE1jTWFu dXMgPHBtY21hbnVzQG1vemlsbGEuY29tPg0KU3ViamVjdDogUmU6IFVuaWRpcmVjdGlvbmFsIHN0 cmVhbXMgUFINCg0KT24gMjMgSnVuZSAyMDE3IGF0IDA1OjE1LCBUZWQgSGFyZGllIDx0ZWQuaWV0 ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiBNeSBwZXJzb25hbCB0YWtlIG9uIHRoYXQgcmlnaHQgYW5z d2VyIHRoZXJlIGlzIHRvIHN1cHBvcnQgYm90aCwgd2l0aCANCj4gYW4gZXhwbGljaXQgc2lnbmFs IG9mIHdoZW4gZWFjaCBtb2RlbCBpcyBpbiB1c2UsDQoNCkkgaGF2ZSBoZWFyZCB0aGlzIHJlcXVl c3Qgbm93IGZyb20gc2V2ZXJhbCBmb2xrcyBhdCBHb29nbGUuICBJIGRvbid0IGtub3cgaG93IHRv IG1ha2UgdGhpcyB3b3JrIHdpdGhvdXQgaW5jcmVhc2luZyBjb21wbGV4aXR5IGNvbnNpZGVyYWJs eSAuICBJJ2QgYmUgd2lsbGluZyB0byBiZSB3cm9uZyBhYm91dCB0aGlzLCBidXQgd291bGQgcHJl ZmVyIHRvIHNlZSBhIHByb3Bvc2FsLiAgSSBkb24ndCBuZWVkIGEgZnVsbHktd29ya2VkIHByb3Bv c2FsIHdpdGggdGV4dCwganVzdCBhIHNrZXRjaCBvZiBob3cgdGhlIHBpZWNlcyB3b3JrIGluIGVu b3VnaCBkZXRhaWwgdG8gdW5kZXJzdGFuZCBob3cgdGhpcyBtaWdodCBpbnRlcmFjdCB3aXRoIG90 aGVyIHBhcnRzIG9mIHRoZSBwcm90b2NvbC4gIEkgdGhpbmsgdGhhdCBKYW5hIG9mZmVyZWQgdG8g ZG8gdGhpcywgc28gbWF5YmUgSSBjYW4gd2FpdCBmb3IgdGhhdCAoYy5mLiwgTWFyaydzIGVhcmxp ZXIgc3RhdGVtZW50IGFib3V0IHByaW9yaXR5L3VyZ2VuY3kpLg0KDQo= From nobody Thu Jun 22 16:54:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2903129462 for ; Thu, 22 Jun 2017 16:54:44 -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 MDbqVkwJStps for ; Thu, 22 Jun 2017 16:54:43 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 15989127369 for ; Thu, 22 Jun 2017 16:54:43 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id q86so15658627pfl.3 for ; Thu, 22 Jun 2017 16:54:43 -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=By5cv2mddES6sc9iC4XAprjMQMKhKkK70LaKVGmDeM4=; b=Fzx0k6tnFksQ9VtD16rZ7/kmp1YTwgtnNL96G3sc+tRmC2ViAfoeShuzalGuqDZKbA 5SibUUCl7yd7BsQZ6mjHu5Zwe5tpKSxv2j7ROgDh3iYbVIZsYLtKrgxne5DtNYXYNr2B z3qW6ng92E70h/pouV5ZQztN/nchtbSnHIKZvqYyqnXGyxwdoEfHThfPaBzqcj3eztkY Zg6NDoko5gAkDnbxVj65+wPa3Efi6758VISL4OrlqFOJ4c7M78VGvS38TkvL1JrI3TSz qYT5cckBPFT6LFbN1zAycqdFzQrOLSTsvIrIy1ymRr2VPfJeaEKjT9jEtA0IzZRyTONy ig6Q== 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=By5cv2mddES6sc9iC4XAprjMQMKhKkK70LaKVGmDeM4=; b=r0L3xEHEWljqEAU/qEyc5E54QrUj9jP1RuljzZePa8b9AMcozOIbAW4dEjnqwrUO0d TuWdD35fL9C7TLOcuai0blTztzi4GwvdcEZOLfdAX8+Ho7YsND30Fdvd/j0tD/NAmdDG A7CHcNZFu6DcAVVo7r9pBV7/kmYSbSkPoDleEmIO3QXUgCnbmkILcdogHmwtOlPtNCfv FJSPe3MaH6kaLRqk+9HEbGm8iQJNaW58q8r1PvEKzQOWW7feDm+wx9WeVE4TUOZYi0ZA G8LfZZyWzSyrKncID1wUwr9gKhbtSRxMNi/+5mXYLhG+RE0NXJyu2Ggec3NwiX8kotMT w1jg== X-Gm-Message-State: AKS2vOxmT+vhFEURF5CuNpRJAuPowcyszSAssWFL3eGQSWySTEh+hG1A TzJh6tJTIvUSIQaMMz6zjYycA6IBBisQ X-Received: by 10.84.224.74 with SMTP id a10mr5580451plt.219.1498175682464; Thu, 22 Jun 2017 16:54:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Thu, 22 Jun 2017 16:54:41 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 22 Jun 2017 16:54:41 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Ted Hardie Cc: Martin Thomson , QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="f403043738145dcc0905529535e3" 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, 22 Jun 2017 23:54:45 -0000 --f403043738145dcc0905529535e3 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 22, 2017 at 3:46 PM, Ted Hardie wrote: > On Thu, Jun 22, 2017 at 3:32 PM, Martin Thomson > wrote: > >> On 23 June 2017 at 05:15, Ted Hardie wrote: >> > My personal take on that right answer there is to support both, with an >> > explicit signal of when each model is in use, >> >> I have heard this request now from several folks at Google. > > > Please be careful withyour attributions. Several people replied with very > explicit statements that the were putting forward personal opinions. Some > of those people, including those with different opinions, have day jobs at > the same place, but we were not speaking for our employer nor with the same > experience (either at that employer or elsewhere). > +1. (To be clear, the reason I'm agreeing with Ted here is not because I'm at Google.) thanks, > > Ted > > > > > >> I don't >> know how to make this work without increasing complexity considerably >> . I'd be willing to be wrong about this, but would prefer to see a >> proposal. I don't need a fully-worked proposal with text, just a >> sketch of how the pieces work in enough detail to understand how this >> might interact with other parts of the protocol. I think that Jana >> offered to do this, so maybe I can wait for that (c.f., Mark's earlier >> statement about priority/urgency). >> > > --f403043738145dcc0905529535e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 22, 2017 at 3:46 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Thu, Jun 22, 2017 at 3:32 PM, Martin Thomson <martin.thomson@g= mail.com> wrote:
O= n 23 June 2017 at 05:15, Ted Hardie <ted.ietf@gmail.com> wrote:
> My personal take on that right answer there is to support both, with a= n
> explicit signal of when each model is in use,

I have heard this request now from several folks at Google.=C2=A0

Please be careful withyour attributio= ns.=C2=A0 Several people replied with very explicit statements that the wer= e putting forward personal opinions.=C2=A0 Some of those people, including = those with different opinions, have day jobs at the same place, but we were= not speaking for our employer nor with the same experience (either at that= employer or elsewhere).

<= /div>
+1.
(To be clear, the reason I'm agreeing with Ted = here is not because I'm at Google.)


=
=
thanks,

Ted



=C2=A0
I don't
know how to make this work without increasing complexity considerably
.=C2=A0 I'd be willing to be wrong about this, but would prefer to see = a
proposal.=C2=A0 I don't need a fully-worked proposal with text, just a<= br> sketch of how the pieces work in enough detail to understand how this
might interact with other parts of the protocol.=C2=A0 I think that Jana offered to do this, so maybe I can wait for that (c.f., Mark's earlier<= br> statement about priority/urgency).


--f403043738145dcc0905529535e3-- From nobody Thu Jun 22 17:04: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 68678129BB7 for ; Thu, 22 Jun 2017 17:04:29 -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 uCOMIudbW5Vm for ; Thu, 22 Jun 2017 17:04:24 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 B3A92129BB2 for ; Thu, 22 Jun 2017 17:04:24 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u62so14255250pgb.3 for ; Thu, 22 Jun 2017 17:04: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=pAs1Wsy80bNcp14SYW0NwgDbrw7FxdMgMEtkkLTWY6w=; b=eu4yjgcuVqyD68Y3B8UCZ1REqb0QgrnTNwj4K5ymBHMuaCpOE0kjQ+nOXFzsKPgJ+N JV14Vi7MpuaXyiAnqjPHWuY/0yyMeH+sBpCtjhnGVyPZ++B8ecimxde7qn+r118OximM KL1aSi8/a+pvclm7pJuykaPAUhjr8QdkH/NoWxcXAEnE3Z/IMPm7QRjs38FXLWHkzLIz T0jEMnhKMTP6M+rfCpvo5dEYOOlf8wHCH3UcOtMFn7mabNwqAx5q/5CJRDnuVZsKeIvM F6poki58i/UfjRjc1V6WN8qEcP4DJz/4NwODgqKKHRCZBroDUZKM6NhF5rMuwYDPTxOF q+8Q== 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=pAs1Wsy80bNcp14SYW0NwgDbrw7FxdMgMEtkkLTWY6w=; b=TA4PSzAcYRLTOZmzdVrlKnSm/+/aP6nF5DYgOvDoxQs722gzcn9XuhlPeusaJTbpbk uj3XE1giQ+NL0vfhvtc9zCJdSBKYEs/5hqJ+JKafF2OfVn2bPPNbbGE1G9G59ZXUuk6K iBz5EVrquGrxVCAtsKYRxr8uUl3veYZzfNFrKO+418odt1djglEPNfI1Gs7BiOPqCrOU 5PuX110cCJeJq282M8d/NZ3O3LWRNcGtzmM+3Q9QYAU4q67w1lH7XEi2lCCANFgu96Ti S569GE7dKTZ7WS4iuadQM+DQ1YQX3VYdRf4xpfdtfczNU88H1CsY3yoyGFhAsfY9L6Wl nRQA== X-Gm-Message-State: AKS2vOyg7pIDEvu/QoEjcrsJCfX931RKZcFJOP+dfe0AIx29CYAIkfov ik/AXdSzTWfRCq3lTP+LKeMzv0HpAfXo X-Received: by 10.99.45.6 with SMTP id t6mr5069182pgt.209.1498176264143; Thu, 22 Jun 2017 17:04:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Thu, 22 Jun 2017 17:04:23 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 22 Jun 2017 17:04:23 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson Cc: Ted Hardie , QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="94eb2c1150b6097c1905529558f7" 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, 23 Jun 2017 00:04:29 -0000 --94eb2c1150b6097c1905529558f7 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 22, 2017 at 3:32 PM, Martin Thomson wrote: > On 23 June 2017 at 05:15, Ted Hardie wrote: > > My personal take on that right answer there is to support both, with an > > explicit signal of when each model is in use, > > I have heard this request now from several folks at Google. I don't > know how to make this work without increasing complexity considerably > . I'd be willing to be wrong about this, but would prefer to see a > proposal. I don't need a fully-worked proposal with text, just a > sketch of how the pieces work in enough detail to understand how this > might interact with other parts of the protocol. I think that Jana > offered to do this, so maybe I can wait for that (c.f., Mark's earlier > statement about priority/urgency). > Ian offered to do this in an earlier email, so I'd like to wait for him. But I already outlined some of my thinking earlier. Copying and pasting from earlier email in this thread: "We need to accomodate Server Push and make it work, which, as I suggested in my earlier email, was supported in the early input draft (and in GQUIC). The application can "half close" streams that are known to be unidirectional (app read_close, app write_close). These transitions were then removed during revisions as extraneous, since they were local to an endpoint, but it seems that the core idea was lost as well. In the case of HTTP/2, since server-initiated streams are always unidirectional (Push), the application (HTTP) would always half-close them at both endpoints, not requiring any special signaling on the wire. If we want to make this more general, we could have a single "uni/bi-directional" bit in every stream frame, so that we would not require application knowledge of which streams are expected to be uni/bi-directional." I'd like to wait for Ian's PR and discuss details there, but I believe his core idea is the same. --94eb2c1150b6097c1905529558f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 22, 2017 at 3:32 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 23 June 2017 at 05:15, Ted Hardie <ted.ietf@gmail.com> wrote:
> My personal take on that right answer there is to support both, with a= n
> explicit signal of when each model is in use,

I have heard this request now from several folks at Google.=C2=A0 I = don't
know how to make this work without increasing complexity considerably
.=C2=A0 I'd be willing to be wrong about this, but would prefer to see = a
proposal.=C2=A0 I don't need a fully-worked proposal with text, just a<= br> sketch of how the pieces work in enough detail to understand how this
might interact with other parts of the protocol.=C2=A0 I think that Jana offered to do this, so maybe I can wait for that (c.f., Mark's earlier<= br> statement about priority/urgency).

Ian offered to do t= his in an earlier email, so I'd like to wait for him. But I already out= lined some of my thinking earlier. Copying and pasting from earlier email i= n this thread:

"We need to acc= omodate Server Push and make it work, which, as I suggested in my earlier e= mail, was supported in the early input draft (and in= GQUIC). The application can "half close" streams that are known = to be unidirectional (app read_close, app write_close). These transitions w= ere then removed during revisions as extraneous, since they were local to a= n endpoint, but it seems that the core idea was lost as well. In the case o= f HTTP/2, since server-initiated streams are always unidirectional (Push), = the application (HTTP) would always half-close them at both endpoints, not = requiring any special signaling on the wire.

=
If we want to make this more general, we c= ould have a single "uni/bi-directional" bit in every stream frame= , so that we would not require application knowledge of which streams are e= xpected to be uni/bi-directional."

I'd like to wait for Ian's = PR and discuss details there, but I believe his core idea is the same.
--94eb2c1150b6097c1905529558f7-- From nobody Thu Jun 22 17:14: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 865D7129BB5 for ; Thu, 22 Jun 2017 17:14:57 -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 wJbysuK0keXD for ; Thu, 22 Jun 2017 17:14:55 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 E1056129BB3 for ; Thu, 22 Jun 2017 17:14:54 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id r103so44279862wrb.0 for ; Thu, 22 Jun 2017 17:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u6bhba4jY+jwrUUxB10kWPW0Vtee+m2m7d5IdIVdUfo=; b=stz5HDC3GBb3BVkqSS5Ci9de9HvSiTl6vWmY/uyW7gV/xK94FLKOjkSPwSF2NTjnvp M7AMiebwH+7fVovi8nDC28juZuXXcNCw5NgsTIONjsrJLy/PnN5d5LlEtH8Ou81IuNGk D6SzRmluG+WWTtuGVjq4vG5QOh9yl9Z97xZoDU3hI2KIMzXJa/OqJjjbsPzoNELDFtbe p5Tgc1tuQDQhOl4Mj/+O71SlyAM8ysyDXf3zD7tyAUEBcYPAEMSq9wLh0XaMaZgcW3s+ 5avDNPwjGtjF02W4CDfZCNgxL7YYBEukpwc0X5sTGiE6eR/oTTDsUAJOGekp4p6/hlN3 2jzg== 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=u6bhba4jY+jwrUUxB10kWPW0Vtee+m2m7d5IdIVdUfo=; b=l4SSrpSg/7eAUiSxOdvWaTtvw3nNRfhG+1vjYogIpE95+ZhVL4cnYX5F92GEi/w6f4 JX/NM1dXLNUhVxqb9bDg6SATtM/eAGtTwvtKsMQPG7RCf9EXYOUhvu5ZoXcZiq5L/5B7 h2GpnJYbsrlQOV+N3Gs1hTd5mcf6xxbPlTcuWqtru9D/wcDoXqGFuwIJLLZQFDDx7tXQ Q/L7e/DJ8A2ugn2iBAmTktW+h+xDMjGEk8QRUk5D1CZG6jY4CU/99slu2DaXMpXLh4ad miXrGsFVZ2iWDIBOgdGVKmR41T2udp4OpE6qQSlx0uQb/7St3JpWD1r98fLgQV2jVZof WsSA== X-Gm-Message-State: AKS2vOw03jAL9WkFVNYzSo3DdOMn73LqvFcbHAo6DseEMWidFQyxn5FK gVZDQ/bjHHrfgZSHnzs60R78YZVV43fc X-Received: by 10.28.46.145 with SMTP id u139mr3474540wmu.5.1498176893203; Thu, 22 Jun 2017 17:14:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.217.10 with HTTP; Thu, 22 Jun 2017 17:14:52 -0700 (PDT) Received: by 10.28.217.10 with HTTP; Thu, 22 Jun 2017 17:14:52 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 22 Jun 2017 17:14:52 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114230f08817940552957d68" 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, 23 Jun 2017 00:14:57 -0000 --001a114230f08817940552957d68 Content-Type: text/plain; charset="UTF-8" Thanks for writing this up! I'm concerned that while this appears to simplify the transport draft, it actually ends up a net increase in complexity. By moving the burden of associating the "request stream" and the "response stream" up to the application, say HTTP, we require that each application implement an association mechanism independently. This means that the logic/code/complexity that we remove from transport draft simply moves to the HTTP draft and is then going to be *duplicated* in every other app-over-QUIC mapping draft which want to do bidirectional streaming. I am also concerned that there is no deployment experience with a unidirectional-stream-only API. While I have no doubt that it would be possible to build such a system, without experience to guide us we are likely to be in the dark as to what dragons lurk in the corners. I would be happy to see unidirectional streams added in addition to bidirectional streams but am not supportive of removing bidirectional streams. That being said, I do really like the idea of HTTP PUSH_PROMISE promising a "push ID" instead of a stream ID so as to remove the complexity around stream limits/reserved states. I would like to see this added to the mapping independent of the unidirectional stream change as I think it's an elegant solution to a thorny problem. (QUIC used to have a reserved state which promised streams entered before they were open which avoided hitting the open stream limits and allowed servers to promise more streams than it could currently create (say to push all of the thumbnails on a page of image search results. When the reserved state was removed from the spec, we lost this ability, which as we know is a bummer) Cheers, Ryan On Jun 21, 2017 12:42 AM, "Martin Thomson" wrote: I've created a pull request unidirectional streams. https://github.com/quicwg/base-drafts/pull/643 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. --001a114230f08817940552957d68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for writing this up!
<= br>
I'm concerned that while this appears to sim= plify the transport draft, it actually ends up a net increase in complexity= . By moving the burden of associating the "request stream" and th= e "response stream" up to the application, say HTTP, we require t= hat each application implement an association mechanism independently. This= means that the logic/code/complexity that we remove from transport draft s= imply moves to the HTTP draft and is then going to be *duplicated* in every= other app-over-QUIC mapping draft which want to do bidirectional streaming= .

I am also concerned th= at there is no deployment experience with a unidirectional-stream-only API.= While I have no doubt that it would be possible to build such a system, wi= thout experience to guide us we are likely to be in the dark as to what dra= gons lurk in the corners. I would be happy to see unidirectional streams ad= ded in addition to bidirectional streams but am not supportive of removing = bidirectional streams.

T= hat being said, I do really like the idea of HTTP PUSH_PROMISE promising a = "push ID" instead of a stream ID so as to remove the complexity a= round stream limits/reserved states. I would like to see this added to the = mapping independent of the unidirectional stream change as I think it's= an elegant solution to a thorny problem. (QUIC used to have a reserved sta= te which promised streams entered before they were open which avoided hitti= ng the open stream limits and allowed servers to promise more streams than = it could currently create (say to push all of the thumbnails on a page of i= mage search results. When the reserved state was removed from the spec, we = lost this ability, which as we know is a bummer)
Cheers,

Ryan

On Jun 21, 2017 12:42 AM, "Martin Thomson" <martin.thomson@gm= ail.com> wrote:
I've created a pull request unidirectional streams.<= br>
https://github.com/quicwg/base-drafts/pull/643

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.=C2=A0 Each has three states: idle, open, and closed.=C2=A0 I separated the transitions for sending and receiving because=
that turned out to be easier to explain.=C2=A0 The reordering thing makes them different in subtle ways.

That's all.=C2=A0 The changes in transport are relatively small and the= y
simplify streams a lot.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 First, request and response correlation can't use forwar= d
references because that would mean the client would be exerting
(uncoordinated) control over server streams.=C2=A0 Second, that gives the server the most flexibility in terms of how it answers requests (see
#281).=C2=A0 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.=C2=A0 This empty frame
indicates that another stream will include the body of the message -
or a promise for a body.=C2=A0 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.=C2=A0 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<= br> create a way to cancel them between the time that the PUSH_PROMISE is
sent and when the push stream is created.=C2=A0 That's called RST_PUSH.=

## Things That Need Improvement

I haven't based this on #171.=C2=A0 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.=C2=A0 (That's a taste thing.)=C2=A0 This really assume= s that we
accept something very much like #171.

This really needs QPACK/QCRAM.=C2=A0 Right now, it is impossible to cancel<= br> some types of request using RST_STREAM because not all messages will
have a body (#176 again).=C2=A0 On balance, given that bodies are what you<= br> really want to kill, it's not disastrous, but it's a problem
nonetheless.=C2=A0 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 .=C2=A0 It
doesn't exactly need that, but merging the streams would make things a<= br> lot easy, both conceptually and structurally.

I chose the simplest possible encoding for all of the fields that I
touched.=C2=A0 That means that stream IDs are all 32 bits in size and the HAS_BODY frame takes an entire 9 octets.=C2=A0 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.=C2=A0 Use of an as-yet-not-created push ID as a node in the priority tree would allow
for prioritization to use "empty" nodes.=C2=A0 We'd need to e= xplicitly
allow that though.

# Fixes

Closes #515, #240, #281, #175.


--001a114230f08817940552957d68-- From nobody Thu Jun 22 17:20: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 7918D129BB3 for ; Thu, 22 Jun 2017 17:20:26 -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 dONa80EawqY3 for ; Thu, 22 Jun 2017 17:20:25 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 0ED51129BB2 for ; Thu, 22 Jun 2017 17:20:25 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id l13so21518033lfl.1 for ; Thu, 22 Jun 2017 17:20:24 -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=EL+S2xygfr5LINizxMioNRUic8CTbrBhCuWqdCGyP18=; b=VAUxoNtx4sFlXJTzMn27XeqYizZ++AUKdt6+8YdymLIg3SvoveMwxpHqj1MfCgWrbo v3UHld57GKzRh2OU7BWZZxAJNJwU5C35rrTgveElSTUjvFn+WPuQby3of/AeQJTBu3gN rqiuS5AY+XOcfR4USV6VBBPGHVGbznGMTlt1OJTn9AoEH4m5fpoxONUhpF6o42CrrRYy uQi1Twx8rXaV2+JafSTxq+HNIHtztX+GbW84s0ke2+JTdWgttSDs58onVBrYDwc8kZ4D Iua15d10iZEAOm6pAu8/1jTsd5w38QckXwycGRZrsrVZeMBsLINYziaroNNFXQW++mSm w1PA== 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=EL+S2xygfr5LINizxMioNRUic8CTbrBhCuWqdCGyP18=; b=pVGQZkE+BgCg6IfNC4Amwly5wUr8bqNRXdamJsIW30fhBW5UXFjmnSfkpBNND20/X/ 79aWzbbsIEQf2U3kQIwbO2fa1P1oDcTYGGxGZJdEF8FY/SY8L6vOjTxuG2e15UjTmeoi SMjGtnu3fH58qkyGzRSBIRZMTCGOwWiPrh5Kw+clXx16imtzx6EMbdPzjXggRaphOa9Q mjPXCyscGeSPGKTQc61OnN071CgmDtSIH3WC8pInYVwxsDNlLaYwJwXqa/SiIr5MTMoL a7WXvVDLsJDIMHiGDd2WPG554JLIT53MvOUIHILBRKmeFXP2HO6WckvetFXfbXuVUQvY xIJA== X-Gm-Message-State: AKS2vOzkIMze3G6RMkrj7fjMKv1XHDbJE+YQEukBDG9NObfakDuxDPl6 UttBmFkW8kNP9U5SvGYfxlYcW+tRCA== X-Received: by 10.25.202.72 with SMTP id h8mr1834792lfj.172.1498177223381; Thu, 22 Jun 2017 17:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Thu, 22 Jun 2017 17:20:22 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 23 Jun 2017 10:20:22 +1000 Message-ID: Subject: Re: Unidirectional streams PR To: Ryan Hamilton 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: Fri, 23 Jun 2017 00:20:26 -0000 On 23 June 2017 at 10:14, Ryan Hamilton wrote: > When the reserved state was removed from the spec, we lost this ability Removing reserved didn't change anything here, unless I missed something. The server still needs to commit to a stream ID for pushing. The stream limits still applied when the server wanted to use the stream. From nobody Thu Jun 22 18:06: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 121BA129BBD for ; Thu, 22 Jun 2017 18:06:48 -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, 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 iXPnC2CrvbDs for ; Thu, 22 Jun 2017 18:06:46 -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 5418E129BD7 for ; Thu, 22 Jun 2017 18:06:46 -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 v5N12C0g026686; Fri, 23 Jun 2017 02:06:43 +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=I18pBx3dGHO+6Ut1t1RMYcAZyZ24JLTZKtZGqJU+0JM=; b=XZ5nhLbssVQOY41kj8xLfEvx1ZPw8Hln1l48mZvD87+XpLcvpQEJjSPRRC5coeKmxEir v/rtgsQFg4osra6WQKx2EWrnVhjskZwnAjmGuQ8x0EHehVjI54mJ5JOT8ZOvZa/9Z9Tq MIwISzO5vEaEJUSWYhDXj5mPFNciVXLVlfS9Obf12gEhPlsamRIdWt0j/PLpPVNwUgb+ 7nvk3Rb06TRnRa5z3TOu2iHoCtcwCPaK4XKzKDH2n+sQQDmAMJX8HvycFnZM97AlqP6e EymA7giAQHhbd2m/bb57u+NRyyfzrzyPum+whTz/oqGEqgEWmJjzYE3HZ5tLhDhsiCeh QA== 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 2b8kpx1p6c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 02:06:43 +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 v5N15ZmA005387; Thu, 22 Jun 2017 21:06:42 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b4yrvn0y0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Jun 2017 21:06:42 -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; Thu, 22 Jun 2017 21:06:41 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 22 Jun 2017 21:06:41 -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, 22 Jun 2017 21:06:41 -0400 From: "Lubashev, Igor" To: Mike Bishop , Martin Thomson , Ted Hardie CC: Jana Iyengar , QUIC WG , Patrick McManus Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHzFJcNmOfPnkGlJjRXQ/9soKIvh8kAgADqdYCAACIYgIABI/8AgAAEzYCAAARGgP//0FFw Date: Fri, 23 Jun 2017 01:06:40 +0000 Message-ID: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> References: 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.34.60] 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-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230016 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230015 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, 23 Jun 2017 01:06:48 -0000 SSBsaWtlIHRoZSBpZGVhIG9mIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMsIGlmIHRoZXkgbWFrZSBs aWZlIGVhc2llciBmb3IgYXBwcyAtLSBib3RoICJ0cmFkaXRpb25hbCIgYXBwcyBsaWtlIEgyIGFz IHdlbGwgYXMgbGVzcyB1c3VhbCBhcHBzIGxpa2Ugc3NoIChvbmUgc3RyZWFtIGluIG9uZSBkaXJl Y3Rpb24sIHR3byBhc3NvY2lhdGVkIHN0cmVhbXMgaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiku DQoNCkkgYWxzbyBsaWtlIE1pa2UncyBpZGVhIG9mIE9QRU5fU1RSRUFNIGZyYW1lLiAgVGhlIHdh eSBJJ2QgZGVzY3JpYmUgT1BFTl9TVFJFQU0gZnJhbWUgaXMgdGhhdCBpdCBpcyBpbXBsaWNpdGx5 IGEgU1RSRUFNIGZyYW1lIHdpdGggMC1vZmZzZXQgYW5kIGEgc2V0IG9mICJwZXItc3RyZWFtIHBy b3BlcnRpZXMiLg0KDQpBbiBpbXBvcnRhbnQgcG9pbnQgaXMgdGhhdCB3aGVuIFRyYW5zcG9ydCBp cyBhd2FyZSBvZiB0aGUgYXNzb2NpYXRpb24gb2YgdHdvIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMs IHRoZSBUcmFuc3BvcnQgQVBJIHdvdWxkIGJlIGFibGUgdG8gaW1wbGVtZW50IGEgYmlkaXJlY3Rp b25hbCBzb2NrZXQtbGlrZSBhYnN0cmFjdGlvbiBmb3IgYXBwbGljYXRpb25zIHRoYXQgZGVzaXJl IG9uZS4NCg0KDQpPUEVOX1NUUkVBTSBmcmFtZQ0KVGhlIHR5cGUgYnl0ZSBmb3IgYSBPUEVOX1NU UkVBTSBmcmFtZSBjb250YWlucyBlbWJlZGRlZCBmbGFncywgYW5kIGlzIGZvcm1hdHRlZCBhcyAx MEZTU1BQRC4gVGhlIEYsIFNTLCBhbmQgRCBiaXRzIGFyZSBwYXJzZWQgYXMgcGVyIFNUUkVBTSBm cmFtZS4NCiogVGhlIFBQIGJpdHMgZW5jb2RlIHRoZSBzaXplIG9mIHRoZSBQYXJhbXMgQml0bWFw IGZpZWxkLiBUaGUgdmFsdWVzIDAwLCAwMSwgMDIsIGFuZCAwMyBpbmRpY2F0ZSBsZW5ndGhzIG9m IDgsIDE2LCAyNCwgYW5kIDMyIGJpdHMgbG9uZyByZXNwZWN0aXZlbHkuDQoNClRoZSB0d28gTGVh c3QgU2lnbmlmaWNhbnQgYml0cyBvZiB0aGUgUGFyYW1zIEJpdG1hcCBpbmRpY2F0ZSB0aGUgbGVu Z3RoIG9mIHRoZSBBc3NvY2lhdGVkIFN0cmVhbSBJRC4gVGhlIExTQiB2YWx1ZXMgMDAsIDAxLCAw MiwgYW5kIDAzIGluZGljYXRlIGxlbmd0aHMgb2YgMCAobm9uZSksIDgsIDE2LCBhbmQgMzIgYml0 cyBsb25nIHJlc3BlY3RpdmVseS4NCldlIGNhbiBkZWZpbmUgdXAgdG8gMzAgYWRkaXRpb25hbCBi aXRzIHRvIGJlIG1lYW5pbmdmdWwgdG8gdGhlIHRyYW5zcG9ydC4gIChJIGNhbiBpbWFnaW5lIFBh cnRpYWwtUmVsaWFiaWxpdHkgYml0LCBGbG93LUNvbnRyb2wtRXhlbXB0IGJpdCwgUHJpb3JpdHkt RGVsaXZlcnkgKGFrYSAiRG9udEJ1ZmZlciIpIGJpdCwgZXRjKS4NCg0KMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KIDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0K Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCnwgICAgICAgICAgICAgICAgICAgIFN0cmVhbSBJRCAoOC8xNi8yNC8zMikgICAg ICAgICAgICAgICAgICAgLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICBQYXJhbXMgQml0 bWFwICAoOC8xNi8yNC8zMikgICAgICAgICAgICAgICAgICAgLi4uDQorLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAg ICAgICAgIEFzc29jaWF0ZWQgU3RyZWFtIElEICgwLzgvMTYvMzIpICAgICAgICAgICAgICAgICAg ICAuLi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQp8ICAgICAgIFtEYXRhIExlbmd0aCAoMTYpXSAgICAgIHwgICAgICAg IFN0cmVhbSBEYXRhICgqKSAgICAgIC4uLg0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KTm90ZSB0aGF0IGlmIFBhcmFt cyBCaXRtYXAgaXMgMHgwLCB0aGlzIE9QRU5fU1RSRUFNIGZyYW1lIGlzIGVxdWl2YWxlbnQgdG8g U1RSRUFNIGZyYW1lIHdpdGggT089MC4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb21d IA0KU2VudDogVGh1cnNkYXksIEp1bmUgMjIsIDIwMTcgNjo0OCBQTQ0KVG86IE1hcnRpbiBUaG9t c29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFp bC5jb20+DQpDYzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc+OyBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPg0KU3ViamVj dDogUkU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgUFINCg0KSSBzdXBwb3NlIHlvdSBjb3VsZCBk cm9wIHRoZSBzdHJlYW0gdHlwZSBoZWFkZXIgZnJvbSBIVFRQIGludG8gUVVJQyBhbmQgbWFrZSB0 aGUgdHlwZXMgImJpZGlyZWN0aW9uYWwgc3RyZWFtLCIgInVuaWRpcmVjdGlvbmFsIHN0cmVhbSwi IGFuZCAibWF0ZSBvZiBiaWRpcmVjdGlvbmFsIHN0cmVhbSI7IHRoZSBsYXN0IHdvdWxkIGZ1cnRo ZXIgbmVlZCB0byBpZGVudGlmeSB3aGljaCBwZWVyIHN0cmVhbSBpdCBjb3JyZXNwb25kZWQgdG8u DQoNCkJ1dCBtYWtpbmcgdGhlbSB0aGUgZmlyc3QgY291cGxlIGJ5dGVzIG9mIHRoZSBzdHJlYW0g ZGF0YSBmZWVscyBraW5kIG9mIGtsdWRneSBpZiB0aGlzIGlzIGZ1bmRhbWVudGFsbHkgYnVpbHQg aW50byB0aGUgdHJhbnNwb3J0LCB3aGljaCBtZWFucyB0aGV5IHJlYWxseSBiZWxvbmcgaW4gYSBk ZWRpY2F0ZWQgZnJhbWUuICBNYXliZSBhIGRlZGljYXRlZCBPUEVOX1NUUkVBTSBmcmFtZSwgd2hp Y2ggYmxvY2tzIGFueSBkYXRhIHJlY2VpdmVkIG9uIHRoYXQgc3RyZWFtIHVudGlsIHlvdSBrbm93 IHdoYXQgdHlwZSBpdCBpcz8NCg0KQWN0dWFsbHksIGlmIHdlJ3JlIHBsYW5uaW5nIG9uIGludHJv ZHVjaW5nIG90aGVyIHBlci1zdHJlYW0gcHJvcGVydGllcyBsaWtlIHBhcnRpYWwgcmVsaWFiaWxp dHksIHRoZXJlIG1pZ2h0IGJlIHZhbHVlIGluIGFuIE9QRU5fU1RSRUFNIGZyYW1lIHdoZXJlIHdl IGNhbiBkZXNjcmliZSBhIHN0cmVhbSdzIGRlc2lyZWQgcHJvcGVydGllcyBiZWZvcmUgYW55IGRh dGEgZmxvd3MuLi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFtt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24N ClNlbnQ6IFRodXJzZGF5LCBKdW5lIDIyLCAyMDE3IDM6MzIgUE0NClRvOiBUZWQgSGFyZGllIDx0 ZWQuaWV0ZkBnbWFpbC5jb20+DQpDYzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IFFV SUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEu Y29tPg0KU3ViamVjdDogUmU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgUFINCg0KT24gMjMgSnVu ZSAyMDE3IGF0IDA1OjE1LCBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0K PiBNeSBwZXJzb25hbCB0YWtlIG9uIHRoYXQgcmlnaHQgYW5zd2VyIHRoZXJlIGlzIHRvIHN1cHBv cnQgYm90aCwgd2l0aCANCj4gYW4gZXhwbGljaXQgc2lnbmFsIG9mIHdoZW4gZWFjaCBtb2RlbCBp cyBpbiB1c2UsDQoNCkkgaGF2ZSBoZWFyZCB0aGlzIHJlcXVlc3Qgbm93IGZyb20gc2V2ZXJhbCBm b2xrcyBhdCBHb29nbGUuICBJIGRvbid0IGtub3cgaG93IHRvIG1ha2UgdGhpcyB3b3JrIHdpdGhv dXQgaW5jcmVhc2luZyBjb21wbGV4aXR5IGNvbnNpZGVyYWJseSAuICBJJ2QgYmUgd2lsbGluZyB0 byBiZSB3cm9uZyBhYm91dCB0aGlzLCBidXQgd291bGQgcHJlZmVyIHRvIHNlZSBhIHByb3Bvc2Fs LiAgSSBkb24ndCBuZWVkIGEgZnVsbHktd29ya2VkIHByb3Bvc2FsIHdpdGggdGV4dCwganVzdCBh IHNrZXRjaCBvZiBob3cgdGhlIHBpZWNlcyB3b3JrIGluIGVub3VnaCBkZXRhaWwgdG8gdW5kZXJz dGFuZCBob3cgdGhpcyBtaWdodCBpbnRlcmFjdCB3aXRoIG90aGVyIHBhcnRzIG9mIHRoZSBwcm90 b2NvbC4gIEkgdGhpbmsgdGhhdCBKYW5hIG9mZmVyZWQgdG8gZG8gdGhpcywgc28gbWF5YmUgSSBj YW4gd2FpdCBmb3IgdGhhdCAoYy5mLiwgTWFyaydzIGVhcmxpZXIgc3RhdGVtZW50IGFib3V0IHBy aW9yaXR5L3VyZ2VuY3kpLg0KDQo= From nobody Thu Jun 22 18:25:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077E9129B9B for ; Thu, 22 Jun 2017 18:25:45 -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 FA_EQ23Tt0PG for ; Thu, 22 Jun 2017 18:25:42 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A87126DFB for ; Thu, 22 Jun 2017 18:25:42 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id e187so14971954pgc.1 for ; Thu, 22 Jun 2017 18:25:42 -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=lbym2AV7tYCU+u9wTwnQm1qFukhFBVqHst7X1w4K/hQ=; b=R7F5GhgDiZGujzLkx056pLYC4ZywMXenW6HtbZjLHEk04/c9jM7X9oCWh910BCoHjo RU++ko6xV22kkBIuQirTCwDvwgmZ0H7K6/GuwXzJcus2QNykMabyXMvy91JAgJptOoSl q16eanYkIj4YKqHqkemCtVBCzAywLfr5W/YZYEnRoB/+Z7MPpNUGSpmzl7DJwDtE+6QW NltBRgmrmmrS/9tCEXmhsaszijXiZ8ULH4usKn2+mXBaCTM5oLlHZk5z8EoBRJiNWUJR CkLWrPY3xntoHQ3n0XFymwJEvZNwoDmk6xFauSpIZUfDBsiC3cAgKWtsnjJlU5O+dvMh Y9Hw== 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=lbym2AV7tYCU+u9wTwnQm1qFukhFBVqHst7X1w4K/hQ=; b=eZOaaLHtDWvjRYdIyNzVCgKPTpBtYJfwhpqyswD7hga5P32z1MmGz/qSy0f+kdhM4E aEpy3f7ZyrPAWYgKXhdBoERpG2UmcUmWqWMHGoPXglEjBwqGhZT1qnyIO0AJO39c/EwC rnrXveAs1hYEoRZ9LUgnDKB56fVIH7QNIbzIVy/5wLj2dGG096RO62MPyYTdGmAG9iej pS7nIEgcv1NowbXSyHiA+K/eb/B4LWVydljSlfP6qSp0eWu59+75Ygb3u+UeuOJZ2hLJ /k6ZZlooE6F/tS/fhJmCXGv6CCADyywKKoCxP6HpH2kKalvWYTcv4IxXEkt6Dy/pkyyU /8iQ== X-Gm-Message-State: AKS2vOym3KMYzoSzDAVjpnwbGPYluH17IiYfiUxwsZe50py00v0/MGQE ovXRIIJx7AIt0vINGyUBLLbLnC64RKD1 X-Received: by 10.99.121.1 with SMTP id u1mr5469977pgc.20.1498181141507; Thu, 22 Jun 2017 18:25:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.39 with HTTP; Thu, 22 Jun 2017 18:25:40 -0700 (PDT) In-Reply-To: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> From: Jana Iyengar Date: Thu, 22 Jun 2017 18:25:40 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: "Lubashev, Igor" Cc: Mike Bishop , Martin Thomson , Ted Hardie , QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="94eb2c0ef260c015d80552967ae7" 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, 23 Jun 2017 01:25:45 -0000 --94eb2c0ef260c015d80552967ae7 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 22, 2017 at 6:06 PM, Lubashev, Igor wrote: > I like the idea of unidirectional streams, if they make life easier for > apps -- both "traditional" apps like H2 as well as less usual apps like ssh > (one stream in one direction, two associated streams in the opposite > direction). > > I also like Mike's idea of OPEN_STREAM frame. The way I'd describe > OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offset and > a set of "per-stream properties". > > An important point is that when Transport is aware of the association of > two unidirectional streams, the Transport API would be able to implement a > bidirectional socket-like abstraction for applications that desire one. > I'm not sure I follow your thinking here: are you suggesting that QUIC implement bidirectional streams in addition to unidirectional streams? - jana > > OPEN_STREAM frame > The type byte for a OPEN_STREAM frame contains embedded flags, and is > formatted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM frame. > * The PP bits encode the size of the Params Bitmap field. The values 00, > 01, 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respectively. > > The two Least Significant bits of the Params Bitmap indicate the length of > the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate > lengths of 0 (none), 8, 16, and 32 bits long respectively. > We can define up to 30 additional bits to be meaningful to the transport. > (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, > Priority-Delivery (aka "DontBuffer") bit, etc). > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream ID (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Params Bitmap (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Associated Stream ID (0/8/16/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Data Length (16)] | Stream Data (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent to > STREAM frame with OO=0. > > > > -----Original Message----- > From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] > Sent: Thursday, June 22, 2017 6:48 PM > To: Martin Thomson ; Ted Hardie < > ted.ietf@gmail.com> > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > Subject: RE: Unidirectional streams PR > > I suppose you could drop the stream type header from HTTP into QUIC and > make the types "bidirectional stream," "unidirectional stream," and "mate > of bidirectional stream"; the last would further need to identify which > peer stream it corresponded to. > > But making them the first couple bytes of the stream data feels kind of > kludgy if this is fundamentally built into the transport, which means they > really belong in a dedicated frame. Maybe a dedicated OPEN_STREAM frame, > which blocks any data received on that stream until you know what type it > is? > > Actually, if we're planning on introducing other per-stream properties > like partial reliability, there might be value in an OPEN_STREAM frame > where we can describe a stream's desired properties before any data > flows.... > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Thursday, June 22, 2017 3:32 PM > To: Ted Hardie > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > Subject: Re: Unidirectional streams PR > > On 23 June 2017 at 05:15, Ted Hardie wrote: > > My personal take on that right answer there is to support both, with > > an explicit signal of when each model is in use, > > I have heard this request now from several folks at Google. I don't know > how to make this work without increasing complexity considerably . I'd be > willing to be wrong about this, but would prefer to see a proposal. I > don't need a fully-worked proposal with text, just a sketch of how the > pieces work in enough detail to understand how this might interact with > other parts of the protocol. I think that Jana offered to do this, so > maybe I can wait for that (c.f., Mark's earlier statement about > priority/urgency). > > --94eb2c0ef260c015d80552967ae7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 22, 2017 at 6:06 PM, Lubashev, Igor <ilubashe@akamai.com&g= t; wrote:
I like the idea of unidi= rectional streams, if they make life easier for apps -- both "traditio= nal" apps like H2 as well as less usual apps like ssh (one stream in o= ne direction, two associated streams in the opposite direction).

I also like Mike's idea of OPEN_STREAM frame.=C2=A0 The way I'd des= cribe OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offs= et and a set of "per-stream properties".

An important point is that when Transport is aware of the association of tw= o unidirectional streams, the Transport API would be able to implement a bi= directional socket-like abstraction for applications that desire one.

I'm not sure I follow your thinking here= : are you suggesting that QUIC implement bidirectional streams in addition = to unidirectional streams?

- jana
=C2=A0=

OPEN_STREAM frame
The type byte for a OPEN_STREAM frame contains embedded flags, and is forma= tted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM frame.
* The PP bits encode the size of the Params Bitmap field. The values 00, 01= , 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respectively.<= br>
The two Least Significant bits of the Params Bitmap indicate the length of = the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate length= s of 0 (none), 8, 16, and 32 bits long respectively.
We can define up to 30 additional bits to be meaningful to the transport.= =C2=A0 (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, Pri= ority-Delivery (aka "DontBuffer") bit, etc).

0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stre= am ID (8/16/24/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Params Bitmap=C2= =A0 (8/16/24/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Associated Stream ID (0/8/16/32)= =C2=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[Data Length (16)]=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stream Data (*)=C2=A0 =C2=A0 =C2=A0 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent to = STREAM frame with OO=3D0.



-----Original Message-----
From: Mike Bishop [mailto:M= ichael.Bishop@microsoft.com]
Sent: Thursday, June 22, 2017 6:48 PM
To: Martin Thomson <martin.t= homson@gmail.com>; Ted Hardie <ted.ietf@gmail.com>
Cc: Jana Iyengar <jri@google.com&g= t;; QUIC WG <quic@ietf.org>; Pat= rick McManus <pmcmanus@mozilla.c= om>
Subject: RE: Unidirectional = streams PR

I suppose you could drop the stream type header from HTTP into QUIC and mak= e the types "bidirectional stream," "unidirectional stream,&= quot; and "mate of bidirectional stream"; the last would further = need to identify which peer stream it corresponded to.

But making them the first couple bytes of the stream data feels kind of klu= dgy if this is fundamentally built into the transport, which means they rea= lly belong in a dedicated frame.=C2=A0 Maybe a dedicated OPEN_STREAM frame,= which blocks any data received on that stream until you know what type it = is?

Actually, if we're planning on introducing other per-stream properties = like partial reliability, there might be value in an OPEN_STREAM frame wher= e we can describe a stream's desired properties before any data flows..= ..

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Martin Thomson
Sent: Thursday, June 22, 2017 3:32 PM
To: Ted Hardie <ted.ietf@gmail.com= >
Cc: Jana Iyengar <jri@google.com&g= t;; QUIC WG <quic@ietf.org>; Pat= rick McManus <pmcmanus@mozilla.c= om>
Subject: Re: Unidirectional streams PR

On 23 June 2017 at 05:15, Ted Hardie <ted.ietf@gmail.com> wrote:
> My personal take on that right answer there is to support both, with > an explicit signal of when each model is in use,

I have heard this request now from several folks at Google.=C2=A0 I don'= ;t know how to make this work without increasing complexity considerably .= =C2=A0 I'd be willing to be wrong about this, but would prefer to see a= proposal.=C2=A0 I don't need a fully-worked proposal with text, just a= sketch of how the pieces work in enough detail to understand how this migh= t interact with other parts of the protocol.=C2=A0 I think that Jana offere= d to do this, so maybe I can wait for that (c.f., Mark's earlier statem= ent about priority/urgency).


--94eb2c0ef260c015d80552967ae7-- From nobody Thu Jun 22 18:43: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 6F642129BF0 for ; Thu, 22 Jun 2017 18:43:31 -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 fpjqRFBfvhNB for ; Thu, 22 Jun 2017 18:43:28 -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 311FF129BEE for ; Thu, 22 Jun 2017 18:43:28 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id v7so12307107ywc.2 for ; Thu, 22 Jun 2017 18:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dSp5lt/CPYchMbUpR3Vvt6zgWvsXg5/LdsB7nz+l1jc=; b=ZKgcDbETlAZlPniN5yN+he1gxCJyE/LgEXQ1zzk0Fg1o75XkuUbN288xfwO+7A0HYj S0K25mtmdcZYFSl2aQ4qFHHUnrVg8Pn1R99Pgi/UX+XSv25gVy6vsiwIoVIYk7V+tU75 eDPjHSMuwmzoyLfAQIiRjlmV299ORcsVILQ/A6iALGetdZRUr85Q9qkA3KVR7OsmeFwk PZ0YmvnPE0mlpGlCUNG97vpWCSj4ElhMrAllHpOUEN7Z+1b2ULqziW8Z7HsYYYMwLEaK gEtGGJhaR39d2+olq6GS1gsYZIPpRobdlsUbGj+ufW+KfLb1QY+loy2M/3OPmgpDuU1R za+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dSp5lt/CPYchMbUpR3Vvt6zgWvsXg5/LdsB7nz+l1jc=; b=Nuhll2JFFH2/NXtZNmEO3OBSSfNgrngqg9GPwPrGgEHCYBrPTSzR7lOrFCGMxfs0tC CKBN9Mc0RJo+coA96dWA/rE9sQ+XkzmvjMQawYpg/M78NAu8hFT+zX1EuOhmZJtVMbz7 A6bGQzOORjjUVnKQd0GhO4rKywcsfa5muEytzxX+XjgABS86jrUuA6BJmrBcF/d4ry4k 73FOxJAsAGjwQVDBDQ3SI/FaaL/1gXtjk3IUSp6VBg2eLrXH+bqg2u5TpLJCg8BxnpFw 3afsUXsYDcY7yzEowdBMa4x7SIwBKHBS30lOuJ3G2WeS7bBkLt4E2EmqpwWXFUAS27yY 0EMQ== X-Gm-Message-State: AKS2vOxf+NOjkswKsZykmmGBM8ZB4NhvzdTzQW2zlfbOUMjIsCB61cSB C4YmlYQHrjv/+t5huRbXDsXiOss3pewE X-Received: by 10.13.229.193 with SMTP id o184mr4065676ywe.101.1498182207216; Thu, 22 Jun 2017 18:43:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.3 with HTTP; Thu, 22 Jun 2017 18:43:06 -0700 (PDT) In-Reply-To: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ian Swett Date: Thu, 22 Jun 2017 21:43:06 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: "Lubashev, Igor" Cc: Mike Bishop , Martin Thomson , Ted Hardie , Jana Iyengar , QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="94eb2c081d7445f1a3055296bae5" 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, 23 Jun 2017 01:43:31 -0000 --94eb2c081d7445f1a3055296bae5 Content-Type: text/plain; charset="UTF-8" As promised, here is my 1 bit extension to the existing QUIC STREAM frame to support unidirectional streams in addition to bidirectional streams. It uses an extra bit in the type byte to indicate a STREAM frame is unidirectional, and hence the stream is to be opened in a half-closed(unidirectional) state. There are many ways to frame this, which I'm happy to discuss, but the key idea is that adding unidirectional streams to the existing design does not add much complexity, and provides a more flexible API to use cases including server push and RTP. https://github.com/quicwg/base-drafts/pull/656 PS: This does not solve the issue Ryan identified above with PUSH_PROMISE transitioning to a push id to avoid using up open stream limits. I think that should be separable and easy to put on top of this PR as well. On Thu, Jun 22, 2017 at 9:06 PM, Lubashev, Igor wrote: > I like the idea of unidirectional streams, if they make life easier for > apps -- both "traditional" apps like H2 as well as less usual apps like ssh > (one stream in one direction, two associated streams in the opposite > direction). > > I also like Mike's idea of OPEN_STREAM frame. The way I'd describe > OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offset and > a set of "per-stream properties". > > An important point is that when Transport is aware of the association of > two unidirectional streams, the Transport API would be able to implement a > bidirectional socket-like abstraction for applications that desire one. > > > OPEN_STREAM frame > The type byte for a OPEN_STREAM frame contains embedded flags, and is > formatted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM frame. > * The PP bits encode the size of the Params Bitmap field. The values 00, > 01, 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respectively. > > The two Least Significant bits of the Params Bitmap indicate the length of > the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate > lengths of 0 (none), 8, 16, and 32 bits long respectively. > We can define up to 30 additional bits to be meaningful to the transport. > (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, > Priority-Delivery (aka "DontBuffer") bit, etc). > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream ID (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Params Bitmap (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Associated Stream ID (0/8/16/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Data Length (16)] | Stream Data (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent to > STREAM frame with OO=0. > > > > -----Original Message----- > From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] > Sent: Thursday, June 22, 2017 6:48 PM > To: Martin Thomson ; Ted Hardie < > ted.ietf@gmail.com> > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > Subject: RE: Unidirectional streams PR > > I suppose you could drop the stream type header from HTTP into QUIC and > make the types "bidirectional stream," "unidirectional stream," and "mate > of bidirectional stream"; the last would further need to identify which > peer stream it corresponded to. > > But making them the first couple bytes of the stream data feels kind of > kludgy if this is fundamentally built into the transport, which means they > really belong in a dedicated frame. Maybe a dedicated OPEN_STREAM frame, > which blocks any data received on that stream until you know what type it > is? > > Actually, if we're planning on introducing other per-stream properties > like partial reliability, there might be value in an OPEN_STREAM frame > where we can describe a stream's desired properties before any data > flows.... > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Thursday, June 22, 2017 3:32 PM > To: Ted Hardie > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > Subject: Re: Unidirectional streams PR > > On 23 June 2017 at 05:15, Ted Hardie wrote: > > My personal take on that right answer there is to support both, with > > an explicit signal of when each model is in use, > > I have heard this request now from several folks at Google. I don't know > how to make this work without increasing complexity considerably . I'd be > willing to be wrong about this, but would prefer to see a proposal. I > don't need a fully-worked proposal with text, just a sketch of how the > pieces work in enough detail to understand how this might interact with > other parts of the protocol. I think that Jana offered to do this, so > maybe I can wait for that (c.f., Mark's earlier statement about > priority/urgency). > > --94eb2c081d7445f1a3055296bae5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As promised, here is my 1 bit extension to the existing QU= IC STREAM frame to support unidirectional streams in addition to bidirectio= nal streams.=C2=A0 It uses an extra bit in the type byte to indicate a STRE= AM frame is unidirectional, and hence the stream is to be opened in a half-= closed(unidirectional) state.

There are many ways to fra= me this, which I'm happy to discuss, but the key idea is that adding un= idirectional streams to the existing design does not add much complexity, a= nd provides a more flexible API to use cases including server push and RTP.=

=
PS: This does not solve the issue Ryan identified above with= PUSH_PROMISE transitioning to a push id to avoid using up open stream limi= ts.=C2=A0 I think that should be separable and easy to put on top of this P= R as well.

On Thu, Jun 22, 2017 at 9:06 PM, Lubashev, Igor <= ilubashe@akamai.co= m> wrote:
I like the idea o= f unidirectional streams, if they make life easier for apps -- both "t= raditional" apps like H2 as well as less usual apps like ssh (one stre= am in one direction, two associated streams in the opposite direction).

I also like Mike's idea of OPEN_STREAM frame.=C2=A0 The way I'd des= cribe OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offs= et and a set of "per-stream properties".

An important point is that when Transport is aware of the association of tw= o unidirectional streams, the Transport API would be able to implement a bi= directional socket-like abstraction for applications that desire one.


OPEN_STREAM frame
The type byte for a OPEN_STREAM frame contains embedded flags, and is forma= tted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM frame.
* The PP bits encode the size of the Params Bitmap field. The values 00, 01= , 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respectively.<= br>
The two Least Significant bits of the Params Bitmap indicate the length of = the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate length= s of 0 (none), 8, 16, and 32 bits long respectively.
We can define up to 30 additional bits to be meaningful to the transport.= =C2=A0 (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, Pri= ority-Delivery (aka "DontBuffer") bit, etc).

0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stre= am ID (8/16/24/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Params Bitmap=C2= =A0 (8/16/24/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Associated Stream ID (0/8/16/32)= =C2=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[Data Length (16)]=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stream Data (*)=C2=A0 =C2=A0 =C2=A0 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent to = STREAM frame with OO=3D0.



-----Original Message-----
From: Mike Bishop [mailto:M= ichael.Bishop@microsoft.com]
Sent: Thursday, June 22, 2017 6:48 PM
To: Martin Thomson <martin.t= homson@gmail.com>; Ted Hardie <ted.ietf@gmail.com>
Cc: Jana Iyengar <jri@google.com&g= t;; QUIC WG <quic@ietf.org>; Pat= rick McManus <pmcmanus@mozilla.c= om>
Subject: RE: Unidirectional = streams PR

I suppose you could drop the stream type header from HTTP into QUIC and mak= e the types "bidirectional stream," "unidirectional stream,&= quot; and "mate of bidirectional stream"; the last would further = need to identify which peer stream it corresponded to.

But making them the first couple bytes of the stream data feels kind of klu= dgy if this is fundamentally built into the transport, which means they rea= lly belong in a dedicated frame.=C2=A0 Maybe a dedicated OPEN_STREAM frame,= which blocks any data received on that stream until you know what type it = is?

Actually, if we're planning on introducing other per-stream properties = like partial reliability, there might be value in an OPEN_STREAM frame wher= e we can describe a stream's desired properties before any data flows..= ..

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Martin Thomson
Sent: Thursday, June 22, 2017 3:32 PM
To: Ted Hardie <ted.ietf@gmail.com= >
Cc: Jana Iyengar <jri@google.com&g= t;; QUIC WG <quic@ietf.org>; Pat= rick McManus <pmcmanus@mozilla.c= om>
Subject: Re: Unidirectional streams PR

On 23 June 2017 at 05:15, Ted Hardie <ted.ietf@gmail.com> wrote:
> My personal take on that right answer there is to support both, with > an explicit signal of when each model is in use,

I have heard this request now from several folks at Google.=C2=A0 I don'= ;t know how to make this work without increasing complexity considerably .= =C2=A0 I'd be willing to be wrong about this, but would prefer to see a= proposal.=C2=A0 I don't need a fully-worked proposal with text, just a= sketch of how the pieces work in enough detail to understand how this migh= t interact with other parts of the protocol.=C2=A0 I think that Jana offere= d to do this, so maybe I can wait for that (c.f., Mark's earlier statem= ent about priority/urgency).


--94eb2c081d7445f1a3055296bae5-- From nobody Thu Jun 22 18:50: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 53943129BF5 for ; Thu, 22 Jun 2017 18:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 3I8J0A6McfQA for ; Thu, 22 Jun 2017 18:49:57 -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 7C52812762F for ; Thu, 22 Jun 2017 18:49:57 -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 v5N1lYcG029741; Fri, 23 Jun 2017 02:49:54 +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=jMerIgqZtM/ogB/hqfUsHtxfEZZC1QvWhhL/UcK5XPo=; b=DwMdTVeCqnwCDqRMEqUQCEwznV+5/Dcp4pQ7fvbmOh4v1063iB2HXIKY0mHOuIkkR8Jx cJY1aEVHgqGwq7za8S09BPkMGb/G4ARNOM+bCSLEt0AFo2f5U7E2478FiAYmFOVfwsRM asG7ZlAE6+Vs7awJJVFOpQIymGnfonkyy4qWhkzqFI2oMqF/3UPpsYrYz/CFTe4gV84I +y/4JZuQ4s1ORIHOlVaxS+zlo8k20z1yMfkecFmf8mmWdXpAZRTCW+HDPCdLeZvt7rKI tV3C1Cmy/TBKHTdtln7yt/+WEZXNHMbNHGXOaKqxKRpFG3MqgcqDUp63eh/huAeeM25r ZA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2b8kpx1vyf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 02:49:54 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5N1kBuW026720; Thu, 22 Jun 2017 21:49:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yruw73d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Jun 2017 21:49:52 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 22 Jun 2017 21:49:52 -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, 22 Jun 2017 21:49:52 -0400 From: "Lubashev, Igor" To: Jana Iyengar CC: Mike Bishop , Ted Hardie , QUIC WG , Martin Thomson , Patrick McManus Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHzFJcNmOfPnkGlJjRXQ/9soKIvh8kAgADqdYCAACIYgIABI/8AgAAEzYCAAARGgP//0FFwgABb0AD//76RwA== Date: Fri, 23 Jun 2017 01:49:51 +0000 Message-ID: <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> References: <349d20e4f7d9458aaf7797d2025b2064@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.34.60] Content-Type: multipart/alternative; boundary="_000_9bf0712b00e540eeafdd3e6f357c2845usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230028 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230028 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, 23 Jun 2017 01:50:00 -0000 --_000_9bf0712b00e540eeafdd3e6f357c2845usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBvZiB0aHJlZSBsYXllcnMgb2YgYWJzdHJhY3Rpb246DQoNCg0KMS4gICAgICAgUVVJ QyBXaXJlIFByb3RvY29sICh0aGUgdGhpbmcgZGVzY3JpYmVkIGJ5IHRoZSBRVUlDIFRyYW5zcG9y dCBSRkMpDQoNCjIuICAgICAgIFFVSUMgTGlicmFyeSBBUEkgKGEgbGlicmFyeSBleHBvc2luZyBz b21lIHVzZWZ1bCBhYnN0cmFjdGlvbnMgLS0gc3VjaCBhcyBibG9ja2luZy9ub24tYmxvY2tpbmcg dW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhbmQgYmlkaXJlY3Rpb25hbCDigJxzb2NrZXRz4oCdIC0t IGFuZCBpbXBsZW1lbnRpbmcgdGhlbSB1c2luZyBRVUlDIFdpcmUgUHJvdG9jb2wpDQoNCjMuICAg ICAgIEFwcGxpY2F0aW9uIChzb21ldGhpbmcgdGhhdCB1c2VzIFFVSUMgTGlicmFyeSBBUElzKQ0K DQpXaGF0IEkgYW0gc2F5aW5nIGlzIHRoYXQgTWFydGlu4oCZcyB1bmlkaXJlY3Rpb25hbCBzdHJl YW1zIHByb3Bvc2FsIGRvZXMgbm90IGhhdmUgYSB3YXkgdG8gaW1wbGVtZW50IGdlbmVyaWMgYmlk aXJlY3Rpb25hbCBzb2NrZXQtbGlrZSBhYnN0cmFjdGlvbnMgb24gdGhlIFFVSUMgTGlicmFyeSBB UEkgbGF5ZXIuICBIb3dldmVyLCBpZiB3ZSBmb2xsb3cgTWlrZeKAmXMgc3VnZ2VzdGlvbiBhbmQg YWxsb3cgYW4gQXNzb2NpYXRlZCBTdHJlYW0gSUQgaW4gT1BFTl9TVFJFQU0gZnJhbWVzLCB0aGlz IHdvdWxkIG1ha2UgaXQgZWFzeSBmb3IgUVVJQ0sgTGlicmFyaWVzIHRvIHByb3ZpZGUgZ2VuZXJp YyBiaWRpcmVjdGlvbmFsIHNvY2tldC1saWtlIGFic3RyYWN0aW9ucy4NCg0KU28gd2hhdCBJIGFt IHN1Z2dlc3RpbmcgaXMgdGhhdCB3ZSBrZWVwIFFVSUMgV2lyZSBQcm90b2NvbCBzdGF0ZSBtYWNo aW5lIHNpbXBsZSBhbmQgdW5jaGFuZ2VkLiAgSG93ZXZlciwgd2l0aCB0aGUgT1BFTl9TVFJFQU0g ZnJhbWUsIHdlIHdvdWxkIGFsbG93IFFVSUMgTGlicmFyaWVzIHRvIGltcGxlbWVudCBib3RoIHVu aWRpcmVjdGlvbmFsIGFuZCBiaWRpcmVjdGlvbmFsIHN0cmVhbXMuDQoNCg0KLSAgICAgICAgICBJ Z29yDQoNCg0KRnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dDQpTZW50 OiBUaHVyc2RheSwgSnVuZSAyMiwgMjAxNyA5OjI2IFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGls dWJhc2hlQGFrYW1haS5jb20+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBRVUlDIFdHIDxxdWlj QGlldGYub3JnPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IFBh dHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSZTogVW5pZGly ZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQpPbiBUaHUsIEp1biAyMiwgMjAxNyBhdCA2OjA2IFBNLCBM dWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFp LmNvbT4+IHdyb3RlOg0KSSBsaWtlIHRoZSBpZGVhIG9mIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMs IGlmIHRoZXkgbWFrZSBsaWZlIGVhc2llciBmb3IgYXBwcyAtLSBib3RoICJ0cmFkaXRpb25hbCIg YXBwcyBsaWtlIEgyIGFzIHdlbGwgYXMgbGVzcyB1c3VhbCBhcHBzIGxpa2Ugc3NoIChvbmUgc3Ry ZWFtIGluIG9uZSBkaXJlY3Rpb24sIHR3byBhc3NvY2lhdGVkIHN0cmVhbXMgaW4gdGhlIG9wcG9z aXRlIGRpcmVjdGlvbikuDQoNCkkgYWxzbyBsaWtlIE1pa2UncyBpZGVhIG9mIE9QRU5fU1RSRUFN IGZyYW1lLiAgVGhlIHdheSBJJ2QgZGVzY3JpYmUgT1BFTl9TVFJFQU0gZnJhbWUgaXMgdGhhdCBp dCBpcyBpbXBsaWNpdGx5IGEgU1RSRUFNIGZyYW1lIHdpdGggMC1vZmZzZXQgYW5kIGEgc2V0IG9m ICJwZXItc3RyZWFtIHByb3BlcnRpZXMiLg0KDQpBbiBpbXBvcnRhbnQgcG9pbnQgaXMgdGhhdCB3 aGVuIFRyYW5zcG9ydCBpcyBhd2FyZSBvZiB0aGUgYXNzb2NpYXRpb24gb2YgdHdvIHVuaWRpcmVj dGlvbmFsIHN0cmVhbXMsIHRoZSBUcmFuc3BvcnQgQVBJIHdvdWxkIGJlIGFibGUgdG8gaW1wbGVt ZW50IGEgYmlkaXJlY3Rpb25hbCBzb2NrZXQtbGlrZSBhYnN0cmFjdGlvbiBmb3IgYXBwbGljYXRp b25zIHRoYXQgZGVzaXJlIG9uZS4NCg0KSSdtIG5vdCBzdXJlIEkgZm9sbG93IHlvdXIgdGhpbmtp bmcgaGVyZTogYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgUVVJQyBpbXBsZW1lbnQgYmlkaXJlY3Rp b25hbCBzdHJlYW1zIGluIGFkZGl0aW9uIHRvIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXM/DQoNCi0g amFuYQ0KDQoNCk9QRU5fU1RSRUFNIGZyYW1lDQpUaGUgdHlwZSBieXRlIGZvciBhIE9QRU5fU1RS RUFNIGZyYW1lIGNvbnRhaW5zIGVtYmVkZGVkIGZsYWdzLCBhbmQgaXMgZm9ybWF0dGVkIGFzIDEw RlNTUFBELiBUaGUgRiwgU1MsIGFuZCBEIGJpdHMgYXJlIHBhcnNlZCBhcyBwZXIgU1RSRUFNIGZy YW1lLg0KKiBUaGUgUFAgYml0cyBlbmNvZGUgdGhlIHNpemUgb2YgdGhlIFBhcmFtcyBCaXRtYXAg ZmllbGQuIFRoZSB2YWx1ZXMgMDAsIDAxLCAwMiwgYW5kIDAzIGluZGljYXRlIGxlbmd0aHMgb2Yg OCwgMTYsIDI0LCBhbmQgMzIgYml0cyBsb25nIHJlc3BlY3RpdmVseS4NCg0KVGhlIHR3byBMZWFz dCBTaWduaWZpY2FudCBiaXRzIG9mIHRoZSBQYXJhbXMgQml0bWFwIGluZGljYXRlIHRoZSBsZW5n dGggb2YgdGhlIEFzc29jaWF0ZWQgU3RyZWFtIElELiBUaGUgTFNCIHZhbHVlcyAwMCwgMDEsIDAy LCBhbmQgMDMgaW5kaWNhdGUgbGVuZ3RocyBvZiAwIChub25lKSwgOCwgMTYsIGFuZCAzMiBiaXRz IGxvbmcgcmVzcGVjdGl2ZWx5Lg0KV2UgY2FuIGRlZmluZSB1cCB0byAzMCBhZGRpdGlvbmFsIGJp dHMgdG8gYmUgbWVhbmluZ2Z1bCB0byB0aGUgdHJhbnNwb3J0LiAgKEkgY2FuIGltYWdpbmUgUGFy dGlhbC1SZWxpYWJpbGl0eSBiaXQsIEZsb3ctQ29udHJvbC1FeGVtcHQgYml0LCBQcmlvcml0eS1E ZWxpdmVyeSAoYWthICJEb250QnVmZmVyIikgYml0LCBldGMpLg0KDQowICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQor LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgU3RyZWFtIElEICg4LzE2LzI0LzMyKSAgICAg ICAgICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAgIFBhcmFtcyBCaXRt YXAgICg4LzE2LzI0LzMyKSAgICAgICAgICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAg ICAgICAgQXNzb2NpYXRlZCBTdHJlYW0gSUQgKDAvOC8xNi8zMikgICAgICAgICAgICAgICAgICAg IC4uLg0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCnwgICAgICAgW0RhdGEgTGVuZ3RoICgxNildICAgICAgfCAgICAgICAg U3RyZWFtIERhdGEgKCopICAgICAgLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpOb3RlIHRoYXQgaWYgUGFyYW1z IEJpdG1hcCBpcyAweDAsIHRoaXMgT1BFTl9TVFJFQU0gZnJhbWUgaXMgZXF1aXZhbGVudCB0byBT VFJFQU0gZnJhbWUgd2l0aCBPTz0wLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IE1pa2UgQmlzaG9wIFttYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxt YWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT5dDQpTZW50OiBUaHVyc2RheSwgSnVu ZSAyMiwgMjAxNyA2OjQ4IFBNDQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj47IFRlZCBIYXJkaWUgPHRl ZC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86dGVkLmlldGZAZ21haWwuY29tPj4NCkNjOiBKYW5hIEl5 ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+OyBRVUlDIFdHIDxx dWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IFBhdHJpY2sgTWNNYW51cyA8cG1j bWFudXNAbW96aWxsYS5jb208bWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tPj4NClN1YmplY3Q6 IFJFOiBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBSDQoNCkkgc3VwcG9zZSB5b3UgY291bGQgZHJv cCB0aGUgc3RyZWFtIHR5cGUgaGVhZGVyIGZyb20gSFRUUCBpbnRvIFFVSUMgYW5kIG1ha2UgdGhl IHR5cGVzICJiaWRpcmVjdGlvbmFsIHN0cmVhbSwiICJ1bmlkaXJlY3Rpb25hbCBzdHJlYW0sIiBh bmQgIm1hdGUgb2YgYmlkaXJlY3Rpb25hbCBzdHJlYW0iOyB0aGUgbGFzdCB3b3VsZCBmdXJ0aGVy IG5lZWQgdG8gaWRlbnRpZnkgd2hpY2ggcGVlciBzdHJlYW0gaXQgY29ycmVzcG9uZGVkIHRvLg0K DQpCdXQgbWFraW5nIHRoZW0gdGhlIGZpcnN0IGNvdXBsZSBieXRlcyBvZiB0aGUgc3RyZWFtIGRh dGEgZmVlbHMga2luZCBvZiBrbHVkZ3kgaWYgdGhpcyBpcyBmdW5kYW1lbnRhbGx5IGJ1aWx0IGlu dG8gdGhlIHRyYW5zcG9ydCwgd2hpY2ggbWVhbnMgdGhleSByZWFsbHkgYmVsb25nIGluIGEgZGVk aWNhdGVkIGZyYW1lLiAgTWF5YmUgYSBkZWRpY2F0ZWQgT1BFTl9TVFJFQU0gZnJhbWUsIHdoaWNo IGJsb2NrcyBhbnkgZGF0YSByZWNlaXZlZCBvbiB0aGF0IHN0cmVhbSB1bnRpbCB5b3Uga25vdyB3 aGF0IHR5cGUgaXQgaXM/DQoNCkFjdHVhbGx5LCBpZiB3ZSdyZSBwbGFubmluZyBvbiBpbnRyb2R1 Y2luZyBvdGhlciBwZXItc3RyZWFtIHByb3BlcnRpZXMgbGlrZSBwYXJ0aWFsIHJlbGlhYmlsaXR5 LCB0aGVyZSBtaWdodCBiZSB2YWx1ZSBpbiBhbiBPUEVOX1NUUkVBTSBmcmFtZSB3aGVyZSB3ZSBj YW4gZGVzY3JpYmUgYSBzdHJlYW0ncyBkZXNpcmVkIHByb3BlcnRpZXMgYmVmb3JlIGFueSBkYXRh IGZsb3dzLi4uLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uDQpTZW50OiBUaHVyc2RheSwgSnVuZSAyMiwgMjAx NyAzOjMyIFBNDQpUbzogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQu aWV0ZkBnbWFpbC5jb20+Pg0KQ2M6IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFpbHRv OmpyaUBnb29nbGUuY29tPj47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0 Zi5vcmc+PjsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbTxtYWlsdG86cG1j bWFudXNAbW96aWxsYS5jb20+Pg0KU3ViamVjdDogUmU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMg UFINCg0KT24gMjMgSnVuZSAyMDE3IGF0IDA1OjE1LCBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFp bC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiBNeSBwZXJzb25hbCB0 YWtlIG9uIHRoYXQgcmlnaHQgYW5zd2VyIHRoZXJlIGlzIHRvIHN1cHBvcnQgYm90aCwgd2l0aA0K PiBhbiBleHBsaWNpdCBzaWduYWwgb2Ygd2hlbiBlYWNoIG1vZGVsIGlzIGluIHVzZSwNCg0KSSBo YXZlIGhlYXJkIHRoaXMgcmVxdWVzdCBub3cgZnJvbSBzZXZlcmFsIGZvbGtzIGF0IEdvb2dsZS4g IEkgZG9uJ3Qga25vdyBob3cgdG8gbWFrZSB0aGlzIHdvcmsgd2l0aG91dCBpbmNyZWFzaW5nIGNv bXBsZXhpdHkgY29uc2lkZXJhYmx5IC4gIEknZCBiZSB3aWxsaW5nIHRvIGJlIHdyb25nIGFib3V0 IHRoaXMsIGJ1dCB3b3VsZCBwcmVmZXIgdG8gc2VlIGEgcHJvcG9zYWwuICBJIGRvbid0IG5lZWQg YSBmdWxseS13b3JrZWQgcHJvcG9zYWwgd2l0aCB0ZXh0LCBqdXN0IGEgc2tldGNoIG9mIGhvdyB0 aGUgcGllY2VzIHdvcmsgaW4gZW5vdWdoIGRldGFpbCB0byB1bmRlcnN0YW5kIGhvdyB0aGlzIG1p Z2h0IGludGVyYWN0IHdpdGggb3RoZXIgcGFydHMgb2YgdGhlIHByb3RvY29sLiAgSSB0aGluayB0 aGF0IEphbmEgb2ZmZXJlZCB0byBkbyB0aGlzLCBzbyBtYXliZSBJIGNhbiB3YWl0IGZvciB0aGF0 IChjLmYuLCBNYXJrJ3MgZWFybGllciBzdGF0ZW1lbnQgYWJvdXQgcHJpb3JpdHkvdXJnZW5jeSku DQoNCg== --_000_9bf0712b00e540eeafdd3e6f357c2845usma1exdag1mb5msgcorpak_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaW0NCgl7bXNvLXN0eWxlLW5hbWU6aW07fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MzIzMDQ1NDA0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotODA4OTMwODIyIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE4MjgxMjg0NzI7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIxMjQ1NzUwODYgLTIwNDcw MDk5MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkg dGhpbmsgb2YgdGhyZWUgbGF5ZXJzIG9mIGFic3RyYWN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+UVVJQyBXaXJlIFByb3RvY29sICh0aGUgdGhpbmcgZGVzY3JpYmVk IGJ5IHRoZSBRVUlDIFRyYW5zcG9ydCBSRkMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UVVJ QyBMaWJyYXJ5IEFQSSAoYSBsaWJyYXJ5IGV4cG9zaW5nIHNvbWUgdXNlZnVsIGFic3RyYWN0aW9u cyAtLSBzdWNoIGFzIGJsb2NraW5nL25vbi1ibG9ja2luZyB1bmlkaXJlY3Rpb25hbCBzdHJlYW1z IGFuZCBiaWRpcmVjdGlvbmFsIOKAnHNvY2tldHPigJ0gLS0gYW5kIGltcGxlbWVudGluZw0KIHRo ZW0gdXNpbmcgUVVJQyBXaXJlIFByb3RvY29sKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFw cGxpY2F0aW9uIChzb21ldGhpbmcgdGhhdCB1c2VzIFFVSUMgTGlicmFyeSBBUElzKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5XaGF0IEkgYW0gc2F5aW5nIGlzIHRoYXQgTWFydGlu4oCZcyB1bmlkaXJlY3Rpb25h bCBzdHJlYW1zIHByb3Bvc2FsIGRvZXMgbm90IGhhdmUgYSB3YXkgdG8gaW1wbGVtZW50IGdlbmVy aWMgYmlkaXJlY3Rpb25hbCBzb2NrZXQtbGlrZSBhYnN0cmFjdGlvbnMgb24gdGhlIFFVSUMgTGli cmFyeSBBUEkgbGF5ZXIuJm5ic3A7DQogSG93ZXZlciwgaWYgd2UgZm9sbG93IE1pa2XigJlzIHN1 Z2dlc3Rpb24gYW5kIGFsbG93IGFuIEFzc29jaWF0ZWQgU3RyZWFtIElEIGluIE9QRU5fU1RSRUFN IGZyYW1lcywgdGhpcyB3b3VsZCBtYWtlIGl0IGVhc3kgZm9yIFFVSUNLIExpYnJhcmllcyB0byBw cm92aWRlIGdlbmVyaWMgYmlkaXJlY3Rpb25hbCBzb2NrZXQtbGlrZSBhYnN0cmFjdGlvbnMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlNvIHdoYXQgSSBhbSBzdWdnZXN0aW5nIGlzIHRoYXQgd2Uga2VlcCBRVUlD IFdpcmUgUHJvdG9jb2wgc3RhdGUgbWFjaGluZSBzaW1wbGUgYW5kIHVuY2hhbmdlZC4mbmJzcDsg SG93ZXZlciwgd2l0aCB0aGUgT1BFTl9TVFJFQU0gZnJhbWUsIHdlIHdvdWxkIGFsbG93IFFVSUMg TGlicmFyaWVzIHRvIGltcGxlbWVudA0KIGJvdGggdW5pZGlyZWN0aW9uYWwgYW5kIGJpZGlyZWN0 aW9uYWwgc3RyZWFtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omwx IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SWdvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAyMiwgMjAxNyA5OjI2IFBNPGJy Pg0KPGI+VG86PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlzaG9wICZsdDtNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQu Y29tJmd0OzsgVGVkIEhhcmRpZSAmbHQ7dGVkLmlldGZAZ21haWwuY29tJmd0OzsgUVVJQyBXRyAm bHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20mZ3Q7OyBQYXRyaWNrIE1jTWFudXMgJmx0O3BtY21hbnVzQG1vemlsbGEuY29tJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBK dW4gMjIsIDIwMTcgYXQgNjowNiBQTSwgTHViYXNoZXYsIElnb3IgJmx0OzxhIGhyZWY9Im1haWx0 bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWx1YmFzaGVAYWthbWFpLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgbGlrZSB0aGUgaWRlYSBvZiB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zLCBpZiB0 aGV5IG1ha2UgbGlmZSBlYXNpZXIgZm9yIGFwcHMgLS0gYm90aCAmcXVvdDt0cmFkaXRpb25hbCZx dW90OyBhcHBzIGxpa2UgSDIgYXMgd2VsbCBhcyBsZXNzIHVzdWFsIGFwcHMgbGlrZSBzc2ggKG9u ZSBzdHJlYW0gaW4gb25lIGRpcmVjdGlvbiwgdHdvIGFzc29jaWF0ZWQgc3RyZWFtcyBpbiB0aGUg b3Bwb3NpdGUgZGlyZWN0aW9uKS48YnI+DQo8YnI+DQpJIGFsc28gbGlrZSBNaWtlJ3MgaWRlYSBv ZiBPUEVOX1NUUkVBTSBmcmFtZS4mbmJzcDsgVGhlIHdheSBJJ2QgZGVzY3JpYmUgT1BFTl9TVFJF QU0gZnJhbWUgaXMgdGhhdCBpdCBpcyBpbXBsaWNpdGx5IGEgU1RSRUFNIGZyYW1lIHdpdGggMC1v ZmZzZXQgYW5kIGEgc2V0IG9mICZxdW90O3Blci1zdHJlYW0gcHJvcGVydGllcyZxdW90Oy48YnI+ DQo8YnI+DQpBbiBpbXBvcnRhbnQgcG9pbnQgaXMgdGhhdCB3aGVuIFRyYW5zcG9ydCBpcyBhd2Fy ZSBvZiB0aGUgYXNzb2NpYXRpb24gb2YgdHdvIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMsIHRoZSBU cmFuc3BvcnQgQVBJIHdvdWxkIGJlIGFibGUgdG8gaW1wbGVtZW50IGEgYmlkaXJlY3Rpb25hbCBz b2NrZXQtbGlrZSBhYnN0cmFjdGlvbiBmb3IgYXBwbGljYXRpb25zIHRoYXQgZGVzaXJlIG9uZS48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkknbSBub3Qgc3VyZSBJIGZvbGxvdyB5b3VyIHRoaW5raW5nIGhlcmU6IGFyZSB5b3Ugc3Vn Z2VzdGluZyB0aGF0IFFVSUMgaW1wbGVtZW50IGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBpbiBhZGRp dGlvbiB0byB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGphbmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT1BFTl9TVFJFQU0g ZnJhbWU8YnI+DQpUaGUgdHlwZSBieXRlIGZvciBhIE9QRU5fU1RSRUFNIGZyYW1lIGNvbnRhaW5z IGVtYmVkZGVkIGZsYWdzLCBhbmQgaXMgZm9ybWF0dGVkIGFzIDEwRlNTUFBELiBUaGUgRiwgU1Ms IGFuZCBEIGJpdHMgYXJlIHBhcnNlZCBhcyBwZXIgU1RSRUFNIGZyYW1lLjxicj4NCiogVGhlIFBQ IGJpdHMgZW5jb2RlIHRoZSBzaXplIG9mIHRoZSBQYXJhbXMgQml0bWFwIGZpZWxkLiBUaGUgdmFs dWVzIDAwLCAwMSwgMDIsIGFuZCAwMyBpbmRpY2F0ZSBsZW5ndGhzIG9mIDgsIDE2LCAyNCwgYW5k IDMyIGJpdHMgbG9uZyByZXNwZWN0aXZlbHkuPGJyPg0KPGJyPg0KVGhlIHR3byBMZWFzdCBTaWdu aWZpY2FudCBiaXRzIG9mIHRoZSBQYXJhbXMgQml0bWFwIGluZGljYXRlIHRoZSBsZW5ndGggb2Yg dGhlIEFzc29jaWF0ZWQgU3RyZWFtIElELiBUaGUgTFNCIHZhbHVlcyAwMCwgMDEsIDAyLCBhbmQg MDMgaW5kaWNhdGUgbGVuZ3RocyBvZiAwIChub25lKSwgOCwgMTYsIGFuZCAzMiBiaXRzIGxvbmcg cmVzcGVjdGl2ZWx5Ljxicj4NCldlIGNhbiBkZWZpbmUgdXAgdG8gMzAgYWRkaXRpb25hbCBiaXRz IHRvIGJlIG1lYW5pbmdmdWwgdG8gdGhlIHRyYW5zcG9ydC4mbmJzcDsgKEkgY2FuIGltYWdpbmUg UGFydGlhbC1SZWxpYWJpbGl0eSBiaXQsIEZsb3ctQ29udHJvbC1FeGVtcHQgYml0LCBQcmlvcml0 eS1EZWxpdmVyeSAoYWthICZxdW90O0RvbnRCdWZmZXImcXVvdDspIGJpdCwgZXRjKS48YnI+DQo8 YnI+DQowJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7MSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszPGJyPg0KJm5ic3A7 MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxPGJyPg0KJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8YnI+DQp8Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFN0cmVhbSBJRCAoOC8xNi8yNC8zMikmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48YnI+DQomIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOzxicj4NCnwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFBhcmFtcyBCaXRtYXAmbmJzcDsgKDgvMTYvMjQvMzIpJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Li4uPGJyPg0KJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8YnI+DQp8Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXNzb2NpYXRlZCBTdHJlYW0gSUQgKDAv OC8xNi8zMikmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLi4uPGJyPg0KJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8 YnI+DQp8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0RhdGEgTGVuZ3RoICgxNildJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdHJlYW0gRGF0YSAo KikmbmJzcDsgJm5ic3A7ICZuYnNwOyAuLi48YnI+DQomIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Ozxicj4NCjxicj4NCk5vdGUgdGhhdCBpZiBQYXJhbXMgQml0bWFwIGlzIDB4MCwgdGhpcyBPUEVO X1NUUkVBTSBmcmFtZSBpcyBlcXVpdmFsZW50IHRvIFNUUkVBTSBmcmFtZSB3aXRoIE9PPTAuPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImltIj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkZyb206IE1pa2UgQmlzaG9wIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iPk1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+XTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0i PlNlbnQ6IFRodXJzZGF5LCBKdW5lIDIyLCAyMDE3IDY6NDggUE08L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImltIj5UbzogTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7OyBUZWQg SGFyZGllICZsdDs8YSBocmVmPSJtYWlsdG86dGVkLmlldGZAZ21haWwuY29tIj50ZWQuaWV0ZkBn bWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkNjOiBKYW5hIEl5 ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+anJpQGdvb2dsZS5jb208 L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNA aWV0Zi5vcmc8L2E+Jmd0OzsgUGF0cmljayBNY01hbnVzICZsdDs8YSBocmVmPSJtYWlsdG86cG1j bWFudXNAbW96aWxsYS5jb20iPnBtY21hbnVzQG1vemlsbGEuY29tPC9hPiZndDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+U3ViamVjdDogUkU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMg UFI8YnI+DQo8YnI+DQpJIHN1cHBvc2UgeW91IGNvdWxkIGRyb3AgdGhlIHN0cmVhbSB0eXBlIGhl YWRlciBmcm9tIEhUVFAgaW50byBRVUlDIGFuZCBtYWtlIHRoZSB0eXBlcyAmcXVvdDtiaWRpcmVj dGlvbmFsIHN0cmVhbSwmcXVvdDsgJnF1b3Q7dW5pZGlyZWN0aW9uYWwgc3RyZWFtLCZxdW90OyBh bmQgJnF1b3Q7bWF0ZSBvZiBiaWRpcmVjdGlvbmFsIHN0cmVhbSZxdW90OzsgdGhlIGxhc3Qgd291 bGQgZnVydGhlciBuZWVkIHRvIGlkZW50aWZ5IHdoaWNoIHBlZXIgc3RyZWFtIGl0IGNvcnJlc3Bv bmRlZCB0by48YnI+DQo8YnI+DQpCdXQgbWFraW5nIHRoZW0gdGhlIGZpcnN0IGNvdXBsZSBieXRl cyBvZiB0aGUgc3RyZWFtIGRhdGEgZmVlbHMga2luZCBvZiBrbHVkZ3kgaWYgdGhpcyBpcyBmdW5k YW1lbnRhbGx5IGJ1aWx0IGludG8gdGhlIHRyYW5zcG9ydCwgd2hpY2ggbWVhbnMgdGhleSByZWFs bHkgYmVsb25nIGluIGEgZGVkaWNhdGVkIGZyYW1lLiZuYnNwOyBNYXliZSBhIGRlZGljYXRlZCBP UEVOX1NUUkVBTSBmcmFtZSwgd2hpY2ggYmxvY2tzIGFueSBkYXRhIHJlY2VpdmVkIG9uIHRoYXQN CiBzdHJlYW0gdW50aWwgeW91IGtub3cgd2hhdCB0eXBlIGl0IGlzPzxicj4NCjxicj4NCkFjdHVh bGx5LCBpZiB3ZSdyZSBwbGFubmluZyBvbiBpbnRyb2R1Y2luZyBvdGhlciBwZXItc3RyZWFtIHBy b3BlcnRpZXMgbGlrZSBwYXJ0aWFsIHJlbGlhYmlsaXR5LCB0aGVyZSBtaWdodCBiZSB2YWx1ZSBp biBhbiBPUEVOX1NUUkVBTSBmcmFtZSB3aGVyZSB3ZSBjYW4gZGVzY3JpYmUgYSBzdHJlYW0ncyBk ZXNpcmVkIHByb3BlcnRpZXMgYmVmb3JlIGFueSBkYXRhIGZsb3dzLi4uLjxicj4NCjxicj4NCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogUVVJQyBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5d IE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbjxicj4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDIy LCAyMDE3IDM6MzIgUE08YnI+DQpUbzogVGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRl ZC5pZXRmQGdtYWlsLmNvbSI+dGVkLmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQpDYzogSmFu YSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBnb29nbGUu Y29tPC9hPiZndDs7IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5x dWljQGlldGYub3JnPC9hPiZndDs7IFBhdHJpY2sgTWNNYW51cyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBtY21hbnVzQG1vemlsbGEuY29tIj5wbWNtYW51c0Btb3ppbGxhLmNvbTwvYT4mZ3Q7PGJyPg0K U3ViamVjdDogUmU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgUFI8YnI+DQo8YnI+DQpPbiAyMyBK dW5lIDIwMTcgYXQgMDU6MTUsIFRlZCBIYXJkaWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0 ZkBnbWFpbC5jb20iPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsg TXkgcGVyc29uYWwgdGFrZSBvbiB0aGF0IHJpZ2h0IGFuc3dlciB0aGVyZSBpcyB0byBzdXBwb3J0 IGJvdGgsIHdpdGg8YnI+DQomZ3Q7IGFuIGV4cGxpY2l0IHNpZ25hbCBvZiB3aGVuIGVhY2ggbW9k ZWwgaXMgaW4gdXNlLDxicj4NCjxicj4NCkkgaGF2ZSBoZWFyZCB0aGlzIHJlcXVlc3Qgbm93IGZy b20gc2V2ZXJhbCBmb2xrcyBhdCBHb29nbGUuJm5ic3A7IEkgZG9uJ3Qga25vdyBob3cgdG8gbWFr ZSB0aGlzIHdvcmsgd2l0aG91dCBpbmNyZWFzaW5nIGNvbXBsZXhpdHkgY29uc2lkZXJhYmx5IC4m bmJzcDsgSSdkIGJlIHdpbGxpbmcgdG8gYmUgd3JvbmcgYWJvdXQgdGhpcywgYnV0IHdvdWxkIHBy ZWZlciB0byBzZWUgYSBwcm9wb3NhbC4mbmJzcDsgSSBkb24ndCBuZWVkIGEgZnVsbHktd29ya2Vk IHByb3Bvc2FsIHdpdGgNCiB0ZXh0LCBqdXN0IGEgc2tldGNoIG9mIGhvdyB0aGUgcGllY2VzIHdv cmsgaW4gZW5vdWdoIGRldGFpbCB0byB1bmRlcnN0YW5kIGhvdyB0aGlzIG1pZ2h0IGludGVyYWN0 IHdpdGggb3RoZXIgcGFydHMgb2YgdGhlIHByb3RvY29sLiZuYnNwOyBJIHRoaW5rIHRoYXQgSmFu YSBvZmZlcmVkIHRvIGRvIHRoaXMsIHNvIG1heWJlIEkgY2FuIHdhaXQgZm9yIHRoYXQgKGMuZi4s IE1hcmsncyBlYXJsaWVyIHN0YXRlbWVudCBhYm91dCBwcmlvcml0eS91cmdlbmN5KS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9bf0712b00e540eeafdd3e6f357c2845usma1exdag1mb5msgcorpak_-- From nobody Thu Jun 22 19:10: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 C5555129BF6 for ; Thu, 22 Jun 2017 19:10:14 -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 idZxVIyoFaPg for ; Thu, 22 Jun 2017 19:10:12 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6945129329 for ; Thu, 22 Jun 2017 19:10:11 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id t127so1615871ywc.3 for ; Thu, 22 Jun 2017 19:10:11 -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=5By2yMelMee7oscWk9PTf/UlRcIi/JD/1J/KLPBhtuE=; b=BJ2UtFvgVjbsDBa0J96KAgbfJ+CIYX7dWQg5QQpcXU+WnCE+e85egt7UoP+CpPfGpq d67xtvBFTAZI2YbDWoluKpx+0OZ4Mo64TpY95x2O8zhSv4NxojTQ12D+g7mQdYzaSVDd Gyn7MpVpBdDSSfSmZ94oaG2RhtiK73FuGU/8mAck0kYqJ2YMsUmeXR46Y+314YnJeo7r zZ5mfolWoVbzifI+HZaMdYVrBZAKRXRHFGIABIl2FzhzDf+WIdR+v1zUeMsEst/4R1Vd RMwvh7DvaSE/wm14TTTIUimtZjpdDF/XHRXH7xV+hFG4GGZOJUz3QJfvKH/FOcIH34Rb +znQ== 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=5By2yMelMee7oscWk9PTf/UlRcIi/JD/1J/KLPBhtuE=; b=WV3ieSt6EKAYC/o7sQerVcilkqeyTL2Ux94+M8RHkHgOY43wAf2drEFcYv5MPUD9Wb fXY3HjGHPpnE230npO35evgpkDlE7SeRt/ndnUkoSgdPZkzhTfPqS+EsHEznYsNkKjm9 RiuReQP6rq+fWlo1nI56RcsrQZs/rO01nuuIKzyou0mOp5sVQFMgLGZ+Xi+isa1AUu4c +DvUAU6Yl8Xil9aQzJxd9mwyeXtmD1K6J1Oe7og4/yS4qLWL6ftKydTdNDxqONTralfF 8kcCwzWinB8i7D7cM0dCunt5iMmxd6KbYTILSPBjIuMZFrnms6nB++AzdIMmpqqWI5Ma SGGQ== X-Gm-Message-State: AKS2vOwNLAlidip2TIK1f+qzdQtyxklzkMiXn1rKSJJqrN7RyTh8chWT TJ7N/hL3lZ4w7XXLkytNSIM/ol8lTGzq X-Received: by 10.129.146.15 with SMTP id j15mr1508199ywg.283.1498183810752; Thu, 22 Jun 2017 19:10:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.3 with HTTP; Thu, 22 Jun 2017 19:09:49 -0700 (PDT) In-Reply-To: <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ian Swett Date: Thu, 22 Jun 2017 22:09:49 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: "Lubashev, Igor" Cc: Jana Iyengar , Mike Bishop , Ted Hardie , QUIC WG , Martin Thomson , Patrick McManus Content-Type: multipart/alternative; boundary="94eb2c094216d9b25f055297192f" 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, 23 Jun 2017 02:10:15 -0000 --94eb2c094216d9b25f055297192f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 22, 2017 at 9:49 PM, Lubashev, Igor wrote= : > 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 Protoc= ol) > > 3. Application (something that uses QUIC Library APIs) > > > > What I am saying is that Martin=E2=80=99s unidirectional streams proposal= does not > have a way to implement generic bidirectional socket-like abstractions on > the QUIC Library API layer. However, if we follow Mike=E2=80=99s suggest= ion and > allow an Associated Stream ID in OPEN_STREAM frames, this would make it > easy for QUICK Libraries to provide generic bidirectional socket-like > abstractions. > > > > So what I am suggesting is that we keep QUIC Wire Protocol state machine > simple and unchanged. However, with the OPEN_STREAM frame, we would allo= w > QUIC Libraries to implement both unidirectional and bidirectional streams= . > > > > - Igor > > Igor, I think you and I are in agreement that we both want a relatively easy way of doing both unidirectional streams as well as bidirectional streams? Given that, it comes down to what to standardize at the transport layer and some framing. In regards to the unidirectional only model: 1) The QUIC stream state machine is really not that complex, and the current documentation does a nice job of explaining it. Changing to unidirectional only streams only saves 2 states, from 5 to 3, and a small bit of text. 2) I'm very concerned that if we don't standardize a way to do bidirectional streams, different 'QUIC Library API's will internally standardize on different approaches for recreating bidirectional streams. I fear this may create more work and interoperability challenges down the road. So if we think literally no one will have any use for the bidirectional stream model, then I agree we should remove it. But even today, the HTTP mapping is simpler with the bidirectional stream model than with only unidirectional streams, which means the total amount of work of implementing HTTP + QUIC is about the same either way, and I believe if bidirectional streams and unidirectional streams do exist in QUIC(as in my PR above), then the HTTP would/should use both. > > > > > *From:* Jana Iyengar [mailto:jri@google.com] > *Sent:* Thursday, June 22, 2017 9:26 PM > *To:* Lubashev, Igor > *Cc:* Mike Bishop ; Ted Hardie < > ted.ietf@gmail.com>; QUIC WG ; Martin Thomson < > martin.thomson@gmail.com>; Patrick McManus > > *Subject:* Re: Unidirectional streams PR > > > > On Thu, Jun 22, 2017 at 6:06 PM, Lubashev, Igor > wrote: > > I like the idea of unidirectional streams, if they make life easier for > apps -- both "traditional" apps like H2 as well as less usual apps like s= sh > (one stream in one direction, two associated streams in the opposite > direction). > > I also like Mike's idea of OPEN_STREAM frame. The way I'd describe > OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offset a= nd > a set of "per-stream properties". > > An important point is that when Transport is aware of the association of > two unidirectional streams, the Transport API would be able to implement = a > bidirectional socket-like abstraction for applications that desire one. > > > > I'm not sure I follow your thinking here: are you suggesting that QUIC > implement bidirectional streams in addition to unidirectional streams? > > > > - jana > > > > > OPEN_STREAM frame > The type byte for a OPEN_STREAM frame contains embedded flags, and is > formatted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM fra= me. > * The PP bits encode the size of the Params Bitmap field. The values 00, > 01, 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respective= ly. > > The two Least Significant bits of the Params Bitmap indicate the length o= f > the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate > lengths of 0 (none), 8, 16, and 32 bits long respectively. > We can define up to 30 additional bits to be meaningful to the transport. > (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, > Priority-Delivery (aka "DontBuffer") bit, etc). > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream ID (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Params Bitmap (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Associated Stream ID (0/8/16/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Data Length (16)] | Stream Data (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent t= o > STREAM frame with OO=3D0. > > > > -----Original Message----- > From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] > Sent: Thursday, June 22, 2017 6:48 PM > To: Martin Thomson ; Ted Hardie < > ted.ietf@gmail.com> > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > > Subject: RE: Unidirectional streams PR > > I suppose you could drop the stream type header from HTTP into QUIC and > make the types "bidirectional stream," "unidirectional stream," and "mate > of bidirectional stream"; the last would further need to identify which > peer stream it corresponded to. > > But making them the first couple bytes of the stream data feels kind of > kludgy if this is fundamentally built into the transport, which means the= y > really belong in a dedicated frame. Maybe a dedicated OPEN_STREAM frame, > which blocks any data received on that stream until you know what type it > is? > > Actually, if we're planning on introducing other per-stream properties > like partial reliability, there might be value in an OPEN_STREAM frame > where we can describe a stream's desired properties before any data > flows.... > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Thursday, June 22, 2017 3:32 PM > To: Ted Hardie > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > Subject: Re: Unidirectional streams PR > > On 23 June 2017 at 05:15, Ted Hardie wrote: > > My personal take on that right answer there is to support both, with > > an explicit signal of when each model is in use, > > I have heard this request now from several folks at Google. I don't know > how to make this work without increasing complexity considerably . I'd b= e > willing to be wrong about this, but would prefer to see a proposal. I > don't need a fully-worked proposal with text, just a sketch of how the > pieces work in enough detail to understand how this might interact with > other parts of the protocol. I think that Jana offered to do this, so > maybe I can wait for that (c.f., Mark's earlier statement about > priority/urgency). > > > --94eb2c094216d9b25f055297192f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 22, 2017 at 9:49 PM, Lubashev, Igor <ilubashe@akamai.com&g= t; wrote:

I think of three layers of abstraction:

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 QUIC Wire Protocol (the thing described by the= QUIC Transport RFC)

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 QUIC Library API (a library exposing some usef= ul abstractions -- such as blocking/non-blocking unidirectional streams and= bidirectional =E2=80=9Csockets=E2=80=9D -- and implementing them using QUIC Wire Protocol)

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Application (something that uses QUIC Library = APIs)

=C2=A0

What I am saying is that Martin=E2=80=99s unidirect= ional streams proposal does not have a way to implement generic bidirection= al socket-like abstractions on the QUIC Library API layer.=C2=A0 However, if we follow Mike=E2=80=99s suggestion and allow an Associated St= ream ID in OPEN_STREAM frames, this would make it easy for QUICK Libraries = to provide generic bidirectional socket-like abstractions.

=C2=A0

So what I am suggesting is that we keep QUIC Wire P= rotocol state machine simple and unchanged.=C2=A0 However, with the OPEN_ST= REAM frame, we would allow QUIC Libraries to implement both unidirectional and bidirectional streams.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Igor

Igo= r, I think you and I are in agreement that we both want a relatively easy w= ay of doing both unidirectional streams as well as bidirectional streams?= =C2=A0 Given that, it comes down to what to standardize at the transport la= yer and some framing.

In regards to the unidirecti= onal only model:
=C2=A01) The QUIC stream state machine is really= not that complex, and the current documentation does a nice job of explain= ing it.=C2=A0 Changing to unidirectional only streams only saves 2 states, = from 5 to 3, and a small bit of text.
=C2=A02) I'm very conce= rned that if we don't standardize a way to do bidirectional streams, di= fferent 'QUIC Library API's will internally standardize on differen= t approaches for recreating bidirectional streams.=C2=A0 I fear this may cr= eate more work and interoperability challenges down the road.
So if we think literally no one will have any use for the bidir= ectional stream model, then I agree we should remove it.=C2=A0 But even tod= ay, the HTTP mapping is simpler with the bidirectional stream model than wi= th only unidirectional streams, which means the total amount of work of imp= lementing HTTP + QUIC is about the same either way, and I believe if bidire= ctional streams and unidirectional streams do exist in QUIC(as in my PR abo= ve), then the HTTP would/should use both.
=C2=A0

=C2=A0=

=C2=A0

From: Jana Iyengar [mailto:jri@google.com]
Sent: Thursday, June 22, 2017 9:26 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Ted Hardie <= ;ted.ietf@gmail.com= >; QUIC WG <qu= ic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>; Patrick McManu= s <pmcmanus@mo= zilla.com>


Subject: Re: Unidirectional streams PR

<= /p>

=C2=A0

On Thu, Jun 22, 2017 at 6:06 PM, Lubashev, Igor <= ilubashe@akamai.co= m> wrote:

I like the idea of unidirectional streams, if they m= ake life easier for apps -- both "traditional" apps like H2 as we= ll as less usual apps like ssh (one stream in one direction, two associated= streams in the opposite direction).

I also like Mike's idea of OPEN_STREAM frame.=C2=A0 The way I'd des= cribe OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offs= et and a set of "per-stream properties".

An important point is that when Transport is aware of the association of tw= o unidirectional streams, the Transport API would be able to implement a bi= directional socket-like abstraction for applications that desire one.

=C2=A0

I'm not sure I follow your thinking here: are yo= u suggesting that QUIC implement bidirectional streams in addition to unidi= rectional streams?

=C2=A0

- jana

=C2=A0


OPEN_STREAM frame
The type byte for a OPEN_STREAM frame contains embedded flags, and is forma= tted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM frame.
* The PP bits encode the size of the Params Bitmap field. The values 00, 01= , 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respectively.<= br>
The two Least Significant bits of the Params Bitmap indicate the length of = the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate length= s of 0 (none), 8, 16, and 32 bits long respectively.
We can define up to 30 additional bits to be meaningful to the transport.= =C2=A0 (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, Pri= ority-Delivery (aka "DontBuffer") bit, etc).

0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stre= am ID (8/16/24/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Params Bitmap=C2= =A0 (8/16/24/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Associated Stream ID (0/8/16/32)= =C2=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[Data Length (16)]=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stream Data (*)=C2=A0 =C2=A0 =C2=A0 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent to = STREAM frame with OO=3D0.



-----Original Message----- From: Mike Bishop [mailto:Michael.Bishop@<= wbr>microsoft.com]
Sent: Thursday, June 22, 2017 6:48 = PM
To: Martin Thomson <martin.thomson@gmail.com<= /a>>; Ted Hardie <ted.ietf@gmail.com>
Cc: Jana Iyengar <jri@google.com>; QUIC WG <<= a href=3D"mailto:quic@ietf.org" target=3D"_blank">quic@ietf.org>; Pa= trick McManus <pmcmanus@mozilla.com>

Subject: RE: Unidirec= tional streams PR

I suppose you could drop the stream type header from HTTP into QUIC and mak= e the types "bidirectional stream," "unidirectional stream,&= quot; and "mate of bidirectional stream"; the last would further = need to identify which peer stream it corresponded to.

But making them the first couple bytes of the stream data feels kind of klu= dgy if this is fundamentally built into the transport, which means they rea= lly belong in a dedicated frame.=C2=A0 Maybe a dedicated OPEN_STREAM frame,= which blocks any data received on that stream until you know what type it is?

Actually, if we're planning on introducing other per-stream properties = like partial reliability, there might be value in an OPEN_STREAM frame wher= e we can describe a stream's desired properties before any data flows..= ..

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Thursday, June 22, 2017 3:32 PM
To: Ted Hardie <= ted.ietf@gmail.com>
Cc: Jana Iyengar <jr= i@google.com>; QUIC WG <quic@ietf.org>; Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: Unidirectional streams PR

On 23 June 2017 at 05:15, Ted Hardie <ted.ietf@gmail.com> wrote:
> My personal take on that right answer there is to support both, with > an explicit signal of when each model is in use,

I have heard this request now from several folks at Google.=C2=A0 I don'= ;t know how to make this work without increasing complexity considerably .= =C2=A0 I'd be willing to be wrong about this, but would prefer to see a= proposal.=C2=A0 I don't need a fully-worked proposal with text, just a sketch of how the pieces work in enough detail to understand = how this might interact with other parts of the protocol.=C2=A0 I think tha= t Jana offered to do this, so maybe I can wait for that (c.f., Mark's e= arlier statement about priority/urgency).

=C2=A0


--94eb2c094216d9b25f055297192f-- From nobody Thu Jun 22 19:43: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 1CA03129449 for ; Thu, 22 Jun 2017 19:43: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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP7s3ux_AOE8 for ; Thu, 22 Jun 2017 19:43:29 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76671200E5 for ; Thu, 22 Jun 2017 19:43:29 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5N2hOnJ031327; Fri, 23 Jun 2017 03:43:24 +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=MsY++mB8nQ/aZNxysEzngGcD3Mj8prbTnzAMYrQugjA=; b=acNdP0nNVqwIClZVo+ABSGe4bbWrpQpjCVJi40+4Ce476TPc70RINSVm6T2kBUuKcomR d8uFjQUB/KAxIdmdvA7si7fOU6ekipYg1uGkyc0pSzslCI4J4aT7E/tJxqsJwwfaIUmG VAymGKndkfYvYHA3rxzbVSv13BZqTpQt1fXswy2gEoqn8n2KlQF5gmb4zqQyZIAuRJvt iahPZkKsRhzy1ekYAr34pHibEN7fVRqOBQrLresfdoV3xv2fswCzAv4lxNQlJMTeOziE FSwvd2VoWXUFRiF7vyZ1WNEUkRuLzB2tmZtOq4OcKt6krf/vXUVWqZGqhQGEyZQoS5O5 JQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b8f92ujmn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 03:43:24 +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 v5N2eoth005259; Thu, 22 Jun 2017 22:43:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b4yrvn7ym-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Jun 2017 22:43:23 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 22 Jun 2017 22:43:22 -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, 22 Jun 2017 22:43:22 -0400 From: "Lubashev, Igor" To: Ian Swett CC: Jana Iyengar , Mike Bishop , Ted Hardie , QUIC WG , Martin Thomson , Patrick McManus Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHzFJcNmOfPnkGlJjRXQ/9soKIvh8kAgADqdYCAACIYgIABI/8AgAAEzYCAAARGgP//0FFwgABb0AD//76RwIAATcWA//+9o9A= Date: Fri, 23 Jun 2017 02:43:22 +0000 Message-ID: <2260e852b904465a9f8c9488e7e76166@usma1ex-dag1mb5.msg.corp.akamai.com> References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@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.34.60] Content-Type: multipart/alternative; boundary="_000_2260e852b904465a9f8c9488e7e76166usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230044 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230044 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, 23 Jun 2017 02:43:32 -0000 --_000_2260e852b904465a9f8c9488e7e76166usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB3ZSBhcmUgaW4gYW4gYWdyZWVtZW50IHRoYXQgd2Ugd2FudCDigJxRVUlDIExpYnJhcmll c+KAnSB0byBwcm92aWRlIGFuIGVhc3kgd2F5IG9mIGRvaW5nIGJvdGggdW5pZGlyZWN0aW9uYWwg c3RyZWFtcyBhcyB3ZWxsIGFzIGJpZGlyZWN0aW9uYWwgc3RyZWFtcy4NCg0KSSBkbyBub3QgaGF2 ZSBhIHN0cm9uZyBwcmVmZXJlbmNlIGFzIHRvIHRoZSBkZXRhaWxzIG9mIGZyYW1pbmcuIE9uIG9u ZSBoYW5kLCBJIGFtIG5vdCB3b3JyaWVkIGFib3V0IGxpYnJhcmllcyBpbXBsZW1lbnRpbmcgYmlk aXJlY3Rpb25hbCBzdHJlYW1zIGRpZmZlcmVudGx5IHdpdGggT1BFTl9TVFJFQU0g4oCTIHRoZXJl IGlzIHJlYWxseSBqdXN0IG9uZSBzYW5lIHdheSBvZiBkb2luZyBpdCwgYW5kIHRoZSBPUEVOX1NU UkVBTSBtb2RlbCBpcyBtb3JlIGZsZXhpYmxlLiAgT24gdGhlIG90aGVyIGhhbmQsIE9QRU5fU1RS RUFNIGNvbWVzIGF0IGEgY29zdCBvZiBhIGZldyBleHRyYSBieXRlcyBmb3IgYSBzaW1wbGUgYmlk aXJlY3Rpb25hbCBzdHJlYW0gaW1wbGVtZW50YXRpb24uDQoNClRoZSBVTkkgZG9lcyBjb21wbGlj YXRlIHRoZSBzdGF0ZSBtYWNoaW5lIGEgYml0IGJ5IGFkZGluZyBhbiBleHRyYSBzdGF0ZSwgYXMg ZWtyIHBvaW50ZWQgb3V0LiAgWW91IG5lZWQgYSBzcGVjaWFsIHN0YXRlIGZvciBpbXBsaWNpdGx5 IG9wZW5lZCBzdHJlYW1zLiAgVGhleSBhcmUgbm90IOKAnGlkbGXigJ0gKHRoZXkgY291bnQgdG93 YXJkIHRoZSBtYXgpLCBhbmQgdGhleSBhcmUgbm90IOKAnG9wZW7igJ0gKHlvdSBjYW5ub3Qgd3Jp dGUgdG8gdGhlbSksIGFuZCB0aGV5IGFyZSBub3Qg4oCcbG9jYWwgaGFsZi1jbG9zZWTigJ0gKHRo ZXkgbWF5IHRyYW5zaXRpb24gdG8g4oCcb3BlbuKAnSkuICBJIGRvIG5vdCB0aGluayB0aGlzIGlz IGEgaHVnZSBkZWFsLCB0aG91Z2gg4oCTIFRDUCBoYXMgYSBsb3QgbW9yZSBzdGF0ZXMhDQoNCg0K RnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBKdW5lIDIyLCAyMDE3IDEwOjEwIFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hl QGFrYW1haS5jb20+DQpDYzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IE1pa2UgQmlz aG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPjsgVGVkIEhhcmRpZSA8dGVkLmlldGZA Z21haWwuY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uIDxtYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20+OyBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEu Y29tPg0KU3ViamVjdDogUmU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgUFINCg0KT24gVGh1LCBK dW4gMjIsIDIwMTcgYXQgOTo0OSBQTSwgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5j b208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCkkgdGhpbmsgb2YgdGhyZWUg bGF5ZXJzIG9mIGFic3RyYWN0aW9uOg0KDQoNCjEuICAgICAgIFFVSUMgV2lyZSBQcm90b2NvbCAo dGhlIHRoaW5nIGRlc2NyaWJlZCBieSB0aGUgUVVJQyBUcmFuc3BvcnQgUkZDKQ0KDQoyLiAgICAg ICBRVUlDIExpYnJhcnkgQVBJIChhIGxpYnJhcnkgZXhwb3Npbmcgc29tZSB1c2VmdWwgYWJzdHJh Y3Rpb25zIC0tIHN1Y2ggYXMgYmxvY2tpbmcvbm9uLWJsb2NraW5nIHVuaWRpcmVjdGlvbmFsIHN0 cmVhbXMgYW5kIGJpZGlyZWN0aW9uYWwg4oCcc29ja2V0c+KAnSAtLSBhbmQgaW1wbGVtZW50aW5n IHRoZW0gdXNpbmcgUVVJQyBXaXJlIFByb3RvY29sKQ0KDQozLiAgICAgICBBcHBsaWNhdGlvbiAo c29tZXRoaW5nIHRoYXQgdXNlcyBRVUlDIExpYnJhcnkgQVBJcykNCg0KV2hhdCBJIGFtIHNheWlu ZyBpcyB0aGF0IE1hcnRpbuKAmXMgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBwcm9wb3NhbCBkb2Vz IG5vdCBoYXZlIGEgd2F5IHRvIGltcGxlbWVudCBnZW5lcmljIGJpZGlyZWN0aW9uYWwgc29ja2V0 LWxpa2UgYWJzdHJhY3Rpb25zIG9uIHRoZSBRVUlDIExpYnJhcnkgQVBJIGxheWVyLiAgSG93ZXZl ciwgaWYgd2UgZm9sbG93IE1pa2XigJlzIHN1Z2dlc3Rpb24gYW5kIGFsbG93IGFuIEFzc29jaWF0 ZWQgU3RyZWFtIElEIGluIE9QRU5fU1RSRUFNIGZyYW1lcywgdGhpcyB3b3VsZCBtYWtlIGl0IGVh c3kgZm9yIFFVSUNLIExpYnJhcmllcyB0byBwcm92aWRlIGdlbmVyaWMgYmlkaXJlY3Rpb25hbCBz b2NrZXQtbGlrZSBhYnN0cmFjdGlvbnMuDQoNClNvIHdoYXQgSSBhbSBzdWdnZXN0aW5nIGlzIHRo YXQgd2Uga2VlcCBRVUlDIFdpcmUgUHJvdG9jb2wgc3RhdGUgbWFjaGluZSBzaW1wbGUgYW5kIHVu Y2hhbmdlZC4gIEhvd2V2ZXIsIHdpdGggdGhlIE9QRU5fU1RSRUFNIGZyYW1lLCB3ZSB3b3VsZCBh bGxvdyBRVUlDIExpYnJhcmllcyB0byBpbXBsZW1lbnQgYm90aCB1bmlkaXJlY3Rpb25hbCBhbmQg YmlkaXJlY3Rpb25hbCBzdHJlYW1zLg0KDQoNCi0gICAgICAgICAgSWdvcg0KSWdvciwgSSB0aGlu ayB5b3UgYW5kIEkgYXJlIGluIGFncmVlbWVudCB0aGF0IHdlIGJvdGggd2FudCBhIHJlbGF0aXZl bHkgZWFzeSB3YXkgb2YgZG9pbmcgYm90aCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFzIHdlbGwg YXMgYmlkaXJlY3Rpb25hbCBzdHJlYW1zPyAgR2l2ZW4gdGhhdCwgaXQgY29tZXMgZG93biB0byB3 aGF0IHRvIHN0YW5kYXJkaXplIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIgYW5kIHNvbWUgZnJhbWlu Zy4NCg0KSW4gcmVnYXJkcyB0byB0aGUgdW5pZGlyZWN0aW9uYWwgb25seSBtb2RlbDoNCiAxKSBU aGUgUVVJQyBzdHJlYW0gc3RhdGUgbWFjaGluZSBpcyByZWFsbHkgbm90IHRoYXQgY29tcGxleCwg YW5kIHRoZSBjdXJyZW50IGRvY3VtZW50YXRpb24gZG9lcyBhIG5pY2Ugam9iIG9mIGV4cGxhaW5p bmcgaXQuICBDaGFuZ2luZyB0byB1bmlkaXJlY3Rpb25hbCBvbmx5IHN0cmVhbXMgb25seSBzYXZl cyAyIHN0YXRlcywgZnJvbSA1IHRvIDMsIGFuZCBhIHNtYWxsIGJpdCBvZiB0ZXh0Lg0KIDIpIEkn bSB2ZXJ5IGNvbmNlcm5lZCB0aGF0IGlmIHdlIGRvbid0IHN0YW5kYXJkaXplIGEgd2F5IHRvIGRv IGJpZGlyZWN0aW9uYWwgc3RyZWFtcywgZGlmZmVyZW50ICdRVUlDIExpYnJhcnkgQVBJJ3Mgd2ls bCBpbnRlcm5hbGx5IHN0YW5kYXJkaXplIG9uIGRpZmZlcmVudCBhcHByb2FjaGVzIGZvciByZWNy ZWF0aW5nIGJpZGlyZWN0aW9uYWwgc3RyZWFtcy4gIEkgZmVhciB0aGlzIG1heSBjcmVhdGUgbW9y ZSB3b3JrIGFuZCBpbnRlcm9wZXJhYmlsaXR5IGNoYWxsZW5nZXMgZG93biB0aGUgcm9hZC4NCg0K U28gaWYgd2UgdGhpbmsgbGl0ZXJhbGx5IG5vIG9uZSB3aWxsIGhhdmUgYW55IHVzZSBmb3IgdGhl IGJpZGlyZWN0aW9uYWwgc3RyZWFtIG1vZGVsLCB0aGVuIEkgYWdyZWUgd2Ugc2hvdWxkIHJlbW92 ZSBpdC4gIEJ1dCBldmVuIHRvZGF5LCB0aGUgSFRUUCBtYXBwaW5nIGlzIHNpbXBsZXIgd2l0aCB0 aGUgYmlkaXJlY3Rpb25hbCBzdHJlYW0gbW9kZWwgdGhhbiB3aXRoIG9ubHkgdW5pZGlyZWN0aW9u YWwgc3RyZWFtcywgd2hpY2ggbWVhbnMgdGhlIHRvdGFsIGFtb3VudCBvZiB3b3JrIG9mIGltcGxl bWVudGluZyBIVFRQICsgUVVJQyBpcyBhYm91dCB0aGUgc2FtZSBlaXRoZXIgd2F5LCBhbmQgSSBi ZWxpZXZlIGlmIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBhbmQgdW5pZGlyZWN0aW9uYWwgc3RyZWFt cyBkbyBleGlzdCBpbiBRVUlDKGFzIGluIG15IFBSIGFib3ZlKSwgdGhlbiB0aGUgSFRUUCB3b3Vs ZC9zaG91bGQgdXNlIGJvdGguDQoNCg== --_000_2260e852b904465a9f8c9488e7e76166usma1exdag1mb5msgcorpak_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tNjQzNTcxNzM4ODg1MjU1NzA1 N21zb2xpc3RwYXJhZ3JhcGgsIGxpLm02NDM1NzE3Mzg4ODUyNTU3MDU3bXNvbGlzdHBhcmFncmFw aCwgZGl2Lm02NDM1NzE3Mzg4ODUyNTU3MDU3bXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUt bmFtZTptXzY0MzU3MTczODg4NTI1NTcwNTdtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5tNjQzNTcxNzM4ODg1MjU1NzA1N2lt DQoJe21zby1zdHlsZS1uYW1lOm1fNjQzNTcxNzM4ODg1MjU1NzA1N2ltO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjExMDcyMzk0NTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE5ODYwNTA3NjIgMTg2MTk0MTcwNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgd2UgYXJlIGluIGFuIGFncmVlbWVudCB0aGF0 IHdlIHdhbnQg4oCcUVVJQyBMaWJyYXJpZXPigJ0gdG8gcHJvdmlkZSBhbiBlYXN5IHdheSBvZiBk b2luZyBib3RoIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXMgd2VsbCBhcyBiaWRpcmVjdGlvbmFs IHN0cmVhbXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG8gbm90IGhhdmUgYSBzdHJvbmcgcHJlZmVyZW5j ZSBhcyB0byB0aGUgZGV0YWlscyBvZiBmcmFtaW5nLiBPbiBvbmUgaGFuZCwgSSBhbSBub3Qgd29y cmllZCBhYm91dCBsaWJyYXJpZXMgaW1wbGVtZW50aW5nIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBk aWZmZXJlbnRseSB3aXRoIE9QRU5fU1RSRUFNDQog4oCTIHRoZXJlIGlzIHJlYWxseSBqdXN0IG9u ZSBzYW5lIHdheSBvZiBkb2luZyBpdCwgYW5kIHRoZSBPUEVOX1NUUkVBTSBtb2RlbCBpcyBtb3Jl IGZsZXhpYmxlLiAmbmJzcDtPbiB0aGUgb3RoZXIgaGFuZCwgT1BFTl9TVFJFQU0gY29tZXMgYXQg YSBjb3N0IG9mIGEgZmV3IGV4dHJhIGJ5dGVzIGZvciBhIHNpbXBsZSBiaWRpcmVjdGlvbmFsIHN0 cmVhbSBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIFVOSSBkb2VzIGNvbXBsaWNh dGUgdGhlIHN0YXRlIG1hY2hpbmUgYSBiaXQgYnkgYWRkaW5nIGFuIGV4dHJhIHN0YXRlLCBhcyBl a3IgcG9pbnRlZCBvdXQuJm5ic3A7IFlvdSBuZWVkIGEgc3BlY2lhbCBzdGF0ZSBmb3IgaW1wbGlj aXRseSBvcGVuZWQgc3RyZWFtcy4mbmJzcDsgVGhleSBhcmUgbm90IOKAnGlkbGXigJ0NCiAodGhl eSBjb3VudCB0b3dhcmQgdGhlIG1heCksIGFuZCB0aGV5IGFyZSBub3Qg4oCcb3BlbuKAnSAoeW91 IGNhbm5vdCB3cml0ZSB0byB0aGVtKSwgYW5kIHRoZXkgYXJlIG5vdCDigJxsb2NhbCBoYWxmLWNs b3NlZOKAnSAodGhleSBtYXkgdHJhbnNpdGlvbiB0byDigJxvcGVu4oCdKS4mbmJzcDsgSSBkbyBu b3QgdGhpbmsgdGhpcyBpcyBhIGh1Z2UgZGVhbCwgdGhvdWdoIOKAkyBUQ1AgaGFzIGEgbG90IG1v cmUgc3RhdGVzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDIyLCAyMDE3IDEwOjEwIFBNPGJyPg0K PGI+VG86PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IEphbmEgSXllbmdhciAmbHQ7anJpQGdvb2dsZS5jb20mZ3Q7OyBNaWtlIEJp c2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IFRlZCBIYXJkaWUgJmx0 O3RlZC5pZXRmQGdtYWlsLmNvbSZndDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBN YXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgUGF0cmljayBN Y01hbnVzICZsdDtwbWNtYW51c0Btb3ppbGxhLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgUFI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVuIDIyLCAyMDE3IGF0IDk6NDkgUE0s IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIG9mIHRocmVlIGxheWVycyBvZiBhYnN0cmFjdGlv bjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02NDM1NzE3 Mzg4ODUyNTU3MDU3bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlFVSUMgV2lyZSBQcm90b2NvbCAodGhl IHRoaW5nIGRlc2NyaWJlZCBieSB0aGUgUVVJQyBUcmFuc3BvcnQgUkZDKTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtNjQzNTcxNzM4ODg1MjU1NzA1N21zb2xpc3RwYXJhZ3JhcGgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Mi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5RVUlDIExpYnJhcnkgQVBJIChhIGxpYnJhcnkgZXhwb3Npbmcgc29tZSB1c2VmdWwgYWJz dHJhY3Rpb25zIC0tIHN1Y2ggYXMgYmxvY2tpbmcvbm9uLWJsb2NraW5nIHVuaWRpcmVjdGlvbmFs IHN0cmVhbXMgYW5kIGJpZGlyZWN0aW9uYWwg4oCcc29ja2V0c+KAnSAtLSBhbmQgaW1wbGVtZW50 aW5nIHRoZW0gdXNpbmcgUVVJQyBXaXJlDQogUHJvdG9jb2wpPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im02NDM1NzE3Mzg4ODUyNTU3MDU3bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFw cGxpY2F0aW9uIChzb21ldGhpbmcgdGhhdCB1c2VzIFFVSUMgTGlicmFyeSBBUElzKTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+V2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IE1hcnRpbuKAmXMgdW5pZGlyZWN0 aW9uYWwgc3RyZWFtcyBwcm9wb3NhbCBkb2VzIG5vdCBoYXZlIGEgd2F5IHRvIGltcGxlbWVudCBn ZW5lcmljIGJpZGlyZWN0aW9uYWwNCiBzb2NrZXQtbGlrZSBhYnN0cmFjdGlvbnMgb24gdGhlIFFV SUMgTGlicmFyeSBBUEkgbGF5ZXIuJm5ic3A7IEhvd2V2ZXIsIGlmIHdlIGZvbGxvdyBNaWtl4oCZ cyBzdWdnZXN0aW9uIGFuZCBhbGxvdyBhbiBBc3NvY2lhdGVkIFN0cmVhbSBJRCBpbiBPUEVOX1NU UkVBTSBmcmFtZXMsIHRoaXMgd291bGQgbWFrZSBpdCBlYXN5IGZvciBRVUlDSyBMaWJyYXJpZXMg dG8gcHJvdmlkZSBnZW5lcmljIGJpZGlyZWN0aW9uYWwgc29ja2V0LWxpa2UgYWJzdHJhY3Rpb25z Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+U28gd2hhdCBJIGFtIHN1Z2dlc3RpbmcgaXMgdGhhdCB3ZSBr ZWVwIFFVSUMgV2lyZSBQcm90b2NvbCBzdGF0ZSBtYWNoaW5lIHNpbXBsZSBhbmQgdW5jaGFuZ2Vk LiZuYnNwOyBIb3dldmVyLCB3aXRoIHRoZQ0KIE9QRU5fU1RSRUFNIGZyYW1lLCB3ZSB3b3VsZCBh bGxvdyBRVUlDIExpYnJhcmllcyB0byBpbXBsZW1lbnQgYm90aCB1bmlkaXJlY3Rpb25hbCBhbmQg YmlkaXJlY3Rpb25hbCBzdHJlYW1zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTY0MzU3MTczODg4NTI1NTcwNTdtc29saXN0cGFyYWdyYXBoIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5JZ29yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZ29yLCBJIHRoaW5r IHlvdSBhbmQgSSBhcmUgaW4gYWdyZWVtZW50IHRoYXQgd2UgYm90aCB3YW50IGEgcmVsYXRpdmVs eSBlYXN5IHdheSBvZiBkb2luZyBib3RoIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXMgd2VsbCBh cyBiaWRpcmVjdGlvbmFsIHN0cmVhbXM/Jm5ic3A7IEdpdmVuIHRoYXQsIGl0IGNvbWVzIGRvd24g dG8gd2hhdCB0byBzdGFuZGFyZGl6ZSBhdCB0aGUgdHJhbnNwb3J0IGxheWVyIGFuZCBzb21lIGZy YW1pbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHJlZ2FyZHMgdG8gdGhlIHVuaWRpcmVjdGlvbmFsIG9ubHkgbW9kZWw6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsxKSBUaGUg UVVJQyBzdHJlYW0gc3RhdGUgbWFjaGluZSBpcyByZWFsbHkgbm90IHRoYXQgY29tcGxleCwgYW5k IHRoZSBjdXJyZW50IGRvY3VtZW50YXRpb24gZG9lcyBhIG5pY2Ugam9iIG9mIGV4cGxhaW5pbmcg aXQuJm5ic3A7IENoYW5naW5nIHRvIHVuaWRpcmVjdGlvbmFsIG9ubHkgc3RyZWFtcyBvbmx5IHNh dmVzIDIgc3RhdGVzLCBmcm9tIDUgdG8gMywgYW5kIGEgc21hbGwgYml0IG9mIHRleHQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsyKSBJ J20gdmVyeSBjb25jZXJuZWQgdGhhdCBpZiB3ZSBkb24ndCBzdGFuZGFyZGl6ZSBhIHdheSB0byBk byBiaWRpcmVjdGlvbmFsIHN0cmVhbXMsIGRpZmZlcmVudCAnUVVJQyBMaWJyYXJ5IEFQSSdzIHdp bGwgaW50ZXJuYWxseSBzdGFuZGFyZGl6ZSBvbiBkaWZmZXJlbnQgYXBwcm9hY2hlcyBmb3IgcmVj cmVhdGluZyBiaWRpcmVjdGlvbmFsIHN0cmVhbXMuJm5ic3A7IEkgZmVhciB0aGlzIG1heSBjcmVh dGUgbW9yZQ0KIHdvcmsgYW5kIGludGVyb3BlcmFiaWxpdHkgY2hhbGxlbmdlcyBkb3duIHRoZSBy b2FkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TbyBpZiB3ZSB0aGluayBsaXRlcmFsbHkgbm8gb25lIHdpbGwgaGF2ZSBhbnkgdXNlIGZvciB0 aGUgYmlkaXJlY3Rpb25hbCBzdHJlYW0gbW9kZWwsIHRoZW4gSSBhZ3JlZSB3ZSBzaG91bGQgcmVt b3ZlIGl0LiZuYnNwOyBCdXQgZXZlbiB0b2RheSwgdGhlIEhUVFAgbWFwcGluZyBpcyBzaW1wbGVy IHdpdGggdGhlIGJpZGlyZWN0aW9uYWwgc3RyZWFtIG1vZGVsIHRoYW4gd2l0aCBvbmx5IHVuaWRp cmVjdGlvbmFsIHN0cmVhbXMsDQogd2hpY2ggbWVhbnMgdGhlIHRvdGFsIGFtb3VudCBvZiB3b3Jr IG9mIGltcGxlbWVudGluZyBIVFRQICYjNDM7IFFVSUMgaXMgYWJvdXQgdGhlIHNhbWUgZWl0aGVy IHdheSwgYW5kIEkgYmVsaWV2ZSBpZiBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgYW5kIHVuaWRpcmVj dGlvbmFsIHN0cmVhbXMgZG8gZXhpc3QgaW4gUVVJQyhhcyBpbiBteSBQUiBhYm92ZSksIHRoZW4g dGhlIEhUVFAgd291bGQvc2hvdWxkIHVzZSBib3RoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2260e852b904465a9f8c9488e7e76166usma1exdag1mb5msgcorpak_-- From nobody Thu Jun 22 20:18: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 005891241FC for ; Thu, 22 Jun 2017 20:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_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 0qPAv84v_XMm for ; Thu, 22 Jun 2017 20:18:32 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0104.outbound.protection.outlook.com [104.47.36.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 7E407120046 for ; Thu, 22 Jun 2017 20:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q/R0ytPYEZJpqhd2HwDcYqnbhJYLX/rp0xoXmc7RZv8=; b=eb9ca3YqzWFXqyfm7vZdZmxh+r4T/ekKuw+BvYOH9NUed+vg56zrm/E1hpMEHPBr3Tawt9Bqd3ldeE8IcCgCoagZaSoRPMEaN4rkzTOt+MnkPz/cUCkgecinRnQJ5s7v9qPK5Og7ZeFhn6+1p98xhmG8tzlU3yiUF7S9EokT3Qw= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.1; Fri, 23 Jun 2017 03:18:30 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.01.1220.005; Fri, 23 Jun 2017 03:18:30 +0000 From: Mike Bishop To: "Lubashev, Igor" , Martin Thomson , Ted Hardie CC: Jana Iyengar , QUIC WG , Patrick McManus Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHyIpxR/afFiUiHxd5TQx2M+qIvEnAAgADqdYCAACIZgIABI/4AgAA3F4CAAAIxEIAAKOgAgAAhMfA= Date: Fri, 23 Jun 2017 03:18:29 +0000 Message-ID: References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> 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=microsoft.com; x-originating-ip: [2601:600:8080:5a28:2d28:f631:f3c8:650e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0141; 7:KMH1uahYSdpLqM2e2IVZEMMjORTlY3Kxw+y49VorwQ4KAw96JxzkcS7AUkVUKU4uX+5Q/6T8/VDdMNm66BkgJP4j5+2vNS8X5gW6hYS9aGpQqv8CT5Y7v2AAITns+wPCpUJeb4i/nvm3016CYX/vsO1R7S1vzErwo9m+VmfSToTtGfDbpcUgNrC2f+9+tFKAT/UUtp3BE8GAS/PNxzxYukFg/kNqdv/fMa0nS5c9WFYEOiyddnuiNz7Jxl/5PMl2XWEMdWeDJ0CI2Ut5dKI9l2SaHz63FoGLiwDCBWmkEbtYeVJVZMvRVi7WtINm6+JnID+XmKXxRrZMOcT12Ulb/nZNVBQ8nGvOOsddTRrkYOmeu3gy8s7aq4RflcNolku8zYRFn8lEjAga1SYxisvkm8ptxGIp+pL5BcqrNRw1avDPwRHY4aSiZLTLwdf4SbLf5F2hgg/Wib78u8ZpjPWPp5+QhYXML41FauUHIzA4XBDE6HSK402qDemeEatT0z6om+M7xvpdIt2iGTgfK6+l1TlZWkiXteGq4v02KRGX2ea3tGsqP3IePFztKzaahyHyN3PWABvNA8T+mUGstmvKTReKkLeeky8+32bVM7tCyKaWVQWlVFYFcZAvujsYRxG6Y0Nt6ChgJsWiDIccqwPDyRE8GVNPLLYfumTJr6NO1UR3yEthaP2mpPxirUKKca7pnO+HJyHb3xjRJJcglsJhBdk3BIizB1/tB2V846bshHrIBLvnA1UtZvGGzUK4HnYGLhD59a0sktKkYGDXWW4Egg+gr1r5NHs9ntTkEc1rwQcFum7b7gsp/Hted2v8k4a5 x-ms-office365-filtering-correlation-id: be4b3d01-a01f-4212-b911-08d4b9e68599 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500061)(300135000095)(300000501061)(300135300095)(22001)(300000502061)(300135100095)(2017030254075)(48565401081)(300000503061)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504061)(300135200095)(300000505061)(300135600095)(300000506054)(300135500095); SRVR:MWHPR21MB0141; x-ms-traffictypediagnostic: MWHPR21MB0141: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(35073007944872)(211936372134217)(155532106045638); 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)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0141; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0141; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39400400002)(39850400002)(39410400002)(39840400002)(51444003)(24454002)(377454003)(13464003)(561944003)(53546010)(53936002)(6246003)(5005710100001)(77096006)(38730400002)(74316002)(72206003)(229853002)(6506006)(6436002)(99286003)(55016002)(54906002)(305945005)(102836003)(86612001)(2900100001)(8676002)(7696004)(2950100002)(81166006)(8936002)(86362001)(478600001)(3480700004)(93886004)(5660300001)(6116002)(9686003)(7116003)(8990500004)(33656002)(7736002)(4326008)(3660700001)(122556002)(3280700002)(14454004)(189998001)(10290500003)(25786009)(50986999)(68736007)(39060400002)(10090500001)(2906002)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0141; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2017 03:18:29.7590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0141 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, 23 Jun 2017 03:18:35 -0000 SW50ZXJlc3RpbmcgZGVzaWduLiAgSSB3YXMgdHJ5aW5nIHRvIGF2b2lkIGRvdWJsaW5nIHRoZSBu dW1iZXIgb2YgZnJhbWVzIGNvbnN1bWVkIGJ5IHRoZSBTVFJFQU0gZnJhbWUgYnkgY29uc3VtaW5n IGp1c3Qgb25lLiAgQnV0IGl0J3MgYSBnb29kIGluc2lnaHQgdGhhdCBvZmZzZXQgaXMgb25seSBh YnNlbnQgb24gdGhlIGZpcnN0IFNUUkVBTSBmcmFtZSwgc28gd2UgY291bGQgbGV2ZXJhZ2UgdGhh dCBpZiB3ZSB3YW50ZWQgdG8uICBNYXliZSBPTz0wIGluZGljYXRlcyB0aGUgcHJlc2VuY2Ugb2Yg c29tZSBmaXhlZC1zaXplIHBhcmFtcywgYW5kIG9uZSBvZiB0aG9zZSBiaXRzIGlzIGRpcmVjdGlv bmFsaXR5Pw0KDQpJIHdhc24ndCBjb252aW5jZWQgdGhpcyBpcyBzaW1wbGVyLCBiZWNhdXNlIEhU VFAvUVVJQyB3b3VsZCBzdGlsbCBuZWVkIGEgc3RyZWFtIGhlYWRlci4gIEJ1dCBpZiB3ZSB1c2Vk IGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBmb3IgcmVxdWVzdC9yZXNwb25zZSwgdGhlbiBhbGwgdW5p ZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUgUFVTSF9QUk9NSVNFLCBhbmQgdGhleSdyZSB0aGUgb25s eSBvbmVzIHRoYXQgbmVlZCBhIHN0cmVhbSBoZWFkZXIuDQoNCkhvd2V2ZXIsIGxldCBtZSBwb2lu dCBvdXQgdGhhdCB0aGlzIGlzIGZ1bmRhbWVudGFsbHkgc3RpbGwgdW5pZGlyZWN0aW9uYWwgc3Ry ZWFtcyB3aXRoIHRoZSBhYmlsaXR5IHRvIGRlY2xhcmUgKGFzIG1ldGFkYXRhKSB0aGF0IGEgcGFy dGljdWxhciBzdHJlYW0gaXMgImFmZmlsaWF0ZWQiIHdpdGggYSBzdHJlYW0gaW4gdGhlIG9wcG9z aXRlIGRpcmVjdGlvbi4gIChBbmQgcGVyaGFwcyB0aGUgYWJpbGl0eSBmb3IgdGhlIHN0cmVhbSBp bml0aWF0b3IgdG8gZGVjbGFyZSBhbiBleHBlY3RhdGlvbiB0aGF0IHRoZXJlIHdpbGwgYmUgYW4g YWZmaWxpYXRpb24gY29taW5nLikgIFRoaXMgZG9lcyBjaGFuZ2UgdGhlIHJlcXVlc3Qgb24gTiAv IHJlc3BvbnNlIG9uIE4gbW9kZWwuICBXZSdyZSBqdXN0IHRhbGtpbmcgYWJvdXQgbW92aW5nIHRo ZSBjb3JyZWxhdG9yIGludG8gdGhlIFFVSUMgZnJhbWluZywgc28gdGhhdCBlYWNoIG1hcHBpbmcg ZG9lc24ndCBoYXZlIHRvIHJlY29uc3RydWN0IGhvdyB0byBkbyBjb3JyZWxhdGlvbnMuDQoNClRo YXQgbWVhbnMgd2UgZ2V0IChvciBjYW4gZ2V0KSB0aGUgc2FtZSBzdGF0ZSBzaW1wbGlmaWNhdGlv bnMgYXMgaW4gdGhlIFBSIGJ5IGNvbnNpZGVyaW5nIHRoZSBzdHJlYW1zIHRvIGhhdmUgaW5kZXBl bmRlbnQgbGlmZWN5Y2xlcyAtLSB0aGUgY29ycmVsYXRvciBpcyBzaW1wbHkgbWFkZSBhdmFpbGFi bGUgdG8gdGhlIGFwcGxpY2F0aW9uIGFzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdHJlYW0uICBU aGF0IGFsc28gbWVhbnMgdGhhdCBhZGRpbmcgdGhlIGNvcnJlbGF0b3IgY2FuIGJlIGRvbmUgaW4g YSBzZXBhcmF0ZSBQUiwgaWYgd2UgcHJlZmVyLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZUBha2FtYWkuY29tXSANClNl bnQ6IFRodXJzZGF5LCBKdW5lIDIyLCAyMDE3IDY6MDcgUE0NClRvOiBNaWtlIEJpc2hvcCA8TWlj aGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+DQpDYzogSmFuYSBJ eWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBQYXRyaWNr IE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPg0KU3ViamVjdDogUkU6IFVuaWRpcmVjdGlv bmFsIHN0cmVhbXMgUFINCg0KSSBsaWtlIHRoZSBpZGVhIG9mIHVuaWRpcmVjdGlvbmFsIHN0cmVh bXMsIGlmIHRoZXkgbWFrZSBsaWZlIGVhc2llciBmb3IgYXBwcyAtLSBib3RoICJ0cmFkaXRpb25h bCIgYXBwcyBsaWtlIEgyIGFzIHdlbGwgYXMgbGVzcyB1c3VhbCBhcHBzIGxpa2Ugc3NoIChvbmUg c3RyZWFtIGluIG9uZSBkaXJlY3Rpb24sIHR3byBhc3NvY2lhdGVkIHN0cmVhbXMgaW4gdGhlIG9w cG9zaXRlIGRpcmVjdGlvbikuDQoNCkkgYWxzbyBsaWtlIE1pa2UncyBpZGVhIG9mIE9QRU5fU1RS RUFNIGZyYW1lLiAgVGhlIHdheSBJJ2QgZGVzY3JpYmUgT1BFTl9TVFJFQU0gZnJhbWUgaXMgdGhh dCBpdCBpcyBpbXBsaWNpdGx5IGEgU1RSRUFNIGZyYW1lIHdpdGggMC1vZmZzZXQgYW5kIGEgc2V0 IG9mICJwZXItc3RyZWFtIHByb3BlcnRpZXMiLg0KDQpBbiBpbXBvcnRhbnQgcG9pbnQgaXMgdGhh dCB3aGVuIFRyYW5zcG9ydCBpcyBhd2FyZSBvZiB0aGUgYXNzb2NpYXRpb24gb2YgdHdvIHVuaWRp cmVjdGlvbmFsIHN0cmVhbXMsIHRoZSBUcmFuc3BvcnQgQVBJIHdvdWxkIGJlIGFibGUgdG8gaW1w bGVtZW50IGEgYmlkaXJlY3Rpb25hbCBzb2NrZXQtbGlrZSBhYnN0cmFjdGlvbiBmb3IgYXBwbGlj YXRpb25zIHRoYXQgZGVzaXJlIG9uZS4NCg0KDQpPUEVOX1NUUkVBTSBmcmFtZQ0KVGhlIHR5cGUg Ynl0ZSBmb3IgYSBPUEVOX1NUUkVBTSBmcmFtZSBjb250YWlucyBlbWJlZGRlZCBmbGFncywgYW5k IGlzIGZvcm1hdHRlZCBhcyAxMEZTU1BQRC4gVGhlIEYsIFNTLCBhbmQgRCBiaXRzIGFyZSBwYXJz ZWQgYXMgcGVyIFNUUkVBTSBmcmFtZS4NCiogVGhlIFBQIGJpdHMgZW5jb2RlIHRoZSBzaXplIG9m IHRoZSBQYXJhbXMgQml0bWFwIGZpZWxkLiBUaGUgdmFsdWVzIDAwLCAwMSwgMDIsIGFuZCAwMyBp bmRpY2F0ZSBsZW5ndGhzIG9mIDgsIDE2LCAyNCwgYW5kIDMyIGJpdHMgbG9uZyByZXNwZWN0aXZl bHkuDQoNClRoZSB0d28gTGVhc3QgU2lnbmlmaWNhbnQgYml0cyBvZiB0aGUgUGFyYW1zIEJpdG1h cCBpbmRpY2F0ZSB0aGUgbGVuZ3RoIG9mIHRoZSBBc3NvY2lhdGVkIFN0cmVhbSBJRC4gVGhlIExT QiB2YWx1ZXMgMDAsIDAxLCAwMiwgYW5kIDAzIGluZGljYXRlIGxlbmd0aHMgb2YgMCAobm9uZSks IDgsIDE2LCBhbmQgMzIgYml0cyBsb25nIHJlc3BlY3RpdmVseS4NCldlIGNhbiBkZWZpbmUgdXAg dG8gMzAgYWRkaXRpb25hbCBiaXRzIHRvIGJlIG1lYW5pbmdmdWwgdG8gdGhlIHRyYW5zcG9ydC4g IChJIGNhbiBpbWFnaW5lIFBhcnRpYWwtUmVsaWFiaWxpdHkgYml0LCBGbG93LUNvbnRyb2wtRXhl bXB0IGJpdCwgUHJpb3JpdHktRGVsaXZlcnkgKGFrYSAiRG9udEJ1ZmZlciIpIGJpdCwgZXRjKS4N Cg0KMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMw0KIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMQ0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgICAgICAgICAgICAgICAgIFN0cmVhbSBJ RCAoOC8xNi8yNC8zMikgICAgICAgICAgICAgICAgICAgLi4uDQorLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAg ICAgICAgICBQYXJhbXMgQml0bWFwICAoOC8xNi8yNC8zMikgICAgICAgICAgICAgICAgICAgLi4u DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KfCAgICAgICAgICAgIEFzc29jaWF0ZWQgU3RyZWFtIElEICgwLzgvMTYvMzIp ICAgICAgICAgICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgIFtEYXRhIExlbmd0aCAo MTYpXSAgICAgIHwgICAgICAgIFN0cmVhbSBEYXRhICgqKSAgICAgIC4uLg0KKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0K Tm90ZSB0aGF0IGlmIFBhcmFtcyBCaXRtYXAgaXMgMHgwLCB0aGlzIE9QRU5fU1RSRUFNIGZyYW1l IGlzIGVxdWl2YWxlbnQgdG8gU1RSRUFNIGZyYW1lIHdpdGggT089MC4NCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOk1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVuZSAyMiwgMjAxNyA2OjQ4IFBN DQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IFRlZCBIYXJk aWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29t PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96 aWxsYS5jb20+DQpTdWJqZWN0OiBSRTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQpJIHN1 cHBvc2UgeW91IGNvdWxkIGRyb3AgdGhlIHN0cmVhbSB0eXBlIGhlYWRlciBmcm9tIEhUVFAgaW50 byBRVUlDIGFuZCBtYWtlIHRoZSB0eXBlcyAiYmlkaXJlY3Rpb25hbCBzdHJlYW0sIiAidW5pZGly ZWN0aW9uYWwgc3RyZWFtLCIgYW5kICJtYXRlIG9mIGJpZGlyZWN0aW9uYWwgc3RyZWFtIjsgdGhl IGxhc3Qgd291bGQgZnVydGhlciBuZWVkIHRvIGlkZW50aWZ5IHdoaWNoIHBlZXIgc3RyZWFtIGl0 IGNvcnJlc3BvbmRlZCB0by4NCg0KQnV0IG1ha2luZyB0aGVtIHRoZSBmaXJzdCBjb3VwbGUgYnl0 ZXMgb2YgdGhlIHN0cmVhbSBkYXRhIGZlZWxzIGtpbmQgb2Yga2x1ZGd5IGlmIHRoaXMgaXMgZnVu ZGFtZW50YWxseSBidWlsdCBpbnRvIHRoZSB0cmFuc3BvcnQsIHdoaWNoIG1lYW5zIHRoZXkgcmVh bGx5IGJlbG9uZyBpbiBhIGRlZGljYXRlZCBmcmFtZS4gIE1heWJlIGEgZGVkaWNhdGVkIE9QRU5f U1RSRUFNIGZyYW1lLCB3aGljaCBibG9ja3MgYW55IGRhdGEgcmVjZWl2ZWQgb24gdGhhdCBzdHJl YW0gdW50aWwgeW91IGtub3cgd2hhdCB0eXBlIGl0IGlzPw0KDQpBY3R1YWxseSwgaWYgd2UncmUg cGxhbm5pbmcgb24gaW50cm9kdWNpbmcgb3RoZXIgcGVyLXN0cmVhbSBwcm9wZXJ0aWVzIGxpa2Ug cGFydGlhbCByZWxpYWJpbGl0eSwgdGhlcmUgbWlnaHQgYmUgdmFsdWUgaW4gYW4gT1BFTl9TVFJF QU0gZnJhbWUgd2hlcmUgd2UgY2FuIGRlc2NyaWJlIGEgc3RyZWFtJ3MgZGVzaXJlZCBwcm9wZXJ0 aWVzIGJlZm9yZSBhbnkgZGF0YSBmbG93cy4uLi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNYXJ0aW4gVGhvbXNvbg0KU2VudDogVGh1cnNkYXksIEp1bmUgMjIsIDIwMTcgMzozMiBQTQ0K VG86IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBKYW5hIEl5ZW5nYXIgPGpy aUBnb29nbGUuY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNNYW51cyA8 cG1jbWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSZTogVW5pZGlyZWN0aW9uYWwgc3RyZWFt cyBQUg0KDQpPbiAyMyBKdW5lIDIwMTcgYXQgMDU6MTUsIFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdt YWlsLmNvbT4gd3JvdGU6DQo+IE15IHBlcnNvbmFsIHRha2Ugb24gdGhhdCByaWdodCBhbnN3ZXIg dGhlcmUgaXMgdG8gc3VwcG9ydCBib3RoLCB3aXRoIA0KPiBhbiBleHBsaWNpdCBzaWduYWwgb2Yg d2hlbiBlYWNoIG1vZGVsIGlzIGluIHVzZSwNCg0KSSBoYXZlIGhlYXJkIHRoaXMgcmVxdWVzdCBu b3cgZnJvbSBzZXZlcmFsIGZvbGtzIGF0IEdvb2dsZS4gIEkgZG9uJ3Qga25vdyBob3cgdG8gbWFr ZSB0aGlzIHdvcmsgd2l0aG91dCBpbmNyZWFzaW5nIGNvbXBsZXhpdHkgY29uc2lkZXJhYmx5IC4g IEknZCBiZSB3aWxsaW5nIHRvIGJlIHdyb25nIGFib3V0IHRoaXMsIGJ1dCB3b3VsZCBwcmVmZXIg dG8gc2VlIGEgcHJvcG9zYWwuICBJIGRvbid0IG5lZWQgYSBmdWxseS13b3JrZWQgcHJvcG9zYWwg d2l0aCB0ZXh0LCBqdXN0IGEgc2tldGNoIG9mIGhvdyB0aGUgcGllY2VzIHdvcmsgaW4gZW5vdWdo IGRldGFpbCB0byB1bmRlcnN0YW5kIGhvdyB0aGlzIG1pZ2h0IGludGVyYWN0IHdpdGggb3RoZXIg cGFydHMgb2YgdGhlIHByb3RvY29sLiAgSSB0aGluayB0aGF0IEphbmEgb2ZmZXJlZCB0byBkbyB0 aGlzLCBzbyBtYXliZSBJIGNhbiB3YWl0IGZvciB0aGF0IChjLmYuLCBNYXJrJ3MgZWFybGllciBz dGF0ZW1lbnQgYWJvdXQgcHJpb3JpdHkvdXJnZW5jeSkuDQoNCg== From nobody Thu Jun 22 20:46: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 2414B12947C for ; Thu, 22 Jun 2017 20:46:15 -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 StzNthF8GVVf for ; Thu, 22 Jun 2017 20:46:12 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 2CF09129434 for ; Thu, 22 Jun 2017 20:46:12 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id 77so48095555wrb.1 for ; Thu, 22 Jun 2017 20:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D+izhsnyvEaOeS5SJTN+FwYhFeEpLfxl9H46ib4qLIA=; b=nmAZF/a6tI9oK85Z4ZMV5IqwbTWIE6E6fS69ihAokiAzhJK/Hzo74f/KuCSWOu0pZu E/CC8Hp2YiQNVzuw16nT2hluchCs1b1Zf2b5IZeQYGU6/29fyziZnnSvIECFyobby5YN 5nM4eIH4fFAClWtTt8etdDDURoXh/2dlnQLspji3fVwNpGw78IqBhYZUYdckjtuv9Rc9 X1SrqXfepK8IILZtEMvfB4qJwcCJ3mTw/V9AQa/n2g3wcH7zgSZtnGMhmY5ZjPvrEALa Yfr6g0aTUvtwiMaHE8a3Y4hJKbNEYizBnX3d+Q+YLP3tYzU7sCfWDedzFXmIQLi4A9HP 5MUQ== 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=D+izhsnyvEaOeS5SJTN+FwYhFeEpLfxl9H46ib4qLIA=; b=P9DMIHzam8QelxAqj1mFRWo4fdh/B2QrYNyB4AXUUSokWlHbzLrMp0JuKSM9GJrfUf SM+u9jJ5Vq2GoTjIEFXIsHOw//uQoascQC80uUlBDApJpmCtRrScO8WgJ9fRgrAG9cer qFYFjJb12JxueYGbw1xEW3Hh1jZg8cSVdeIcqJLQ78PcCaH3JLLOmZmfOLPwYDYSUovW U6UunnN2x8UxK4lQ0D4jxG3yTHhHpb3lJAaGpeZmlToXJQagUBwc4yHrULOTkT6mfVEE wEUiAay+pSkirU9OgE+vKL93HOzrKXKGNfO57d27GFAE5Vl+VlpZYWlQz0cp6/vDo8GZ ltLg== X-Gm-Message-State: AKS2vOyQfHDieOPiozMVhMWEm4PLrbnZ1Zpqd/qvbJqjt49NHi2MeFv/ K8UX5bZwBrDEMy7bjF3R5maRl7u/f4vU X-Received: by 10.28.234.193 with SMTP id g62mr3815204wmi.24.1498189570216; Thu, 22 Jun 2017 20:46:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.217.10 with HTTP; Thu, 22 Jun 2017 20:46:09 -0700 (PDT) In-Reply-To: References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ryan Hamilton Date: Thu, 22 Jun 2017 20:46:09 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Mike Bishop Cc: "Lubashev, Igor" , Martin Thomson , Ted Hardie , Jana Iyengar , QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="001a114723fa23e42b05529871cd" 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, 23 Jun 2017 03:46:15 -0000 --001a114723fa23e42b05529871cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 22, 2017 at 8:18 PM, Mike Bishop wrote: > Interesting design. I was trying to avoid doubling the number of frames > consumed by the STREAM frame by consuming just one. But it's a good > insight that offset is only absent on the first STREAM frame, so we could > leverage that if we wanted to. Maybe OO=3D0 indicates the presence of so= me > fixed-size params, and one of those bits is directionality? > > I wasn't convinced this is simpler, because HTTP/QUIC would still need a > stream header. But if we used bidirectional streams for request/response= , > then all unidirectional streams are PUSH_PROMISE, and they're the only on= es > that need a stream header. > > However, let me point out that this is fundamentally still unidirectional > streams with the ability to declare (as metadata) that a particular strea= m > is "affiliated" with a stream in the opposite direction. (And perhaps th= e > ability for the stream initiator to declare an expectation that there wil= l > be an affiliation coming.) This does change the request on N / response = on > N model. We're just talking about moving the correlator into the QUIC > framing, so that each mapping doesn't have to reconstruct how to do > correlations. > =E2=80=8BThat's a clever observation. I think there's one slight difference= though, as it applies to stream limits. In the bidi case, a peer can open a bidi stream if it has not yet exceeded the peer's limit, and the peer is allowed to respond, even if the peer could not otherwise open a new stream because of stream limits. In addition, with the bidi steam case, the stream is considered open until both halves are closed, which would not be the case with uni streams. (Though with the changes to stream limits this might not actually be a terribly important distinction) > That means we get (or can get) the same state simplifications as in the P= R > by considering the streams to have independent lifecycles -- the correlat= or > is simply made available to the application as information about the > stream. That also means that adding the correlator can be done in a > separate PR, if we prefer. > > -----Original Message----- > From: Lubashev, Igor [mailto:ilubashe@akamai.com] > Sent: Thursday, June 22, 2017 6:07 PM > To: Mike Bishop ; Martin Thomson < > martin.thomson@gmail.com>; Ted Hardie > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > Subject: RE: Unidirectional streams PR > > I like the idea of unidirectional streams, if they make life easier for > apps -- both "traditional" apps like H2 as well as less usual apps like s= sh > (one stream in one direction, two associated streams in the opposite > direction). > > I also like Mike's idea of OPEN_STREAM frame. The way I'd describe > OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offset a= nd > a set of "per-stream properties". > > An important point is that when Transport is aware of the association of > two unidirectional streams, the Transport API would be able to implement = a > bidirectional socket-like abstraction for applications that desire one. > > > OPEN_STREAM frame > The type byte for a OPEN_STREAM frame contains embedded flags, and is > formatted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM fra= me. > * The PP bits encode the size of the Params Bitmap field. The values 00, > 01, 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respective= ly. > > The two Least Significant bits of the Params Bitmap indicate the length o= f > the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate > lengths of 0 (none), 8, 16, and 32 bits long respectively. > We can define up to 30 additional bits to be meaningful to the transport. > (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, > Priority-Delivery (aka "DontBuffer") bit, etc). > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream ID (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Params Bitmap (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Associated Stream ID (0/8/16/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Data Length (16)] | Stream Data (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent t= o > STREAM frame with OO=3D0. > > > > -----Original Message----- > From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] > Sent: Thursday, June 22, 2017 6:48 PM > To: Martin Thomson ; Ted Hardie < > ted.ietf@gmail.com> > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > Subject: RE: Unidirectional streams PR > > I suppose you could drop the stream type header from HTTP into QUIC and > make the types "bidirectional stream," "unidirectional stream," and "mate > of bidirectional stream"; the last would further need to identify which > peer stream it corresponded to. > > But making them the first couple bytes of the stream data feels kind of > kludgy if this is fundamentally built into the transport, which means the= y > really belong in a dedicated frame. Maybe a dedicated OPEN_STREAM frame, > which blocks any data received on that stream until you know what type it > is? > > Actually, if we're planning on introducing other per-stream properties > like partial reliability, there might be value in an OPEN_STREAM frame > where we can describe a stream's desired properties before any data > flows.... > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Thursday, June 22, 2017 3:32 PM > To: Ted Hardie > Cc: Jana Iyengar ; QUIC WG ; Patrick > McManus > Subject: Re: Unidirectional streams PR > > On 23 June 2017 at 05:15, Ted Hardie wrote: > > My personal take on that right answer there is to support both, with > > an explicit signal of when each model is in use, > > I have heard this request now from several folks at Google. I don't know > how to make this work without increasing complexity considerably . I'd b= e > willing to be wrong about this, but would prefer to see a proposal. I > don't need a fully-worked proposal with text, just a sketch of how the > pieces work in enough detail to understand how this might interact with > other parts of the protocol. I think that Jana offered to do this, so > maybe I can wait for that (c.f., Mark's earlier statement about > priority/urgency). > > --001a114723fa23e42b05529871cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 2= 2, 2017 at 8:18 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
Interesting design.=C2=A0 I was trying to avoid doubling the number of= frames consumed by the STREAM frame by consuming just one.=C2=A0 But it= 9;s a good insight that offset is only absent on the first STREAM frame, so= we could leverage that if we wanted to.=C2=A0 Maybe OO=3D0 indicates the p= resence of some fixed-size params, and one of those bits is directionality?=

I wasn't convinced this is simpler, because HTTP/QUIC would still need = a stream header.=C2=A0 But if we used bidirectional streams for request/res= ponse, then all unidirectional streams are PUSH_PROMISE, and they're th= e only ones that need a stream header.

However, let me point out that this is fundamentally still unidirectional s= treams with the ability to declare (as metadata) that a particular stream i= s "affiliated" with a stream in the opposite direction.=C2=A0 (An= d perhaps the ability for the stream initiator to declare an expectation th= at there will be an affiliation coming.)=C2=A0 This does change the request= on N / response on N model.=C2=A0 We're just talking about moving the = correlator into the QUIC framing, so that each mapping doesn't have to = reconstruct how to do correlations.

=E2=80=8BThat's a clever observation. I think there's one sligh= t difference though, as it applies to stream limits. In the bidi case, a pe= er can open a bidi stream if it has not yet exceeded the peer's limit, = and the peer is allowed to respond, even if the peer could not otherwise op= en a new stream because of stream limits. In addition, with the bidi steam = case, the stream is considered open until both halves are closed, which wou= ld not be the case with uni streams. (Though with the changes to stream lim= its this might not actually be a terribly important distinction)
= =C2=A0
That means we get (or can get) the same state simplifications as in the PR = by considering the streams to have independent lifecycles -- the correlator= is simply made available to the application as information about the strea= m.=C2=A0 That also means that adding the correlator can be done in a separa= te PR, if we prefer.

-----Original Message-----
From: Lubashev, Igor [mailto:ilubashe@akamai.com]
Sent: Thursday, June 22, 2017 6:07 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>; Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" class=3D"cremed">martin.thomson@= gmail.com>; Ted Hardie <ted.ietf@gmail.com>
Cc: Jana Iyengar <jri= @google.com>; QUIC WG <quic@ietf.org>; Patrick McManus <pmcmanus@mozilla.com>
Subject: RE: Unidirectional streams PR

I like the idea of unidirectional streams, if they make life easier for app= s -- both "traditional" apps like H2 as well as less usual apps l= ike ssh (one stream in one direction, two associated streams in the opposit= e direction).

I also like Mike's idea of OPEN_STREAM frame.=C2=A0 The way I'd des= cribe OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offs= et and a set of "per-stream properties".

An important point is that when Transport is aware of the association of tw= o unidirectional streams, the Transport API would be able to implement a bi= directional socket-like abstraction for applications that desire one.


OPEN_STREAM frame
The type byte for a OPEN_STREAM frame contains embedded flags, and is forma= tted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM frame.
* The PP bits encode the size of the Params Bitmap field. The values 00, 01= , 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respectively.<= br>
The two Least Significant bits of the Params Bitmap indicate the length of = the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate length= s of 0 (none), 8, 16, and 32 bits long respectively.
We can define up to 30 additional bits to be meaningful to the transport.= =C2=A0 (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, Pri= ority-Delivery (aka "DontBuffer") bit, etc).

0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stre= am ID (8/16/24/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Params Bitmap=C2= =A0 (8/16/24/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Associated Stream ID (0/8/16/32)= =C2=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[Data Length (16)]=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stream Data (*)=C2=A0 =C2=A0 =C2=A0 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent to = STREAM frame with OO=3D0.



-----Original Message-----
From: Mike Bishop [mailto:Michael.Bishop@microsoft.com]
Sent: Thursday, June 22, 2017 6:48 PM
To: Martin Thomson <martin.thomson@gmail.com>; Ted Hardie <ted.ietf@gmail.com>
Cc: Jana Iyengar <jri= @google.com>; QUIC WG <quic@ietf.org>; Patrick McManus <pmcmanus@mozilla.com>
Subject: RE: Unidirectional streams PR

I suppose you could drop the stream type header from HTTP into QUIC and mak= e the types "bidirectional stream," "unidirectional stream,&= quot; and "mate of bidirectional stream"; the last would further = need to identify which peer stream it corresponded to.

But making them the first couple bytes of the stream data feels kind of klu= dgy if this is fundamentally built into the transport, which means they rea= lly belong in a dedicated frame.=C2=A0 Maybe a dedicated OPEN_STREAM frame,= which blocks any data received on that stream until you know what type it = is?

Actually, if we're planning on introducing other per-stream properties = like partial reliability, there might be value in an OPEN_STREAM frame wher= e we can describe a stream's desired properties before any data flows..= ..

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Thursday, June 22, 2017 3:32 PM
To: Ted Hardie <t= ed.ietf@gmail.com>
Cc: Jana Iyengar <jri= @google.com>; QUIC WG <quic@ietf.org>; Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: Unidirectional streams PR

On 23 June 2017 at 05:15, Ted Hardie <ted.ietf@gmail.com> wrote:
> My personal take on that right answer there is to support both, with > an explicit signal of when each model is in use,

I have heard this request now from several folks at Google.=C2=A0 I don'= ;t know how to make this work without increasing complexity considerably .= =C2=A0 I'd be willing to be wrong about this, but would prefer to see a= proposal.=C2=A0 I don't need a fully-worked proposal with text, just a= sketch of how the pieces work in enough detail to understand how this migh= t interact with other parts of the protocol.=C2=A0 I think that Jana offere= d to do this, so maybe I can wait for that (c.f., Mark's earlier statem= ent about priority/urgency).


--001a114723fa23e42b05529871cd-- From nobody Thu Jun 22 21:30: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 7D8B7129C07 for ; Thu, 22 Jun 2017 21:30:29 -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 6apLmajgCfB0 for ; Thu, 22 Jun 2017 21:30:27 -0700 (PDT) Received: from mx36-42.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 8F3B31293D6 for ; Thu, 22 Jun 2017 21:30:27 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1dOGEj-00085X-Pj for quic@ietf.org; Fri, 23 Jun 2017 06:30:26 +0200 Received: from internal.xmail10.myhosting.com ([10.5.2.35] helo=xmail10.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dOGEi-0000Gg-AR for quic@ietf.org; Fri, 23 Jun 2017 00:30:24 -0400 Received: (qmail 12821 invoked from network); 23 Jun 2017 04:30:22 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.228]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Jun 2017 04:30:22 -0000 To: quic@ietf.org References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> From: Christian Huitema Message-ID: <3de9380e-a255-5ee0-9f95-32125c0deef2@huitema.net> Date: Thu, 22 Jun 2017 21:30:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Unidirectional streams PR X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.33) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbMzHFUa97P3bfY1LzB69ykND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23RA24pox6mNh20BBBf238P4CguACQY+STnTP7 IZRHeVkrhJcy8gAu1aOhPtEepvkpYOEkjsX7F8KmpUaZQHV+SaoNpL7PRmmTib7l1mO88Em2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpCbsjdvAic40+cHi4LtB9yD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGybnx7z9VblfslEGuqN52OyXeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17rO8mH7U5AhzEIy5x+PFH3y2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe91Y2lWQ2MJXd3CnOcfuxlrTMLn6MURQGfriekzS 9Ga3AA== 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, 23 Jun 2017 04:30:29 -0000 On 6/22/2017 7:09 PM, Ian Swett wrote: > In regards to the unidirectional only model: > 1) The QUIC stream state machine is really not that complex, and the > current documentation does a nice job of explaining it. Changing to > unidirectional only streams only saves 2 states, from 5 to 3, and a > small bit of text. > 2) I'm very concerned that if we don't standardize a way to do > bidirectional streams, different 'QUIC Library API's will internally > standardize on different approaches for recreating bidirectional > streams. I fear this may create more work and interoperability > challenges down the road. I review both PR (#643 and #656). I think they are pretty much equivalent, and will result in the same number of messages on the wire. I have a slight preference for Ian's design because it uses a single stream number space for both client and server originated streams. I am concerned that two independent number spaces will lead to ambiguities and implementation errors. This is visible in the current text around RESET_STREAM. If we have two number spaces, we need to split that in two frames, RESET_MY_STREAM and TAKE_YOUR_STREAM_AWAY. Of course, Martin could also update #643 to use a single stream number...= --=20 Christian Huitema From nobody Thu Jun 22 22:08: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 80340126BF3 for ; Thu, 22 Jun 2017 22:08: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, 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 EYcAA_QGpXrk for ; Thu, 22 Jun 2017 22:08:56 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C6D120721 for ; Thu, 22 Jun 2017 22:08:56 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5N53u4b010913; Fri, 23 Jun 2017 06:08:49 +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=i6PpEHx6KarTQ3yA/Fx35pexDbffLGIwuuljgw0vUnU=; b=iDr9B4yeHpmJni6VZBCXYQUaYwpPEBz7R8o1Li8QwTO3omoBW3zKFOb/wxQ1CdrVGKke Kq1ttqpVVBvOJ2zJLKxQ5bV7siFR24xTyZx5jbKPYlLcgCJvGVPEbNBeeldOOuDRaPoE qsbFBuhm14LNxbWkLNUkSa3/rdiXytyQZytvxvcWCwRYbEwppxzka0d44KUfQMvA25kV UmVMADe39CVb/otZcJzHWyqNlOgF3VSVKfVA/XPeV/rQChiPT5ep4VWubnQRTWfPisYu CaEx3iCy8Hm0aVdpMeil+Q93EHQKd0MyeRv8MYLvp/CPw5z44y79U0BYYR4Q/D0RIxQZ 0Q== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b8fs7uw0n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 06:08:49 +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 v5N57ssQ000585; Fri, 23 Jun 2017 01:08:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b4yrvnjp5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 01:08:48 -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; Fri, 23 Jun 2017 01:08:47 -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; Fri, 23 Jun 2017 01:08:47 -0400 From: "Lubashev, Igor" To: Mike Bishop , Martin Thomson , Ted Hardie CC: Jana Iyengar , QUIC WG , Patrick McManus Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHzFJcNmOfPnkGlJjRXQ/9soKIvh8kAgADqdYCAACIYgIABI/8AgAAEzYCAAARGgP//0FFwgAB7VoD//8914A== Date: Fri, 23 Jun 2017 05:08:46 +0000 Message-ID: References: <349d20e4f7d9458aaf7797d2025b2064@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.34.60] 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-06-23_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-1706230086 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230084 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, 23 Jun 2017 05:08:58 -0000 SWYgeW91IHdhbnQgdG8gYWRkIGluZm9ybWF0aW9uIG9ubHkgdG8gdGhlIGluaXRpYWwgU1RSRUFN IGZyYW1lIHdpdGhvdXQgZG91YmxpbmcgdGhlIG51bWJlciBvZiBmcmFtZXMgZm9yIFNUUkVBTSwg eW91IGhhdmUgc29tZSBvcHRpb25zIChlYWNoIHdpdGggYSB0cmFkZW9mZikuDQoNCjEuIEFzIHlv dSBzYWlkLCBpbml0aWFsIFNUUkVBTSBmcmFtZSAoT089MCkgY2FuIGhhdmUgYW4gYWRkaXRpb25h bCBmaXhlZCBmaWVsZC4NCg0KMi4gSWYgeW91IG5lZWQgdG8gYXR0YWNoIGEgc2luZ2xlIGJpdCBv ZiBpbmZvcm1hdGlvbiBmb3IgdGhlIGluaXRpYWwgU1RSRUFNIGZyYW1lIG9ubHkgb2NjYXNpb25h bGx5LCB5b3UgY2FuIHBheSAxIGJ5dGUgd2hlbiB0aGF0IGJpdCBvZiBpbmZvcm1hdGlvbiBpcyBw cmVzZW50LiAgKFVzZSB0aGUgZmFjdCB0aGF0IE9PPTAgYW5kIE9PPTAxLE9mZnNldD0wIGFyZSBl cXVpdmFsZW50LCBzbyB5b3UgY2FuIG92ZXJsb2FkIE9PPTAxLE9mZnNldD0wIHdpdGggYWRkaXRp b25hbCBzZW1hbnRpY3MuKSAgVGhhdCBiaXQgY2FuIGluZGljYXRlICJVTkkiIG9yIGl0IGNhbiBp bmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgYSBmaXhlZCBmaWVsZCBhZnRlciB0aGUgU3RyZWFtIElE Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pa2UgQmlzaG9wIFtt YWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSnVu ZSAyMiwgMjAxNyAxMToxOCBQTQ0KVG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWku Y29tPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IFRlZCBIYXJk aWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29t PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96 aWxsYS5jb20+DQpTdWJqZWN0OiBSRTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQpJbnRl cmVzdGluZyBkZXNpZ24uICBJIHdhcyB0cnlpbmcgdG8gYXZvaWQgZG91YmxpbmcgdGhlIG51bWJl ciBvZiBmcmFtZXMgY29uc3VtZWQgYnkgdGhlIFNUUkVBTSBmcmFtZSBieSBjb25zdW1pbmcganVz dCBvbmUuICBCdXQgaXQncyBhIGdvb2QgaW5zaWdodCB0aGF0IG9mZnNldCBpcyBvbmx5IGFic2Vu dCBvbiB0aGUgZmlyc3QgU1RSRUFNIGZyYW1lLCBzbyB3ZSBjb3VsZCBsZXZlcmFnZSB0aGF0IGlm IHdlIHdhbnRlZCB0by4gIE1heWJlIE9PPTAgaW5kaWNhdGVzIHRoZSBwcmVzZW5jZSBvZiBzb21l IGZpeGVkLXNpemUgcGFyYW1zLCBhbmQgb25lIG9mIHRob3NlIGJpdHMgaXMgZGlyZWN0aW9uYWxp dHk/DQoNCi4uDQoNCg== From nobody Thu Jun 22 22:31:51 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BC0128954 for ; Thu, 22 Jun 2017 22:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 pUlFbDVILqTK for ; Thu, 22 Jun 2017 22:31:47 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9B0120721 for ; Thu, 22 Jun 2017 22:31:47 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5N5TIQ4029560; Fri, 23 Jun 2017 06:31:41 +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=PVVfE08cBhkmiydRu543xgGt3i9TtsDw/7roLe5z6Cs=; b=D7HXsnnSqDddWGzAFjnqCD+3zpXhJMs1+/N/kZSQJsx22/I4ThIrQLNaVlWmpc2xJAgV NUUpzqAzjKzoRMrJMk99tVIC6SSAClQEVIHIbXQKW9qA0ItTRr7cUyIQzWEnvJ+q29Cr Bv0jhyf7Ur/RbAfri0Nks15WxawV2dEddQfOdTQ4lN/OqGyZp70ZBe2Z7nX0jks7E/kf pjIhrrbLPKV+bnaW4BkHZgFdxjTB7SqaZlfMzAUCoZSxvWESb9/qNM8OUCgjlfv+oKSY LEAekNtvX1J+Lqg8b97GXOSJN2sqgGPGQXHBMYWdjyGIHtlIga1WfKSDHA/WmwttJEn1 SQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b8f92v7q0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 06:31:41 +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 v5N5VU96015815; Fri, 23 Jun 2017 01:31:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b4yrvnmed-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 01:31:39 -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; Fri, 23 Jun 2017 01:31:38 -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; Fri, 23 Jun 2017 01:31:38 -0400 From: "Lubashev, Igor" To: "Lubashev, Igor" , Ian Swett CC: Mike Bishop , Ted Hardie , Patrick McManus , Jana Iyengar , QUIC WG , Martin Thomson Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHzFJcNmOfPnkGlJjRXQ/9soKIvh8kAgADqdYCAACIYgIABI/8AgAAEzYCAAARGgP//0FFwgABb0AD//76RwIAATcWA//+9o9AABjP0UA== Date: Fri, 23 Jun 2017 05:31:38 +0000 Message-ID: <33a1a7ffdfe74bd5ae30266b6b4ebe35@usma1ex-dag1mb5.msg.corp.akamai.com> References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> <2260e852b904465a9f8c9488e7e76166@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <2260e852b904465a9f8c9488e7e76166@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.60] Content-Type: multipart/alternative; boundary="_000_33a1a7ffdfe74bd5ae30266b6b4ebe35usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-23_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-1706230093 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-23_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230091 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, 23 Jun 2017 05:31:50 -0000 --_000_33a1a7ffdfe74bd5ae30266b6b4ebe35usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWFuLCBJIGFtIG5vdCBpbiBsb3ZlIHdpdGggYSBwb3NzaWJpbGl0eSBvZiBoYXZpbmcgVU5JIGZs YWcgY2xlYXIgb24gc29tZSBpbml0aWFsIFNUUkVBTSBmcmFtZXMgYW5kIHRoZW4gVU5JIHNldCBv biBzdWJzZXF1ZW50IFNUUkVBTSBmcmFtZXMuICBUaGUgUFIgZG9lcyBub3QgcHJvaGliaXQgdGhp cy4gIEkgcmVhZCB0aGUgUFIgKHN0YXRlIGRpYWdyYW0pIHRvIHJlcXVpcmUgdGhlIHN0cmVhbSB0 byBnbyBpbW1lZGlhdGVseSBpbnRvIOKAnGhhbGYtY2xvc2VkIChsb2NhbCnigJ0gc3RhdGUgb24g cmVjZWlwdCBvZiBzdWNoIFNUUkVBTStVTkkgZnJhbWUuICBUaGlzIGlzIGEgcHJvYmxlbSwgc2lu Y2Ugc29tZSBwYWNrZXRzIGZyb20gdGhlIHJlY2VpdmVyIHRvIHRoZSBzZW5kZXIgY291bGQgYmUg aW4gZmxpZ2h0LCBhbmQgYWJzZW50IGEgU1RSRUFNK0ZJTiBvciBSU1RfU1RSRUFNIGZyb20gdGhl IHJlY2VpdmVyLCB0aGUgc2VuZGVyIGNhbm5vdCBkbyBmbG93IGNvbnRyb2wgYWNjb3VudGluZy4N Cg0KSXQgc2VlbXMgYmVzdCBpZiBhIHN0cmVhbSBpcyBVTkkgb3IgQkkgZnJvbSBiaXJ0aCwgYW5k IHRoYXTigJlzIGluZGljYXRlZCBieSB0aGUgaW5pdGlhbCBTVFJFQU0gZnJhbWUgb25seS4gIElm IFNUUkVBTSBmcmFtZXMgZ2V0IHJlb3JkZXJlZCwgdW50aWwgdGhlIHJlY2VpdmVyIHJlY2VpdmVz IHRoZSBpbml0aWFsIFNUUkVBTSBmcmFtZSAoT2Zmc2V0PTApLCBpdCBzaG91bGQgY29uc2lkZXIg dGhlIHN0cmVhbSB0byBiZSBpbiDigJxpbXBsaWNpdOKAnSBzdGF0ZSAoZG8gYWNjb3VudGluZyBm b3IgbWF4IHN0cmVhbSBjb3VudCBhbmQgZmxvdyBjb250cm9sIGJ1dCBjYW5ub3Qgc2VuZCBkYXRh IHRvIGl0KS4NCg0KDQpGcm9tOiBMdWJhc2hldiwgSWdvciBbbWFpbHRvOmlsdWJhc2hlQGFrYW1h aS5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVuZSAyMiwgMjAxNyAxMDo0MyBQTQ0KVG86IElhbiBT d2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT4NCkNjOiBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbT47IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT47IFBhdHJp Y2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+OyBKYW5hIEl5ZW5nYXIgPGpyaUBnb29n bGUuY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSRTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQ Ug0KDQpZZXMsIHdlIGFyZSBpbiBhbiBhZ3JlZW1lbnQgdGhhdCB3ZSB3YW50IOKAnFFVSUMgTGli cmFyaWVz4oCdIHRvIHByb3ZpZGUgYW4gZWFzeSB3YXkgb2YgZG9pbmcgYm90aCB1bmlkaXJlY3Rp b25hbCBzdHJlYW1zIGFzIHdlbGwgYXMgYmlkaXJlY3Rpb25hbCBzdHJlYW1zLg0KDQpJIGRvIG5v dCBoYXZlIGEgc3Ryb25nIHByZWZlcmVuY2UgYXMgdG8gdGhlIGRldGFpbHMgb2YgZnJhbWluZy4g T24gb25lIGhhbmQsIEkgYW0gbm90IHdvcnJpZWQgYWJvdXQgbGlicmFyaWVzIGltcGxlbWVudGlu ZyBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgZGlmZmVyZW50bHkgd2l0aCBPUEVOX1NUUkVBTSDigJMg dGhlcmUgaXMgcmVhbGx5IGp1c3Qgb25lIHNhbmUgd2F5IG9mIGRvaW5nIGl0LCBhbmQgdGhlIE9Q RU5fU1RSRUFNIG1vZGVsIGlzIG1vcmUgZmxleGlibGUuICBPbiB0aGUgb3RoZXIgaGFuZCwgT1BF Tl9TVFJFQU0gY29tZXMgYXQgYSBjb3N0IG9mIGEgZmV3IGV4dHJhIGJ5dGVzIGZvciBhIHNpbXBs ZSBiaWRpcmVjdGlvbmFsIHN0cmVhbSBpbXBsZW1lbnRhdGlvbi4NCg0KVGhlIFVOSSBkb2VzIGNv bXBsaWNhdGUgdGhlIHN0YXRlIG1hY2hpbmUgYSBiaXQgYnkgYWRkaW5nIGFuIGV4dHJhIHN0YXRl LCBhcyBla3IgcG9pbnRlZCBvdXQuICBZb3UgbmVlZCBhIHNwZWNpYWwgc3RhdGUgZm9yIGltcGxp Y2l0bHkgb3BlbmVkIHN0cmVhbXMuICBUaGV5IGFyZSBub3Qg4oCcaWRsZeKAnSAodGhleSBjb3Vu dCB0b3dhcmQgdGhlIG1heCksIGFuZCB0aGV5IGFyZSBub3Qg4oCcb3BlbuKAnSAoeW91IGNhbm5v dCB3cml0ZSB0byB0aGVtKSwgYW5kIHRoZXkgYXJlIG5vdCDigJxsb2NhbCBoYWxmLWNsb3NlZOKA nSAodGhleSBtYXkgdHJhbnNpdGlvbiB0byDigJxvcGVu4oCdKS4gIEkgZG8gbm90IHRoaW5rIHRo aXMgaXMgYSBodWdlIGRlYWwsIHRob3VnaCDigJMgVENQIGhhcyBhIGxvdCBtb3JlIHN0YXRlcyEN Cg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KU2VudDog VGh1cnNkYXksIEp1bmUgMjIsIDIwMTcgMTA6MTAgUE0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1 YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+DQpDYzogSmFuYSBJ eWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PjsgTWlrZSBCaXNo b3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1p Y3Jvc29mdC5jb20+PjsgVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQu aWV0ZkBnbWFpbC5jb20+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRm Lm9yZz4+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzpt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PjsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3pp bGxhLmNvbTxtYWlsdG86cG1jbWFudXNAbW96aWxsYS5jb20+Pg0KU3ViamVjdDogUmU6IFVuaWRp cmVjdGlvbmFsIHN0cmVhbXMgUFINCg0KT24gVGh1LCBKdW4gMjIsIDIwMTcgYXQgOTo0OSBQTSwg THViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1h aS5jb20+PiB3cm90ZToNCkkgdGhpbmsgb2YgdGhyZWUgbGF5ZXJzIG9mIGFic3RyYWN0aW9uOg0K DQoNCjEuICAgICAgIFFVSUMgV2lyZSBQcm90b2NvbCAodGhlIHRoaW5nIGRlc2NyaWJlZCBieSB0 aGUgUVVJQyBUcmFuc3BvcnQgUkZDKQ0KDQoyLiAgICAgICBRVUlDIExpYnJhcnkgQVBJIChhIGxp YnJhcnkgZXhwb3Npbmcgc29tZSB1c2VmdWwgYWJzdHJhY3Rpb25zIC0tIHN1Y2ggYXMgYmxvY2tp bmcvbm9uLWJsb2NraW5nIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYW5kIGJpZGlyZWN0aW9uYWwg 4oCcc29ja2V0c+KAnSAtLSBhbmQgaW1wbGVtZW50aW5nIHRoZW0gdXNpbmcgUVVJQyBXaXJlIFBy b3RvY29sKQ0KDQozLiAgICAgICBBcHBsaWNhdGlvbiAoc29tZXRoaW5nIHRoYXQgdXNlcyBRVUlD IExpYnJhcnkgQVBJcykNCg0KV2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IE1hcnRpbuKAmXMgdW5p ZGlyZWN0aW9uYWwgc3RyZWFtcyBwcm9wb3NhbCBkb2VzIG5vdCBoYXZlIGEgd2F5IHRvIGltcGxl bWVudCBnZW5lcmljIGJpZGlyZWN0aW9uYWwgc29ja2V0LWxpa2UgYWJzdHJhY3Rpb25zIG9uIHRo ZSBRVUlDIExpYnJhcnkgQVBJIGxheWVyLiAgSG93ZXZlciwgaWYgd2UgZm9sbG93IE1pa2XigJlz IHN1Z2dlc3Rpb24gYW5kIGFsbG93IGFuIEFzc29jaWF0ZWQgU3RyZWFtIElEIGluIE9QRU5fU1RS RUFNIGZyYW1lcywgdGhpcyB3b3VsZCBtYWtlIGl0IGVhc3kgZm9yIFFVSUNLIExpYnJhcmllcyB0 byBwcm92aWRlIGdlbmVyaWMgYmlkaXJlY3Rpb25hbCBzb2NrZXQtbGlrZSBhYnN0cmFjdGlvbnMu DQoNClNvIHdoYXQgSSBhbSBzdWdnZXN0aW5nIGlzIHRoYXQgd2Uga2VlcCBRVUlDIFdpcmUgUHJv dG9jb2wgc3RhdGUgbWFjaGluZSBzaW1wbGUgYW5kIHVuY2hhbmdlZC4gIEhvd2V2ZXIsIHdpdGgg dGhlIE9QRU5fU1RSRUFNIGZyYW1lLCB3ZSB3b3VsZCBhbGxvdyBRVUlDIExpYnJhcmllcyB0byBp bXBsZW1lbnQgYm90aCB1bmlkaXJlY3Rpb25hbCBhbmQgYmlkaXJlY3Rpb25hbCBzdHJlYW1zLg0K DQoNCi0gICAgICAgICAgSWdvcg0KSWdvciwgSSB0aGluayB5b3UgYW5kIEkgYXJlIGluIGFncmVl bWVudCB0aGF0IHdlIGJvdGggd2FudCBhIHJlbGF0aXZlbHkgZWFzeSB3YXkgb2YgZG9pbmcgYm90 aCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFzIHdlbGwgYXMgYmlkaXJlY3Rpb25hbCBzdHJlYW1z PyAgR2l2ZW4gdGhhdCwgaXQgY29tZXMgZG93biB0byB3aGF0IHRvIHN0YW5kYXJkaXplIGF0IHRo ZSB0cmFuc3BvcnQgbGF5ZXIgYW5kIHNvbWUgZnJhbWluZy4NCg0KSW4gcmVnYXJkcyB0byB0aGUg dW5pZGlyZWN0aW9uYWwgb25seSBtb2RlbDoNCiAxKSBUaGUgUVVJQyBzdHJlYW0gc3RhdGUgbWFj aGluZSBpcyByZWFsbHkgbm90IHRoYXQgY29tcGxleCwgYW5kIHRoZSBjdXJyZW50IGRvY3VtZW50 YXRpb24gZG9lcyBhIG5pY2Ugam9iIG9mIGV4cGxhaW5pbmcgaXQuICBDaGFuZ2luZyB0byB1bmlk aXJlY3Rpb25hbCBvbmx5IHN0cmVhbXMgb25seSBzYXZlcyAyIHN0YXRlcywgZnJvbSA1IHRvIDMs IGFuZCBhIHNtYWxsIGJpdCBvZiB0ZXh0Lg0KIDIpIEknbSB2ZXJ5IGNvbmNlcm5lZCB0aGF0IGlm IHdlIGRvbid0IHN0YW5kYXJkaXplIGEgd2F5IHRvIGRvIGJpZGlyZWN0aW9uYWwgc3RyZWFtcywg ZGlmZmVyZW50ICdRVUlDIExpYnJhcnkgQVBJJ3Mgd2lsbCBpbnRlcm5hbGx5IHN0YW5kYXJkaXpl IG9uIGRpZmZlcmVudCBhcHByb2FjaGVzIGZvciByZWNyZWF0aW5nIGJpZGlyZWN0aW9uYWwgc3Ry ZWFtcy4gIEkgZmVhciB0aGlzIG1heSBjcmVhdGUgbW9yZSB3b3JrIGFuZCBpbnRlcm9wZXJhYmls aXR5IGNoYWxsZW5nZXMgZG93biB0aGUgcm9hZC4NCg0KU28gaWYgd2UgdGhpbmsgbGl0ZXJhbGx5 IG5vIG9uZSB3aWxsIGhhdmUgYW55IHVzZSBmb3IgdGhlIGJpZGlyZWN0aW9uYWwgc3RyZWFtIG1v ZGVsLCB0aGVuIEkgYWdyZWUgd2Ugc2hvdWxkIHJlbW92ZSBpdC4gIEJ1dCBldmVuIHRvZGF5LCB0 aGUgSFRUUCBtYXBwaW5nIGlzIHNpbXBsZXIgd2l0aCB0aGUgYmlkaXJlY3Rpb25hbCBzdHJlYW0g bW9kZWwgdGhhbiB3aXRoIG9ubHkgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcywgd2hpY2ggbWVhbnMg dGhlIHRvdGFsIGFtb3VudCBvZiB3b3JrIG9mIGltcGxlbWVudGluZyBIVFRQICsgUVVJQyBpcyBh Ym91dCB0aGUgc2FtZSBlaXRoZXIgd2F5LCBhbmQgSSBiZWxpZXZlIGlmIGJpZGlyZWN0aW9uYWwg c3RyZWFtcyBhbmQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBkbyBleGlzdCBpbiBRVUlDKGFzIGlu IG15IFBSIGFib3ZlKSwgdGhlbiB0aGUgSFRUUCB3b3VsZC9zaG91bGQgdXNlIGJvdGguDQoNCg== --_000_33a1a7ffdfe74bd5ae30266b6b4ebe35usma1exdag1mb5msgcorpak_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnAubTY0MzU3MTczODg4NTI1NTcwNTdtc29saXN0cGFyYWdyYXBoLCBsaS5tNjQzNTcxNzM4 ODg1MjU1NzA1N21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tNjQzNTcxNzM4ODg1MjU1NzA1N21zb2xp c3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV82NDM1NzE3Mzg4ODUyNTU3MDU3bXNvbGlz dHBhcmFncmFwaDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLm02NDM1NzE3Mzg4ODUyNTU3MDU3aW0NCgl7bXNv LXN0eWxlLW5hbWU6bV82NDM1NzE3Mzg4ODUyNTU3MDU3aW07fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY4MTU4OTMxOTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTYzNzI0MDY2NiAxNjU2NDk4OTQwIDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsN Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+SWFuLCBJIGFtIG5vdCBpbiBsb3ZlIHdpdGggYSBwb3NzaWJpbGl0eSBv ZiBoYXZpbmcgVU5JIGZsYWcgY2xlYXIgb24gc29tZSBpbml0aWFsIFNUUkVBTSBmcmFtZXMgYW5k IHRoZW4gVU5JIHNldCBvbiBzdWJzZXF1ZW50IFNUUkVBTSBmcmFtZXMuJm5ic3A7IFRoZSBQUiBk b2VzIG5vdCBwcm9oaWJpdCB0aGlzLiZuYnNwOw0KIEkgcmVhZCB0aGUgUFIgKHN0YXRlIGRpYWdy YW0pIHRvIHJlcXVpcmUgdGhlIHN0cmVhbSB0byBnbyBpbW1lZGlhdGVseSBpbnRvIOKAnGhhbGYt Y2xvc2VkIChsb2NhbCnigJ0gc3RhdGUgb24gcmVjZWlwdCBvZiBzdWNoIFNUUkVBTSYjNDM7VU5J IGZyYW1lLiZuYnNwOyBUaGlzIGlzIGEgcHJvYmxlbSwgc2luY2Ugc29tZSBwYWNrZXRzIGZyb20g dGhlIHJlY2VpdmVyIHRvIHRoZSBzZW5kZXIgY291bGQgYmUgaW4gZmxpZ2h0LCBhbmQgYWJzZW50 IGEgU1RSRUFNJiM0MztGSU4gb3INCiBSU1RfU1RSRUFNIGZyb20gdGhlIHJlY2VpdmVyLCB0aGUg c2VuZGVyIGNhbm5vdCBkbyBmbG93IGNvbnRyb2wgYWNjb3VudGluZy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SXQgc2VlbXMgYmVzdCBpZiBhIHN0cmVhbSBpcyBVTkkgb3IgQkkgZnJvbSBiaXJ0aCwgYW5kIHRo YXTigJlzIGluZGljYXRlZCBieSB0aGUgaW5pdGlhbCBTVFJFQU0gZnJhbWUgb25seS4mbmJzcDsg SWYgU1RSRUFNIGZyYW1lcyBnZXQgcmVvcmRlcmVkLCB1bnRpbCB0aGUgcmVjZWl2ZXIgcmVjZWl2 ZXMgdGhlIGluaXRpYWwNCiBTVFJFQU0gZnJhbWUgKE9mZnNldD0wKSwgaXQgc2hvdWxkIGNvbnNp ZGVyIHRoZSBzdHJlYW0gdG8gYmUgaW4g4oCcaW1wbGljaXTigJ0gc3RhdGUgKGRvIGFjY291bnRp bmcgZm9yIG1heCBzdHJlYW0gY291bnQgYW5kIGZsb3cgY29udHJvbCBidXQgY2Fubm90IHNlbmQg ZGF0YSB0byBpdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMdWJh c2hldiwgSWdvciBbbWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIEp1bmUgMjIsIDIwMTcgMTA6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+IElhbiBT d2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlz aG9wICZsdDtNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tJmd0OzsgVGVkIEhhcmRpZSAmbHQ7 dGVkLmlldGZAZ21haWwuY29tJmd0OzsgUGF0cmljayBNY01hbnVzICZsdDtwbWNtYW51c0Btb3pp bGxhLmNvbSZndDs7IEphbmEgSXllbmdhciAmbHQ7anJpQGdvb2dsZS5jb20mZ3Q7OyBRVUlDIFdH ICZsdDtxdWljQGlldGYub3JnJmd0OzsgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29u QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFVuaWRpcmVjdGlvbmFsIHN0 cmVhbXMgUFI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlllcywgd2UgYXJlIGluIGFuIGFncmVlbWVudCB0aGF0IHdlIHdhbnQg 4oCcUVVJQyBMaWJyYXJpZXPigJ0gdG8gcHJvdmlkZSBhbiBlYXN5IHdheSBvZiBkb2luZyBib3Ro IHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXMgd2VsbCBhcyBiaWRpcmVjdGlvbmFsIHN0cmVhbXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkkgZG8gbm90IGhhdmUgYSBzdHJvbmcgcHJlZmVyZW5jZSBhcyB0byB0 aGUgZGV0YWlscyBvZiBmcmFtaW5nLiBPbiBvbmUgaGFuZCwgSSBhbSBub3Qgd29ycmllZCBhYm91 dCBsaWJyYXJpZXMgaW1wbGVtZW50aW5nIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBkaWZmZXJlbnRs eSB3aXRoIE9QRU5fU1RSRUFNDQog4oCTIHRoZXJlIGlzIHJlYWxseSBqdXN0IG9uZSBzYW5lIHdh eSBvZiBkb2luZyBpdCwgYW5kIHRoZSBPUEVOX1NUUkVBTSBtb2RlbCBpcyBtb3JlIGZsZXhpYmxl LiAmbmJzcDtPbiB0aGUgb3RoZXIgaGFuZCwgT1BFTl9TVFJFQU0gY29tZXMgYXQgYSBjb3N0IG9m IGEgZmV3IGV4dHJhIGJ5dGVzIGZvciBhIHNpbXBsZSBiaWRpcmVjdGlvbmFsIHN0cmVhbSBpbXBs ZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIFVOSSBkb2VzIGNvbXBsaWNhdGUgdGhlIHN0 YXRlIG1hY2hpbmUgYSBiaXQgYnkgYWRkaW5nIGFuIGV4dHJhIHN0YXRlLCBhcyBla3IgcG9pbnRl ZCBvdXQuJm5ic3A7IFlvdSBuZWVkIGEgc3BlY2lhbCBzdGF0ZSBmb3IgaW1wbGljaXRseSBvcGVu ZWQgc3RyZWFtcy4mbmJzcDsgVGhleSBhcmUgbm90IOKAnGlkbGXigJ0NCiAodGhleSBjb3VudCB0 b3dhcmQgdGhlIG1heCksIGFuZCB0aGV5IGFyZSBub3Qg4oCcb3BlbuKAnSAoeW91IGNhbm5vdCB3 cml0ZSB0byB0aGVtKSwgYW5kIHRoZXkgYXJlIG5vdCDigJxsb2NhbCBoYWxmLWNsb3NlZOKAnSAo dGhleSBtYXkgdHJhbnNpdGlvbiB0byDigJxvcGVu4oCdKS4mbmJzcDsgSSBkbyBub3QgdGhpbmsg dGhpcyBpcyBhIGh1Z2UgZGVhbCwgdGhvdWdoIOKAkyBUQ1AgaGFzIGEgbG90IG1vcmUgc3RhdGVz ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBJYW4gU3dldHQgWzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIj5t YWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEp1bmUgMjIsIDIwMTcgMTA6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29y ICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWthbWFp LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpqcmlAZ29vZ2xlLmNvbSI+anJpQGdvb2dsZS5jb208L2E+Jmd0OzsgTWlrZSBCaXNob3Ag Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIj5NaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDs7IFRlZCBIYXJkaWUgJmx0OzxhIGhyZWY9Im1h aWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20iPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7OyBRVUlD IFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4m Z3Q7Ow0KIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25A Z21haWwuY29tIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsgUGF0cmljayBNY01h bnVzICZsdDs8YSBocmVmPSJtYWlsdG86cG1jbWFudXNAbW96aWxsYS5jb20iPnBtY21hbnVzQG1v emlsbGEuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFVuaWRpcmVjdGlvbmFs IHN0cmVhbXMgUFI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFRodSwgSnVuIDIyLCAyMDE3IGF0IDk6NDkgUE0sIEx1YmFzaGV2LCBJZ29yICZs dDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmls dWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayBvZiB0aHJlZSBs YXllcnMgb2YgYWJzdHJhY3Rpb246PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtNjQzNTcxNzM4ODg1MjU1NzA1N21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+MS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5RVUlD IFdpcmUgUHJvdG9jb2wgKHRoZSB0aGluZyBkZXNjcmliZWQgYnkgdGhlIFFVSUMgVHJhbnNwb3J0 IFJGQyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTY0MzU3MTczODg4NTI1NTcw NTdtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjIuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UVVJQyBMaWJyYXJ5IEFQSSAoYSBsaWJyYXJ5IGV4cG9z aW5nIHNvbWUgdXNlZnVsIGFic3RyYWN0aW9ucyAtLSBzdWNoIGFzIGJsb2NraW5nL25vbi1ibG9j a2luZyB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFuZCBiaWRpcmVjdGlvbmFsIOKAnHNvY2tldHPi gJ0gLS0gYW5kIGltcGxlbWVudGluZyB0aGVtIHVzaW5nIFFVSUMgV2lyZQ0KIFByb3RvY29sKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNjQzNTcxNzM4ODg1MjU1NzA1N21zb2xp c3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+My48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5BcHBsaWNhdGlvbiAoc29tZXRoaW5nIHRoYXQgdXNlcyBRVUlDIExp YnJhcnkgQVBJcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgSSBhbSBzYXlpbmcgaXMgdGhhdCBN YXJ0aW7igJlzIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgcHJvcG9zYWwgZG9lcyBub3QgaGF2ZSBh IHdheSB0byBpbXBsZW1lbnQgZ2VuZXJpYyBiaWRpcmVjdGlvbmFsDQogc29ja2V0LWxpa2UgYWJz dHJhY3Rpb25zIG9uIHRoZSBRVUlDIExpYnJhcnkgQVBJIGxheWVyLiZuYnNwOyBIb3dldmVyLCBp ZiB3ZSBmb2xsb3cgTWlrZeKAmXMgc3VnZ2VzdGlvbiBhbmQgYWxsb3cgYW4gQXNzb2NpYXRlZCBT dHJlYW0gSUQgaW4gT1BFTl9TVFJFQU0gZnJhbWVzLCB0aGlzIHdvdWxkIG1ha2UgaXQgZWFzeSBm b3IgUVVJQ0sgTGlicmFyaWVzIHRvIHByb3ZpZGUgZ2VuZXJpYyBiaWRpcmVjdGlvbmFsIHNvY2tl dC1saWtlIGFic3RyYWN0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIHdoYXQgSSBhbSBzdWdn ZXN0aW5nIGlzIHRoYXQgd2Uga2VlcCBRVUlDIFdpcmUgUHJvdG9jb2wgc3RhdGUgbWFjaGluZSBz aW1wbGUgYW5kIHVuY2hhbmdlZC4mbmJzcDsgSG93ZXZlciwgd2l0aCB0aGUNCiBPUEVOX1NUUkVB TSBmcmFtZSwgd2Ugd291bGQgYWxsb3cgUVVJQyBMaWJyYXJpZXMgdG8gaW1wbGVtZW50IGJvdGgg dW5pZGlyZWN0aW9uYWwgYW5kIGJpZGlyZWN0aW9uYWwgc3RyZWFtcy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02NDM1NzE3Mzg4ODUyNTU3MDU3bXNvbGlz dHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWdvcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SWdvciwgSSB0aGluayB5b3UgYW5kIEkgYXJlIGluIGFncmVlbWVudCB0aGF0IHdlIGJv dGggd2FudCBhIHJlbGF0aXZlbHkgZWFzeSB3YXkgb2YgZG9pbmcgYm90aCB1bmlkaXJlY3Rpb25h bCBzdHJlYW1zIGFzIHdlbGwgYXMgYmlkaXJlY3Rpb25hbCBzdHJlYW1zPyZuYnNwOyBHaXZlbiB0 aGF0LCBpdCBjb21lcyBkb3duIHRvIHdoYXQgdG8gc3RhbmRhcmRpemUgYXQgdGhlIHRyYW5zcG9y dCBsYXllciBhbmQgc29tZSBmcmFtaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiByZWdhcmRzIHRvIHRoZSB1bmlkaXJlY3Rpb25hbCBv bmx5IG1vZGVsOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7MSkgVGhlIFFVSUMgc3RyZWFtIHN0YXRlIG1hY2hpbmUgaXMgcmVhbGx5IG5v dCB0aGF0IGNvbXBsZXgsIGFuZCB0aGUgY3VycmVudCBkb2N1bWVudGF0aW9uIGRvZXMgYSBuaWNl IGpvYiBvZiBleHBsYWluaW5nIGl0LiZuYnNwOyBDaGFuZ2luZyB0byB1bmlkaXJlY3Rpb25hbCBv bmx5IHN0cmVhbXMgb25seSBzYXZlcyAyIHN0YXRlcywgZnJvbSA1IHRvIDMsIGFuZCBhIHNtYWxs IGJpdCBvZiB0ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7MikgSSdtIHZlcnkgY29uY2VybmVkIHRoYXQgaWYgd2UgZG9uJ3Qgc3Rh bmRhcmRpemUgYSB3YXkgdG8gZG8gYmlkaXJlY3Rpb25hbCBzdHJlYW1zLCBkaWZmZXJlbnQgJ1FV SUMgTGlicmFyeSBBUEkncyB3aWxsIGludGVybmFsbHkgc3RhbmRhcmRpemUgb24gZGlmZmVyZW50 IGFwcHJvYWNoZXMgZm9yIHJlY3JlYXRpbmcgYmlkaXJlY3Rpb25hbCBzdHJlYW1zLiZuYnNwOyBJ IGZlYXIgdGhpcyBtYXkgY3JlYXRlIG1vcmUNCiB3b3JrIGFuZCBpbnRlcm9wZXJhYmlsaXR5IGNo YWxsZW5nZXMgZG93biB0aGUgcm9hZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gaWYgd2UgdGhpbmsgbGl0ZXJhbGx5IG5vIG9uZSB3aWxs IGhhdmUgYW55IHVzZSBmb3IgdGhlIGJpZGlyZWN0aW9uYWwgc3RyZWFtIG1vZGVsLCB0aGVuIEkg YWdyZWUgd2Ugc2hvdWxkIHJlbW92ZSBpdC4mbmJzcDsgQnV0IGV2ZW4gdG9kYXksIHRoZSBIVFRQ IG1hcHBpbmcgaXMgc2ltcGxlciB3aXRoIHRoZSBiaWRpcmVjdGlvbmFsIHN0cmVhbSBtb2RlbCB0 aGFuIHdpdGggb25seSB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zLA0KIHdoaWNoIG1lYW5zIHRoZSB0 b3RhbCBhbW91bnQgb2Ygd29yayBvZiBpbXBsZW1lbnRpbmcgSFRUUCAmIzQzOyBRVUlDIGlzIGFi b3V0IHRoZSBzYW1lIGVpdGhlciB3YXksIGFuZCBJIGJlbGlldmUgaWYgYmlkaXJlY3Rpb25hbCBz dHJlYW1zIGFuZCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGRvIGV4aXN0IGluIFFVSUMoYXMgaW4g bXkgUFIgYWJvdmUpLCB0aGVuIHRoZSBIVFRQIHdvdWxkL3Nob3VsZCB1c2UgYm90aC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_33a1a7ffdfe74bd5ae30266b6b4ebe35usma1exdag1mb5msgcorpak_-- From nobody Thu Jun 22 23:43: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 A63831200CF for ; Thu, 22 Jun 2017 23:43:48 -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 bXLczXmGOqNl for ; Thu, 22 Jun 2017 23:43:47 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 CB1901271FD for ; Thu, 22 Jun 2017 23:43:46 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id h22so24343636lfk.3 for ; Thu, 22 Jun 2017 23:43:46 -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=tB1wZ+Z8rE2j3XpJLxw3eAvYjRzqlMktkhTakL5/BKw=; b=p5mPW0l+aXn7YEmm3E8oPEBl8mgcNBnewqsRcVZs9OIewcwpVk3s5WzX2YhJN42Wgl rMhtwZco6tLvI1HiPkjLDm9G27we9u6OcaLEthqEIn5t5+V9GYQOEEapvlpvhrZXrlZ6 2MQFOE3a0mQ/EE98qJsG6Wghl0z5DtFjOeHoj2iVJb+IpNns5DZk4NM4r3S4qFvW0k5f mBkQhmJEdEw4TYBBLDFN5MaGZv0Ppej9OlhlgPs/0dMkyXEc5vYvjv8qKbocX5gspjs8 vUTl6sD9HDDZP/NCYgwTvYztZ/lmBTnk1m73Ab1ADKRkXp21GfR2o6CnDdyj2Sy3igBA x+4w== 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=tB1wZ+Z8rE2j3XpJLxw3eAvYjRzqlMktkhTakL5/BKw=; b=WUY5BWv3qu4xmsdLtF0UGDzuzagJNaT0bTy7uxYgiqlBt2147zvH6TsyzA0utGa9Py 6GNVcP3C1hZix39A0blguHR3S/X6sVfnYcFx2+Y09zZ6DeBlIqWVMrCiT/FzgEPHyzzG O1vBLhKUB4YmAqVdkbZugLkOrYrwX9lcF4JPz4LrgZ/nEgR74bx6W2MOxdX743beAMig s/vE2S3wsEpYSjaDWWpij9LZH+ph/nU3/lW6HZr9cvymQy8vRsDOjIXhkrZmmqHOPYgo nIGBT7xHlTz4KmIU5cIX6WzT7knWOUeeSiEhuGZGmgPFDet45T/sRBzO9+ROv+YLSJGM 81JQ== X-Gm-Message-State: AKS2vOzMNCGZEJjnXC5bhtsJxEwI5Juy7WhtSxym1wJsB7Kzgn0VBzzo zwWNc5WRPhtALEyufu0HtzCVfmuPZk5a X-Received: by 10.25.202.72 with SMTP id h8mr2258549lfj.172.1498200225150; Thu, 22 Jun 2017 23:43:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Thu, 22 Jun 2017 23:43:43 -0700 (PDT) In-Reply-To: <3de9380e-a255-5ee0-9f95-32125c0deef2@huitema.net> References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> <3de9380e-a255-5ee0-9f95-32125c0deef2@huitema.net> From: Martin Thomson Date: Fri, 23 Jun 2017 16:43:43 +1000 Message-ID: Subject: Re: Unidirectional streams PR To: Christian Huitema Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 06:43:49 -0000 On 23 June 2017 at 14:30, Christian Huitema wrote: > This is visible in the current text around > RESET_STREAM. If we have two number spaces, we need to split that in two > frames, RESET_MY_STREAM and TAKE_YOUR_STREAM_AWAY. Note that I think we have some agreement to do this anyway, I just decided to leave that to #171 or something that replaces it. > Of course, Martin could also update #643 to use a single stream number... I considered that, and could easily do so. I would prefer to have two spaces, but it's not a central point. From nobody Fri Jun 23 03:17: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 53266128D40 for ; Fri, 23 Jun 2017 03:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPld6UPF_SPh for ; Fri, 23 Jun 2017 03:17:30 -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 27189128B8D for ; Fri, 23 Jun 2017 03:17:29 -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 v5NAGknJ009401 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 12:16:46 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dOLdp-00033P-F5; Fri, 23 Jun 2017 12:16:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Unidirectional streams PR From: "Philipp S. Tiesel" In-Reply-To: Date: Fri, 23 Jun 2017 12:16:46 +0200 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <8F8383F1-3892-4FF2-871F-B41680687BA7@in-panik.de> References: To: Martin Thomson 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: Fri, 23 Jun 2017 10:17:32 -0000 > On 22. Jun 2017, at 03:50, Martin Thomson = wrote: >=20 > On 22 June 2017 at 09:48, Jana Iyengar wrote: >> My design sense says to optimize for the common case and to allow for = the >> exceptions. Given that our scope is to really get things rolling for = HTTP >> ASAP, I'd argue that request-response is the common case that we need = to >> optimize for. >=20 > I think that this is a fair criticism, and I wanted to address it. >=20 > My concern is exactly the same as yours: I want get HTTP working. And > unfortunately, HTTP/2 is not a simple request/response protocol. This > is why HTTP/2 and now QUIC allow the server to initiate streams. And > it's that exact gap that motivated me to propose this change. In my > view, this change makes it *easier* to finish HTTP over QUIC. >=20 > The cost is that HTTP is marginally more complex. My view is that the > overall protocol (HTTP+QUIC) is no more or less complex than before, > there are big savings in transport, and some minor savings in HTTP > that counteract the added cost: having to include explicit correlation > for request and response, and having to add a way to cancel requests > before the response starts. [1] > [1] I don't consider HAS_BODY to be a cost, I'm now firmly of the > opinion that merging headers and body back into a single stream is the > right solution and that what I wrote up here is only temporary. I have some concerns here, as separating the body into a different = stream allows more flexible design later on: If we added unreliable transport = to quick, having the header sent reliably and the body unreliably seems = useful. Canceling the stream is still possible if a) the stream ID is known by convention or b) the stream ID is provided in a forward-reference. > Ted suggested that we aim for a design that supports BOTH > unidirectional and bidirectional. Given how trivial it is to add an > identifier - as demonstrated by this PR - I don't see how building > that facility into the base transport is a net win. Some protocols > can still use the stream identifiers as a correlator, for instance > those protocols that are properly request/response don't need explicit > correlators. That choice - as with your proposal to retain > bidirectionality - creates a potential for head-of-line blocking under > certain circumstances, something that an explicit correlator at the > application layer neatly avoids. I guess having a OPEN_STREAM frame that allows to associate a new steam to a stream in reverse direction and thus building a a bi-directional stream pair is a good compromise as it allows bi-directinal streams in a quic API without introducing additional state space in the base = protocol. AVE! Philipp S. Tiesel / phils=E2=80=A6 From nobody Fri Jun 23 13:00: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 1F9E4129418 for ; Fri, 23 Jun 2017 13:00:02 -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 gUvS_rx1y1MY for ; Fri, 23 Jun 2017 12:59:59 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 E7EBD128C81 for ; Fri, 23 Jun 2017 12:59:58 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id s9so16115319ybe.3 for ; Fri, 23 Jun 2017 12:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pAqFEr7ZMYuCiUxtCOm5xHGGHBaM/CJdgurHJUU1DWQ=; b=gf1JzoXeRHfeVmuXH0s7SFCd0BH3WBqUZ+r9yf8nG+VQuIDBu0B/3kH70tv4DM9Fc1 gg1gYu2IvasHwdbz9i6dnc5QN0BKCRoFgh5ERpIKYgFvJsAgG5LThnL3fy+zmlthRRB8 +DBJ+dHyU/undW6LYXmCWwwMD142TKdXcfOmOG/z7UVr3UwnsBMEBFaxi0zI+hwlnjhM NiQxS4f+22klJ/JxGQjBoJ2SSEGtUQB/NrkD1DcW6EwUoeebiQcP+mIHMFcvalabcF6/ qu+fy3WM5IUSuDqwrCv9tEHkFu5D6Y1iYDhus41WtdBztAlSXRSe9dXEwcY6Nf7aImlX 16Dw== 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=pAqFEr7ZMYuCiUxtCOm5xHGGHBaM/CJdgurHJUU1DWQ=; b=cOgcNpnUiT6irGU+MUCG97lmrLMQyG7wCnlMbX4rPY2wLJqAqV3U1OcJVWCIjaWadW FZ4OyAkS0j4CXnvi3Gx8J98B53R3pSrR6VB+6ca9l2z4MrR386AbQmqmLvdFCX5L5MhT pomiN36QeemSJXyz6CJF3C8PtPOVfJqymRgyFkDBDc4Gw2O/A36492bkQ0dgaAgp/cPZ 9nsMllFpzYqr3VaaNFZxu5D1hX5uintYGfbg6Vk+noseRi+AaqPSFQg1HSgLe9fdl1so czza3PS9iyKgKkGjcuLnjufa4LMN46B//meNpIBmRTYYfU+XMGSHmG4WP8GWHpUz1bjN MTcQ== X-Gm-Message-State: AKS2vOwgU3hlZh5Na3frhvmdGKHa4fcdMxP1NxRzw5j7etEyJSe4THhm U007EN+vM4rEc/fL9qrtD7bCGowM6qYn X-Received: by 10.37.211.81 with SMTP id e78mr6796409ybf.46.1498247998032; Fri, 23 Jun 2017 12:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.3 with HTTP; Fri, 23 Jun 2017 12:59:37 -0700 (PDT) In-Reply-To: <33a1a7ffdfe74bd5ae30266b6b4ebe35@usma1ex-dag1mb5.msg.corp.akamai.com> References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> <2260e852b904465a9f8c9488e7e76166@usma1ex-dag1mb5.msg.corp.akamai.com> <33a1a7ffdfe74bd5ae30266b6b4ebe35@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ian Swett Date: Fri, 23 Jun 2017 15:59:37 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: "Lubashev, Igor" Cc: Mike Bishop , Ted Hardie , Patrick McManus , Jana Iyengar , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c147c3cb5b6160552a60b69" 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, 23 Jun 2017 20:00:02 -0000 --94eb2c147c3cb5b6160552a60b69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Igor, In terms of the extra state, I believe EKR's right that this either creates a need to change some text or add another state, which I hadn't anticipated, but also isn't the end of the world. However, Buck Krasic pointed out we can now get rid of implicitly opened streams, because we've transitioned from stream limits to max stream ID, which fixes this problem in a simple way. See issue #662 . I attempted to add text to specify that if a STREAM frame specifies UNI on one packet, it must do so on all of them, but the text wasn't written correctly, so I'll fix that in the PR. I did consider whether to mark all STREAM frames or only the first. In the end, I proposed to mark all of them because it's more resilient to reordering and it's easy to document and understand. I'm certainly open to other framings. On Fri, Jun 23, 2017 at 1:31 AM, Lubashev, Igor wrote= : > Ian, I am not in love with a possibility of having UNI flag clear on some > initial STREAM frames and then UNI set on subsequent STREAM frames. The = PR > does not prohibit this. I read the PR (state diagram) to require the > stream to go immediately into =E2=80=9Chalf-closed (local)=E2=80=9D state= on receipt of > such STREAM+UNI frame. This is a problem, since some packets from the > receiver to the sender could be in flight, and absent a STREAM+FIN or > RST_STREAM from the receiver, the sender cannot do flow control accountin= g. > > > > It seems best if a stream is UNI or BI from birth, and that=E2=80=99s ind= icated by > the initial STREAM frame only. If STREAM frames get reordered, until the > receiver receives the initial STREAM frame (Offset=3D0), it should consid= er > the stream to be in =E2=80=9Cimplicit=E2=80=9D state (do accounting for m= ax stream count > and flow control but cannot send data to it). > > > > > > *From:* Lubashev, Igor [mailto:ilubashe@akamai.com] > *Sent:* Thursday, June 22, 2017 10:43 PM > *To:* Ian Swett > *Cc:* Mike Bishop ; Ted Hardie < > ted.ietf@gmail.com>; Patrick McManus ; Jana Iyengar > ; QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* RE: Unidirectional streams PR > > > > Yes, we are in an agreement that we want =E2=80=9CQUIC Libraries=E2=80=9D= to provide an > easy way of doing both unidirectional streams as well as bidirectional > streams. > > > > I do not have a strong preference as to the details of framing. On one > hand, I am not worried about libraries implementing bidirectional streams > differently with OPEN_STREAM =E2=80=93 there is really just one sane way = of doing > it, and the OPEN_STREAM model is more flexible. On the other hand, > OPEN_STREAM comes at a cost of a few extra bytes for a simple bidirection= al > stream implementation. > > > > The UNI does complicate the state machine a bit by adding an extra state, > as ekr pointed out. You need a special state for implicitly opened > streams. They are not =E2=80=9Cidle=E2=80=9D (they count toward the max)= , and they are not > =E2=80=9Copen=E2=80=9D (you cannot write to them), and they are not =E2= =80=9Clocal half-closed=E2=80=9D > (they may transition to =E2=80=9Copen=E2=80=9D). I do not think this is = a huge deal, > though =E2=80=93 TCP has a lot more states! > > > > > > *From:* Ian Swett [mailto:ianswett@google.com ] > *Sent:* Thursday, June 22, 2017 10:10 PM > *To:* Lubashev, Igor > *Cc:* Jana Iyengar ; Mike Bishop < > Michael.Bishop@microsoft.com>; Ted Hardie ; QUIC WG < > quic@ietf.org>; Martin Thomson ; Patrick > McManus > *Subject:* Re: Unidirectional streams PR > > > > On Thu, Jun 22, 2017 at 9:49 PM, Lubashev, Igor > wrote: > > 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 Protoc= ol) > > 3. Application (something that uses QUIC Library APIs) > > > > What I am saying is that Martin=E2=80=99s unidirectional streams proposal= does not > have a way to implement generic bidirectional socket-like abstractions on > the QUIC Library API layer. However, if we follow Mike=E2=80=99s suggest= ion and > allow an Associated Stream ID in OPEN_STREAM frames, this would make it > easy for QUICK Libraries to provide generic bidirectional socket-like > abstractions. > > > > So what I am suggesting is that we keep QUIC Wire Protocol state machine > simple and unchanged. However, with the OPEN_STREAM frame, we would allo= w > QUIC Libraries to implement both unidirectional and bidirectional streams= . > > > > - Igor > > Igor, I think you and I are in agreement that we both want a relatively > easy way of doing both unidirectional streams as well as bidirectional > streams? Given that, it comes down to what to standardize at the transpo= rt > layer and some framing. > > > > In regards to the unidirectional only model: > > 1) The QUIC stream state machine is really not that complex, and the > current documentation does a nice job of explaining it. Changing to > unidirectional only streams only saves 2 states, from 5 to 3, and a small > bit of text. > > 2) I'm very concerned that if we don't standardize a way to do > bidirectional streams, different 'QUIC Library API's will internally > standardize on different approaches for recreating bidirectional streams. > I fear this may create more work and interoperability challenges down the > road. > > > > So if we think literally no one will have any use for the bidirectional > stream model, then I agree we should remove it. But even today, the HTTP > mapping is simpler with the bidirectional stream model than with only > unidirectional streams, which means the total amount of work of > implementing HTTP + QUIC is about the same either way, and I believe if > bidirectional streams and unidirectional streams do exist in QUIC(as in m= y > PR above), then the HTTP would/should use both. > > > --94eb2c147c3cb5b6160552a60b69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Igor,=C2=A0

In terms of the extra state= , I believe EKR's right that this either creates a need to change some = text or add another state, which I hadn't anticipated, but also isn'= ;t the end of the world.=C2=A0 However, Buck Krasic pointed out we can now = get rid of implicitly opened streams, because we've transitioned from s= tream limits to max stream ID, which fixes this problem in a simple way.=C2= =A0 See issue = #662.

I attempted to add text to specify that = if a STREAM frame specifies UNI on one packet, it must do so on all of them= , but the text wasn't written correctly, so I'll fix that in the PR= .=C2=A0 I did consider whether to mark all STREAM frames or only the first.= =C2=A0 In the end, I proposed to mark all of them because it's more res= ilient to reordering and it's easy to document and understand.=C2=A0 I&= #39;m certainly open to other framings.


=



On Fri, Jun 23, 2017 at 1:31 AM, Lubashev, Igor <ilub= ashe@akamai.com> wrote:

Ian, I am not in love with a possibility of having = UNI flag clear on some initial STREAM frames and then UNI set on subsequent= STREAM frames.=C2=A0 The PR does not prohibit this.=C2=A0 I read the PR (state diagram) to require the stream to go immediately into= =E2=80=9Chalf-closed (local)=E2=80=9D state on receipt of such STREAM+UNI = frame.=C2=A0 This is a problem, since some packets from the receiver to the= sender could be in flight, and absent a STREAM+FIN or RST_STREAM from the receiver, the sender cannot do flow control accounting= .

=C2=A0

It seems best if a stream is UNI or BI from birth, = and that=E2=80=99s indicated by the initial STREAM frame only.=C2=A0 If STR= EAM frames get reordered, until the receiver receives the initial STREAM frame (Offset=3D0), it should consider the stream to be in =E2=80= =9Cimplicit=E2=80=9D state (do accounting for max stream count and flow con= trol but cannot send data to it).

=C2=A0

=C2=A0

From: Lubashev, Igor [mailto:ilubashe@akamai.com]
Sent: Thursday, June 22, 2017 10:43 PM
To: Ian Swett <ianswett@google.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Ted Hardie <= ;ted.ietf@gmail.com= >; Patrick McManus <pmcmanus@mozilla.com>; Jana Iyengar <jri@google.com>; QUIC WG <quic@ietf.org>; Mar= tin Thomson <martin.thomson@gmail.com>
Subject: RE: Unidirectional streams PR

=C2=A0

Yes, we are in an agreement that we want =E2=80=9CQ= UIC Libraries=E2=80=9D to provide an easy way of doing both unidirectional = streams as well as bidirectional streams.

=C2=A0

I do not have a strong preference as to the details= of framing. On one hand, I am not worried about libraries implementing bid= irectional streams differently with OPEN_STREAM =E2=80=93 there is really just one sane way of doing it, and the OPEN_STRE= AM model is more flexible.=C2=A0 On the other hand, OPEN_STREAM comes at a = cost of a few extra bytes for a simple bidirectional stream implementation.=

=C2=A0

The UNI does complicate the state machine a bit by = adding an extra state, as ekr pointed out.=C2=A0 You need a special state f= or implicitly opened streams.=C2=A0 They are not =E2=80=9Cidle=E2=80=9D (they count toward the max), and they are not =E2=80=9Copen=E2=80=9D (you = cannot write to them), and they are not =E2=80=9Clocal half-closed=E2=80=9D= (they may transition to =E2=80=9Copen=E2=80=9D).=C2=A0 I do not think this= is a huge deal, though =E2=80=93 TCP has a lot more states!<= /span>

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Thursday, June 22, 2017 10:10 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Jana Iyengar <jri@google.com>; Mike Bishop <Michael.Bishop@microsoft.com>; Ted Hardie <= ted.ietf@gmail.com>; QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>; Patrick McManus <pmcmanus@mozilla.com> Subject: Re: Unidirectional streams PR

=C2=A0

On Thu, Jun 22, 2017 at 9:49 PM, Lubashev, Igor <= ilubashe@akamai.co= m> wrote:

I think of three layers of abstraction:

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 QUIC Wire Protocol (the thing described by the QUIC Transport RFC)<= /span>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 QUIC Library API (a library exposing some useful abstractions -- su= ch as blocking/non-blocking unidirectional streams and bidirectional =E2=80= =9Csockets=E2=80=9D -- and implementing them using QUIC Wire Protocol)

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Application (something that uses QUIC Library APIs)

=C2=A0

What I am saying is that Martin=E2=80=99s unidirect= ional streams proposal does not have a way to implement generic bidirection= al socket-like abstractions on the QUIC Library API layer.=C2=A0 However, if = we follow Mike=E2=80=99s suggestion and allow an Associated Stream ID in OP= EN_STREAM frames, this would make it easy for QUICK Libraries to provide ge= neric bidirectional socket-like abstractions.

=C2=A0

So what I am suggesting is that we keep QUIC Wire P= rotocol state machine simple and unchanged.=C2=A0 However, with the OPEN_STREAM frame, we would allow QUIC Libraries to implement both unidire= ctional and bidirectional streams.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Igor

Igor, I think you and I are in agreement that we bot= h want a relatively easy way of doing both unidirectional streams as well a= s bidirectional streams?=C2=A0 Given that, it comes down to what to standar= dize at the transport layer and some framing.

=C2=A0

In regards to the unidirectional only model:<= u>

=C2=A01) The QUIC stream state machine is really not= that complex, and the current documentation does a nice job of explaining = it.=C2=A0 Changing to unidirectional only streams only saves 2 states, from= 5 to 3, and a small bit of text.

=C2=A02) I'm very concerned that if we don't= standardize a way to do bidirectional streams, different 'QUIC Library= API's will internally standardize on different approaches for recreati= ng bidirectional streams.=C2=A0 I fear this may create more work and interoperability challenges down the road.

=C2=A0

So if we think literally no one will have any use fo= r the bidirectional stream model, then I agree we should remove it.=C2=A0 B= ut even today, the HTTP mapping is simpler with the bidirectional stream mo= del than with only unidirectional streams, which means the total amount of work of implementing HTTP + QUIC is about = the same either way, and I believe if bidirectional streams and unidirectio= nal streams do exist in QUIC(as in my PR above), then the HTTP would/should= use both.

=C2=A0


--94eb2c147c3cb5b6160552a60b69-- From nobody Fri Jun 23 14:59:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507E5129456 for ; Fri, 23 Jun 2017 14:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 gvIBE3dCoOxe for ; Fri, 23 Jun 2017 14:59:37 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82AB127866 for ; Fri, 23 Jun 2017 14:59:37 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5NLvoQh014938; Fri, 23 Jun 2017 22:59:32 +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=30h5qde5GaUzNj1y6qc5M5SUUjFFtBB7hnOcy5g171E=; b=KTGjUKz346QFeqIQIcsO3ZDS77kudZtQaZtysoNJpoyBHvGicF8AyRXCc2soIGg0otzE uFVFG96zKvwdfTY4Nf61ubfwUhfOkEb4ImLWt5IWolTi9oCUBdx47Ko8sMIqGIGvBJ4c 0FVXTEsPdeb6dAx2cytk2vuCTqRcNR3lQ3mTTjcFMGOFFT8WEng6fU4fHyTzfGV9nBHd GRRWK/P6W5BFD05qNp9SmAWAUTX0m2DQ+ToGvzhm8cvMIi+G0jMk+95xu4ubwOtl4qed yEJbHk/SYHRvwsmA0+GxcwuspbB/SKg+N13sSlluwIxbrfkzzZRQ8rX0A8hed2XJY1dn 9g== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2b934payu5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 22:59:32 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5NLtrAf027937; Fri, 23 Jun 2017 17:59:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b4yrvht8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 17:59:31 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 23 Jun 2017 16:59:30 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Fri, 23 Jun 2017 16:59:30 -0500 From: "Lubashev, Igor" To: Ian Swett CC: Mike Bishop , Ted Hardie , Patrick McManus , Jana Iyengar , QUIC WG , Martin Thomson Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHzFJcNmOfPnkGlJjRXQ/9soKIvh8kAgADqdYCAACIYgIABI/8AgAAEzYCAAARGgP//0FFwgABb0AD//76RwIAATcWA//+9o9AABjP0UAAndIaAAAUEE0A= Date: Fri, 23 Jun 2017 21:59:30 +0000 Message-ID: References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> <2260e852b904465a9f8c9488e7e76166@usma1ex-dag1mb5.msg.corp.akamai.com> <33a1a7ffdfe74bd5ae30266b6b4ebe35@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.33.241] Content-Type: multipart/alternative; boundary="_000_a57866b6ed094c12b54eda4ecf57ff3custx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-23_13:, , 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-1706230372 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-23_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230373 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, 23 Jun 2017 21:59:40 -0000 --_000_a57866b6ed094c12b54eda4ecf57ff3custx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBnZXR0aW5nIHJpZCBvZiBpbXBsaWNpdGx5IG9wZW4gc3RyZWFtcyBjYW4gd29yay4gIFRv IGdldCByaWQgb2Yg4oCcaW1wbGljaXTigJ0gc3RhdGUgZW50aXJlbHkgd2l0aCB5b3VyIGRlc2ln biwgeW91IHdvdWxkIG5lZWQgdG8ga2VlcCBVTkkgYml0IG9uIGFsbCBwYWNrZXRzLiAgT3RoZXJ3 aXNlLCByZW9yZGVyaW5nIG9mIHRoZSBpbml0aWFsIFNUUkVBTSBhbmQgYSBzdWJzZXF1ZW50IFNU UkVBTSB3b3VsZCByZXF1aXJlIHRoZSByZWNlaXZlciB0byBlbnRlciDigJxpbXBsaWNpdOKAnSBz dGF0ZSBmb3IgdGhlIHN0cmVhbSAoc3RyZWFtIGlzIG5vIGxvbmdlciBpZGxlLCBidXQgb25lIGNh bm5vdCBhc3N1bWUgaXQgaXMgYmlkaXJlY3Rpb25hbCkuDQoNCg0KDQoNCkZyb206IElhbiBTd2V0 dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb21dDQpTZW50OiBGcmlkYXksIEp1bmUgMjMsIDIw MTcgNDowMCBQTQ0KVG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPg0KQ2M6 IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPjsgVGVkIEhhcmRpZSA8 dGVkLmlldGZAZ21haWwuY29tPjsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNv bT47IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+OyBRVUlDIFdHIDxxdWljQGlldGYub3Jn PjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJl OiBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBSDQoNCklnb3IsDQoNCkluIHRlcm1zIG9mIHRoZSBl eHRyYSBzdGF0ZSwgSSBiZWxpZXZlIEVLUidzIHJpZ2h0IHRoYXQgdGhpcyBlaXRoZXIgY3JlYXRl cyBhIG5lZWQgdG8gY2hhbmdlIHNvbWUgdGV4dCBvciBhZGQgYW5vdGhlciBzdGF0ZSwgd2hpY2gg SSBoYWRuJ3QgYW50aWNpcGF0ZWQsIGJ1dCBhbHNvIGlzbid0IHRoZSBlbmQgb2YgdGhlIHdvcmxk LiAgSG93ZXZlciwgQnVjayBLcmFzaWMgcG9pbnRlZCBvdXQgd2UgY2FuIG5vdyBnZXQgcmlkIG9m IGltcGxpY2l0bHkgb3BlbmVkIHN0cmVhbXMsIGJlY2F1c2Ugd2UndmUgdHJhbnNpdGlvbmVkIGZy b20gc3RyZWFtIGxpbWl0cyB0byBtYXggc3RyZWFtIElELCB3aGljaCBmaXhlcyB0aGlzIHByb2Js ZW0gaW4gYSBzaW1wbGUgd2F5LiAgU2VlIGlzc3VlICM2NjI8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJE ZHJhZnRzX2lzc3Vlc182NjImZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpu M2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPWd2Mm5XOEtzSFM2THUy S2NORmF3OTFvamFWUUVSdTgxNml2aVEyMFZ3a2Mmcz02a1NDUXhGYzBERjJuMUZ5T0RRY3ByTjhK OEtBVGNhMkZIUkxFbTAyYWRjJmU9Pi4NCg0KSSBhdHRlbXB0ZWQgdG8gYWRkIHRleHQgdG8gc3Bl Y2lmeSB0aGF0IGlmIGEgU1RSRUFNIGZyYW1lIHNwZWNpZmllcyBVTkkgb24gb25lIHBhY2tldCwg aXQgbXVzdCBkbyBzbyBvbiBhbGwgb2YgdGhlbSwgYnV0IHRoZSB0ZXh0IHdhc24ndCB3cml0dGVu IGNvcnJlY3RseSwgc28gSSdsbCBmaXggdGhhdCBpbiB0aGUgUFIuICBJIGRpZCBjb25zaWRlciB3 aGV0aGVyIHRvIG1hcmsgYWxsIFNUUkVBTSBmcmFtZXMgb3Igb25seSB0aGUgZmlyc3QuICBJbiB0 aGUgZW5kLCBJIHByb3Bvc2VkIHRvIG1hcmsgYWxsIG9mIHRoZW0gYmVjYXVzZSBpdCdzIG1vcmUg cmVzaWxpZW50IHRvIHJlb3JkZXJpbmcgYW5kIGl0J3MgZWFzeSB0byBkb2N1bWVudCBhbmQgdW5k ZXJzdGFuZC4gIEknbSBjZXJ0YWlubHkgb3BlbiB0byBvdGhlciBmcmFtaW5ncy4NCg0KDQoNCg0K DQpPbiBGcmksIEp1biAyMywgMjAxNyBhdCAxOjMxIEFNLCBMdWJhc2hldiwgSWdvciA8aWx1YmFz aGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+IHdyb3RlOg0KSWFuLCBJ IGFtIG5vdCBpbiBsb3ZlIHdpdGggYSBwb3NzaWJpbGl0eSBvZiBoYXZpbmcgVU5JIGZsYWcgY2xl YXIgb24gc29tZSBpbml0aWFsIFNUUkVBTSBmcmFtZXMgYW5kIHRoZW4gVU5JIHNldCBvbiBzdWJz ZXF1ZW50IFNUUkVBTSBmcmFtZXMuICBUaGUgUFIgZG9lcyBub3QgcHJvaGliaXQgdGhpcy4gIEkg cmVhZCB0aGUgUFIgKHN0YXRlIGRpYWdyYW0pIHRvIHJlcXVpcmUgdGhlIHN0cmVhbSB0byBnbyBp bW1lZGlhdGVseSBpbnRvIOKAnGhhbGYtY2xvc2VkIChsb2NhbCnigJ0gc3RhdGUgb24gcmVjZWlw dCBvZiBzdWNoIFNUUkVBTStVTkkgZnJhbWUuICBUaGlzIGlzIGEgcHJvYmxlbSwgc2luY2Ugc29t ZSBwYWNrZXRzIGZyb20gdGhlIHJlY2VpdmVyIHRvIHRoZSBzZW5kZXIgY291bGQgYmUgaW4gZmxp Z2h0LCBhbmQgYWJzZW50IGEgU1RSRUFNK0ZJTiBvciBSU1RfU1RSRUFNIGZyb20gdGhlIHJlY2Vp dmVyLCB0aGUgc2VuZGVyIGNhbm5vdCBkbyBmbG93IGNvbnRyb2wgYWNjb3VudGluZy4NCg0KSXQg c2VlbXMgYmVzdCBpZiBhIHN0cmVhbSBpcyBVTkkgb3IgQkkgZnJvbSBiaXJ0aCwgYW5kIHRoYXTi gJlzIGluZGljYXRlZCBieSB0aGUgaW5pdGlhbCBTVFJFQU0gZnJhbWUgb25seS4gIElmIFNUUkVB TSBmcmFtZXMgZ2V0IHJlb3JkZXJlZCwgdW50aWwgdGhlIHJlY2VpdmVyIHJlY2VpdmVzIHRoZSBp bml0aWFsIFNUUkVBTSBmcmFtZSAoT2Zmc2V0PTApLCBpdCBzaG91bGQgY29uc2lkZXIgdGhlIHN0 cmVhbSB0byBiZSBpbiDigJxpbXBsaWNpdOKAnSBzdGF0ZSAoZG8gYWNjb3VudGluZyBmb3IgbWF4 IHN0cmVhbSBjb3VudCBhbmQgZmxvdyBjb250cm9sIGJ1dCBjYW5ub3Qgc2VuZCBkYXRhIHRvIGl0 KS4NCg0K --_000_a57866b6ed094c12b54eda4ecf57ff3custx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTkwNjQzNjk1NzkyNDI2 NDQ0NG02NDM1NzE3Mzg4ODUyNTU3MDU3bXNvbGlzdHBhcmFncmFwaCwgbGkubTkwNjQzNjk1Nzky NDI2NDQ0NG02NDM1NzE3Mzg4ODUyNTU3MDU3bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm05MDY0MzY5 NTc5MjQyNjQ0NDRtNjQzNTcxNzM4ODg1MjU1NzA1N21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLW5hbWU6bV85MDY0MzY5NTc5MjQyNjQ0NDRtNjQzNTcxNzM4ODg1MjU1NzA1N21zb2xpc3Rw YXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7 Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAxLjBwdCAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpu b25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgZ2V0dGluZyByaWQgb2YgaW1w bGljaXRseSBvcGVuIHN0cmVhbXMgY2FuIHdvcmsuJm5ic3A7IFRvIGdldCByaWQgb2Yg4oCcaW1w bGljaXTigJ0gc3RhdGUgZW50aXJlbHkgd2l0aCB5b3VyIGRlc2lnbiwgeW91IHdvdWxkIG5lZWQg dG8ga2VlcCBVTkkNCiBiaXQgb24gYWxsIHBhY2tldHMuJm5ic3A7IE90aGVyd2lzZSwgcmVvcmRl cmluZyBvZiB0aGUgaW5pdGlhbCBTVFJFQU0gYW5kIGEgc3Vic2VxdWVudCBTVFJFQU0gd291bGQg cmVxdWlyZSB0aGUgcmVjZWl2ZXIgdG8gZW50ZXIg4oCcaW1wbGljaXTigJ0gc3RhdGUgZm9yIHRo ZSBzdHJlYW0gKHN0cmVhbSBpcyBubyBsb25nZXIgaWRsZSwgYnV0IG9uZSBjYW5ub3QgYXNzdW1l IGl0IGlzIGJpZGlyZWN0aW9uYWwpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMjMsIDIwMTcgNDowMCBQTTxicj4NCjxiPlRvOjwvYj4g THViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IFRlZCBI YXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNvbSZndDs7IFBhdHJpY2sgTWNNYW51cyAmbHQ7cG1j bWFudXNAbW96aWxsYS5jb20mZ3Q7OyBKYW5hIEl5ZW5nYXIgJmx0O2pyaUBnb29nbGUuY29tJmd0 OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBVbmlkaXJl Y3Rpb25hbCBzdHJlYW1zIFBSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWdvciwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkluIHRlcm1zIG9mIHRoZSBleHRyYSBzdGF0ZSwgSSBiZWxpZXZlIEVLUidzIHJpZ2h0IHRoYXQg dGhpcyBlaXRoZXIgY3JlYXRlcyBhIG5lZWQgdG8gY2hhbmdlIHNvbWUgdGV4dCBvciBhZGQgYW5v dGhlciBzdGF0ZSwgd2hpY2ggSSBoYWRuJ3QgYW50aWNpcGF0ZWQsIGJ1dCBhbHNvIGlzbid0IHRo ZSBlbmQgb2YgdGhlIHdvcmxkLiZuYnNwOyBIb3dldmVyLCBCdWNrIEtyYXNpYyBwb2ludGVkIG91 dCB3ZSBjYW4gbm93IGdldA0KIHJpZCBvZiBpbXBsaWNpdGx5IG9wZW5lZCBzdHJlYW1zLCBiZWNh dXNlIHdlJ3ZlIHRyYW5zaXRpb25lZCBmcm9tIHN0cmVhbSBsaW1pdHMgdG8gbWF4IHN0cmVhbSBJ RCwgd2hpY2ggZml4ZXMgdGhpcyBwcm9ibGVtIGluIGEgc2ltcGxlIHdheS4mbmJzcDsgU2VlDQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX2dpdGh1Yi5jb21fcXVpY3dnX2Jhc2UtMkRkcmFmdHNfaXNzdWVzXzY2MiZhbXA7ZD1Ed01G YVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZM M3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPWd2Mm5XOEtzSFM2THUyS2NORmF3OTFvamFW UUVSdTgxNml2aVEyMFZ3a2MmYW1wO3M9NmtTQ1F4RmMwREYybjFGeU9EUWNwck44SjhLQVRjYTJG SFJMRW0wMmFkYyZhbXA7ZT0iPg0KaXNzdWUgIzY2MjwvYT4uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYXR0ZW1wdGVkIHRvIGFkZCB0ZXh0 IHRvIHNwZWNpZnkgdGhhdCBpZiBhIFNUUkVBTSBmcmFtZSBzcGVjaWZpZXMgVU5JIG9uIG9uZSBw YWNrZXQsIGl0IG11c3QgZG8gc28gb24gYWxsIG9mIHRoZW0sIGJ1dCB0aGUgdGV4dCB3YXNuJ3Qg d3JpdHRlbiBjb3JyZWN0bHksIHNvIEknbGwgZml4IHRoYXQgaW4gdGhlIFBSLiZuYnNwOyBJIGRp ZCBjb25zaWRlciB3aGV0aGVyIHRvIG1hcmsgYWxsIFNUUkVBTSBmcmFtZXMgb3INCiBvbmx5IHRo ZSBmaXJzdC4mbmJzcDsgSW4gdGhlIGVuZCwgSSBwcm9wb3NlZCB0byBtYXJrIGFsbCBvZiB0aGVt IGJlY2F1c2UgaXQncyBtb3JlIHJlc2lsaWVudCB0byByZW9yZGVyaW5nIGFuZCBpdCdzIGVhc3kg dG8gZG9jdW1lbnQgYW5kIHVuZGVyc3RhbmQuJm5ic3A7IEknbSBjZXJ0YWlubHkgb3BlbiB0byBv dGhlciBmcmFtaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1biAyMywgMjAxNyBhdCAxOjMxIEFNLCBMdWJh c2hldiwgSWdvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iIHRhcmdl dD0iX2JsYW5rIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklhbiwg SSBhbSBub3QgaW4gbG92ZSB3aXRoIGEgcG9zc2liaWxpdHkgb2YgaGF2aW5nIFVOSSBmbGFnIGNs ZWFyIG9uIHNvbWUgaW5pdGlhbCBTVFJFQU0gZnJhbWVzIGFuZCB0aGVuIFVOSSBzZXQNCiBvbiBz dWJzZXF1ZW50IFNUUkVBTSBmcmFtZXMuJm5ic3A7IFRoZSBQUiBkb2VzIG5vdCBwcm9oaWJpdCB0 aGlzLiZuYnNwOyBJIHJlYWQgdGhlIFBSIChzdGF0ZSBkaWFncmFtKSB0byByZXF1aXJlIHRoZSBz dHJlYW0gdG8gZ28gaW1tZWRpYXRlbHkgaW50byDigJxoYWxmLWNsb3NlZCAobG9jYWwp4oCdIHN0 YXRlIG9uIHJlY2VpcHQgb2Ygc3VjaCBTVFJFQU0mIzQzO1VOSSBmcmFtZS4mbmJzcDsgVGhpcyBp cyBhIHByb2JsZW0sIHNpbmNlIHNvbWUgcGFja2V0cyBmcm9tIHRoZSByZWNlaXZlcg0KIHRvIHRo ZSBzZW5kZXIgY291bGQgYmUgaW4gZmxpZ2h0LCBhbmQgYWJzZW50IGEgU1RSRUFNJiM0MztGSU4g b3IgUlNUX1NUUkVBTSBmcm9tIHRoZSByZWNlaXZlciwgdGhlIHNlbmRlciBjYW5ub3QgZG8gZmxv dyBjb250cm9sIGFjY291bnRpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JdCBzZWVtcyBiZXN0IGlm IGEgc3RyZWFtIGlzIFVOSSBvciBCSSBmcm9tIGJpcnRoLCBhbmQgdGhhdOKAmXMgaW5kaWNhdGVk IGJ5IHRoZSBpbml0aWFsIFNUUkVBTSBmcmFtZSBvbmx5LiZuYnNwOyBJZiBTVFJFQU0NCiBmcmFt ZXMgZ2V0IHJlb3JkZXJlZCwgdW50aWwgdGhlIHJlY2VpdmVyIHJlY2VpdmVzIHRoZSBpbml0aWFs IFNUUkVBTSBmcmFtZSAoT2Zmc2V0PTApLCBpdCBzaG91bGQgY29uc2lkZXIgdGhlIHN0cmVhbSB0 byBiZSBpbiDigJxpbXBsaWNpdOKAnSBzdGF0ZSAoZG8gYWNjb3VudGluZyBmb3IgbWF4IHN0cmVh bSBjb3VudCBhbmQgZmxvdyBjb250cm9sIGJ1dCBjYW5ub3Qgc2VuZCBkYXRhIHRvIGl0KS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a57866b6ed094c12b54eda4ecf57ff3custx2exdag1mb5msgcorpak_-- From nobody Fri Jun 23 17:09:22 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 8308F129B40; Fri, 23 Jun 2017 17:07:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: quic@ietf.org, spencerdawkins.ietf@gmail.com Subject: quic - Requested sessions have been scheduled for IETF 99 X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282153.7840.13704900001095295706.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:01 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:01 -0000 Dear Mark Nottingham, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. quic Session 1 (2:00:00) Thursday, Afternoon Session II 1550-1750 Room Name: Grand Hilton Ballroom size: 250 --------------------------------------------- quic Session 2 (2:00:00) Friday, Morning Session I 0930-1130 Room Name: Grand Hilton Ballroom size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Mark Nottingham Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: httpbis tsvarea tsvwg tls Second Priority: opsawg opsarea mptcp Third Priority: maprg People who must be present: Mark Nottingham Janardhan Iyengar Martin Thomson Spencer Dawkins Lars Eggert Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: --------------------------------------------------------- From nobody Fri Jun 23 17:41:07 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 59C4D129B2D for ; Fri, 23 Jun 2017 17:41:06 -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 JfOKqj0Juiv2 for ; Fri, 23 Jun 2017 17:41:03 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5D1129B2B for ; Fri, 23 Jun 2017 17:41:03 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id t127so11565077ywc.3 for ; Fri, 23 Jun 2017 17:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ID2arChF4r6ValEpvnZRORs2OvjH2tB9W8dCI4u1T+A=; b=TDsaYSuyXTZ+dUS7doFXTzdvl2B+ioKVOEZTawtPNiNIjM/92aEO0ASekB5yOxSfFZ NBiX0Z3EbW2FPiLA8hr1+3BBQvdPBCdezcaLXWTJCjSpy0x4A56XK/7PghVPAJs8yf3m eu0ocHzCoGfPl32D1vGZhZsFz4QlXxmU1Z4TCVP0yAuVx9L/oUFE4laKlAAixwBHa760 giW2A+U6qelUet0ofU4Zem6o/sHj+Pqy4q+beZLWqrMkeWNCOakkWvcLlfqXpuuSM0BZ yGVPG/vkNBfvHwWevnR+lAUvSRbbLy2OsrYDcCDyqjvOzd6DittkfBZLUgV6/tY9g4/O 0l4g== 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=ID2arChF4r6ValEpvnZRORs2OvjH2tB9W8dCI4u1T+A=; b=bLmvDzaxwBvPjk0cjSCVZ3TAUeS/WxAuskBGjHckwkWpb8A5pPRmshDgO/exu4x/Sx zyUEhnbaTeyOK9FkKDFy0QCvn3nkOHT9yqGEKOjCm/S79hKBAHA2qqNT/ceWvqYW1m06 E8RUfIZMmW0BRF0G+Ih65fzFR2TF/5OKW/tzBNLoM1vwCGhyzSI4IBxQ33YYvIiMB1aj j0vyhfXdX5DO+hBS4iWa0salS4eygY9lRCurlQWlIksfpflaD/+yWd91alUArMzqGJ9V M/XhnnMBzo5MgmEIQdTdJ/wXr2AVesbzhA6dpiXI9s96xA4CIuvBXybg3ZR8qEd2DnUB QLRQ== X-Gm-Message-State: AKS2vOxVrtqH6bWFOs8Ld8cQsWxZ0cFsJU5KrdXK7aCDG+wySA4llzD3 gx+KNkj1dLFLg2zMw5m9uNOBltpMaUdJ X-Received: by 10.13.229.193 with SMTP id o184mr7782908ywe.101.1498264862215; Fri, 23 Jun 2017 17:41:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.3 with HTTP; Fri, 23 Jun 2017 17:40:41 -0700 (PDT) In-Reply-To: References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> <2260e852b904465a9f8c9488e7e76166@usma1ex-dag1mb5.msg.corp.akamai.com> <33a1a7ffdfe74bd5ae30266b6b4ebe35@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ian Swett Date: Fri, 23 Jun 2017 20:40:41 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: "Lubashev, Igor" Cc: Mike Bishop , Ted Hardie , Patrick McManus , Jana Iyengar , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c081d74e4ff6c0552a9f810" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:41:06 -0000 --94eb2c081d74e4ff6c0552a9f810 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ekr and I were chatting about the high level design options here. There are a lot of specific details to both PRs which may not be ideal, but no matter what, the HTTP mapping(and future apps) are going to need both bidirectional and unidirectional streams, so it's just a matter of where that functionality is defined and implemented. We came up with 4 options(I'm sure there are sub-options here, but bear with me): 1) Do nothing, let the application(ie: HTTP) create unidirectional streams by closing one half of the bidi stream. 2) Add unidirectional streams as an option to existing bidirectional streams. (my PR is a proof of concept of that) 3) Change the transport text to describe unidirectional streams and add a mechanism in the transport doc to pair them into bidi streams. 4) Replace bidirectional streams with unidirectional streams in the transport doc and make transports implement bidi streams if they need them. (Martin's PR is an example of this) I think Martin and my PR's demonstrate that #2 and #4 are possible options, and I suspect it would be straightforward to draft an example PR for #3 if someone desired. I want to keep bidirectional streaming in the transport doc and wrote up 2 because I felt it was simpler to implement and reason about than 3. I don't believe anyone is a strong supporter of #1 (and if you are, now would be an excellent time to speak up), which leaves the WG choosing between 2, 3 and 4 as architectural directions. I'm going to update my PR to try to fix the issues identified in the comments when I can this weekend, but I think the critical question for the WG is which direction(s) we'd like to spend time refining, and are people clamoring for an example PR representing option 3? On Fri, Jun 23, 2017 at 5:59 PM, Lubashev, Igor wrote= : > Yes, getting rid of implicitly open streams can work. To get rid of > =E2=80=9Cimplicit=E2=80=9D state entirely with your design, you would nee= d to keep UNI bit > on all packets. Otherwise, reordering of the initial STREAM and a > subsequent STREAM would require the receiver to enter =E2=80=9Cimplicit= =E2=80=9D state for > the stream (stream is no longer idle, but one cannot assume it is > bidirectional). > > > > > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Friday, June 23, 2017 4:00 PM > *To:* Lubashev, Igor > *Cc:* Mike Bishop ; Ted Hardie < > ted.ietf@gmail.com>; Patrick McManus ; Jana Iyengar > ; QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* Re: Unidirectional streams PR > > > > Igor, > > > > In terms of the extra state, I believe EKR's right that this either > creates a need to change some text or add another state, which I hadn't > anticipated, but also isn't the end of the world. However, Buck Krasic > pointed out we can now get rid of implicitly opened streams, because we'v= e > transitioned from stream limits to max stream ID, which fixes this proble= m > in a simple way. See issue #662 > > . > > > > I attempted to add text to specify that if a STREAM frame specifies UNI o= n > one packet, it must do so on all of them, but the text wasn't written > correctly, so I'll fix that in the PR. I did consider whether to mark al= l > STREAM frames or only the first. In the end, I proposed to mark all of > them because it's more resilient to reordering and it's easy to document > and understand. I'm certainly open to other framings. > > > > > > > > > > > > On Fri, Jun 23, 2017 at 1:31 AM, Lubashev, Igor > wrote: > > Ian, I am not in love with a possibility of having UNI flag clear on some > initial STREAM frames and then UNI set on subsequent STREAM frames. The = PR > does not prohibit this. I read the PR (state diagram) to require the > stream to go immediately into =E2=80=9Chalf-closed (local)=E2=80=9D state= on receipt of > such STREAM+UNI frame. This is a problem, since some packets from the > receiver to the sender could be in flight, and absent a STREAM+FIN or > RST_STREAM from the receiver, the sender cannot do flow control accountin= g. > > > > It seems best if a stream is UNI or BI from birth, and that=E2=80=99s ind= icated by > the initial STREAM frame only. If STREAM frames get reordered, until the > receiver receives the initial STREAM frame (Offset=3D0), it should consid= er > the stream to be in =E2=80=9Cimplicit=E2=80=9D state (do accounting for m= ax stream count > and flow control but cannot send data to it). > > > --94eb2c081d74e4ff6c0552a9f810 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ekr and I were chatting about the high level design option= s here.=C2=A0 There are a lot of specific details to both PRs which may not= be ideal, but no matter what, the HTTP mapping(and future apps) are going = to need both bidirectional and unidirectional streams, so it's just a m= atter of where that functionality is defined and implemented.

We came up with 4 options(I'm sure there are sub-options here, bu= t bear with me):
=C2=A0 1) Do nothing, let the application(ie: HT= TP) create unidirectional streams by closing one half of the bidi stream.
=C2=A0 2) Add unidirectional streams as an option to existing bidi= rectional streams. (my PR is a proof of concept of that)
=C2=A0 3= ) Change the transport text to describe unidirectional streams and add a me= chanism in the transport doc to pair them into bidi streams.
=C2= =A0 4) Replace bidirectional streams with unidirectional streams in the tra= nsport doc and make transports implement bidi streams if they need them. (M= artin's PR is an example of this)

I think Mart= in and my PR's demonstrate that #2 and #4 are possible options, and I s= uspect it would be straightforward to draft an example PR for #3 if someone= desired.

I want to keep bidirectional streaming i= n the transport doc and wrote up 2 because I felt it was simpler to impleme= nt and reason about than 3.=C2=A0 I don't believe anyone is a strong su= pporter of #1 (and if you are, now would be an excellent time to speak up),= which leaves the WG choosing between 2, 3 and 4 as architectural direction= s.

I'm going to update my PR to try to fix the= issues identified in the comments when I can this weekend, but I think the= critical question for the WG is which direction(s) we'd like to spend = time refining, and are people clamoring for an example PR representing opti= on 3?




On Fri, Jun 23, 2017 at 5:59 P= M, Lubashev, Igor <ilubashe@akamai.com> wrote:

Yes, getting rid = of implicitly open streams can work.=C2=A0 To get rid of =E2=80=9Cimplicit= =E2=80=9D state entirely with your design, you would need to keep UNI bit on all packets.=C2=A0 Otherwise, reordering of the initial STREAM and = a subsequent STREAM would require the receiver to enter =E2=80=9Cimplicit= =E2=80=9D state for the stream (stream is no longer idle, but one cannot as= sume it is bidirectional).

=C2=A0<= /u>

=C2=A0<= /u>

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Friday, June 23, 2017 4:00 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Ted Hardie <= ;ted.ietf@gmail.com= >; Patrick McManus <pmcmanus@mozilla.com>; Jana Iyengar <jri@google.com>; QUIC WG <quic@ietf.org>; Mar= tin Thomson <martin.thomson@gmail.com>
Subject: Re: Unidirectional streams PR

=C2=A0

Igor,=C2=A0

=C2=A0

In terms of the extra state, I believe EKR's rig= ht that this either creates a need to change some text or add another state= , which I hadn't anticipated, but also isn't the end of the world.= =C2=A0 However, Buck Krasic pointed out we can now get rid of implicitly opened streams, because we've transitioned from stre= am limits to max stream ID, which fixes this problem in a simple way.=C2=A0= See issue #662.

=C2=A0

I attempted to add text to specify that if a STREAM = frame specifies UNI on one packet, it must do so on all of them, but the te= xt wasn't written correctly, so I'll fix that in the PR.=C2=A0 I di= d consider whether to mark all STREAM frames or only the first.=C2=A0 In the end, I proposed to mark all of them because i= t's more resilient to reordering and it's easy to document and unde= rstand.=C2=A0 I'm certainly open to other framings.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Jun 23, 2017 at 1:31 AM, Lubashev, Igor <= ilubashe@akamai.co= m> wrote:

Ian, I am not in love with a possibility of having = UNI flag clear on some initial STREAM frames and then UNI set on subsequent STREAM frames.=C2=A0 The PR does not prohibit this.=C2=A0 I = read the PR (state diagram) to require the stream to go immediately into = =E2=80=9Chalf-closed (local)=E2=80=9D state on receipt of such STREAM+UNI f= rame.=C2=A0 This is a problem, since some packets from the receiver to the sender could be in flight, and absent a STREAM+FIN or RST_STREAM fr= om the receiver, the sender cannot do flow control accounting.

=C2=A0

It seems best if a stream is UNI or BI from birth, = and that=E2=80=99s indicated by the initial STREAM frame only.=C2=A0 If STR= EAM frames get reordered, until the receiver receives the initial STREAM frame= (Offset=3D0), it should consider the stream to be in =E2=80=9Cimplicit=E2= =80=9D state (do accounting for max stream count and flow control but canno= t send data to it).

=C2=A0


--94eb2c081d74e4ff6c0552a9f810-- From nobody Fri Jun 23 17:42: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 A31BC129B0A for ; Fri, 23 Jun 2017 17:42:46 -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 h6rrDPOBwdm6 for ; Fri, 23 Jun 2017 17:42:43 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0117.outbound.protection.outlook.com [104.47.41.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 2EFEB12943C for ; Fri, 23 Jun 2017 17:42:43 -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=gbe1iZ1ZF2Ph5cXgStPz4cKlZtP9Jb+EswadppykBzw=; b=NqLdUxLnT+IeJBGDQVYTc4r6AWwL9LokhVupATZLg0bN3fg5aSLs+cvUYgPezlII9xmkaszI8j0ZzvVqH6WJlaqhhK45osrEyIUHdq51ZQZE5pD4nQe4SHou+LggYiQEFTSRMiEvwcqC6cyll+jeZQAcnzNkg7C0ij9ctNroC+4= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0511.namprd21.prod.outlook.com (10.172.95.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.1; Sat, 24 Jun 2017 00:42:40 +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.1220.005; Sat, 24 Jun 2017 00:42:40 +0000 From: Mike Bishop To: Ian Swett , "Lubashev, Igor" CC: Ted Hardie , Patrick McManus , Jana Iyengar , QUIC WG , Martin Thomson Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS6mHyIpxR/afFiUiHxd5TQx2M+qIvEnAAgADqdYCAACIZgIABI/4AgAA3F4CAAAIxEIAAKOgAgAAFTwCAAAbCgIAABZSAgAAJYACAAC8DAIAA8oOAgAAhfwCAAC0JgIAAAGZQ Date: Sat, 24 Jun 2017 00:42:40 +0000 Message-ID: References: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com> <9bf0712b00e540eeafdd3e6f357c2845@usma1ex-dag1mb5.msg.corp.akamai.com> <2260e852b904465a9f8c9488e7e76166@usma1ex-dag1mb5.msg.corp.akamai.com> <33a1a7ffdfe74bd5ae30266b6b4ebe35@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: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.140.154.179] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0511; 7:7ihqI94iiUyt1hs+3TL0ANIM+rN504ZsV++kDZOTGfwYA6W3jkjArp3Nstnhd5CriImk97RA6arqmQAGSX26o27HdUgIXgvUmBgepB+d9pnvzIIhb4xN1s2gnjAwaqayKina58GPaqb5dTaR1I6NELUTcbX+PHjsaEdrikX+kEtQ6I2S+44p+GQwv4j0WYfYu/N0NrLMN8UujbtQt3aa3Ox+vDDgvwhsKsdupIbGhlFt3LoPbBg7ayJcU7zqielnv+QCozKjG0bzlydqtv3uIy7MVp4nSw59oc4WpCCaH650UD7zocGrG5VldbZf/fyhyyjXjMXL0WYiwQbKemA7Zp34ifhmL294k7D8zkDnC0OXs7glHt090WLTP/YRrarz2UPdY6zM8Jk0khygN2mEr3rcM7vGMRb5BJuvMjNzSGXyguj7qB50kvgtpZ1UknnTWJcdnSDbyUSZsBRL7qap6JjE0Am9YsvzYjwmcMIUAG/mewNKBOkUdc52/t4JeUGANG/QKDuoSs6u0uJTvVZpaw+bof2rM/rCZpFWxTbPThpxaJ2GoltxQwIlyOucyPXIvB1czF+oG1pkUDWRoX6Q58E3GLyqRKpMZpya/dG4sCNi31bOSsr6QFI8/n9MoWIFvjp3rO20MDI2SpP9zgT4hT//+Gk9wjuJL+ihfHKrjsC2G+sLoEyULS7bpbO0qd+2xDhkjaoQolBqMzkYg2bax6tCJ8TzaOBcBWyH5Th35xyCiFGCGkd+nu1u/1NDQVG9iZqheSsXpZ2mti1SYGhOh9bv0LkRxUejazPjpI6dOJLlp87i0j+EbpYMqO9vd+s5 x-ms-office365-filtering-correlation-id: 14c5c9f2-7189-4bc6-6c95-08d4ba99eb72 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500078)(300135000095)(300000501078)(300135300095)(300000502078)(300135100095)(22001)(2017030254075)(48565401081)(300000503078)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504078)(300135200095)(300000505078)(300135600095)(300000506063)(300135500095); SRVR:MWHPR21MB0511; x-ms-traffictypediagnostic: MWHPR21MB0511: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(788757137089)(211936372134217)(219752817060721)(21748063052155)(151999592597050)(278178393323532)(26388249023172)(236129657087228)(48057245064654); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0511; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0511; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39400400002)(39850400002)(39840400002)(39860400002)(24454002)(377454003)(97736004)(53546010)(3280700002)(189998001)(10290500003)(33656002)(2906002)(7696004)(81166006)(25786009)(7906003)(2900100001)(7736002)(3846002)(6116002)(2950100002)(14454004)(72206003)(478600001)(8936002)(19609705001)(790700001)(102836003)(3480700004)(74316002)(236005)(8990500004)(54896002)(6246003)(5005710100001)(6306002)(9686003)(66066001)(55016002)(54906002)(99286003)(606005)(10090500001)(4326008)(6506006)(86612001)(77096006)(6436002)(8676002)(5660300001)(122556002)(76176999)(54356999)(7116003)(3660700001)(50986999)(38730400002)(86362001)(229853002)(93886004)(53936002)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0511; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0141E2F04DAA6CA831A9C23387D90MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2017 00:42:40.6687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0511 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:42:47 -0000 --_000_MWHPR21MB0141E2F04DAA6CA831A9C23387D90MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBteSBhbmQgSWdvcuKAmXMgZS1tYWlscyBpbGx1c3RyYXRlIHRoYXQgcGF0aDsgSSBj YW4gcHV0IGEgUFIgdG9nZXRoZXIgaWYgZGVzaXJlZC4NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWls dG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVuZSAyMywgMjAxNyA1OjQx IFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+DQpDYzogTWlrZSBC aXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0 ZkBnbWFpbC5jb20+OyBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPjsgSmFu YSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KU3ViamVjdDogUmU6IFVuaWRp cmVjdGlvbmFsIHN0cmVhbXMgUFINCg0KZWtyIGFuZCBJIHdlcmUgY2hhdHRpbmcgYWJvdXQgdGhl IGhpZ2ggbGV2ZWwgZGVzaWduIG9wdGlvbnMgaGVyZS4gIFRoZXJlIGFyZSBhIGxvdCBvZiBzcGVj aWZpYyBkZXRhaWxzIHRvIGJvdGggUFJzIHdoaWNoIG1heSBub3QgYmUgaWRlYWwsIGJ1dCBubyBt YXR0ZXIgd2hhdCwgdGhlIEhUVFAgbWFwcGluZyhhbmQgZnV0dXJlIGFwcHMpIGFyZSBnb2luZyB0 byBuZWVkIGJvdGggYmlkaXJlY3Rpb25hbCBhbmQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcywgc28g aXQncyBqdXN0IGEgbWF0dGVyIG9mIHdoZXJlIHRoYXQgZnVuY3Rpb25hbGl0eSBpcyBkZWZpbmVk IGFuZCBpbXBsZW1lbnRlZC4NCg0KV2UgY2FtZSB1cCB3aXRoIDQgb3B0aW9ucyhJJ20gc3VyZSB0 aGVyZSBhcmUgc3ViLW9wdGlvbnMgaGVyZSwgYnV0IGJlYXIgd2l0aCBtZSk6DQogIDEpIERvIG5v dGhpbmcsIGxldCB0aGUgYXBwbGljYXRpb24oaWU6IEhUVFApIGNyZWF0ZSB1bmlkaXJlY3Rpb25h bCBzdHJlYW1zIGJ5IGNsb3Npbmcgb25lIGhhbGYgb2YgdGhlIGJpZGkgc3RyZWFtLg0KICAyKSBB ZGQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhcyBhbiBvcHRpb24gdG8gZXhpc3RpbmcgYmlkaXJl Y3Rpb25hbCBzdHJlYW1zLiAobXkgUFIgaXMgYSBwcm9vZiBvZiBjb25jZXB0IG9mIHRoYXQpDQog IDMpIENoYW5nZSB0aGUgdHJhbnNwb3J0IHRleHQgdG8gZGVzY3JpYmUgdW5pZGlyZWN0aW9uYWwg c3RyZWFtcyBhbmQgYWRkIGEgbWVjaGFuaXNtIGluIHRoZSB0cmFuc3BvcnQgZG9jIHRvIHBhaXIg dGhlbSBpbnRvIGJpZGkgc3RyZWFtcy4NCiAgNCkgUmVwbGFjZSBiaWRpcmVjdGlvbmFsIHN0cmVh bXMgd2l0aCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGluIHRoZSB0cmFuc3BvcnQgZG9jIGFuZCBt YWtlIHRyYW5zcG9ydHMgaW1wbGVtZW50IGJpZGkgc3RyZWFtcyBpZiB0aGV5IG5lZWQgdGhlbS4g KE1hcnRpbidzIFBSIGlzIGFuIGV4YW1wbGUgb2YgdGhpcykNCg0KSSB0aGluayBNYXJ0aW4gYW5k IG15IFBSJ3MgZGVtb25zdHJhdGUgdGhhdCAjMiBhbmQgIzQgYXJlIHBvc3NpYmxlIG9wdGlvbnMs IGFuZCBJIHN1c3BlY3QgaXQgd291bGQgYmUgc3RyYWlnaHRmb3J3YXJkIHRvIGRyYWZ0IGFuIGV4 YW1wbGUgUFIgZm9yICMzIGlmIHNvbWVvbmUgZGVzaXJlZC4NCg0KSSB3YW50IHRvIGtlZXAgYmlk aXJlY3Rpb25hbCBzdHJlYW1pbmcgaW4gdGhlIHRyYW5zcG9ydCBkb2MgYW5kIHdyb3RlIHVwIDIg YmVjYXVzZSBJIGZlbHQgaXQgd2FzIHNpbXBsZXIgdG8gaW1wbGVtZW50IGFuZCByZWFzb24gYWJv dXQgdGhhbiAzLiAgSSBkb24ndCBiZWxpZXZlIGFueW9uZSBpcyBhIHN0cm9uZyBzdXBwb3J0ZXIg b2YgIzEgKGFuZCBpZiB5b3UgYXJlLCBub3cgd291bGQgYmUgYW4gZXhjZWxsZW50IHRpbWUgdG8g c3BlYWsgdXApLCB3aGljaCBsZWF2ZXMgdGhlIFdHIGNob29zaW5nIGJldHdlZW4gMiwgMyBhbmQg NCBhcyBhcmNoaXRlY3R1cmFsIGRpcmVjdGlvbnMuDQoNCkknbSBnb2luZyB0byB1cGRhdGUgbXkg UFIgdG8gdHJ5IHRvIGZpeCB0aGUgaXNzdWVzIGlkZW50aWZpZWQgaW4gdGhlIGNvbW1lbnRzIHdo ZW4gSSBjYW4gdGhpcyB3ZWVrZW5kLCBidXQgSSB0aGluayB0aGUgY3JpdGljYWwgcXVlc3Rpb24g Zm9yIHRoZSBXRyBpcyB3aGljaCBkaXJlY3Rpb24ocykgd2UnZCBsaWtlIHRvIHNwZW5kIHRpbWUg cmVmaW5pbmcsIGFuZCBhcmUgcGVvcGxlIGNsYW1vcmluZyBmb3IgYW4gZXhhbXBsZSBQUiByZXBy ZXNlbnRpbmcgb3B0aW9uIDM/DQoNCg0KDQoNCk9uIEZyaSwgSnVuIDIzLCAyMDE3IGF0IDU6NTkg UE0sIEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBh a2FtYWkuY29tPj4gd3JvdGU6DQpZZXMsIGdldHRpbmcgcmlkIG9mIGltcGxpY2l0bHkgb3BlbiBz dHJlYW1zIGNhbiB3b3JrLiAgVG8gZ2V0IHJpZCBvZiDigJxpbXBsaWNpdOKAnSBzdGF0ZSBlbnRp cmVseSB3aXRoIHlvdXIgZGVzaWduLCB5b3Ugd291bGQgbmVlZCB0byBrZWVwIFVOSSBiaXQgb24g YWxsIHBhY2tldHMuICBPdGhlcndpc2UsIHJlb3JkZXJpbmcgb2YgdGhlIGluaXRpYWwgU1RSRUFN IGFuZCBhIHN1YnNlcXVlbnQgU1RSRUFNIHdvdWxkIHJlcXVpcmUgdGhlIHJlY2VpdmVyIHRvIGVu dGVyIOKAnGltcGxpY2l04oCdIHN0YXRlIGZvciB0aGUgc3RyZWFtIChzdHJlYW0gaXMgbm8gbG9u Z2VyIGlkbGUsIGJ1dCBvbmUgY2Fubm90IGFzc3VtZSBpdCBpcyBiaWRpcmVjdGlvbmFsKS4NCg0K DQoNCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86 aWFuc3dldHRAZ29vZ2xlLmNvbT5dDQpTZW50OiBGcmlkYXksIEp1bmUgMjMsIDIwMTcgNDowMCBQ TQ0KVG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNo ZUBha2FtYWkuY29tPj4NCkNjOiBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0 LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+OyBUZWQgSGFyZGllIDx0 ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+OyBQYXRyaWNrIE1j TWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPG1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbT4+ OyBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+OyBR VUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IE1hcnRpbiBUaG9t c29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbT4+DQpTdWJqZWN0OiBSZTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQpJZ29yLA0K DQpJbiB0ZXJtcyBvZiB0aGUgZXh0cmEgc3RhdGUsIEkgYmVsaWV2ZSBFS1IncyByaWdodCB0aGF0 IHRoaXMgZWl0aGVyIGNyZWF0ZXMgYSBuZWVkIHRvIGNoYW5nZSBzb21lIHRleHQgb3IgYWRkIGFu b3RoZXIgc3RhdGUsIHdoaWNoIEkgaGFkbid0IGFudGljaXBhdGVkLCBidXQgYWxzbyBpc24ndCB0 aGUgZW5kIG9mIHRoZSB3b3JsZC4gIEhvd2V2ZXIsIEJ1Y2sgS3Jhc2ljIHBvaW50ZWQgb3V0IHdl IGNhbiBub3cgZ2V0IHJpZCBvZiBpbXBsaWNpdGx5IG9wZW5lZCBzdHJlYW1zLCBiZWNhdXNlIHdl J3ZlIHRyYW5zaXRpb25lZCBmcm9tIHN0cmVhbSBsaW1pdHMgdG8gbWF4IHN0cmVhbSBJRCwgd2hp Y2ggZml4ZXMgdGhpcyBwcm9ibGVtIGluIGEgc2ltcGxlIHdheS4gIFNlZSBpc3N1ZSAjNjYyPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNB X19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vlc182NjIlMjZkJTNERHdNRmFR JTI2YyUzRDk2WmJaWmNhTUY0dzBGNGpwTjZMWmclMjZyJTNERGpuM2JRNXVOSkRQTV8yc2tmTDNy VzF0emNJeHlqVVpkbl9tNTVLUG1sbyUyNm0lM0RndjJuVzhLc0hTNkx1MktjTkZhdzkxb2phVlFF UnU4MTZpdmlRMjBWd2tjJTI2cyUzRDZrU0NReEZjMERGMm4xRnlPRFFjcHJOOEo4S0FUY2EyRkhS TEVtMDJhZGMlMjZlJTNEJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuQmlzaG9wJTQwbWljcm9zb2Z0 LmNvbSU3QzdhYTFjNTEyYjcwMTRiNTc2ZGI5MDhkNGJhOTliMTQ0JTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjMzODYxNjY0NzgyNjA0OSZzZGF0YT1NbVJp JTJCZFZiNk5Ia2NTM0ZqNWF2SzBBdFkzVUdzcG1zSmtTeEhBYXBPSjAlM0QmcmVzZXJ2ZWQ9MD4u DQoNCkkgYXR0ZW1wdGVkIHRvIGFkZCB0ZXh0IHRvIHNwZWNpZnkgdGhhdCBpZiBhIFNUUkVBTSBm cmFtZSBzcGVjaWZpZXMgVU5JIG9uIG9uZSBwYWNrZXQsIGl0IG11c3QgZG8gc28gb24gYWxsIG9m IHRoZW0sIGJ1dCB0aGUgdGV4dCB3YXNuJ3Qgd3JpdHRlbiBjb3JyZWN0bHksIHNvIEknbGwgZml4 IHRoYXQgaW4gdGhlIFBSLiAgSSBkaWQgY29uc2lkZXIgd2hldGhlciB0byBtYXJrIGFsbCBTVFJF QU0gZnJhbWVzIG9yIG9ubHkgdGhlIGZpcnN0LiAgSW4gdGhlIGVuZCwgSSBwcm9wb3NlZCB0byBt YXJrIGFsbCBvZiB0aGVtIGJlY2F1c2UgaXQncyBtb3JlIHJlc2lsaWVudCB0byByZW9yZGVyaW5n IGFuZCBpdCdzIGVhc3kgdG8gZG9jdW1lbnQgYW5kIHVuZGVyc3RhbmQuICBJJ20gY2VydGFpbmx5 IG9wZW4gdG8gb3RoZXIgZnJhbWluZ3MuDQoNCg0KDQoNCg0KT24gRnJpLCBKdW4gMjMsIDIwMTcg YXQgMTozMSBBTSwgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmls dWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCklhbiwgSSBhbSBub3QgaW4gbG92ZSB3aXRoIGEg cG9zc2liaWxpdHkgb2YgaGF2aW5nIFVOSSBmbGFnIGNsZWFyIG9uIHNvbWUgaW5pdGlhbCBTVFJF QU0gZnJhbWVzIGFuZCB0aGVuIFVOSSBzZXQgb24gc3Vic2VxdWVudCBTVFJFQU0gZnJhbWVzLiAg VGhlIFBSIGRvZXMgbm90IHByb2hpYml0IHRoaXMuICBJIHJlYWQgdGhlIFBSIChzdGF0ZSBkaWFn cmFtKSB0byByZXF1aXJlIHRoZSBzdHJlYW0gdG8gZ28gaW1tZWRpYXRlbHkgaW50byDigJxoYWxm LWNsb3NlZCAobG9jYWwp4oCdIHN0YXRlIG9uIHJlY2VpcHQgb2Ygc3VjaCBTVFJFQU0rVU5JIGZy YW1lLiAgVGhpcyBpcyBhIHByb2JsZW0sIHNpbmNlIHNvbWUgcGFja2V0cyBmcm9tIHRoZSByZWNl aXZlciB0byB0aGUgc2VuZGVyIGNvdWxkIGJlIGluIGZsaWdodCwgYW5kIGFic2VudCBhIFNUUkVB TStGSU4gb3IgUlNUX1NUUkVBTSBmcm9tIHRoZSByZWNlaXZlciwgdGhlIHNlbmRlciBjYW5ub3Qg ZG8gZmxvdyBjb250cm9sIGFjY291bnRpbmcuDQoNCkl0IHNlZW1zIGJlc3QgaWYgYSBzdHJlYW0g aXMgVU5JIG9yIEJJIGZyb20gYmlydGgsIGFuZCB0aGF04oCZcyBpbmRpY2F0ZWQgYnkgdGhlIGlu aXRpYWwgU1RSRUFNIGZyYW1lIG9ubHkuICBJZiBTVFJFQU0gZnJhbWVzIGdldCByZW9yZGVyZWQs IHVudGlsIHRoZSByZWNlaXZlciByZWNlaXZlcyB0aGUgaW5pdGlhbCBTVFJFQU0gZnJhbWUgKE9m ZnNldD0wKSwgaXQgc2hvdWxkIGNvbnNpZGVyIHRoZSBzdHJlYW0gdG8gYmUgaW4g4oCcaW1wbGlj aXTigJ0gc3RhdGUgKGRvIGFjY291bnRpbmcgZm9yIG1heCBzdHJlYW0gY291bnQgYW5kIGZsb3cg Y29udHJvbCBidXQgY2Fubm90IHNlbmQgZGF0YSB0byBpdCkuDQoNCg0K --_000_MWHPR21MB0141E2F04DAA6CA831A9C23387D90MWHPR21MB0141namp_ 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 IHRoaW5rIG15IGFuZCBJZ29y4oCZcyBlLW1haWxzIGlsbHVzdHJhdGUgdGhhdCBwYXRoOyBJIGNh biBwdXQgYSBQUiB0b2dldGhlciBpZiBkZXNpcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwv YT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFu Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IElhbiBTd2V0dCBbbWFpbHRvOmlh bnN3ZXR0QGdvb2dsZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMjMsIDIw MTcgNTo0MSBQTTxicj4NCjxiPlRvOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFr YW1haS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbSZndDs7IFRlZCBIYXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNvbSZn dDs7IFBhdHJpY2sgTWNNYW51cyAmbHQ7cG1jbWFudXNAbW96aWxsYS5jb20mZ3Q7OyBKYW5hIEl5 ZW5nYXIgJmx0O2pyaUBnb29nbGUuY29tJmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBSPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5la3IgYW5kIEkgd2VyZSBjaGF0dGluZyBhYm91dCB0aGUgaGln aCBsZXZlbCBkZXNpZ24gb3B0aW9ucyBoZXJlLiZuYnNwOyBUaGVyZSBhcmUgYSBsb3Qgb2Ygc3Bl Y2lmaWMgZGV0YWlscyB0byBib3RoIFBScyB3aGljaCBtYXkgbm90IGJlIGlkZWFsLCBidXQgbm8g bWF0dGVyIHdoYXQsIHRoZSBIVFRQIG1hcHBpbmcoYW5kIGZ1dHVyZSBhcHBzKSBhcmUgZ29pbmcg dG8gbmVlZCBib3RoIGJpZGlyZWN0aW9uYWwgYW5kIHVuaWRpcmVjdGlvbmFsDQogc3RyZWFtcywg c28gaXQncyBqdXN0IGEgbWF0dGVyIG9mIHdoZXJlIHRoYXQgZnVuY3Rpb25hbGl0eSBpcyBkZWZp bmVkIGFuZCBpbXBsZW1lbnRlZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlIGNhbWUgdXAgd2l0aCA0IG9wdGlvbnMoSSdtIHN1cmUgdGhlcmUgYXJlIHN1 Yi1vcHRpb25zIGhlcmUsIGJ1dCBiZWFyIHdpdGggbWUpOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDEpIERvIG5vdGhpbmcsIGxldCB0 aGUgYXBwbGljYXRpb24oaWU6IEhUVFApIGNyZWF0ZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGJ5 IGNsb3Npbmcgb25lIGhhbGYgb2YgdGhlIGJpZGkgc3RyZWFtLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDIpIEFkZCB1bmlkaXJlY3Rp b25hbCBzdHJlYW1zIGFzIGFuIG9wdGlvbiB0byBleGlzdGluZyBiaWRpcmVjdGlvbmFsIHN0cmVh bXMuIChteSBQUiBpcyBhIHByb29mIG9mIGNvbmNlcHQgb2YgdGhhdCk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAzKSBDaGFuZ2UgdGhl IHRyYW5zcG9ydCB0ZXh0IHRvIGRlc2NyaWJlIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYW5kIGFk ZCBhIG1lY2hhbmlzbSBpbiB0aGUgdHJhbnNwb3J0IGRvYyB0byBwYWlyIHRoZW0gaW50byBiaWRp IHN0cmVhbXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgNCkgUmVwbGFjZSBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgd2l0aCB1bmlkaXJl Y3Rpb25hbCBzdHJlYW1zIGluIHRoZSB0cmFuc3BvcnQgZG9jIGFuZCBtYWtlIHRyYW5zcG9ydHMg aW1wbGVtZW50IGJpZGkgc3RyZWFtcyBpZiB0aGV5IG5lZWQgdGhlbS4gKE1hcnRpbidzIFBSIGlz IGFuIGV4YW1wbGUgb2YgdGhpcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBNYXJ0aW4gYW5kIG15IFBSJ3MgZGVtb25zdHJhdGUg dGhhdCAjMiBhbmQgIzQgYXJlIHBvc3NpYmxlIG9wdGlvbnMsIGFuZCBJIHN1c3BlY3QgaXQgd291 bGQgYmUgc3RyYWlnaHRmb3J3YXJkIHRvIGRyYWZ0IGFuIGV4YW1wbGUgUFIgZm9yICMzIGlmIHNv bWVvbmUgZGVzaXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB3YW50IHRvIGtlZXAgYmlkaXJlY3Rpb25hbCBzdHJlYW1pbmcgaW4gdGhl IHRyYW5zcG9ydCBkb2MgYW5kIHdyb3RlIHVwIDIgYmVjYXVzZSBJIGZlbHQgaXQgd2FzIHNpbXBs ZXIgdG8gaW1wbGVtZW50IGFuZCByZWFzb24gYWJvdXQgdGhhbiAzLiZuYnNwOyBJIGRvbid0IGJl bGlldmUgYW55b25lIGlzIGEgc3Ryb25nIHN1cHBvcnRlciBvZiAjMSAoYW5kIGlmIHlvdSBhcmUs IG5vdyB3b3VsZCBiZSBhbiBleGNlbGxlbnQNCiB0aW1lIHRvIHNwZWFrIHVwKSwgd2hpY2ggbGVh dmVzIHRoZSBXRyBjaG9vc2luZyBiZXR3ZWVuIDIsIDMgYW5kIDQgYXMgYXJjaGl0ZWN0dXJhbCBk aXJlY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JJ20gZ29pbmcgdG8gdXBkYXRlIG15IFBSIHRvIHRyeSB0byBmaXggdGhlIGlzc3Vl cyBpZGVudGlmaWVkIGluIHRoZSBjb21tZW50cyB3aGVuIEkgY2FuIHRoaXMgd2Vla2VuZCwgYnV0 IEkgdGhpbmsgdGhlIGNyaXRpY2FsIHF1ZXN0aW9uIGZvciB0aGUgV0cgaXMgd2hpY2ggZGlyZWN0 aW9uKHMpIHdlJ2QgbGlrZSB0byBzcGVuZCB0aW1lIHJlZmluaW5nLCBhbmQgYXJlIHBlb3BsZSBj bGFtb3JpbmcgZm9yIGFuDQogZXhhbXBsZSBQUiByZXByZXNlbnRpbmcgb3B0aW9uIDM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEZyaSwgSnVuIDIzLCAyMDE3IGF0IDU6NTkgUE0sIEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVm PSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFr YW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMS4wcHQgMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+WWVzLCBnZXR0aW5nIHJpZCBvZiBpbXBsaWNpdGx5IG9wZW4gc3RyZWFtcyBjYW4g d29yay4mbmJzcDsgVG8gZ2V0IHJpZCBvZiDigJxpbXBsaWNpdOKAnSBzdGF0ZSBlbnRpcmVseSB3 aXRoIHlvdXIgZGVzaWduLCB5b3Ugd291bGQgbmVlZCB0byBrZWVwIFVOSSBiaXQgb24gYWxsIHBh Y2tldHMuJm5ic3A7IE90aGVyd2lzZSwgcmVvcmRlcmluZw0KIG9mIHRoZSBpbml0aWFsIFNUUkVB TSBhbmQgYSBzdWJzZXF1ZW50IFNUUkVBTSB3b3VsZCByZXF1aXJlIHRoZSByZWNlaXZlciB0byBl bnRlciDigJxpbXBsaWNpdOKAnSBzdGF0ZSBmb3IgdGhlIHN0cmVhbSAoc3RyZWFtIGlzIG5vIGxv bmdlciBpZGxlLCBidXQgb25lIGNhbm5vdCBhc3N1bWUgaXQgaXMgYmlkaXJlY3Rpb25hbCkuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPkZyb206PC9iPiBJYW4gU3dldHQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWFuc3dldHRA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAyMywgMjAxNyA0OjAwIFBNPGJyPg0KPGI+VG86 PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5j b20iIHRhcmdldD0iX2JsYW5rIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDs8YnI+DQo8Yj5D Yzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWlj cm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208 L2E+Jmd0OzsgVGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7OyBQYXRyaWNrIE1j TWFudXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBtY21hbnVzQG1vemlsbGEuY29tPC9hPiZndDs7DQogSmFuYSBJeWVuZ2FyICZsdDs8 YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xl LmNvbTwvYT4mZ3Q7OyBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPklnb3IsJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SW4gdGVybXMgb2YgdGhlIGV4dHJhIHN0YXRlLCBJIGJlbGlldmUgRUtSJ3Mg cmlnaHQgdGhhdCB0aGlzIGVpdGhlciBjcmVhdGVzIGEgbmVlZCB0byBjaGFuZ2Ugc29tZSB0ZXh0 IG9yIGFkZCBhbm90aGVyIHN0YXRlLCB3aGljaCBJIGhhZG4ndCBhbnRpY2lwYXRlZCwgYnV0IGFs c28gaXNuJ3QgdGhlIGVuZCBvZg0KIHRoZSB3b3JsZC4mbmJzcDsgSG93ZXZlciwgQnVjayBLcmFz aWMgcG9pbnRlZCBvdXQgd2UgY2FuIG5vdyBnZXQgcmlkIG9mIGltcGxpY2l0bHkgb3BlbmVkIHN0 cmVhbXMsIGJlY2F1c2Ugd2UndmUgdHJhbnNpdGlvbmVkIGZyb20gc3RyZWFtIGxpbWl0cyB0byBt YXggc3RyZWFtIElELCB3aGljaCBmaXhlcyB0aGlzIHByb2JsZW0gaW4gYSBzaW1wbGUgd2F5LiZu YnNwOyBTZWUNCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYy JTJGdXJsJTNGdSUzRGh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lz c3Vlc182NjIlMjZkJTNERHdNRmFRJTI2YyUzRDk2WmJaWmNhTUY0dzBGNGpwTjZMWmclMjZyJTNE RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyUyNm0lM0RndjJuVzhL c0hTNkx1MktjTkZhdzkxb2phVlFFUnU4MTZpdmlRMjBWd2tjJTI2cyUzRDZrU0NReEZjMERGMm4x RnlPRFFjcHJOOEo4S0FUY2EyRkhSTEVtMDJhZGMlMjZlJTNEJmFtcDtkYXRhPTAyJTdDMDElN0NN aWNoYWVsLkJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M3YWExYzUxMmI3MDE0YjU3NmRiOTA4ZDRi YTk5YjE0NCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYz Mzg2MTY2NDc4MjYwNDkmYW1wO3NkYXRhPU1tUmklMkJkVmI2TkhrY1MzRmo1YXZLMEF0WTNVR3Nw bXNKa1N4SEFhcE9KMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaXNzdWUg IzY2MjwvYT4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIGF0dGVtcHRlZCB0byBhZGQgdGV4dCB0byBzcGVjaWZ5IHRoYXQgaWYgYSBT VFJFQU0gZnJhbWUgc3BlY2lmaWVzIFVOSSBvbiBvbmUgcGFja2V0LCBpdCBtdXN0IGRvIHNvIG9u IGFsbCBvZiB0aGVtLCBidXQgdGhlIHRleHQgd2Fzbid0IHdyaXR0ZW4gY29ycmVjdGx5LCBzbyBJ J2xsIGZpeCB0aGF0IGluIHRoZQ0KIFBSLiZuYnNwOyBJIGRpZCBjb25zaWRlciB3aGV0aGVyIHRv IG1hcmsgYWxsIFNUUkVBTSBmcmFtZXMgb3Igb25seSB0aGUgZmlyc3QuJm5ic3A7IEluIHRoZSBl bmQsIEkgcHJvcG9zZWQgdG8gbWFyayBhbGwgb2YgdGhlbSBiZWNhdXNlIGl0J3MgbW9yZSByZXNp bGllbnQgdG8gcmVvcmRlcmluZyBhbmQgaXQncyBlYXN5IHRvIGRvY3VtZW50IGFuZCB1bmRlcnN0 YW5kLiZuYnNwOyBJJ20gY2VydGFpbmx5IG9wZW4gdG8gb3RoZXIgZnJhbWluZ3MuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gRnJpLCBKdW4gMjMsIDIwMTcgYXQgMTozMSBBTSwgTHViYXNoZXYsIElnb3Ig Jmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWFuLCBJIGFtIG5vdCBpbiBsb3ZlIHdpdGggYSBwb3Nz aWJpbGl0eSBvZiBoYXZpbmcgVU5JIGZsYWcgY2xlYXIgb24gc29tZSBpbml0aWFsIFNUUkVBTSBm cmFtZXMgYW5kIHRoZW4gVU5JIHNldCBvbiBzdWJzZXF1ZW50IFNUUkVBTSBmcmFtZXMuJm5ic3A7 IFRoZSBQUiBkb2VzIG5vdCBwcm9oaWJpdCB0aGlzLiZuYnNwOyBJDQogcmVhZCB0aGUgUFIgKHN0 YXRlIGRpYWdyYW0pIHRvIHJlcXVpcmUgdGhlIHN0cmVhbSB0byBnbyBpbW1lZGlhdGVseSBpbnRv IOKAnGhhbGYtY2xvc2VkIChsb2NhbCnigJ0gc3RhdGUgb24gcmVjZWlwdCBvZiBzdWNoIFNUUkVB TSYjNDM7VU5JIGZyYW1lLiZuYnNwOyBUaGlzIGlzIGEgcHJvYmxlbSwgc2luY2Ugc29tZSBwYWNr ZXRzIGZyb20gdGhlIHJlY2VpdmVyIHRvIHRoZSBzZW5kZXIgY291bGQgYmUgaW4gZmxpZ2h0LCBh bmQgYWJzZW50IGEgU1RSRUFNJiM0MztGSU4gb3INCiBSU1RfU1RSRUFNIGZyb20gdGhlIHJlY2Vp dmVyLCB0aGUgc2VuZGVyIGNhbm5vdCBkbyBmbG93IGNvbnRyb2wgYWNjb3VudGluZy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHNlZW1zIGJlc3QgaWYgYSBzdHJlYW0gaXMgVU5JIG9y IEJJIGZyb20gYmlydGgsIGFuZCB0aGF04oCZcyBpbmRpY2F0ZWQgYnkgdGhlIGluaXRpYWwgU1RS RUFNIGZyYW1lIG9ubHkuJm5ic3A7IElmIFNUUkVBTSBmcmFtZXMgZ2V0IHJlb3JkZXJlZCwgdW50 aWwgdGhlIHJlY2VpdmVyIHJlY2VpdmVzIHRoZSBpbml0aWFsDQogU1RSRUFNIGZyYW1lIChPZmZz ZXQ9MCksIGl0IHNob3VsZCBjb25zaWRlciB0aGUgc3RyZWFtIHRvIGJlIGluIOKAnGltcGxpY2l0 4oCdIHN0YXRlIChkbyBhY2NvdW50aW5nIGZvciBtYXggc3RyZWFtIGNvdW50IGFuZCBmbG93IGNv bnRyb2wgYnV0IGNhbm5vdCBzZW5kIGRhdGEgdG8gaXQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB0141E2F04DAA6CA831A9C23387D90MWHPR21MB0141namp_-- From mikkelfj@gmail.com Fri Jun 23 23:00: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 7D0ED126BF3 for ; Fri, 23 Jun 2017 23:00:27 -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 DpsNfN2FMnEE for ; Fri, 23 Jun 2017 23:00:25 -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 DCE4C128854 for ; Fri, 23 Jun 2017 23:00:24 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 70so47564103uau.0 for ; Fri, 23 Jun 2017 23:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=uz/D7xiKPHdBXCFvhuH6KVL7w62XnmGt7BMM7pbec70=; b=FG60QMokZwbUNG5Dqp8hZ/ajrDQmka+LTbSVTK9qARNNnBkjyvdDdr686pjdu231lC 6BhNt0WPsdzX0xA5ePyCeVggryCSaDjHio0DuoKLeaWs0l+G5eXjojm0FzuPY68dzcj9 3cja2h2IBGY5wl9TqDnK1k5JcM7c8rlph12/FkKn5igpb2nVVFgQiqtX10Fr7mdurIMz zRWUJ5T+bcJTHOA/yIc6D49XlG2VMDuMVM6ASSx0h6JnigMyJIo2rdOoVrDjS6rq1pEr 6sbWoIfPFKXsfwepi9TehIdNcEOsMSUrmRQiOir6ZtQGmsX59CpZ59uUaru+u1Zbn6Ya BvsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=uz/D7xiKPHdBXCFvhuH6KVL7w62XnmGt7BMM7pbec70=; b=sKkRWipjj3E2GFw3nT1sonfNP0YZRORZwLYCTF/ctxALx4dLFjX0Spp1jN2/JhMAac RkgYFdRKv3zbFK+bA7HSZMB3frGrHpo8HhZG6OQe9jF7j1DoTd8xB9+qSaaXGBEt80CI +RxLIVYlAJwp8Eqsgcj5ocSAZTAUYSAZS+yNdA2lpPeZ6Kj5b+RKdh0jryEAHW1V7bzN lAj4mqtqjboTw8H6Zgb4BpY7Fc8mqTAxNZ32FSq3ZGYAgYTeiImW7Oj5sfB4DQPIXSBd 7XRwk5qWN8Rlyj1A+oXXuI8yORlJ8PrMDm6twjv0VpJ/zTUP6JDhBWcYEPl1eyA9l6yy WkKQ== X-Gm-Message-State: AKS2vOxWubjyr2ojC3cJZLuoOWS7IwfRlSkEtLg9eePslj7Uuo2uWbMt p/VfdaKvd9s2QUcI0FXntQ2jp62mZejg X-Received: by 10.159.48.132 with SMTP id j4mr8229194uab.42.1498284023678; Fri, 23 Jun 2017 23:00:23 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 23 Jun 2017 23:00:23 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 23 Jun 2017 23:00:23 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: quic@ietf.org Content-Type: multipart/alternative; boundary="f403045e3ede010c8c0552ae6f41" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 06:02:45 -0000 --f403045e3ede010c8c0552ae6f41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I think my and Igor=E2=80=99s e-mails illustrate that path; I can put a P= R together if desired. I=E2=80=99d like that. I=E2=80=99m concerned with the complexity of bidi+uni and I am not fond of = bidi alone either. It leaves a lot of room for error related to handling unexpected transmissions on streams and how and when to open and close streams. Uni-directional streams avoids these issues. I also see the value in an API layer implementing a default BIDI layer on top of uni-directional streams where a stream association is optional so applications can build on that. Thus, I would like to see a PR for uni+optional associated streams (option 3). But otherwise I prefer uni only (option 4). While 3) appears useful, an application may have better context to provide associations, but if it works out, it would be useful. Note that bidi streams might offload some work for applications - but the quic library needs to inform the app of events so an app would have to handle abnormal cases such as early transmissions on a stream that is expected to only be replied to after sending data. Therefore it might be simpler to just manage uni-directional streams with fewer surprises even if more explicit. I have a separate use case for very light-weight uni-directional streams - it=E2=80=99s relevant here to illustrate why you might want very small stre= am headers - the point being - stream open and association should not require a stream frame to be large by default - I don=E2=80=99t propose to include = these details for now, but just for illustration of what can be done: A messaging application may send thousands upwards to 1 million messages per second (if stream ID were 64 bit var length). Each packet might contain 30 messages of 50 bytes each without stream offset but with FIN bit and clearly uni-directional. The stream ID can be delta encoded relative to previous streams in same packet. If the application embeds an app specific message receiver, the stream ID becomes a serial number. This effectively implements partial reliability because a receiver could drop older messages for the same app ID - e.g. game state or last sensor reading. The stream length could also be allowed to be just 1 byte. This results in messages that could have only 3 bytes of framing overhead per message on average: , , {black box payload including app specific stream receiver}. Note that 1 million messages per second is perfectly possible on 10Gpbs but it would run out of identifiers after 1 hour using 32-bit identifiers. *From:* Mike Bishop I think my and Igor=E2=80=99s e-mails illustrate that path; I can put a PR = together if desired. *From:* Ian Sweet ekr and I were chatting about the high level design options here. There are a lot of specific details to both PRs which may not be ideal, but no matter what, the HTTP mapping(and future apps) are going to need both bidirectional and unidirectional streams, so it's just a matter of where that functionality is defined and implemented. We came up with 4 options(I'm sure there are sub-options here, but bear with me): 1) Do nothing, let the application(ie: HTTP) create unidirectional streams by closing one half of the bidi stream. 2) Add unidirectional streams as an option to existing bidirectional streams. (my PR is a proof of concept of that) 3) Change the transport text to describe unidirectional streams and add a mechanism in the transport doc to pair them into bidi streams. 4) Replace bidirectional streams with unidirectional streams in the transport doc and make transports implement bidi streams if they need them. (Martin's PR is an example of this) --f403045e3ede010c8c0552ae6f41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

> I think my and Igor=E2=80=99s e-mails illustrate that p= ath; I can put a PR together if desired.


I=E2=80=99d like that.


I=E2=80=99m concerned with the complexity of bidi+uni and I am n= ot fond of bidi alone either. It leaves a lot of room for error related to = handling unexpected transmissions on streams and how and when to open and c= lose streams. Uni-directional streams avoids these issues.

=

= =C2=A0

I also see the value in an API layer implementing a default BIDI lay= er on top of uni-directional streams where a stream association is optional= so applications can build on that.

=C2=A0

Thus, I would like to see a PR for uni+optional associated s= treams (option 3). B= ut otherwise I prefer uni only (option 4). While 3) appears useful, an appl= ication may have better context to provide associations, but if it works ou= t, it would be useful.


<= /p>

Note that bidi streams might offload some = work for applications - but the=C2=A0quic library needs to inform the app o= f events so an app would have to handle abnormal cases such as early transm= issions on a stream that is expected to only be replied to after sending da= ta. Therefore it might be simpler to just manage uni-directional streams wi= th fewer surprises even if more explicit.


=

I have a separate us= e case for very light-weight uni-directional streams - it=E2=80=99s relevan= t here to illustrate why you might want very small stream headers - the poi= nt being - stream open and association should not require a stream frame to= be large by default - I don=E2=80=99t propose to include these details for= now, but just for illustration of what can be done:


A messaging ap= plication may send thousands upwards to 1 million messages per second (if s= tream ID were 64 bit var length). Each packet might contain 30 messages of = 50 bytes each without stream offset but with FIN bit and clearly uni-direct= ional. The stream ID can be delta encoded relative to previous streams in s= ame packet. If the application embeds an app specific message receiver, the= stream ID becomes a serial number. This effectively implements partial rel= iability because a receiver could drop older messages for the same app ID -= e.g. game state or last sensor reading. The stream length could also be al= lowed to be just 1 byte. This results in messages that could have only 3 by= tes of framing overhead per message on average: <type-byte with flags:= =C2=A0uni, fin, no-o= ffset>, <var length signed stream ID byte, delta to first in packet&g= t;, <var length packet length>{black box payload including app specif= ic stream receiver}.=C2=A0Note that 1 million messages per second is perfectl= y possible on 10Gpbs but it would run out of=C2=A0identifiers after 1 hour = using 32-bit identifiers.


From:=C2=A0Mike Bi= shop=C2=A0

I think my and Igor=E2=80=99s e-mails i= llustrate that path; I can put a PR together if desired.

<= b>From:=C2=A0Ian Sweet

ekr and I were chatting about the high level design option= s here.=C2=A0 There are a lot of specific details to both PRs which may not= be ideal, but no matter what, the HTTP mapping(and future apps) are going = to need both bidirectional and unidirectional streams, so it's just a m= atter of where that functionality is defined and implemented.

=C2=A0

We came up= with 4 options(I'm sure there are sub-options here, but bear with me):=

=C2=A0 1) Do nothing, let the application(ie: HTTP) create unidirectional= streams by closing one half of the bidi stream.

=C2=A0 2) Add unidirectio= nal streams as an option to existing bidirectional streams. (my PR is a pro= of of concept of that)

=C2=A0 3) Change the transport text to describe uni= directional streams and add a mechanism in the transport doc to pair them i= nto bidi streams.

=C2=A0 4) Replace bidirectional streams with unidirectio= nal streams in the transport doc and make transports implement bidi streams= if they need them. (Martin's PR is an example of this)


--f403045e3ede010c8c0552ae6f41-- From nobody Sat Jun 24 12:15: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 04F51126D73 for ; Sat, 24 Jun 2017 12:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-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 SNALmbEiphwO for ; Sat, 24 Jun 2017 12:15:22 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A271270A7 for ; Sat, 24 Jun 2017 12:15:22 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dOqWd-0002Cj-9K for quic@ietf.org; Sat, 24 Jun 2017 21:15:20 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dOqWW-0001U4-42 for quic@ietf.org; Sat, 24 Jun 2017 15:15:16 -0400 Received: (qmail 30690 invoked from network); 24 Jun 2017 19:15:08 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.228]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Jun 2017 19:15:08 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> Date: Sat, 24 Jun 2017 12:15:03 -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: Unidirectional streams PR 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.47) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23SqfQgkOp6hcRjynR4M9lwIryRN09Lit7hjFm LHo/TaUAFnKDN/u9YJu29Qcu3NteYOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyXmEKFUex3GCBp/sQ6IwamreNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj234Kahp30YSTh5OL3yMqjF0jNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxiSsoNTiR/GmpPv4QzJ0uLs078I0y+3uS4dN KiUgYTBUcmBYfZ/VWDOr4EGvIULOPIAbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/RufmJqHIgpwQblHGid2pC00i13zjCiwPgdt77s k1WBMw== 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: Sat, 24 Jun 2017 19:15:24 -0000 Nice discussion. Seeing this design by many PR, I am afraid we will meet an old friend: https://en.wikipedia.org/wiki/Camel. -- Christian Huitema From nobody Sun Jun 25 16:31: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 4268F1270B4 for ; Sun, 25 Jun 2017 16:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8mZLgcGVvOWg for ; Sun, 25 Jun 2017 16:31:06 -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 D54CC126C22 for ; Sun, 25 Jun 2017 16:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: Subject:From:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=RJ2QNLibBu4Lk9vjuQJYEAwHWS9jhNdsI0lVK+dZgqk=; b=Bk8jFHIBrGbEsptd5trFi4Wkqq jk1G38n3p3cY15AkfkOImZEu47MSMORFYHC86ilo1TIbFWA39bXdquGgEu4p+FfHb5XY8Hu8xN8cT mx9DoaiLTHg7Ny7oM4eN6cW7MygnBNMwnkDidBN2ANiMnSWmDqqrHnv1Hz5lI68K4Twk8w5oM55m7 xhOUS/RUYKJXXYSRumPon3rrQD7d6t5zfIgwF/A9/75hHbj7z+Z/fivUHoBeSc3xj5wx4oFbYWxhe FxRTOZHL5Y29YZrUpArDD8uEpsqB2FgeL8YEG0GFDD8zPk0OpMnugR/2TpU9hp6n0xGC9yQk6dPR3 vY2XcEZg==; Received: from [31.185.128.124] (port=46000 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dPGzd-0001fb-Th; Mon, 26 Jun 2017 00:31:04 +0100 To: Ingemar Johansson S From: Bob Briscoe Subject: Quick review of ECN for QUIC: draft-johansson-quic-ecn-03 Cc: QUIC IETF mailing list Message-ID: <0062c1c4-254c-651f-c091-7f85fc1a28fa@bobbriscoe.net> Date: Mon, 26 Jun 2017 00:31:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D985351030404B53F1E60F6E" 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: Sun, 25 Jun 2017 23:31:09 -0000 This is a multi-part message in MIME format. --------------D985351030404B53F1E60F6E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ingemar, As just promised (on tcpm - pasted below) here's a rushed write-up of the high order bits of my review of your draft-johansson-quic-ecn-03. This is purely a list of my immediate reactions to sentences in the draft. I will need longer to think about the protocol as a whole, whether this is the best approach, whether there might be a better approach, and the open issues you list. 2.1 It would be useful to first describe how the protocol would work across a network without Byzantine middlebox behaviour and without hobbled operating systems that cannot access the ECN field of IP packets. Then separately describe fall-back in the face of various ECN failures separately. Preferably, let's try to think of a way to support ECN on the very first QUIC connection setup datagrams (see comments pasted below about copying the techniques in draft-bagnulo-tcpm-generalized-ecn, which depends on draft-ietf-tcpm-accurate-ecn for this capability). 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). 2.1.1 The argument for sending an ECN negotiation frame in a packet on its own only only makes sense if loss is more likely for packets with a non-zero IP-ECN field. Therefore, this should not necessarily be a long-term requirement on the protocol. Why always use CE to test traversal of the IP-ECN field? Setting the ECT codepoint that will be used throughout the connection also tests for zeroing the ECN field, without risking losing visibility of a CE marking introduced in the network. Define "a failed challenge/response phase". Can't it fail for a half-connection, not necessarily for the whole connection? 2.1.2 The mode mechanism of RFC6679 needs to be described, not just referenced. Note that draft-ietf-tsvwg-ecn-experimentation intends to update RFC6679 in this respect (removing the use of the ECN nonce). 2.3 Nit: You assign the names E1 and E2 for the fields for the length of each encoding of ECT(0) and ECT(1). It would be less illogical if they were called E0 and E1. The feedback gives the number of marked bytes. It needs to specify which headers are (not) included in the byte count. And if a datagram with zero bytes is ECN-marked, how do you propose to feed that back (in AccECN it feeds back marked packets and marked bytes)? It says 1 octet overhead if ECN is not supported. Can't the ends send no ECN feedback at all if they have disabled ECN during the challenge response? 2.4 It suggests using a given pattern to detect the need for fall-back. That's a good idea. I think any particular connection should only need to include two IP-ECN codepoints in the pattern: the relevant ECT codepoint and CE. You might also want to look at this expired I-D: draft-moncaster-tcpm-rcv-cheat which uses CE randomly to verify that the receiver feedback is not cheating. You might be able to integrate that into the path traversal testing, although I accept that a deterministic pattern allows the remote peer to detect problems, whereas a random one doesn't. It suggests a generic ECN fall-back draft. It is hard to describe fall-back independent of any specific protocol. 2.6 Nit: s/remark/re-mark/ because remark means something different. A couple of months ago, we were discussing using timestamps on feedback, so that fewer ACKs could be sent without losing timing info. Are you planning to include that idea in this draft? That's it for now. Bob -------- Forwarded Message -------- Subject: Re: Re : Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Date: Sun, 25 Jun 2017 23:17:42 +0100 From: Bob Briscoe To: Ingemar Johansson S , tcpm@ietf.org CC: tcpm-chairs@ietf.org , marcelo bagnulo braun Ingemar, The draft already says this work shoul be transferable to SCTP. I might also add a note that it could also benefit QUIC, altho I'd like to see some detail before presuming this will work. Coincidentally, I just read your ECN in QUIC draft yesterday. And, also coincidentally, one of my main comments was going to be that it seems disappointing that it only "sends an ECN negotiation frame when connection setup is completed." Retransmission timeouts have to be conservative during connection set-up whatever the protocol. So the background level of congestion loss will then lead to unnecessarily protracted intermittent delays, which will particularly hit short QUIC flows. So I was going to suggest that you might be able to protect QUIC connection setup from random congestion loss by an approach similar to ECN++. I cannot guarantee that I will have time to write up the other comments from my review in time for you to use it before the IETF deadline (I am about to take a week off, returning on 3 Jul). But I will try to do a quick summary for the QUIC list now. Bob On 25/06/17 19:03, Ingemar Johansson S wrote: > Hi > > I support this work. > In addition, parts of the findings and recommendations in this TCP generalized ECN work may also be useful for the specification of the ECN support in QUIC, currently outlined in (https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt ). > > Regards > Ingemar Johansson > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------D985351030404B53F1E60F6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Ingemar,

As just promised (on tcpm - pasted below) here's a rushed write-up of the high order bits of my review of your draft-johansson-quic-ecn-03.
This is purely a list of my immediate reactions to sentences in the draft. I will need longer to think about the protocol as a whole, whether this is the best approach, whether there might be a better approach, and the open issues you list.

2.1
It would be useful to first describe how the protocol would work across a network without Byzantine middlebox behaviour and without hobbled operating systems that cannot access the ECN field of IP packets. Then separately describe fall-back in the face of various ECN failures separately.

Preferably, let's try to think of a way to support ECN on the very first QUIC connection setup datagrams (see comments pasted below about copying the techniques in draft-bagnulo-tcpm-generalized-ecn, which depends on draft-ietf-tcpm-accurate-ecn for this capability).

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).

2.1.1
The argument for sending an ECN negotiation frame in a packet on its own only only makes sense if loss is more likely for packets with a non-zero IP-ECN field. Therefore, this should not necessarily be a long-term requirement on the protocol.

Why always use CE to test traversal of the IP-ECN field? Setting the ECT codepoint that will be used throughout the connection also tests for zeroing the ECN field, without risking losing visibility of a CE marking introduced in the network.

Define "a failed challenge/response phase". Can't it fail for a half-connection, not necessarily for the whole connection?

2.1.2
The mode mechanism of RFC6679 needs to be described, not just referenced. Note that draft-ietf-tsvwg-ecn-experimentation intends to update RFC6679 in this respect (removing the use of the ECN nonce).

2.3
Nit: You assign the names E1 and E2 for the fields for the length of each encoding of ECT(0) and ECT(1). It would be less illogical if they were called E0 and E1.

The feedback gives the number of marked bytes. It needs to specify which headers are (not) included in the byte count. And if a datagram with zero bytes is ECN-marked, how do you propose to feed that back (in AccECN it feeds back marked packets and marked bytes)?

It says 1 octet overhead if ECN is not supported. Can't the ends send no ECN feedback at all if they have disabled ECN during the challenge response?

2.4
It suggests using a given pattern to detect the need for fall-back. That's a good idea. I think any particular connection should only need to include two IP-ECN codepoints in the pattern: the relevant ECT codepoint and CE.

You might also want to look at this expired I-D: draft-moncaster-tcpm-rcv-cheat which uses CE randomly to verify that the receiver feedback is not cheating. You might be able to integrate that into the path traversal testing, although I accept that a deterministic pattern allows the remote peer to detect problems, whereas a random one doesn't.

It suggests a generic ECN fall-back draft. It is hard to describe fall-back independent of any specific protocol.

2.6
Nit: s/remark/re-mark/ because remark means something different.


A couple of months ago, we were discussing using timestamps on feedback, so that fewer ACKs could be sent without losing timing info. Are you planning to include that idea in this draft?

That's it for now.



Bob


-------- Forwarded Message --------
Subject: Re: Re : Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04
Date: Sun, 25 Jun 2017 23:17:42 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, tcpm@ietf.org <tcpm@ietf.org>
CC: tcpm-chairs@ietf.org <tcpm-chairs@ietf.org>, marcelo bagnulo braun <marcelo@it.uc3m.es> 


Ingemar,

The draft already says this work shoul be transferable to SCTP. I might 
also add a note that it could also benefit QUIC, altho I'd like to see 
some detail before presuming this will work.

Coincidentally, I just read your ECN in QUIC draft yesterday. And, also 
coincidentally, one of my main comments was going to be that it seems 
disappointing that it only "sends an ECN negotiation frame when 
connection setup is completed." Retransmission timeouts have to be 
conservative during connection set-up whatever the protocol. So the 
background level of congestion loss will then lead to unnecessarily 
protracted intermittent delays, which will particularly hit short QUIC 
flows. So I was going to suggest that you might be able to protect QUIC 
connection setup from random congestion loss by an approach similar to 
ECN++.


I cannot guarantee that I will have time to write up the other comments 
from my review in time for you to use it before the IETF deadline (I am 
about to take a week off, returning on 3 Jul). But I will try to do a 
quick summary for the QUIC list now.



Bob

On 25/06/17 19:03, Ingemar Johansson S wrote:
> Hi
>
> I support this work.
> In addition, parts of the findings and recommendations in this TCP generalized ECN work may also be useful for the specification of the ECN support in QUIC, currently outlined in (https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt ).
>
> Regards
> Ingemar Johansson
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------D985351030404B53F1E60F6E-- From nobody Tue Jun 27 14:32: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 337511200C5 for ; Tue, 27 Jun 2017 14:32:02 -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 iAF7YZdTyMl4 for ; Tue, 27 Jun 2017 14:31:59 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 B7C99126CB6 for ; Tue, 27 Jun 2017 14:31:59 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id h134so25576855iof.2 for ; Tue, 27 Jun 2017 14:31:59 -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=vUvHu7ysGRa2bRdP1ubMcBSj9o9DoOErZXWNYe78x0c=; b=OuSLKFJuE9GWjFyXJ6WTUs0nFOqlI9q3tNn9FM4lcMnnOAl2mHlHtMKOKEgqqwk+bu x6IrgyJaHI7Jx3sJSse4c4CEM10B9n8ND+ermsLNk9/68e1H3YS2zp3bRhbYUD0h7xmF H+Oz5MS0zLyy5W9pPh2k6T3OLeL4smASY2wFhZpLZ7qdRif2f3BMVV5TRdu8uhdXLKLz XmM2RTdLK19S9W/ppFEUT3V1fj78hYr4lX8yIkM7hZNpjbbced6VDorZpPLm4BT4ONVI 8aEh5dxbPzCWdh8PqwZ9dpFt9MB65DkWtAsw9TmLjhPIR8YYaJjbNzZYrdvprNNxb9fZ C/bQ== 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=vUvHu7ysGRa2bRdP1ubMcBSj9o9DoOErZXWNYe78x0c=; b=bT1ybVFgNIxeOhRQL+RwGlSVhXHxtnYWgGOzBW/twWl59bcdtpLav1/3BuN153GZOX g4xONB89H8B7aXz2qIsnoElbfrNcZfJo0i33g4uB1VTg69T1XYmQmsur6OQNYxPzN10E 6s1rKr+2g9m8MwZnQumXztIObuibv86eEN6jAk1qvs5s7u1cpAOQ6YM6nZAuOQ33m9Ne RarIwlM/r7RYFksi8CU2vn6UobkBFcCF3GfiOxTPs5ABo82JeefcaX2fk4A6RnApzNSl 8L7i4PQ2l3kN0LIP14ard6id4QItzTfWWfIl+w3/PxMV+vc1ztnd/QCy2BxUo3Cw+S1l ETKg== X-Gm-Message-State: AKS2vOz2RWT0a5Kpf0PDmhs0+6faCGApLhUAYqiGS7bzBgxCE+PNvu/n cUP2sQyl7yywYJAKF9EBd+OD+YwB1Q== X-Received: by 10.107.138.81 with SMTP id m78mr8514868iod.60.1498599118722; Tue, 27 Jun 2017 14:31:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.125.132 with HTTP; Tue, 27 Jun 2017 14:31:38 -0700 (PDT) In-Reply-To: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> From: Ranjeeth Kumar Dasineni Date: Tue, 27 Jun 2017 14:31:38 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Christian Huitema Cc: quic@ietf.org Content-Type: multipart/alternative; boundary="001a113fe80821ddb70552f7ccf4" 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, 27 Jun 2017 21:32:02 -0000 --001a113fe80821ddb70552f7ccf4 Content-Type: text/plain; charset="UTF-8" This thread has gone quiet. So, I am voicing my concerns about Martin's proposal here to reiterate the importance of deployment experience, making things no simpler than necessary and to generally evoke a sense of urgency. Personal opinions, of course!! 1. We are the underplaying the importance of deployment experience. I am afraid that IETF-QUIC, after these changes, diverges quite far from the deployed G-QUIC. Far enough, to throw serious doubt on all assumptions about performance and deployability. It becomes effectively a brand new protocol designed not based on running code but what seems to be an obvious simplification of one layer, at the cost of complexity at another layer. Leaving the benefits of simplification aside, I am wary of standardizing things that have not been deployed anywhere. H2 push and priorities should serve as a lesson here where one could clearly articulate the benefits when designing them and yet it was extremely hard to realize those benefits in practice. Here, I have a hard time even articulating the benefits of a simple transport layer, speaking of which ... 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. Arguably, it's far simpler for an application to simulate/enforce unidirectionality when it needs. Not to mention there does not seem a deployed application or an immediate candidate that needs it. H2 Push is a special pony which is yet to be deployed widely and something that I would treat as an exception, not norm. Even with H2, where implementation of application level correlators seems simple enough, it raises the questions on ease of deployment (if proxies will get this right), debuggability (examining a single request + response is now harder) and the impact of bug (more prone to sending critical data to the wrong destination). The demonstrated success of G-QUIC and the first likely role for IETF-QUIC is as an approximately drop-in replacement for H2. I would like the focus to be on succeeding there first before attempting to build an overly generic transport protocol. Which leads me to ... 3. QUIC is not the last transport that will be built. Not to speak of future versions of QUIC itself. Part of the allure of moving transport to user space, to me, is the ability to iterate faster. The success of H2 and the wide interest in QUIC convinces me that protocols will evolve at a much faster rate going forward. And that there will be enough time and opportunities to experiment as more applications use QUIC and evolve a different set of needs. Such experiments and implementation experience should drive the changes, I believe. Having said that, some ideas in the PR (like the explicit type field in stream header and the push id) are not really tied to unidirectionality and I would like to see them absorbed into IETF-QUIC anyway. This is my first mail to the working group. My biggest motivation was to reiterate on the sense of urgency. Pardon me if I flouted any rules in the process. Cheers, Ranjeeth On Sat, Jun 24, 2017 at 12:15 PM, Christian Huitema wrote: > Nice discussion. Seeing this design by many PR, I am afraid we will meet > an old friend: https://en.wikipedia.org/wiki/Camel. > > -- > Christian Huitema > > --001a113fe80821ddb70552f7ccf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This t= hread has gone quiet. So, I am voicing my concerns about Martin's propo= sal here to reiterate the importance of deployment experience, making thing= s no simpler than necessary and to generally evoke a sense of urgency. Pers= onal opinions, of course!!=C2=A0

1. We are the underplaying the impo= rtance of deployment experience. I am afraid that IETF-QUIC, after these ch= anges, diverges quite far from the deployed G-QUIC. Far enough, to throw se= rious doubt on all assumptions about performance and deployability. It beco= mes effectively a brand new protocol designed not based on running code but= what seems to be an obvious simplification of one layer, at the cost of co= mplexity at another layer. Leaving the benefits of simplification aside, I = am wary of standardizing things that have not been deployed anywhere. H2 pu= sh and priorities should serve as a lesson here where one could clearly art= iculate the benefits when designing them and yet it was extremely hard to r= ealize those benefits in practice. Here, I have a hard time even articulati= ng the benefits of a simple transport layer, speaking of which ...

2. We are overplay= ing the simplicity of design. Even if we deem deployment experience not a c= oncern, if every application layer protocol that needs support for bidirect= ional streams has to implement some correlators and such above, that's = a net negative in terms of complexity. Arguably, it's far simpler for a= n application to simulate/enforce unidirectionality when it needs. Not to m= ention there does not seem a deployed application or an immediate candidate= that needs it. H2 Push is a special pony which is yet to be deployed widel= y and something that I would treat as an exception, not norm. Even with H2,= where implementation of application level correlators seems simple enough,= it raises the questions on ease of deployment (if proxies will get this ri= ght), debuggability (examining a single request + response is now harder) a= nd the impact of bug (more prone to sending critical data to the wrong dest= ination). The demonstrated success of G-QUIC and the first likely role for = IETF-QUIC is as an approximately drop-in replacement for H2. I would like t= he focus to be on succeeding there first before attempting to build an over= ly generic transport protocol. Which leads me to ...

3. QUIC is not = the last transport that will be built. Not to speak of future versions of Q= UIC itself. Part of the allure of moving transport to user space, to me, is= the ability to iterate faster. The success of H2 and the wide interest in = QUIC convinces me that protocols will evolve at a much faster rate going fo= rward. And that there will be enough time and opportunities to experiment a= s more applications use QUIC and evolve a different set of needs. Such expe= riments and implementation experience should drive the changes, I believe. = Having said that, some ideas in the PR (like the explicit type field in str= eam header and the push id) are not really tied to unidirectionality and I = would like to see them absorbed into IETF-QUIC anyway.

This is my first mail to the working group.= My biggest motivation was to reiterate on the sense of urgency. Pardon me = if I flouted any rules in the process.

Cheers,
Ranjeeth

On Sat, Jun 24, 2017 at 12:15 PM, Christian = Huitema <huitema@huitema.net> wrote:
Nice discussion. Seeing this design by many PR, I am afraid w= e will meet
an old friend: https://en.wikipedia.org/wiki/Camel.

--
Christian Huitema


--001a113fe80821ddb70552f7ccf4-- From nobody Wed Jun 28 00: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 4512D12EACE for ; Wed, 28 Jun 2017 00:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=pckFin4+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oxTE1inD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7FeIaZb-6Pn for ; Wed, 28 Jun 2017 00:07:22 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E048212EA98 for ; Wed, 28 Jun 2017 00:07:21 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 406BD2080C; Wed, 28 Jun 2017 03:07:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 28 Jun 2017 03:07:21 -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=UE1mRgWPXE5AQGcZgjllN3h4ZOxGERtcbW8Vbh5O5 x0=; b=pckFin4+jNgi/e/Vk+6fXgcCChhZTir4UBoWdS7B/9aGhlYklEjX3IDl/ qCzpaEKpIgkRKU1oiuVIEeM+m8HE3Gyz4MRKmUfm/swHYh0k2HjBzZg1b4B5PdNq mSYfHR/yVSn70pO31aT73MCQfN0YIDbhjaAWzGwFzyOq9dVpv1I2dZ8zYvj9ie1a fFUW347EnsJk0jQ6WsxR0cxEN8cT7gwlO1BhLL9x7cyZq4Fp9o+xzFX4ofa85uN4 2RijUrUigBA/iDUhqHQujIjCQvt6izMEQ+5zDHiF6BxBBOliiM+2mjCcVuIMvpkd 72vlb7WZGibEa1bm6FYNQobFH7gYg== 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=UE1mRgWPXE5AQGcZgj llN3h4ZOxGERtcbW8Vbh5O5x0=; b=oxTE1inDwbiFHVRzXy8TXufE5PB8IGOwGK ALj/9HVlou7FfTNbg4kXIe6hCHxXWOwzLYVC5/d+xzrpveY+Fq194rh6ck0CFYQV NM0BhYJxEvnG1q7Cp2wzDPyL3GYPo/cbihPIJqsYCjHhafkUzBx08MxieZ341PJX jE4Nhgif+4DUluD113HLfSyzaeV8yCAP9Swc3mCB/dIJWP9nSNt9/D6cV21grL9g roTevPj1OdkHq1daAaz2qSdX9lZkvEGodsrxXoD7we43zdG295OSnLfr4sIC9jgf /ku7loMRwAmeJk/CFALqVOe2/BD3zce/BO21pBIVcPw2sYwO2afA== X-ME-Sender: X-Sasl-enc: ukDWKj8frLXVKl+x+pKLYop9nwTAzcJCXZX3M2z8dNoi 1498633640 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 06EBA7E4AA; Wed, 28 Jun 2017 03:07:19 -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: QUIC meetings in the US Message-Id: <93099A18-1036-452B-A233-7DD767943E1E@mnot.net> Date: Wed, 28 Jun 2017 17:07:15 +1000 Cc: Lars Eggert , Spencer Dawkins at IETF 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, 28 Jun 2017 07:07:25 -0000 [ Co-chair hat on ] Everyone, You may have seen reports that someone who participates in this work was = recently refused entry to the US*, for unspecified reasons. Anecdotally, we've heard of an increasing number of cases of = non-resident aliens being refused entry to the US because they are = perceived to be "working" there. We are not immigration lawyers, but it = appears that "work" is not well-defined in this context, and what = definition there is may not be evenly applied. "Business meetings" are = explicitly allowed under non-working visas to the US, but there is often = a blurry line between "work" and "meetings." Due to the nature of what we do, this might affect standards = participants more than others. After some discussion amongst the chairs = and with our responsible AD, we've decided that: 1) The planned interim meeting in Seattle will go ahead; changing the = location is likely to be more disruptive than leaving it in place. We've = been in touch with the participant mentioned above, who says they did = not intend on travelling to the US for the Seattle interim. 2) We won't hold any further interim meetings in the US, until there's a = change in this situation. This means that we'll either need to find = suitable hosts in Canada or Mexico, or our meeting rotation will need to = change to be exclusively Europe and Asia. There isn't a perfect solution to this problem; every country has = immigration requirements, and we've heard from some participants that = they have trouble *leaving* the US, due to constraints on their = immigration status there. While the uncertainty regarding the "travel = ban" and its status as it winds its way through the US court system is a = concern, the situation cited above is more relevant to the current = participants in our work. Finally - remember that the IETF needs data about immigration/border = problems. If you have issues obtaining a visa, entering a country, or = otherwise are unable to participate in a meeting due to a host country's = immigration policies or actions, please get in touch with IETF = leadership. If it's regarding a QUIC Interim meeting, your first point = of contact should be Lars and/or I. Cheers, * Technically - they were told that the US did not allow them to travel = on an ESTA before boarding. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jun 28 05:42:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA9F129A96 for ; Wed, 28 Jun 2017 05:42:32 -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 5EvYgfjXjd9c for ; Wed, 28 Jun 2017 05:42:31 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 37FA61242F5 for ; Wed, 28 Jun 2017 05:42:31 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id 16so49390115qkg.2 for ; Wed, 28 Jun 2017 05:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Kr8uSQcxlJEvjfKKj2lWo+fsCY9TIpyP3Qac05zttpQ=; b=g+bkSLw2Mnjx9m3Sk0NteSQQYGDB2yC1kW53psQqKnWdqAX3p98gNbyLiGXWWkMHHp TMY2bweGDZ3rxuCBs+uLDi4X6itkkmsBRPbJXHPPcZkDNDoUTm7pqLcH4Nrrh+KR5Rzk jw7ONksAIy+yyEEFzbsZQedqg5Akm4xCIJ8aWDWtbqGZqzIjIeEET9C5CiBFh8fB4gFR T9bo/3k/KKvdExE2pv4d+vjjg1c1kFdpY0f0x7vD8PDeDjDXq5FiFOq4y0Os3tawELZg rWN8IsWv4lBw6yBjAMcJMKurzcgOjhLAsPZMxIE8QPd0cvMN4BMbSjSuRMYQfjEY0qy8 3qOw== 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=Kr8uSQcxlJEvjfKKj2lWo+fsCY9TIpyP3Qac05zttpQ=; b=NNj9BXh6CR8x+H/KCn6o2o+ykMD9nIbUZYXDV4KXn8VfwhSPbrNpdM+HDlzm4E34U7 ZP06j2IG4tYjhOLw/Eq7+AQXqPGUGXzTto3c14i856+4FGJhQ3tIFnLA0mG6F3NMWIm2 QXJdLbR0K6Gkm/k82k6j1jf0YuehW1w84/jVBJ43a5KqTR1tRf4hAPxGW/exXE0SBcNQ 7pNmzyt3nluuRWfyYM7Ax5I6R/WygpZFc/u5STpch3gRwDCUpdDz6cwSIEimZOrA7gpa DQGEZE7qGhfSRp+JJ65yR/8qkRCkvfmQtzmYbjL+EnaRrP5oOM6ptW5XswLF3qJHq01v i2sw== X-Gm-Message-State: AKS2vOwKkOQ1ritJUTUc+rFZCblXzHXcqKNRMaSB6Wj6h0SwmD7Yjmdn CvE0N9E7llK+HL8yBcw= X-Received: by 10.55.192.197 with SMTP id v66mr11994559qkv.175.1498653750154; Wed, 28 Jun 2017 05:42:30 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id l32sm1650647qkh.15.2017.06.28.05.42.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 05:42:29 -0700 (PDT) Date: Wed, 28 Jun 2017 08:42:21 -0400 From: Dmitri Tikhonov To: quic@ietf.org Subject: Re: Unidirectional streams PR Message-ID: <20170628124221.GA15608@ubuntu-dmitri> References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> 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: Wed, 28 Jun 2017 12:42:33 -0000 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. From nobody Wed Jun 28 06:41: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 658F6129482 for ; Wed, 28 Jun 2017 06:41:40 -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, 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 g5CMBN4kpCVq for ; Wed, 28 Jun 2017 06:41:37 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 350BD129B04 for ; Wed, 28 Jun 2017 06:41:36 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id r125so33131181vkf.1 for ; Wed, 28 Jun 2017 06:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=++CkosIL5ZD5u5gbftZYBGVBLAk4ZEtvyIphwhSUSH8=; b=YIwpPbsvcRFe+ScT15Yr1VNeBkFbWTxIBin9T4FtskTjR3yGfYs+PG48gOKRj08Mh8 orlevn773/DWd8Z4mgjh8t0TQm+RyKOXF907i4ILuHrOpBqrBa4AMlXs6eVEEOuw1HLL k+42A8ibVpoRe6z1+r4xRWBH9CL6xvUMzCcGWqFx6Uz1STtwhirg/uI2sJvNA4/JT284 XLiEmn4qGmWkEpQzthU+JjSzoqCdgkv+yDrEw17ZBLRRbCfT0I7IwLMTBzktvoVN/UWS YH42wRQ9OHYS4v/FdtPQdpLEfT5Lmo08zQO+3WrGSftBjnl/HFdHKLekMLRSvMtrcqVV Dvcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=++CkosIL5ZD5u5gbftZYBGVBLAk4ZEtvyIphwhSUSH8=; b=ppxgREM8MTUq9KUberV4W4nF9wrQAOKN6muOVxm00wBAFbK3YCpGwpOKOwpF2Eavv1 hNN1rEh+YM5T10mGqz1m/zQIadEzgVno2ZJtNVY/Vd880FWE0g+u2qChO/6L74nhp9p1 qzYEFUMwbLJ0C/gairs83KoxRb+k014CIqQCtvlRnP+gwlqcsqdFAJ63jHfgTq+ylusi GQ10aMazWe7TTrMk0y21FBTwSR5/67sFgbMv2jFgSclrDJCruZ7u2l6yyMqagY/O4m8U gj4mpc27f73eNGK1MYxIWFLeif/AQsGddDRNFBHBETu4lAcvsuReFPHehEi1A/ww1MG5 1gEg== X-Gm-Message-State: AKS2vOzF2Xb2BL5vxTZeMX7+pV7OIQYFXTXYcrlRXHaWN3vchKbSlTYY JJuX10jvFw+wz0124UvTL8uRQlNuGv7P X-Received: by 10.31.41.213 with SMTP id p204mr5185763vkp.80.1498657295080; Wed, 28 Jun 2017 06:41:35 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Jun 2017 09:41:34 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20170628124221.GA15608@ubuntu-dmitri> References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 28 Jun 2017 09:41:34 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: quic@ietf.org, Dmitri Tikhonov Content-Type: multipart/alternative; boundary="001a113f042cb6a39705530557d3" 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, 28 Jun 2017 13:41:40 -0000 --001a113f042cb6a39705530557d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 standar= d 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=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. --001a113f042cb6a39705530557d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
In reply to=C2=A0Ranjeeth

It is not only a matter= of simplicity for the sake of simplicity:

- A complex transport layer might end up being poorl= y 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 util= isation 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 strea= ms with same identifiers, e.g. in a RPC scenario. That said, I do see a pot= ential benefit of a wrapper that implements the common bi-directional case.=

- Complexity at the = application layer may be duplicated, but implementation errors are also iso= lated to that application. Specifically for HTTP I would assume that QUIC t= ransport 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 concer= ning.

- Unix pipes ar= e traditionally constructed as a pair of uni-directional file descriptors a= nd that is a reasonably proven model. C=E2=80=99s standard library stdin, s= tdout 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 conn= ectivity - Kafka high volume message queuing for example. The industry tren= d 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 / RE= ST RPC replacement.

-= Uni-directional streams may currently be unproven in the wild, but a propo= sal 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 i= s very necessary so it makes sense to have QUIC being sufficiently simple a= nd expressive 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 num= ber of application protocols.

- Finally, it may turn o= ut that uni-directional streams just is a bad idea - I doubt it, but I do b= elieve 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:

<= /div>
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 de= ployment
> experience not a concern, if every application layer protocol that= needs
> support for bidirectional streams has to implement some correlator= s 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.

--001a113f042cb6a39705530557d3-- From nobody Wed Jun 28 07:09:07 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 3E45412783A for ; Wed, 28 Jun 2017 07:09:05 -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 EqSAoajKjdVb for ; Wed, 28 Jun 2017 07:09:02 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78791126557 for ; Wed, 28 Jun 2017 07:09:02 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id j11so24769422ywa.2 for ; Wed, 28 Jun 2017 07:09:02 -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=iR3eSlPjIMWwP0eeiMsKMLWBp7L1/OAQnrsR3mVCYH4=; b=E252uThASMn+Xtd7wUPbyqs+IQNZl/Yxj980RZx9FQExA2KZbeRLfzZZIbu9/xXWJY RnCWc8hy50etLA6sfPksT8ang6uVvIfNU2KoCgJeOeiaS8L5RMXehiF+rEhodsAv9jYj jkKJE2J/VODUdfotONbEJFqwz/EbeHioZiDt1PPZuQDfDoiXKE3zzjEJs1yNh3VGwzeN G3RPlHNdQNijgGXczmC3YGWgtFeyp9D1LxesI4+QNXLaPPx1ewABcgxyQWRGVFcYmETN ZL9JFeWAh779WcJPFA80/IRi3OcQvpnGlK7jdtCkWSpnTeodQE3MJc3y+dnMMUh3QpZ8 rKJA== 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=iR3eSlPjIMWwP0eeiMsKMLWBp7L1/OAQnrsR3mVCYH4=; b=KiuBxSUZBU5OOUL1nbX7SqDg0h54XdOLSR32PiATPZ+dRGoz0I7GllKxJtNLMC2Vdn Kt/aXm2HYKAFxqYkEn7xldIhk4fO7btpswyK8tsg0g6zsPaPBcpkbB8xaJBUHNS34p3y 3xd9yoWFnwBsh2/Cw61Y/gzpntaBnnR/jXVEhCQVDbznItEZsqy6RZJ07AfDOMdxOGu4 w+OS0z54biebTiLz/Fn2LZ+1OyTLIpbw47JXuD9Hww70XHYYcf2cLIWychsQ6AdOQXXL DTnMx/FJexzzhcNiCrXaSfCqRN68nNRa2q1g6OHZm/vUSbKUAUAjiptrr1SsYSVojIF0 JN1Q== X-Gm-Message-State: AKS2vOzx8LUc5pypO1kbQ9DAyGlm+71jqMy1ZBdOmQ/xar3QLYA9mdaz cpxpol2EPA9ntMCTNFBVJeNinxCRqcqR X-Received: by 10.129.146.15 with SMTP id j15mr7757089ywg.283.1498658941214; Wed, 28 Jun 2017 07:09:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.5.209 with HTTP; Wed, 28 Jun 2017 07:09:00 -0700 (PDT) In-Reply-To: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> From: Jo Kulik Date: Wed, 28 Jun 2017 10:09:00 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: QUIC WG , Dmitri Tikhonov Content-Type: multipart/alternative; boundary="94eb2c094216d52814055305b996" 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, 28 Jun 2017 14:09:05 -0000 --94eb2c094216d52814055305b996 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Protoc= ol) > 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 n= ot > 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 th= e > 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 stand= ard > library stdin, stdout and stderr is an example of an asymmetric model wit= h > 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 agr= ee > that it is easy to design into wrong assumptions without real world testi= ng. > > - 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 ide= a > - 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 need= s > > 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. > > --94eb2c094216d52814055305b996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to pop back up to a comment Igor made last we= ek, because I find it helpful in thinking about the design space:

<= /div>
I think of three layers of a= bstraction:
=C2=A0
1.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0QUIC Wire Protocol (the thing described by the QU= IC Transport RFC)
2.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0QUIC Library API (a library exposi= ng some useful abstractions -- such as blocking/non-blocking unidirectional= streams and bidirectional =E2=80=9Csockets=E2=80=9D -- and implementing th= em using QUIC Wire Protocol)
3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Application (something t= hat uses QUIC Library APIs)

I think there is some argument to be made that M= artin's original proposal did not take into account how we would achiev= e (2) for bi-directional streams. =C2=A0(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 ev= ery application, and this is not how g-quic (our largest deployment) works = right now.=C2=A0 These arguments make sense to me, but YMMV.

=
Just because the particular *mechanism* that is being proposed h= as some issues, however, doesn't scream out to me, at least, that we sh= ould abandon this particular *design goal*.=C2=A0 The goal being a transpor= t protocol that can elegantly fit with a uni/bi stream model.=C2=A0 Now, if= we conclude that there can never be an elegant model that achieves this go= al, then so be it.=C2=A0 But I also feel like we haven't reached that p= oint in the discussion yet. =C2=A0(At the very least, this discussion has b= een fruitful to me in terms of mapping the design space and elucidating req= uirements).

One of the reasons I still think this = design goal is under consideration is that Ian and Igor/Mike have been talk= ing about alternate solutions which have a similar flavor.=C2=A0 During the= recent "quiet"ness on the thread, personally, I've been wait= ing to hear more from them.

<= div class=3D"gmail_quote">On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahn=C3= =B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
In reply to= =C2=A0Ranjeeth

It is not only a ma= tter of simplicity for the sake of simplicity:

- A com= plex transport layer might end up being poorly implemented leading to reduc= ed interoperability and ultimately adoption. This complexity is not only in= implementation but also in understanding the exact semantics of stream lif= etime. Even if the spec is sufficiently clear, it will still be open to mis= interpretations.

- 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 r= esource utilisation because the transport layer has insufficient informatio= n.

- The extra complexity at the application layer may= be overstated - it is significantly simpler to manage a map that associate= s to two streams than it is to maintain bi-directional state at the transpo= rt layer. It is even possible to implicitly link streams with same identifi= ers, e.g. in a RPC scenario. That said, I do see a potential benefit of a w= rapper that implements the common bi-directional case.

- Complexity at the application layer may be duplicated, but implementatio= n errors are also isolated to that application. Specifically for HTTP I wou= ld 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 b= e particularly concerning.

- Unix pipes are traditiona= lly 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 st= derr 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 f= or example. The industry trend appears to move towards asynchronous process= ing and messaging. It depends on whether you look at QUIC as a TCP + TLS re= placement, or as a HTTPS / REST RPC replacement.

- Un= i-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. Wi= despread adaptation and compatibility is very necessary so it makes sense t= o 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.<= div>
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 de= ployment
> experience not a concern, if every application layer protocol that= needs
> support for bidirectional streams has to implement some correlator= s 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.


--94eb2c094216d52814055305b996-- From nobody Wed Jun 28 07:56: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 05314129AF1 for ; Wed, 28 Jun 2017 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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] 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 faH7kxqlskSh for ; Wed, 28 Jun 2017 07:56:21 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0093.outbound.protection.outlook.com [104.47.2.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9748A126DFF for ; Wed, 28 Jun 2017 07:56:20 -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=4yAkEUuJyMHpywxxhtN5vIQmXCm0uVpyG/gEXZUJaPc=; b=La0ouoHdvnQpYMd66wLk/bJDE3idkpEj6zSg2Q3SxSvG9yszpoZGukm3HT85eOBHlYNg8dnP9dBjrx0yBVFkGzzUpPvoDot3i/3Su6aBzLtNYByVBzQNABoz/ZD6VmM9qs86GTPmn+FoBwyY3/0ehofzzrm3ovEGrdtDqWNKbvU= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB1397.eurprd07.prod.outlook.com (10.166.4.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Wed, 28 Jun 2017 14:56:17 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::c44f:b7d8:722a:538a]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::c44f:b7d8:722a:538a%14]) with mapi id 15.01.1220.014; Wed, 28 Jun 2017 14:56:17 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Jo Kulik , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: QUIC WG , Dmitri Tikhonov Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qvWj8C/nfKUa6AZIv8lA1caI0Yv6AgATdKACAAP5zgIAAEIwAgAAHqgCAAAHpIA== Date: Wed, 28 Jun 2017 14:56:17 +0000 Message-ID: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@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: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB1397; 7:O3kodsCGGCysDYnisf/bjlMZ2SlaxecQASDptDjYndSihvV++QFhl5Yp4fLDCAKD4yzmfniJtPXNCOn1ebYRbMjZ1uJufz4Bfu10nCFWRwQH0TdGm1uncyKgi6GMu2LwvuugU2wWktoPNKyx6fP8bijHDZxzMLkiPLWoHZlKlGsYZPYodxTsQwGOArUSlgTRDGrl2UMoIevDKSI3orIDtj+OV2tAgUiDjd5tQRA5Gn/kbwOsy0LMaATH/17vUSpx91AuEBOQzq1C5OxhuLPLC4R5JoxA6I6C8/psv6pGuir2yZRw321g2rOlWB/oYOwSZqI8IKqmMuJPVD69Kij5nx4K9UQnX/DOX7Xgp0gpKMlGSSxDKuOj96R2+kuUeMrpbD12QVjbfQUdryP2szU4k78PmFPvfc/sizdPZtuIBi2qNWISwrHWgvzyZh9YqYTHcUcWRlUxmfIOCq6CFdYVjjN4NtaOU7boqCfRDU5wsPioJ4iSRtPEswcra+AHsa+ZTSN9GF7aqMMA9mbMJYJ8Xrm0apmC4e53GE7Mb6vyAKWVnY/a4Mt9cW6SjSMMv6H/f8oD7ZU9cWLkJeII2ctaH0nwMyvOzWqnKDRc41/MNX5bzbUWFcegzMW2ELCuCCT32Nluabsyn8HTFMd6RrXVqj79g13QfwBDAAMpoaTmeXkOcx7jRXNo0t637rGVLjXXhlGkH0a2qfLPy7eiGLWHRMXoO26zsKYmXJJMNYxAEqG2UclEky0+g+UtbouJfzw7Muox8OqI6LFtN4TVe5WtVEfGI4Z/pcmGz+aE3cC/oIw= x-ms-office365-filtering-correlation-id: fe97f8bc-ad74-4c2e-ec92-08d4be35d4d9 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)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB1397; x-ms-traffictypediagnostic: DB5PR07MB1397: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(158342451672863)(133145235818549)(278428928389397)(26388249023172)(236129657087228)(192374486261705)(148574349560750)(21748063052155)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1397; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1397; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39860400002)(39850400002)(39840400002)(39450400003)(24454002)(377454003)(6246003)(6436002)(54356999)(102836003)(790700001)(50986999)(3846002)(76176999)(6116002)(53936002)(6506006)(229853002)(93886004)(2950100002)(38730400002)(5250100002)(4326008)(7736002)(5660300001)(7116003)(236005)(54906002)(55016002)(99286003)(9686003)(6306002)(25786009)(53546010)(7696004)(478600001)(2900100001)(74316002)(33656002)(39060400002)(86362001)(54896002)(561944003)(2906002)(66066001)(3280700002)(81166006)(3660700001)(8936002)(189998001)(3480700004)(8676002)(81156014)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1397; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB123748F2AB7374DAC0CC9E1484DD0DB5PR07MB1237eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 14:56:17.7021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1397 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, 28 Jun 2017 14:56:25 -0000 --_000_DB5PR07MB123748F2AB7374DAC0CC9E1484DD0DB5PR07MB1237eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IGxvb2tpbmcgYXQgdGhlIGxheWVycyBvZiBhYnN0cmFjdGlvbiBpcyB1c2Vm dWwuIEluIHByaW5jaXBsZSBoYXZpbmcgdGhlIHdpcmUgcHJvdG9jb2wganVzdCBoYXZlIGNvbnN0 cnVjdHMgZm9yIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgZG9lcyBub3QgaW4gaXRzZWxmIGxpbWl0 IGNyZWF0aW5nIGJpLWRpcmVjdGlvbmFsIGNvbW11bmljYXRpb24gZmxvd3MsIHN1cHBvcnRlZCBh dCBlaXRoZXIgdGhlIGxpYnJhcnkgb3IgYXBwbGljYXRpb24gbGF5ZXIuDQoNCkhvd2V2ZXIsIHRo ZXJlIG5lZWQgdG8gYmUgYSBzdGFuZGFyZCB3YXkgb2YgZG9pbmcgYmktZGlyZWN0aW9uYWwgY29t bXVuaWNhdGlvbiBmb3IgbWlncmF0aW5nIGFwcGxpY2F0aW9ucyBpbXBsZW1lbnRlZCB1c2luZyBh IHNvY2tldCBzdHlsZSBhcGkuIEl0IG5lZWRzIHRvIGJlIGVhc3kgdG8gbW92ZSBhbiBleGlzdGlu ZyBhcHBsaWNhdGlvbiBmcm9tIFRDUCB0byBRVUlDLiBUaGlzIG1vdmUgbWF5IGJlIGF0dHJhY3Rp dmUgaW4gbWFueSBzaXR1YXRpb25zIGFzIFFVSUMgZ2l2ZXMgaW1wcm92ZWQgc2VjdXJpdHkgYW5k IG1heSBhbGxvdyBncmVhdGVyIHRocm91Z2hwdXQgZHVlIHRvIHRoZSBtb3JlIG1vZGVybiAoYW5k IGN1c3RvbWl6YWJsZSkgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobXMgY29tcGFyZWQgdG8g dGhlIE9TIFRDUCBzdGFjay4NCg0KRm9yIG1pZ3JhdGluZyBzdGFuZGFyZCBzb2NrZXQgYXBpIGFw cGxpY2F0aW9ucyBJIGRvbuKAmXQgdGhpbmsgaXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gbGVh dmUgdGhlIHdvcmsgdG8gdGhlIGFwcGxpY2F0aW9uIHRvIGRvIGNvcnJlbGF0aW9uLCBhdCBsZWFz dCB0aGUgbGlicmFyeSBzaG91bGQgYmUgcHJvdmlkaW5nIHRoaXMgc2VydmljZSB1c2luZyB0aGUg d2lyZSBwcm90b2NvbCBhcyBhcHByb3ByaWF0ZS4gQ2xlYXJseSB3ZSB3YW50IGEgY2xpZW50IHdy aXR0ZW4gd2l0aCBvbmUgbGlicmFyeSB0byBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHN1Y2Nlc3Nm dWxseSB3aXRoIGEgc2VydmVyIHdyaXR0ZW4gdXNpbmcgYSBkaWZmZXJlbnQgbGlicmFyeS4gVGhp cyBuZWVkcyBzb21lIGZvcm0gb2Ygc3RhbmRhcmRpemF0aW9uIG9mIHRoZSBzaWduYWxsaW5nLiBU aGlzIGNvdWxkIGVpdGhlciBiZSBhIGJ1aWxkaW5nIGJsb2NrIG92ZXJsYXkgb24gdG9wIG9mIFFV SUMsIG9yIGltcGxlbWVudGVkIGF0IHRoZSB3aXJlIHByb3RvY29sIGxldmVsLg0KDQpJbiB0ZXJt cyBvZiBwYXR0ZXJucyBJIHRoaW5rIHRoZSBmb2xsb3dpbmcgbWF5IGJlIHNvbWUgb2YgdGhlIG1v c3QgY29tbW9uIHBhdHRlcm5zICh3aXRoIHBvdGVudGlhbCB0byBiZSBwcm92aWRlZCBhdCB0aGUg bGlicmFyeSBhbmQgb3Igd2lyZSBwcm90b2NvbCBsZXZlbCkuDQpJL08gcGF0dGVybiAgOiBFeGFt cGxlDQoxLzAgICA6IEFuIGlucHV0IG9ubHkgZmxvdywgcGVyaGFwcyBhIGRhdGEgbG9nZ2VyIGxp a2Ugc3lzbG9nIHdpdGggbm8gY29uZmlybWF0aW9uL2ZlZWRiYWNrDQowLzEgIDogYW4gb3V0cHV0 IG9ubHkgZmxvdywgcGVyaGFwcyBhIHRvcGljIG1lc3NhZ2UgYnVzIHNlcnZpY2Ugd2l0aCBubyBj b25maXJtYXRpb24vZmVlZGJhY2sNCjEvMSA6IHN0YW5kYXJkIFRDUCBhcHBsaWNhdGlvbnMgd2l0 aCBhIHNpbmdsZSBmbG93IHBlciBjb25uZWN0aW9uDQoxLyogOiBzaW5nbGUgaW5wdXQsIG1hbnkg b3V0cHV0LCBtb2RlbGxpbmcgU1RESU4vU1RET1VUK1NUREVSUg0KKDEvMSkqIDogbXVsdGlwbGV4 ZWQgcGFpcnMgb2YgZmxvd3Mg4oCTIHN1cHBvcnRpbmcgbXVsdGlwbGUgc29ja2V0cyBtdXhlZCBv bnRvIGEgc2luZ2xlIFFVSUMgY29ubmVjdGlvbg0KDQpPYnZpb3VzbHksIGFuIGFwcGxpY2F0aW9u IHdvdWxkIGFsd2F5cyBoYXZlIHRoZSBvcHRpb24gdG8gY29tYmluZSBhbnkgc2luZ2xlIGRpcmVj dGlvbiBmbG93cyB3aXRoIGFwcGxpY2F0aW9uIGxldmVsIGNvcnJlbGF0b3JzIHRvIGNvbnN0cnVj dCBtb3JlIGNvbXBsZXggZmxvd3MgaWYgZGVzaXJlZC4NCg0KQXQgdGhlIG1vbWVudCBteSBndXQg c2F5cyB0aGUgMS8xIHVzZS1jYXNlIGlzIGNvbW1vbiBlbm91Z2ggdGhhdCB0aGUgd2lyZSBwcm90 b2NvbCBzaG91bGQgcHJvdmlkZSBhIHN0YW5kYXJkIG1lY2hhbmlzbSB0byBzdXBwb3J0IGl0IGFz IGEgc3RhbmRhcmQgb3ZlcmxheSB3b3VsZCBwcm9iYWJseSBlbmQgdXAgYmVpbmcgdHJlYXRlZCBh cyBwYXJ0IG9mIHRoZSB3aXJlIGZvcm1hdCBhbnl3YXkuDQoNClBlcmhhcHMgc3RyZWFtcyBzaG91 bGQgYmUgZXhwbGljaXRseSBjcmVhdGVkIHdpdGggYSBDUkVBVEVfU1RSRUFNIGZyYW1lIHdoaWNo IHdvdWxkIGJlIGNhcGFibGUgb2YgZGVmaW5pbmcgbXVsdGlwbGUgcmVsYXRlZCBzdHJlYW1zPw0K VGhlcmUgaXMgdGhlIG9wdGlvbiBvZiB3aGV0aGVyIG9ubHkgKDEvMSkgcGFpcnMgY2FuIGJlIGNy ZWF0ZWQgdGhpcyB3YXksIG9yICgxL24pIGNvbWJpbmF0aW9ucyBjb3VsZCBiZSBzdXBwb3J0ZWQg KHdpdGggYW4gYXBwbGljYXRpb24gZGVmaW5lZCB3YXkgdG8gaWRlbnRpZnkgdGhlIHVzZSBvZiBl YWNoIG9mIHRoZSBvdXRwdXQgc3RyZWFtcykuIEEgc3RlcCBmdXJ0aGVyIG1heSBiZSB0aGF0IHRo ZXJlIGlzIGEgdHJhbnNwb3J0IHBhcmFtZXRlciB0aGF0IGRlZmluZXMgd2hldGhlciB0aGUgc2Vy dmVyIGlzIGFsbG93ZWQgdG8gY3JlYXRlIGFkZGl0aW9uYWwgc3RyZWFtcywgb3IgaWYgc3RyZWFt IGNyZWF0aW9uIGlzIHB1cmVseSBjbGllbnQgZHJpdmVuIChsaWtlIFRDUCkuIEkgZG9u4oCZdCBr bm93IGlmIGVpdGhlciBvZiB0aGVzZSB3b3VsZCBzaW1wbGlmeSBob3cgdG8gaGFuZGxlIHN0cmVh bSBhY2NvdW50aW5nLCBhbmQgaW4gcGFydGljdWxhciBvbmx5IGNyZWF0aW5nIGEgZmxvdyB3aGVu IGFsbCBwYXJ0aWVzIGhhdmUgc3VmZmljaWVudCBhbGxvd2FuY2VzIGxlZnQuDQoNClRob21hcw0K DQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg Sm8gS3VsaWsNClNlbnQ6IDI4IEp1bmUgMjAxNyAxNTowOQ0KVG86IE1pa2tlbCBGYWhuw7hlIErD uHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCkNjOiBRVUlDIFdHIDxxdWljQGlldGYub3Jn PjsgRG1pdHJpIFRpa2hvbm92IDxkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+DQpTdWJqZWN0 OiBSZTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQpJJ2QgbGlrZSB0byBwb3AgYmFjayB1 cCB0byBhIGNvbW1lbnQgSWdvciBtYWRlIGxhc3Qgd2VlaywgYmVjYXVzZSBJIGZpbmQgaXQgaGVs cGZ1bCBpbiB0aGlua2luZyBhYm91dCB0aGUgZGVzaWduIHNwYWNlOg0KDQpJIHRoaW5rIG9mIHRo cmVlIGxheWVycyBvZiBhYnN0cmFjdGlvbjoNCg0KMS4gICAgICAgUVVJQyBXaXJlIFByb3RvY29s ICh0aGUgdGhpbmcgZGVzY3JpYmVkIGJ5IHRoZSBRVUlDIFRyYW5zcG9ydCBSRkMpDQoyLiAgICAg ICBRVUlDIExpYnJhcnkgQVBJIChhIGxpYnJhcnkgZXhwb3Npbmcgc29tZSB1c2VmdWwgYWJzdHJh Y3Rpb25zIC0tIHN1Y2ggYXMgYmxvY2tpbmcvbm9uLWJsb2NraW5nIHVuaWRpcmVjdGlvbmFsIHN0 cmVhbXMgYW5kIGJpZGlyZWN0aW9uYWwg4oCcc29ja2V0c+KAnSAtLSBhbmQgaW1wbGVtZW50aW5n IHRoZW0gdXNpbmcgUVVJQyBXaXJlIFByb3RvY29sKQ0KMy4gICAgICAgQXBwbGljYXRpb24gKHNv bWV0aGluZyB0aGF0IHVzZXMgUVVJQyBMaWJyYXJ5IEFQSXMpDQpJIHRoaW5rIHRoZXJlIGlzIHNv bWUgYXJndW1lbnQgdG8gYmUgbWFkZSB0aGF0IE1hcnRpbidzIG9yaWdpbmFsIHByb3Bvc2FsIGRp ZCBub3QgdGFrZSBpbnRvIGFjY291bnQgaG93IHdlIHdvdWxkIGFjaGlldmUgKDIpIGZvciBiaS1k aXJlY3Rpb25hbCBzdHJlYW1zLiAgKEkgZG9uJ3QgdGhpbmsgaXQgc3RyaWN0bHkgc2FpZCAidGhv dSBzaGFsdCBub3QgZG8gKDIpIiBlaXRoZXIsIGJ1dCB0aGF0IGlzIHVwIHRvIGludGVycHJldGF0 aW9uLikNCg0KU2V2ZXJhbCBwZW9wbGUgaGF2ZSBhcmd1ZWQgdGhhdCB3ZSBkbyBub3Qgd2FudCBl dmVyeSBhcHBsaWNhdGlvbiB0byBoYXZlIHRvIHJlLWltcGxlbWVudCBiaS1kaXJlY3Rpb25hbCBz dHJlYW1zICgzKSBmb3IgZXZlcnkgYXBwbGljYXRpb24sIGFuZCB0aGlzIGlzIG5vdCBob3cgZy1x dWljIChvdXIgbGFyZ2VzdCBkZXBsb3ltZW50KSB3b3JrcyByaWdodCBub3cuICBUaGVzZSBhcmd1 bWVudHMgbWFrZSBzZW5zZSB0byBtZSwgYnV0IFlNTVYuDQoNCkp1c3QgYmVjYXVzZSB0aGUgcGFy dGljdWxhciAqbWVjaGFuaXNtKiB0aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGhhcyBzb21lIGlzc3Vl cywgaG93ZXZlciwgZG9lc24ndCBzY3JlYW0gb3V0IHRvIG1lLCBhdCBsZWFzdCwgdGhhdCB3ZSBz aG91bGQgYWJhbmRvbiB0aGlzIHBhcnRpY3VsYXIgKmRlc2lnbiBnb2FsKi4gIFRoZSBnb2FsIGJl aW5nIGEgdHJhbnNwb3J0IHByb3RvY29sIHRoYXQgY2FuIGVsZWdhbnRseSBmaXQgd2l0aCBhIHVu aS9iaSBzdHJlYW0gbW9kZWwuICBOb3csIGlmIHdlIGNvbmNsdWRlIHRoYXQgdGhlcmUgY2FuIG5l dmVyIGJlIGFuIGVsZWdhbnQgbW9kZWwgdGhhdCBhY2hpZXZlcyB0aGlzIGdvYWwsIHRoZW4gc28g YmUgaXQuICBCdXQgSSBhbHNvIGZlZWwgbGlrZSB3ZSBoYXZlbid0IHJlYWNoZWQgdGhhdCBwb2lu dCBpbiB0aGUgZGlzY3Vzc2lvbiB5ZXQuICAoQXQgdGhlIHZlcnkgbGVhc3QsIHRoaXMgZGlzY3Vz c2lvbiBoYXMgYmVlbiBmcnVpdGZ1bCB0byBtZSBpbiB0ZXJtcyBvZiBtYXBwaW5nIHRoZSBkZXNp Z24gc3BhY2UgYW5kIGVsdWNpZGF0aW5nIHJlcXVpcmVtZW50cykuDQoNCk9uZSBvZiB0aGUgcmVh c29ucyBJIHN0aWxsIHRoaW5rIHRoaXMgZGVzaWduIGdvYWwgaXMgdW5kZXIgY29uc2lkZXJhdGlv biBpcyB0aGF0IElhbiBhbmQgSWdvci9NaWtlIGhhdmUgYmVlbiB0YWxraW5nIGFib3V0IGFsdGVy bmF0ZSBzb2x1dGlvbnMgd2hpY2ggaGF2ZSBhIHNpbWlsYXIgZmxhdm9yLiAgRHVyaW5nIHRoZSBy ZWNlbnQgInF1aWV0Im5lc3Mgb24gdGhlIHRocmVhZCwgcGVyc29uYWxseSwgSSd2ZSBiZWVuIHdh aXRpbmcgdG8gaGVhciBtb3JlIGZyb20gdGhlbS4NCg0KT24gV2VkLCBKdW4gMjgsIDIwMTcgYXQg OTo0MSBBTSwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1h aWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiB3cm90ZToNCkluIHJlcGx5IHRvIFJhbmplZXRoDQoN Ckl0IGlzIG5vdCBvbmx5IGEgbWF0dGVyIG9mIHNpbXBsaWNpdHkgZm9yIHRoZSBzYWtlIG9mIHNp bXBsaWNpdHk6DQoNCi0gQSBjb21wbGV4IHRyYW5zcG9ydCBsYXllciBtaWdodCBlbmQgdXAgYmVp bmcgcG9vcmx5IGltcGxlbWVudGVkIGxlYWRpbmcgdG8gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5 IGFuZCB1bHRpbWF0ZWx5IGFkb3B0aW9uLiBUaGlzIGNvbXBsZXhpdHkgaXMgbm90IG9ubHkgaW4g aW1wbGVtZW50YXRpb24gYnV0IGFsc28gaW4gdW5kZXJzdGFuZGluZyB0aGUgZXhhY3Qgc2VtYW50 aWNzIG9mIHN0cmVhbSBsaWZldGltZS4gRXZlbiBpZiB0aGUgc3BlYyBpcyBzdWZmaWNpZW50bHkg Y2xlYXIsIGl0IHdpbGwgc3RpbGwgYmUgb3BlbiB0byBtaXNpbnRlcnByZXRhdGlvbnMuDQoNCi0g QmktZGlyZWN0aW9uYWwgc3RhdGUgbWF5IGhhdmUgdG8gYmUgbWFpbnRhaW5lZCBsb25nZXIgYW5k IHdpdGggbW9yZSBvdmVyaGVhZCB0aGFuIHdpdGggdW5pLWRpcmVjdGlvbmFsIHN0cmVhbXMsIGVz cGVjaWFsbHkgdW5kZXIgbG9zcywgcG90ZW50aWFsbHkgbGVhZGluZyB0byBwb29yIHBlcmZvcm1h bmNlIGFuZCBwb29yIHJlc291cmNlIHV0aWxpc2F0aW9uIGJlY2F1c2UgdGhlIHRyYW5zcG9ydCBs YXllciBoYXMgaW5zdWZmaWNpZW50IGluZm9ybWF0aW9uLg0KDQotIFRoZSBleHRyYSBjb21wbGV4 aXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBtYXkgYmUgb3ZlcnN0YXRlZCAtIGl0IGlzIHNp Z25pZmljYW50bHkgc2ltcGxlciB0byBtYW5hZ2UgYSBtYXAgdGhhdCBhc3NvY2lhdGVzIHRvIHR3 byBzdHJlYW1zIHRoYW4gaXQgaXMgdG8gbWFpbnRhaW4gYmktZGlyZWN0aW9uYWwgc3RhdGUgYXQg dGhlIHRyYW5zcG9ydCBsYXllci4gSXQgaXMgZXZlbiBwb3NzaWJsZSB0byBpbXBsaWNpdGx5IGxp bmsgc3RyZWFtcyB3aXRoIHNhbWUgaWRlbnRpZmllcnMsIGUuZy4gaW4gYSBSUEMgc2NlbmFyaW8u IFRoYXQgc2FpZCwgSSBkbyBzZWUgYSBwb3RlbnRpYWwgYmVuZWZpdCBvZiBhIHdyYXBwZXIgdGhh dCBpbXBsZW1lbnRzIHRoZSBjb21tb24gYmktZGlyZWN0aW9uYWwgY2FzZS4NCg0KLSBDb21wbGV4 aXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBtYXkgYmUgZHVwbGljYXRlZCwgYnV0IGltcGxl bWVudGF0aW9uIGVycm9ycyBhcmUgYWxzbyBpc29sYXRlZCB0byB0aGF0IGFwcGxpY2F0aW9uLiBT cGVjaWZpY2FsbHkgZm9yIEhUVFAgSSB3b3VsZCBhc3N1bWUgdGhhdCBRVUlDIHRyYW5zcG9ydCBh bmQgUVVJQyBIVFRQIGltcGxlbWVudGVycyB3b3VsZCBiZSBsYXJnZSB0aGUgc2FtZSBmb3IgYSBs b25nIHRpbWUgdG8gY29tZSwgc28gSSB3b3VsZCBub3QgZXhwZWN0IHRoZSB0cmFkZW9mZiBoZXJl IHRvIGJlIHBhcnRpY3VsYXJseSBjb25jZXJuaW5nLg0KDQotIFVuaXggcGlwZXMgYXJlIHRyYWRp dGlvbmFsbHkgY29uc3RydWN0ZWQgYXMgYSBwYWlyIG9mIHVuaS1kaXJlY3Rpb25hbCBmaWxlIGRl c2NyaXB0b3JzIGFuZCB0aGF0IGlzIGEgcmVhc29uYWJseSBwcm92ZW4gbW9kZWwuIEPigJlzIHN0 YW5kYXJkIGxpYnJhcnkgc3RkaW4sIHN0ZG91dCBhbmQgc3RkZXJyIGlzIGFuIGV4YW1wbGUgb2Yg YW4gYXN5bW1ldHJpYyBtb2RlbCB3aXRoIGltcGxpY2l0IGxpbmthZ2UgYmV0d2VlbiB1bmktZGly ZWN0aW9uYWwgZmlsZSBkZXNjcmlwdG9ycy4NCg0KLSBUaGVyZSBhcmUgbG90cyBvZiB1c2UgY2Fz ZXMgZm9yIG5vbi1IVFRQIGxpa2UgY29ubmVjdGl2aXR5IC0gS2Fma2EgaGlnaCB2b2x1bWUgbWVz c2FnZSBxdWV1aW5nIGZvciBleGFtcGxlLiBUaGUgaW5kdXN0cnkgdHJlbmQgYXBwZWFycyB0byBt b3ZlIHRvd2FyZHMgYXN5bmNocm9ub3VzIHByb2Nlc3NpbmcgYW5kIG1lc3NhZ2luZy4gSXQgZGVw ZW5kcyBvbiB3aGV0aGVyIHlvdSBsb29rIGF0IFFVSUMgYXMgYSBUQ1AgKyBUTFMgcmVwbGFjZW1l bnQsIG9yIGFzIGEgSFRUUFMgLyBSRVNUIFJQQyByZXBsYWNlbWVudC4NCg0KLSBVbmktZGlyZWN0 aW9uYWwgc3RyZWFtcyBtYXkgY3VycmVudGx5IGJlIHVucHJvdmVuIGluIHRoZSB3aWxkLCBidXQg YSBwcm9wb3NhbCBpcyBuZWVkZWQgYmVmb3JlIGFuIGltcGxlbWVudGF0aW9uIGNhbiBiZSBtYWRl IGFuZCB0ZXN0ZXQuIEkgYWdyZWUgdGhhdCBpdCBpcyBlYXN5IHRvIGRlc2lnbiBpbnRvIHdyb25n IGFzc3VtcHRpb25zIHdpdGhvdXQgcmVhbCB3b3JsZCB0ZXN0aW5nLg0KDQotIFRoZXJlIHdpbGwg aG9wZWZ1bGx5IG5vdCBiZSBhIGxhcmdlIG51bWJlciBvZiBzdWNjZXNzb3JzIHRvIFFVSUMgLSBw ZXJoYXBzIHNvbWUgcHVycG9zZSBzcGVjaWZpYyB2YXJpYW50cywgZS5nLiBmb3IgZW1iZWRkZWQg dXNlLiBXaWRlc3ByZWFkIGFkYXB0YXRpb24gYW5kIGNvbXBhdGliaWxpdHkgaXMgdmVyeSBuZWNl c3Nhcnkgc28gaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBRVUlDIGJlaW5nIHN1ZmZpY2llbnRseSBz aW1wbGUgYW5kIGV4cHJlc3NpdmUgdG8gYWNoaWV2ZSB0aGlzIGdvYWwuIEEgcG9seW1vcmYgUVVJ QyB3aWxsIG5vdCBhY2hpZXZlIHRoYXQgZ29hbC4gT24gdGhlIG90aGVyIGhhbmQsIGEgc29saWQg UVVJQyBmb3VuZGF0aW9uIGNhbiBiZSB1c2VkIGZvciBhIGxhcmdlIG51bWJlciBvZiBhcHBsaWNh dGlvbiBwcm90b2NvbHMuDQoNCi0gRmluYWxseSwgaXQgbWF5IHR1cm4gb3V0IHRoYXQgdW5pLWRp cmVjdGlvbmFsIHN0cmVhbXMganVzdCBpcyBhIGJhZCBpZGVhIC0gSSBkb3VidCBpdCwgYnV0IEkg ZG8gYmVsaWV2ZSByZWFsIHdvcmxkIHRlc3RzIGFyZSBuZWVkZWQuDQoNCktpbmQgUmVnYXJkcywN Ck1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiAyOCBKdW5lIDIwMTcgYXQgMTQuNDIu MzYsIERtaXRyaSBUaWtob25vdiAoZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29tPG1haWx0bzpk dGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+KSB3cm90ZToNCk9uIFR1ZSwgSnVuIDI3LCAyMDE3 IGF0IDAyOjMxOjM4UE0gLTA3MDAsIFJhbmplZXRoIEt1bWFyIERhc2luZW5pIHdyb3RlOg0KPiAy LiBXZSBhcmUgb3ZlcnBsYXlpbmcgdGhlIHNpbXBsaWNpdHkgb2YgZGVzaWduLiBFdmVuIGlmIHdl IGRlZW0gZGVwbG95bWVudA0KPiBleHBlcmllbmNlIG5vdCBhIGNvbmNlcm4sIGlmIGV2ZXJ5IGFw cGxpY2F0aW9uIGxheWVyIHByb3RvY29sIHRoYXQgbmVlZHMNCj4gc3VwcG9ydCBmb3IgYmlkaXJl Y3Rpb25hbCBzdHJlYW1zIGhhcyB0byBpbXBsZW1lbnQgc29tZSBjb3JyZWxhdG9ycyBhbmQNCj4g c3VjaCBhYm92ZSwgdGhhdCdzIGEgbmV0IG5lZ2F0aXZlIGluIHRlcm1zIG9mIGNvbXBsZXhpdHku DQoNClRoaXMgaXMgYW4gaW1wb3J0YW50IHBvaW50OiB3ZSB3YW50IFFVSUMgYWRvcHRpb24gdG8g YmUgbWFkZSBlYXN5Lg0KQSBwcm9ncmFtIHRoYXQgc3BlYWtzIEhUVFAgdG9kYXkgc2hvdWxkIGJl IGFibGUgdG8gdXNlIGFuIGV4aXN0aW5nIFFVSUMNCmxpYnJhcnkgd2l0aG91dCBoYXZpbmcgdG8g ZW11bGF0ZSBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgaW4gb3JkZXIgdG8gZml0DQppdCBpbnRvIEhU VFAgdXNhZ2UgcGF0dGVybi4gRm9yY2luZyBldmVyeSBvbmUgb2YgdGhlc2UgcHJvZ3JhbXMgdG8g ZG8NCnRoaXMgaXMgY2VydGFpbmx5IGEgaHVyZGxlLg0KDQotIERtaXRyaS4NCg0K --_000_DB5PR07MB123748F2AB7374DAC0CC9E1484DD0DB5PR07MB1237eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2 ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EgTmV1 ZSI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KcC5nbWFpbC1tNTQyMzU5ODA3NDcwNDM3OTgzMm02NDM1NzE3Mzg4ODUy NTU3MDU3bXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbTU0MjM1OTgwNzQ3MDQzNzk4MzJtNjQz NTcxNzM4ODg1MjU1NzA1N21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tNTQyMzU5ODA3NDcw NDM3OTgzMm02NDM1NzE3Mzg4ODUyNTU3MDU3bXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUt bmFtZTpnbWFpbC1tXzU0MjM1OTgwNzQ3MDQzNzk4MzJtXzY0MzU3MTczODg4NTI1NTcwNTdtc29s aXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K cC5tMTk5NTg0OTQ0NjMzNDYzNjA5OGFpcm1haWxvbiwgbGkubTE5OTU4NDk0NDYzMzQ2MzYwOThh aXJtYWlsb24sIGRpdi5tMTk5NTg0OTQ0NjMzNDYzNjA5OGFpcm1haWxvbg0KCXttc28tc3R5bGUt bmFtZTptXzE5OTU4NDk0NDYzMzQ2MzYwOThhaXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5JIGFncmVlIHRoYXQgbG9va2luZyBhdCB0aGUgbGF5ZXJzIG9mIGFic3RyYWN0aW9uIGlz IHVzZWZ1bC4gSW4gcHJpbmNpcGxlIGhhdmluZyB0aGUgd2lyZSBwcm90b2NvbCBqdXN0IGhhdmUg Y29uc3RydWN0cyBmb3IgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcw0KIGRvZXMgbm90IGluIGl0c2Vs ZiBsaW1pdCBjcmVhdGluZyBiaS1kaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uIGZsb3dzLCBzdXBw b3J0ZWQgYXQgZWl0aGVyIHRoZSBsaWJyYXJ5IG9yIGFwcGxpY2F0aW9uIGxheWVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5Ib3dldmVyLCB0aGVyZSBuZWVkIHRvIGJlIGEgc3RhbmRhcmQgd2F5IG9mIGRvaW5nIGJp LWRpcmVjdGlvbmFsIGNvbW11bmljYXRpb24gZm9yIG1pZ3JhdGluZyBhcHBsaWNhdGlvbnMgaW1w bGVtZW50ZWQgdXNpbmcgYSBzb2NrZXQgc3R5bGUgYXBpLiBJdA0KIG5lZWRzIHRvIGJlIGVhc3kg dG8gbW92ZSBhbiBleGlzdGluZyBhcHBsaWNhdGlvbiBmcm9tIFRDUCB0byBRVUlDLiBUaGlzIG1v dmUgbWF5IGJlIGF0dHJhY3RpdmUgaW4gbWFueSBzaXR1YXRpb25zIGFzIFFVSUMgZ2l2ZXMgaW1w cm92ZWQgc2VjdXJpdHkgYW5kIG1heSBhbGxvdyBncmVhdGVyIHRocm91Z2hwdXQgZHVlIHRvIHRo ZSBtb3JlIG1vZGVybiAoYW5kIGN1c3RvbWl6YWJsZSkgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29y aXRobXMgY29tcGFyZWQNCiB0byB0aGUgT1MgVENQIHN0YWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Gb3IgbWln cmF0aW5nIHN0YW5kYXJkIHNvY2tldCBhcGkgYXBwbGljYXRpb25zIEkgZG9u4oCZdCB0aGluayBp dCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBsZWF2ZSB0aGUgd29yayB0byB0aGUgYXBwbGljYXRp b24gdG8gZG8gY29ycmVsYXRpb24sIGF0IGxlYXN0DQogdGhlIGxpYnJhcnkgc2hvdWxkIGJlIHBy b3ZpZGluZyB0aGlzIHNlcnZpY2UgdXNpbmcgdGhlIHdpcmUgcHJvdG9jb2wgYXMgYXBwcm9wcmlh dGUuIENsZWFybHkgd2Ugd2FudCBhIGNsaWVudCB3cml0dGVuIHdpdGggb25lIGxpYnJhcnkgdG8g YmUgYWJsZSB0byBjb21tdW5pY2F0ZSBzdWNjZXNzZnVsbHkgd2l0aCBhIHNlcnZlciB3cml0dGVu IHVzaW5nIGEgZGlmZmVyZW50IGxpYnJhcnkuIFRoaXMgbmVlZHMgc29tZSBmb3JtIG9mIHN0YW5k YXJkaXphdGlvbg0KIG9mIHRoZSBzaWduYWxsaW5nLiBUaGlzIGNvdWxkIGVpdGhlciBiZSBhIGJ1 aWxkaW5nIGJsb2NrIG92ZXJsYXkgb24gdG9wIG9mIFFVSUMsIG9yIGltcGxlbWVudGVkIGF0IHRo ZSB3aXJlIHByb3RvY29sIGxldmVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JbiB0ZXJtcyBvZiBwYXR0ZXJucyBJ IHRoaW5rIHRoZSBmb2xsb3dpbmcgbWF5IGJlIHNvbWUgb2YgdGhlIG1vc3QgY29tbW9uIHBhdHRl cm5zICh3aXRoIHBvdGVudGlhbCB0byBiZSBwcm92aWRlZCBhdCB0aGUgbGlicmFyeSBhbmQgb3Ig d2lyZSBwcm90b2NvbA0KIGxldmVsKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkv TyBwYXR0ZXJuICZuYnNwOzogRXhhbXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ MS8wJm5ic3A7Jm5ic3A7IDogQW4gaW5wdXQgb25seSBmbG93LCBwZXJoYXBzIGEgZGF0YSBsb2dn ZXIgbGlrZSBzeXNsb2cgd2l0aCBubyBjb25maXJtYXRpb24vZmVlZGJhY2s8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjAvMSZuYnNwOyA6IGFuIG91dHB1dCBvbmx5IGZsb3csIHBlcmhh cHMgYSB0b3BpYyBtZXNzYWdlIGJ1cyBzZXJ2aWNlIHdpdGggbm8gY29uZmlybWF0aW9uL2ZlZWRi YWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4xLzEgOiBzdGFuZGFyZCBUQ1AgYXBw bGljYXRpb25zIHdpdGggYSBzaW5nbGUgZmxvdyBwZXIgY29ubmVjdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+MS8qIDogc2luZ2xlIGlucHV0LCBtYW55IG91dHB1dCwgbW9kZWxs aW5nIFNURElOL1NURE9VVCYjNDM7U1RERVJSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4oMS8xKSogOiBtdWx0aXBsZXhlZCBwYWlycyBvZiBmbG93cyDigJMgc3VwcG9ydGluZyBtdWx0 aXBsZSBzb2NrZXRzIG11eGVkIG9udG8gYSBzaW5nbGUgUVVJQyBjb25uZWN0aW9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPk9idmlvdXNseSwgYW4gYXBwbGljYXRpb24gd291bGQgYWx3YXlzIGhhdmUgdGhlIG9wdGlv biB0byBjb21iaW5lIGFueSBzaW5nbGUgZGlyZWN0aW9uIGZsb3dzIHdpdGggYXBwbGljYXRpb24g bGV2ZWwgY29ycmVsYXRvcnMgdG8gY29uc3RydWN0IG1vcmUNCiBjb21wbGV4IGZsb3dzIGlmIGRl c2lyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkF0IHRoZSBtb21lbnQgbXkgZ3V0IHNheXMgdGhlIDEvMSB1c2Ut Y2FzZSBpcyBjb21tb24gZW5vdWdoIHRoYXQgdGhlIHdpcmUgcHJvdG9jb2wgc2hvdWxkIHByb3Zp ZGUgYSBzdGFuZGFyZCBtZWNoYW5pc20gdG8gc3VwcG9ydCBpdCBhcyBhIHN0YW5kYXJkDQogb3Zl cmxheSB3b3VsZCBwcm9iYWJseSBlbmQgdXAgYmVpbmcgdHJlYXRlZCBhcyBwYXJ0IG9mIHRoZSB3 aXJlIGZvcm1hdCBhbnl3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlBlcmhhcHMgc3RyZWFtcyBzaG91bGQgYmUg ZXhwbGljaXRseSBjcmVhdGVkIHdpdGggYSBDUkVBVEVfU1RSRUFNIGZyYW1lIHdoaWNoIHdvdWxk IGJlIGNhcGFibGUgb2YgZGVmaW5pbmcgbXVsdGlwbGUgcmVsYXRlZCBzdHJlYW1zPw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGVyZSBpcyB0aGUgb3B0aW9uIG9mIHdoZXRoZXIg b25seSAoMS8xKSBwYWlycyBjYW4gYmUgY3JlYXRlZCB0aGlzIHdheSwgb3IgKDEvbikgY29tYmlu YXRpb25zIGNvdWxkIGJlIHN1cHBvcnRlZCAod2l0aCBhbiBhcHBsaWNhdGlvbiBkZWZpbmVkIHdh eQ0KIHRvIGlkZW50aWZ5IHRoZSB1c2Ugb2YgZWFjaCBvZiB0aGUgb3V0cHV0IHN0cmVhbXMpLiBB IHN0ZXAgZnVydGhlciBtYXkgYmUgdGhhdCB0aGVyZSBpcyBhIHRyYW5zcG9ydCBwYXJhbWV0ZXIg dGhhdCBkZWZpbmVzIHdoZXRoZXIgdGhlIHNlcnZlciBpcyBhbGxvd2VkIHRvIGNyZWF0ZSBhZGRp dGlvbmFsIHN0cmVhbXMsIG9yIGlmIHN0cmVhbSBjcmVhdGlvbiBpcyBwdXJlbHkgY2xpZW50IGRy aXZlbiAobGlrZSBUQ1ApLiBJIGRvbuKAmXQga25vdyBpZg0KIGVpdGhlciBvZiB0aGVzZSB3b3Vs ZCBzaW1wbGlmeSBob3cgdG8gaGFuZGxlIHN0cmVhbSBhY2NvdW50aW5nLCBhbmQgaW4gcGFydGlj dWxhciBvbmx5IGNyZWF0aW5nIGEgZmxvdyB3aGVuIGFsbCBwYXJ0aWVzIGhhdmUgc3VmZmljaWVu dCBhbGxvd2FuY2VzIGxlZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRob21hczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvIEt1bGlrPGJyPg0KPGI+U2VudDo8L2I+ IDI4IEp1bmUgMjAxNyAxNTowOTxicj4NCjxiPlRvOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdl bnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUVVJQyBXRyAm bHQ7cXVpY0BpZXRmLm9yZyZndDs7IERtaXRyaSBUaWtob25vdiAmbHQ7ZHRpa2hvbm92QGxpdGVz cGVlZHRlY2guY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVW5pZGlyZWN0aW9uYWwg c3RyZWFtcyBQUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JJ2QgbGlrZSB0byBwb3AgYmFjayB1cCB0byBhIGNvbW1lbnQgSWdvciBtYWRlIGxh c3Qgd2VlaywgYmVjYXVzZSBJIGZpbmQgaXQgaGVscGZ1bCBpbiB0aGlua2luZyBhYm91dCB0aGUg ZGVzaWduIHNwYWNlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayBvZiB0aHJlZSBsYXllcnMg b2YgYWJzdHJhY3Rpb246PGJyPg0KJm5ic3A7PGJyPg0KMS48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UVVJQyBXaXJlIFByb3RvY29sICh0aGUgdGhpbmcgZGVz Y3JpYmVkIGJ5IHRoZSBRVUlDIFRyYW5zcG9ydCBSRkMpPGJyPg0KMi48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UVVJQyBMaWJyYXJ5IEFQSSAoYSBsaWJyYXJ5 IGV4cG9zaW5nIHNvbWUgdXNlZnVsIGFic3RyYWN0aW9ucyAtLSBzdWNoIGFzIGJsb2NraW5nL25v bi1ibG9ja2luZyB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFuZCBiaWRpcmVjdGlvbmFsIOKAnHNv Y2tldHPigJ0NCiAtLSBhbmQgaW1wbGVtZW50aW5nIHRoZW0gdXNpbmcgUVVJQyBXaXJlIFByb3Rv Y29sKTxicj4NCjMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkFwcGxpY2F0aW9uIChzb21ldGhpbmcgdGhhdCB1c2VzIFFVSUMgTGlicmFyeSBBUElzKTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlcmUgaXMgc29tZSBhcmd1bWVudCB0byBiZSBtYWRlIHRo YXQgTWFydGluJ3Mgb3JpZ2luYWwgcHJvcG9zYWwgZGlkIG5vdCB0YWtlIGludG8gYWNjb3VudCBo b3cgd2Ugd291bGQgYWNoaWV2ZSAoMikgZm9yIGJpLWRpcmVjdGlvbmFsIHN0cmVhbXMuICZuYnNw OyhJIGRvbid0IHRoaW5rIGl0IHN0cmljdGx5IHNhaWQgJnF1b3Q7dGhvdSBzaGFsdCBub3QgZG8g KDIpJnF1b3Q7IGVpdGhlciwgYnV0IHRoYXQgaXMgdXAgdG8NCiBpbnRlcnByZXRhdGlvbi4pPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNldmVy YWwgcGVvcGxlIGhhdmUgYXJndWVkIHRoYXQgd2UgZG8gbm90IHdhbnQgZXZlcnkgYXBwbGljYXRp b24gdG8gaGF2ZSB0byByZS1pbXBsZW1lbnQgYmktZGlyZWN0aW9uYWwgc3RyZWFtcyAoMykgZm9y IGV2ZXJ5IGFwcGxpY2F0aW9uLCBhbmQgdGhpcyBpcyBub3QgaG93IGctcXVpYyAob3VyIGxhcmdl c3QgZGVwbG95bWVudCkgd29ya3MgcmlnaHQgbm93LiZuYnNwOyBUaGVzZSBhcmd1bWVudHMgbWFr ZSBzZW5zZQ0KIHRvIG1lLCBidXQgWU1NVi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBiZWNhdXNlIHRoZSBwYXJ0aWN1bGFyICptZWNo YW5pc20qIHRoYXQgaXMgYmVpbmcgcHJvcG9zZWQgaGFzIHNvbWUgaXNzdWVzLCBob3dldmVyLCBk b2Vzbid0IHNjcmVhbSBvdXQgdG8gbWUsIGF0IGxlYXN0LCB0aGF0IHdlIHNob3VsZCBhYmFuZG9u IHRoaXMgcGFydGljdWxhciAqZGVzaWduIGdvYWwqLiZuYnNwOyBUaGUgZ29hbCBiZWluZyBhIHRy YW5zcG9ydCBwcm90b2NvbCB0aGF0IGNhbiBlbGVnYW50bHkgZml0DQogd2l0aCBhIHVuaS9iaSBz dHJlYW0gbW9kZWwuJm5ic3A7IE5vdywgaWYgd2UgY29uY2x1ZGUgdGhhdCB0aGVyZSBjYW4gbmV2 ZXIgYmUgYW4gZWxlZ2FudCBtb2RlbCB0aGF0IGFjaGlldmVzIHRoaXMgZ29hbCwgdGhlbiBzbyBi ZSBpdC4mbmJzcDsgQnV0IEkgYWxzbyBmZWVsIGxpa2Ugd2UgaGF2ZW4ndCByZWFjaGVkIHRoYXQg cG9pbnQgaW4gdGhlIGRpc2N1c3Npb24geWV0LiAmbmJzcDsoQXQgdGhlIHZlcnkgbGVhc3QsIHRo aXMgZGlzY3Vzc2lvbiBoYXMgYmVlbiBmcnVpdGZ1bA0KIHRvIG1lIGluIHRlcm1zIG9mIG1hcHBp bmcgdGhlIGRlc2lnbiBzcGFjZSBhbmQgZWx1Y2lkYXRpbmcgcmVxdWlyZW1lbnRzKS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIG9mIHRo ZSByZWFzb25zIEkgc3RpbGwgdGhpbmsgdGhpcyBkZXNpZ24gZ29hbCBpcyB1bmRlciBjb25zaWRl cmF0aW9uIGlzIHRoYXQgSWFuIGFuZCBJZ29yL01pa2UgaGF2ZSBiZWVuIHRhbGtpbmcgYWJvdXQg YWx0ZXJuYXRlIHNvbHV0aW9ucyB3aGljaCBoYXZlIGEgc2ltaWxhciBmbGF2b3IuJm5ic3A7IER1 cmluZyB0aGUgcmVjZW50ICZxdW90O3F1aWV0JnF1b3Q7bmVzcyBvbiB0aGUgdGhyZWFkLCBwZXJz b25hbGx5LCBJJ3ZlIGJlZW4NCiB3YWl0aW5nIHRvIGhlYXIgbW9yZSBmcm9tIHRoZW0uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg SnVuIDI4LCAyMDE3IGF0IDk6NDEgQU0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtrZWxm akBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gcmVwbHkgdG8mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDssc2VyaWYiPlJhbmplZXRoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMz NDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i bV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SXQgaXMgbm90IG9ubHkgYSBtYXR0ZXIgb2Ygc2ltcGxp Y2l0eSBmb3IgdGhlIHNha2Ugb2Ygc2ltcGxpY2l0eTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LSBB IGNvbXBsZXggdHJhbnNwb3J0IGxheWVyIG1pZ2h0IGVuZCB1cCBiZWluZyBwb29ybHkgaW1wbGVt ZW50ZWQgbGVhZGluZyB0byByZWR1Y2VkIGludGVyb3BlcmFiaWxpdHkgYW5kIHVsdGltYXRlbHkg YWRvcHRpb24uIFRoaXMgY29tcGxleGl0eSBpcyBub3Qgb25seSBpbiBpbXBsZW1lbnRhdGlvbg0K IGJ1dCBhbHNvIGluIHVuZGVyc3RhbmRpbmcgdGhlIGV4YWN0IHNlbWFudGljcyBvZiBzdHJlYW0g bGlmZXRpbWUuIEV2ZW4gaWYgdGhlIHNwZWMgaXMgc3VmZmljaWVudGx5IGNsZWFyLCBpdCB3aWxs IHN0aWxsIGJlIG9wZW4gdG8gbWlzaW50ZXJwcmV0YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE5OTU4NDk0NDYzMzQ2MzYwOThi bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4tIEJpLWRpcmVjdGlvbmFsIHN0YXRlIG1heSBoYXZlIHRvIGJlIG1haW50YWluZWQgbG9uZ2Vy IGFuZCB3aXRoIG1vcmUgb3ZlcmhlYWQgdGhhbiB3aXRoIHVuaS1kaXJlY3Rpb25hbCBzdHJlYW1z LCBlc3BlY2lhbGx5IHVuZGVyIGxvc3MsIHBvdGVudGlhbGx5IGxlYWRpbmcgdG8gcG9vciBwZXJm b3JtYW5jZQ0KIGFuZCBwb29yIHJlc291cmNlIHV0aWxpc2F0aW9uIGJlY2F1c2UgdGhlIHRyYW5z cG9ydCBsYXllciBoYXMgaW5zdWZmaWNpZW50IGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE5OTU4NDk0NDYzMzQ2MzYw OThibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4tIFRoZSBleHRyYSBjb21wbGV4aXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBtYXkg YmUgb3ZlcnN0YXRlZCAtIGl0IGlzIHNpZ25pZmljYW50bHkgc2ltcGxlciB0byBtYW5hZ2UgYSBt YXAgdGhhdCBhc3NvY2lhdGVzIHRvIHR3byBzdHJlYW1zIHRoYW4gaXQgaXMgdG8gbWFpbnRhaW4g YmktZGlyZWN0aW9uYWwNCiBzdGF0ZSBhdCB0aGUgdHJhbnNwb3J0IGxheWVyLiBJdCBpcyBldmVu IHBvc3NpYmxlIHRvIGltcGxpY2l0bHkgbGluayBzdHJlYW1zIHdpdGggc2FtZSBpZGVudGlmaWVy cywgZS5nLiBpbiBhIFJQQyBzY2VuYXJpby4gVGhhdCBzYWlkLCBJIGRvIHNlZSBhIHBvdGVudGlh bCBiZW5lZml0IG9mIGEgd3JhcHBlciB0aGF0IGltcGxlbWVudHMgdGhlIGNvbW1vbiBiaS1kaXJl Y3Rpb25hbCBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8x OTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJtXzE5OTU4NDk0NDYzMzQ2MzYwOThibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIENvbXBsZXhpdHkgYXQgdGhlIGFw cGxpY2F0aW9uIGxheWVyIG1heSBiZSBkdXBsaWNhdGVkLCBidXQgaW1wbGVtZW50YXRpb24gZXJy b3JzIGFyZSBhbHNvIGlzb2xhdGVkIHRvIHRoYXQgYXBwbGljYXRpb24uIFNwZWNpZmljYWxseSBm b3IgSFRUUCBJIHdvdWxkIGFzc3VtZSB0aGF0IFFVSUMgdHJhbnNwb3J0DQogYW5kIFFVSUMgSFRU UCBpbXBsZW1lbnRlcnMgd291bGQgYmUgbGFyZ2UgdGhlIHNhbWUgZm9yIGEgbG9uZyB0aW1lIHRv IGNvbWUsIHNvIEkgd291bGQgbm90IGV4cGVjdCB0aGUgdHJhZGVvZmYgaGVyZSB0byBiZSBwYXJ0 aWN1bGFybHkgY29uY2VybmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LSBVbml4IHBpcGVzIGFy ZSB0cmFkaXRpb25hbGx5IGNvbnN0cnVjdGVkIGFzIGEgcGFpciBvZiB1bmktZGlyZWN0aW9uYWwg ZmlsZSBkZXNjcmlwdG9ycyBhbmQgdGhhdCBpcyBhIHJlYXNvbmFibHkgcHJvdmVuIG1vZGVsLiBD 4oCZcyBzdGFuZGFyZCBsaWJyYXJ5IHN0ZGluLCBzdGRvdXQgYW5kIHN0ZGVycg0KIGlzIGFuIGV4 YW1wbGUgb2YgYW4gYXN5bW1ldHJpYyBtb2RlbCB3aXRoIGltcGxpY2l0IGxpbmthZ2UgYmV0d2Vl biB1bmktZGlyZWN0aW9uYWwgZmlsZSBkZXNjcmlwdG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxv b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ LSBUaGVyZSBhcmUgbG90cyBvZiB1c2UgY2FzZXMgZm9yIG5vbi1IVFRQIGxpa2UgY29ubmVjdGl2 aXR5IC0gS2Fma2EgaGlnaCB2b2x1bWUgbWVzc2FnZSBxdWV1aW5nIGZvciBleGFtcGxlLiBUaGUg aW5kdXN0cnkgdHJlbmQgYXBwZWFycyB0byBtb3ZlIHRvd2FyZHMgYXN5bmNocm9ub3VzIHByb2Nl c3NpbmcNCiBhbmQgbWVzc2FnaW5nLiBJdCBkZXBlbmRzIG9uIHdoZXRoZXIgeW91IGxvb2sgYXQg UVVJQyBhcyBhIFRDUCAmIzQzOyBUTFMgcmVwbGFjZW1lbnQsIG9yIGFzIGEgSFRUUFMgLyBSRVNU IFJQQyByZXBsYWNlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LSBVbmktZGlyZWN0aW9uYWwg c3RyZWFtcyBtYXkgY3VycmVudGx5IGJlIHVucHJvdmVuIGluIHRoZSB3aWxkLCBidXQgYSBwcm9w b3NhbCBpcyBuZWVkZWQgYmVmb3JlIGFuIGltcGxlbWVudGF0aW9uIGNhbiBiZSBtYWRlIGFuZCB0 ZXN0ZXQuIEkgYWdyZWUgdGhhdCBpdCBpcyBlYXN5IHRvIGRlc2lnbg0KIGludG8gd3JvbmcgYXNz dW1wdGlvbnMgd2l0aG91dCByZWFsIHdvcmxkIHRlc3RpbmcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE5OTU4NDk0NDYzMzQ2MzYwOThibG9vcF9jdXN0b21mb250 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJs b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pi0gVGhlcmUgd2lsbCBob3BlZnVsbHkgbm90IGJlIGEgbGFyZ2UgbnVtYmVyIG9mIHN1Y2Nlc3Nv cnMgdG8gUVVJQyAtIHBlcmhhcHMgc29tZSBwdXJwb3NlIHNwZWNpZmljIHZhcmlhbnRzLCBlLmcu IGZvciBlbWJlZGRlZCB1c2UuIFdpZGVzcHJlYWQgYWRhcHRhdGlvbiBhbmQgY29tcGF0aWJpbGl0 eQ0KIGlzIHZlcnkgbmVjZXNzYXJ5IHNvIGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgUVVJQyBiZWlu ZyBzdWZmaWNpZW50bHkgc2ltcGxlIGFuZCBleHByZXNzaXZlIHRvIGFjaGlldmUgdGhpcyBnb2Fs LiBBIHBvbHltb3JmIFFVSUMgd2lsbCBub3QgYWNoaWV2ZSB0aGF0IGdvYWwuIE9uIHRoZSBvdGhl ciBoYW5kLCBhIHNvbGlkIFFVSUMgZm91bmRhdGlvbiBjYW4gYmUgdXNlZCBmb3IgYSBsYXJnZSBu dW1iZXIgb2YgYXBwbGljYXRpb24gcHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEZpbmFsbHksIGl0IG1heSB0dXJuIG91dCB0 aGF0IHVuaS1kaXJlY3Rpb25hbCBzdHJlYW1zIGp1c3QgaXMgYSBiYWQgaWRlYSAtIEkgZG91YnQg aXQsIGJ1dCBJIGRvIGJlbGlldmUgcmVhbCB3b3JsZCB0ZXN0cyBhcmUgbmVlZGVkLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3Bfc2lnbl8xNDk4NjU0MDMyMzAw ODgxOTIwIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ S2luZCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTk5NTg0OTQ0NjMzNDYzNjA5OGFpcm1haWxvbiI+ T24gMjggSnVuZSAyMDE3IGF0IDE0LjQyLjM2LCBEbWl0cmkgVGlraG9ub3YgKDxhIGhyZWY9Im1h aWx0bzpkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20iIHRhcmdldD0iX2JsYW5rIj5kdGlraG9u b3ZAbGl0ZXNwZWVkdGVjaC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pk9uIFR1ZSwgSnVuIDI3LCAyMDE3IGF0IDAyOjMxOjM4UE0gLTA3MDAsIFJhbmplZXRoIEt1bWFy IERhc2luZW5pIHdyb3RlOg0KPGJyPg0KJmd0OyAyLiBXZSBhcmUgb3ZlcnBsYXlpbmcgdGhlIHNp bXBsaWNpdHkgb2YgZGVzaWduLiBFdmVuIGlmIHdlIGRlZW0gZGVwbG95bWVudCA8YnI+DQomZ3Q7 IGV4cGVyaWVuY2Ugbm90IGEgY29uY2VybiwgaWYgZXZlcnkgYXBwbGljYXRpb24gbGF5ZXIgcHJv dG9jb2wgdGhhdCBuZWVkcyA8YnI+DQomZ3Q7IHN1cHBvcnQgZm9yIGJpZGlyZWN0aW9uYWwgc3Ry ZWFtcyBoYXMgdG8gaW1wbGVtZW50IHNvbWUgY29ycmVsYXRvcnMgYW5kIDxicj4NCiZndDsgc3Vj aCBhYm92ZSwgdGhhdCdzIGEgbmV0IG5lZ2F0aXZlIGluIHRlcm1zIG9mIGNvbXBsZXhpdHkuIDxi cj4NCjxicj4NClRoaXMgaXMgYW4gaW1wb3J0YW50IHBvaW50OiB3ZSB3YW50IFFVSUMgYWRvcHRp b24gdG8gYmUgbWFkZSBlYXN5LiA8YnI+DQpBIHByb2dyYW0gdGhhdCBzcGVha3MgSFRUUCB0b2Rh eSBzaG91bGQgYmUgYWJsZSB0byB1c2UgYW4gZXhpc3RpbmcgUVVJQyA8YnI+DQpsaWJyYXJ5IHdp dGhvdXQgaGF2aW5nIHRvIGVtdWxhdGUgYmlkaXJlY3Rpb25hbCBzdHJlYW1zIGluIG9yZGVyIHRv IGZpdCA8YnI+DQppdCBpbnRvIEhUVFAgdXNhZ2UgcGF0dGVybi4gRm9yY2luZyBldmVyeSBvbmUg b2YgdGhlc2UgcHJvZ3JhbXMgdG8gZG8gPGJyPg0KdGhpcyBpcyBjZXJ0YWlubHkgYSBodXJkbGUu IDxicj4NCjxicj4NCi0gRG1pdHJpLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DB5PR07MB123748F2AB7374DAC0CC9E1484DD0DB5PR07MB1237eurp_-- From nobody Wed Jun 28 13:51: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 6971D12EAFB for ; Wed, 28 Jun 2017 13:51:15 -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 CfHZoKOIBWaR for ; Wed, 28 Jun 2017 13:51:13 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id BCDB21270AC for ; Wed, 28 Jun 2017 13:51:13 -0700 (PDT) Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com [209.85.216.181]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6134F3A019 for ; Wed, 28 Jun 2017 16:51:11 -0400 (EDT) Received: by mail-qt0-f181.google.com with SMTP id f92so59615077qtb.2 for ; Wed, 28 Jun 2017 13:51:11 -0700 (PDT) X-Gm-Message-State: AKS2vOzSFuDHzzpxIttxxOoE9bNxyHHDkCT9dM7IxyMbIiVaaeGvJ9qQ vT4Aea29+YdKLzij9S2I5LfPzrMCWw== X-Received: by 10.237.61.153 with SMTP id i25mr15917037qtf.239.1498683071124; Wed, 28 Jun 2017 13:51:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.85 with HTTP; Wed, 28 Jun 2017 13:51:10 -0700 (PDT) From: Patrick McManus Date: Wed, 28 Jun 2017 13:51:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: 2 Points of First Implementation Draft we might clarify To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113b859a15dbe605530b5837" 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, 28 Jun 2017 20:51:15 -0000 --001a113b859a15dbe605530b5837 Content-Type: text/plain; charset="UTF-8" Hi All - First, its really amazing to see nascent quic implementations emerging from primordial soup over the last couple of weeks. I can count at least 5 that have been mentioned on email, chat, or twitter trying to do real interop. Its all a giant morass of work in progress of course - but this is exciting and I take it as a very good sign. A couple things have come up 1] The implementation milestone wiki should probably specific a draft version of TLS 1.3. Both -18 and -20 have been in common use (depending on what TLS library you are using) and this leads to a common interop failure. Presumably this isn't a problem we will have with the second milestone when the TLS WG will have settled on a final revision. I would argue for -20 simply because its a later marker on the march of forward progress. 2] the text on connection_close doesn't indicate which peer does the close, or really when. If we want to do un-attended endpoint testing it might be a useful thing to profile. e.g. "the server sends connection close on a timer 2 seconds after the handshake is complete".. or something. -Patrick --001a113b859a15dbe605530b5837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All - First, its really amazing to see nascent qui= c implementations emerging from primordial soup over the last couple of wee= ks. I can count at least 5 that have been mentioned on email, chat, or twit= ter trying to do real interop. Its all a giant morass of work in progress o= f course - but this is exciting and I take it as a very good sign.

A couple things have come up

1] T= he implementation milestone wiki should probably specific a draft version o= f TLS 1.3. Both -18 and -20 have been in common use (depending on what TLS = library you are using) and this leads to a common interop failure. Presumab= ly this isn't a problem we will have with the second milestone when the= TLS WG will have settled on a final revision. I would argue for -20 simply= because its a later marker on the march of forward progress.
2] the text on connection_close doesn't indicate which peer= does the close, or really when. If we want to do un-attended endpoint test= ing it might be a useful thing to profile. e.g. "the server sends conn= ection close on a timer 2 seconds after the handshake is complete".. o= r something.

-Patrick


--001a113b859a15dbe605530b5837-- From nobody Wed Jun 28 13:54: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 3AF8D12EB40 for ; Wed, 28 Jun 2017 13:54:02 -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 hgvlnt9PQq3B for ; Wed, 28 Jun 2017 13:54:00 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4829612EB09 for ; Wed, 28 Jun 2017 13:54:00 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l21so20972398ywb.1 for ; Wed, 28 Jun 2017 13:54:00 -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=lvb2fqFGOVNQzudNPdEJOPgI9tVK+4j8GIFgWpoOjJA=; b=DIZJcNGhxhMORUI6nbrU52/HFaCYZ42HMfHGyEayaG2CN6PoBt13jEiwzp2/YOITD1 qLjmTKeDIVFlkcj6s2i7DkGOKKmo6nSoZhBFJgBWkk4Ar2kws60bjNQlgo+SJhaQMojh XDjr3VpGvbYCevCk6+BsfdA6vaaU4AiUcyUxH+lM5BxGU/nwZg2IJ0+scu0z6jlUxe68 +QJeiTdeA/R97FwsQ4PHKXl5ia7iHzHTLwA5bOkZ28vSMMoy6x1HpNoSlR4ytyCLruDz lkRb610a5Aj9dMMTleG8a2IYc8ugwnxgyLWLVA7OPpKPMTON2kUCSRrd/bzw5cFLrTew 5RfA== 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=lvb2fqFGOVNQzudNPdEJOPgI9tVK+4j8GIFgWpoOjJA=; b=bG8NqflcZIGNgqoXepCE8Y1uRbUJ43UbXlEwt5mroDfja1WBp+PmvmeEI6qCF/PmHb BWJWa+x2xfr4Z4qu+AiaA+nQjhw1ttP6HB+TUQROHp9aSLqVylRxTGD434oDtvlr18Ow AUX3TbRn0CulInFgt1Pi7xQg7jCP4BAperyHGSEFRkMKlzWYogxoLq8pnH4JeJMFsnRY okJXq74YuCqWsoeYxBhwMH9toC78Ko7N5tIGSmknRZtXVAfJfOP0o/8H85KCvSzjgXV4 xOcYtnzKdSPEsQy/qmg8MCrk+M3sv+QzZVO9+Ond1UanwYOt5NUsyYgsJvEKCATVugCM gDSg== X-Gm-Message-State: AKS2vOwwYWh6Sljg8sHMgRkNg2JR6vnPwBnyQueLpYOgHMkrCNSpbBQH 5RsYtOptqcioZFRilbimuIx9Jc8SWcpm X-Received: by 10.129.162.86 with SMTP id z83mr9835896ywg.103.1498683239347; Wed, 28 Jun 2017 13:53:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.3 with HTTP; Wed, 28 Jun 2017 13:53:38 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Wed, 28 Jun 2017 16:53:38 -0400 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Patrick McManus Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c129a021d4a5805530b62ed" 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, 28 Jun 2017 20:54:02 -0000 --94eb2c129a021d4a5805530b62ed Content-Type: text/plain; charset="UTF-8" Those both seem like good changes to me. On Wed, Jun 28, 2017 at 4:51 PM, Patrick McManus wrote: > Hi All - First, its really amazing to see nascent quic implementations > emerging from primordial soup over the last couple of weeks. I can count at > least 5 that have been mentioned on email, chat, or twitter trying to do > real interop. Its all a giant morass of work in progress of course - but > this is exciting and I take it as a very good sign. > > A couple things have come up > > 1] The implementation milestone wiki should probably specific a draft > version of TLS 1.3. Both -18 and -20 have been in common use (depending on > what TLS library you are using) and this leads to a common interop failure. > Presumably this isn't a problem we will have with the second milestone when > the TLS WG will have settled on a final revision. I would argue for -20 > simply because its a later marker on the march of forward progress. > > 2] the text on connection_close doesn't indicate which peer does the > close, or really when. If we want to do un-attended endpoint testing it > might be a useful thing to profile. e.g. "the server sends connection close > on a timer 2 seconds after the handshake is complete".. or something. > > -Patrick > > > > --94eb2c129a021d4a5805530b62ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Those both seem like good changes to me.

On Wed, Jun 28, 2017 at 4:5= 1 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
Hi All - First, its real= ly amazing to see nascent quic implementations emerging from primordial sou= p over the last couple of weeks. I can count at least 5 that have been ment= ioned on email, chat, or twitter trying to do real interop. Its all a giant= morass of work in progress of course - but this is exciting and I take it = as a very good sign.

A couple things have come up<= /div>

1] The implementation milestone wiki should probab= ly specific a draft version of TLS 1.3. Both -18 and -20 have been in commo= n use (depending on what TLS library you are using) and this leads to a com= mon interop failure. Presumably this isn't a problem we will have with = the second milestone when the TLS WG will have settled on a final revision.= I would argue for -20 simply because its a later marker on the march of fo= rward progress.

2] the text on connection_close do= esn't indicate which peer does the close, or really when. If we want to= do un-attended endpoint testing it might be a useful thing to profile. e.g= . "the server sends connection close on a timer 2 seconds after the ha= ndshake is complete".. or something.

-Patrick



--94eb2c129a021d4a5805530b62ed-- From nobody Wed Jun 28 14:11: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 97CCA12EC45 for ; Wed, 28 Jun 2017 14:11:11 -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 fMVFyuVsCkZT for ; Wed, 28 Jun 2017 14:11:04 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 4581E12EBAA for ; Wed, 28 Jun 2017 14:11:04 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j11so29617791ywa.2 for ; Wed, 28 Jun 2017 14:11:04 -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=/kldxSjCXet0PINRKZH+2RG5ES//VUBkMnMXvCbURTk=; b=YkLuBIOJR2gXVEBr21rsFr7s8Rh0XvK9YnwoV1bYSvAqKLupivwyt+YH2g0oy77dw+ Wk5jBDn4Sti4Rph53PVZW6vPqrpka9aXD4dgTZofSwurEWX//PhVhcLU9DF8t8dHMEl4 GSOdznuc6fmFPU9Gx0rqI3vHVR4K1ZNQ3WAbIOHYG5UuFHkZ4/CzX0kifTGXFZIF83cr kSK/7hBSrtYe0rQsarppM/IZMvlHH9KpqsbI0UXYL93CE4CjXRj2Kr9mbndpMllJIUyx +VDt9g/S0kIOwVuEHVJpeFang9laWS3fdKweUi5iungBV3nHGeZoeh8RtUJpJZwdDia7 KIUQ== 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=/kldxSjCXet0PINRKZH+2RG5ES//VUBkMnMXvCbURTk=; b=S5CqFu5HnF+WqIf7uf21kjmV9LVsllLaspZB1c1OpD/1PHn6J6/liUtMvA2gr4soaq Z0ewM+SPUzZkgZXcecuGL5vgHnII7U5v45V3zM3LLq6ZQPzVlqSr360ZZjvpGByawrM6 8+RQSzijgIr20pOc++hg+0jjDkHNmMQpxG1lWXeeNQ4C/6amrhGbQFf4FOihwC0BJuxT 4wZswQWkFC7csSc2ddFyRD5pOVG2R5bAuLrRHWDqsng5qLU+tbPuXP/RVvlh7339yUxr 5537mlDdF6LpFPsE+qJdsUUMajR08u2wVsc3h5RHAYLOy1s2PANtG/nEB/4C8+q9tPQN SfaQ== X-Gm-Message-State: AKS2vOxEH+eryzybS3dWMeKXARiFbVDjEN+u3F1rmOhrJrzWkEMu0UYW JiuS//ZKIGHgphiFHHGRzD2u4Hhe43ZK X-Received: by 10.129.162.86 with SMTP id z83mr9897203ywg.103.1498684263289; Wed, 28 Jun 2017 14:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.3 with HTTP; Wed, 28 Jun 2017 14:10:42 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Wed, 28 Jun 2017 17:10:42 -0400 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Patrick McManus Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c129a02257bda05530b9fbd" 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, 28 Jun 2017 21:11:12 -0000 --94eb2c129a02257bda05530b9fbd Content-Type: text/plain; charset="UTF-8" I've been informed that BoringSSL doesn't yet support draft 20 and won't until we understand how to get middleboxes to stop hating TLS 1.3 over TCP, so from a practical perspective, it would be much easier for us to support 18. Would only supporting 18 cause problems for anyone? On Wed, Jun 28, 2017 at 4:53 PM, Ian Swett wrote: > Those both seem like good changes to me. > > On Wed, Jun 28, 2017 at 4:51 PM, Patrick McManus > wrote: > >> Hi All - First, its really amazing to see nascent quic implementations >> emerging from primordial soup over the last couple of weeks. I can count at >> least 5 that have been mentioned on email, chat, or twitter trying to do >> real interop. Its all a giant morass of work in progress of course - but >> this is exciting and I take it as a very good sign. >> >> A couple things have come up >> >> 1] The implementation milestone wiki should probably specific a draft >> version of TLS 1.3. Both -18 and -20 have been in common use (depending on >> what TLS library you are using) and this leads to a common interop failure. >> Presumably this isn't a problem we will have with the second milestone when >> the TLS WG will have settled on a final revision. I would argue for -20 >> simply because its a later marker on the march of forward progress. >> >> 2] the text on connection_close doesn't indicate which peer does the >> close, or really when. If we want to do un-attended endpoint testing it >> might be a useful thing to profile. e.g. "the server sends connection close >> on a timer 2 seconds after the handshake is complete".. or something. >> >> -Patrick >> >> >> >> > --94eb2c129a02257bda05530b9fbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been informed that BoringSSL doesn't yet supp= ort draft 20 and won't until we understand how to get middleboxes to st= op hating TLS 1.3 over TCP, so from a practical perspective, it would be mu= ch easier for us to support 18.

Would only supporting 18 cause prob= lems for anyone?

On Wed, Jun 28, 2017 at 4:53 PM, Ian Swett <= ;ianswett@google.c= om> wrote:
Those both seem like good changes to me.

On We= d, Jun 28, 2017 at 4:51 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
= Hi All - First, its really amazing to see nascent quic implementations emer= ging from primordial soup over the last couple of weeks. I can count at lea= st 5 that have been mentioned on email, chat, or twitter trying to do real = interop. Its all a giant morass of work in progress of course - but this is= exciting and I take it as a very good sign.

A cou= ple things have come up

1] The implementation mile= stone wiki should probably specific a draft version of TLS 1.3. Both -18 an= d -20 have been in common use (depending on what TLS library you are using)= and this leads to a common interop failure. Presumably this isn't a pr= oblem we will have with the second milestone when the TLS WG will have sett= led on a final revision. I would argue for -20 simply because its a later m= arker on the march of forward progress.

2] the tex= t on connection_close doesn't indicate which peer does the close, or re= ally when. If we want to do un-attended endpoint testing it might be a usef= ul thing to profile. e.g. "the server sends connection close on a time= r 2 seconds after the handshake is complete".. or something.

-Patrick



=


--94eb2c129a02257bda05530b9fbd-- From nobody Wed Jun 28 14:12:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949A612EC45 for ; Wed, 28 Jun 2017 14:12: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 YPr4yYBLokrJ for ; Wed, 28 Jun 2017 14:12:52 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 99C8A12EA6A for ; Wed, 28 Jun 2017 14:12:51 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id z78so457475lff.0 for ; Wed, 28 Jun 2017 14:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NOHoPZUPYjQ9vD3Ru1clAPKfzsfIyc1VPy0+j91rsCQ=; b=s+F80mQmcJ8jBL/GTdTnAcjxnNY5VwyGghO1efLWCFSkWdovajbAdSHO9ZAqmPFYEs zNreqg797s6PNpu6P9y+0Z4y9PKTZx5WSHqppO1cZFE8G890OjQVpXw3UOdJ1g0KPz2z BkH7/RGo8SpKkQsQUqU0KXr1m1fZMN5WJWwnjQY5RDOlmGvM9y5WGMS/j5vFbGte+/0x 53GdjReSaR0gjKku0oh/tv2F1R4RkCOGgyTgdibdjx6dLn+Y6tVjGKBDZ6o0TYVoPAsT Zv8pRA7UN39qIEA7StuKtzYw73Cvt2z8dlSo/uiBAHqB7+GRJ8Qdd5NO0R0abLxqERL2 Z0AA== 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=NOHoPZUPYjQ9vD3Ru1clAPKfzsfIyc1VPy0+j91rsCQ=; b=XzyzVTnG1erUn7yXwLGCcjGKJdnRj/OGg6cKtFjxgaI0nFeydb2wadXKNi7UtyC0mM GNiQWGB8RQJrXN4rr47IFRSIlM/fPo3l12V5PDO//G0DMilDj+QhxbzEkSgUuxZp3Poj 7D/f1hCNE11CI3s2joV1es5tPa3FmmQjbirHmtl7/SRlxb8Jqroc9orlQaDpk+tO0Gf2 dAPd55N0cws4RoDQdrjm3zdBRA+AxBJeN+XjkvE6bvkKeWR1dKlLWJ/P5KcjvnV7Is63 6dhnhrnSjGSuDfaHGN3MQeFrFA8I6tLJfTx7dteBusgCeAq9echiZ3W/Vo9cP9TpePEg HRiQ== X-Gm-Message-State: AKS2vOxRLRg44/BUAGx9aV5IljyJuruT/ZWtoACWjagKHU9DDrnsqY+q BkFwwKJavc5tEYsfl1SRzk+xTCFOww== X-Received: by 10.46.77.70 with SMTP id a67mr4127680ljb.103.1498684369910; Wed, 28 Jun 2017 14:12:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Wed, 28 Jun 2017 14:12:49 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 28 Jun 2017 14:12:49 -0700 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Ian Swett Cc: Patrick McManus , 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: Wed, 28 Jun 2017 21:12:53 -0000 On 28 June 2017 at 14:10, Ian Swett wrote: > Would only supporting 18 cause problems for anyone? Anyone using OpenSSL would have a real hard time. From nobody Wed Jun 28 14:13: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 6A20112EA6A for ; Wed, 28 Jun 2017 14:13:39 -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 LQCGXF8O0iyG for ; Wed, 28 Jun 2017 14:13:38 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 07BFB12EC58 for ; Wed, 28 Jun 2017 14:13:38 -0700 (PDT) Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com [209.85.216.169]) by linode64.ducksong.com (Postfix) with ESMTPSA id A601A3A0A0 for ; Wed, 28 Jun 2017 17:13:36 -0400 (EDT) Received: by mail-qt0-f169.google.com with SMTP id f92so60062911qtb.2 for ; Wed, 28 Jun 2017 14:13:36 -0700 (PDT) X-Gm-Message-State: AKS2vOxktxIj3/4yZ/3nfC/aZcO2iNAOBH4VFXqC7nh1LxW2mW/efL+V U/k7JvIP9tgjxjHdXRg/eziyP3AppA== X-Received: by 10.237.61.153 with SMTP id i25mr16029877qtf.239.1498684416470; Wed, 28 Jun 2017 14:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.85 with HTTP; Wed, 28 Jun 2017 14:13:35 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Wed, 28 Jun 2017 14:13:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Martin Thomson Cc: Ian Swett , Patrick McManus , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113b859a46347105530ba841" 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, 28 Jun 2017 21:13:39 -0000 --001a113b859a46347105530ba841 Content-Type: text/plain; charset="UTF-8" and now we see the reason we have a problem :) On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson wrote: > On 28 June 2017 at 14:10, Ian Swett wrote: > > Would only supporting 18 cause problems for anyone? > > > Anyone using OpenSSL would have a real hard time. > --001a113b859a46347105530ba841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
and now we see the reason we have a problem :)

On Wed, Jun 28, 201= 7 at 2:12 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 28 June 201= 7 at 14:10, Ian Swett <ianswett@g= oogle.com> wrote:
> Would only supporting 18 cause problems for anyone?


Anyone using OpenSSL would have a real hard time.

--001a113b859a46347105530ba841-- From nobody Wed Jun 28 15:26:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47A112EC7B for ; Wed, 28 Jun 2017 15:26:44 -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 PB3isQK23-9z for ; Wed, 28 Jun 2017 15:26:41 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0130.outbound.protection.outlook.com [104.47.32.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE381126CB6 for ; Wed, 28 Jun 2017 15:26:40 -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=A0Hpv37HStGE5jG6SaIeV7lk2GZrxT5v5bUnNRYgjQA=; b=DntYHmD9itrV6DRqc9wB/efFfSBu7dHW7tE0VeCc7pXYMa9t7rNulv4Cgb2EKqda03ngHxnJs7keHoi11soU6qx656bmcyhK+TNBcHideOmUvofgrpawUo0ZTE0mKMbKBmFM6bW7Z+vUYyp0CUsvuJkHx8auZvs0sqhvS3vQY24= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0126.namprd21.prod.outlook.com (10.173.52.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.5; Wed, 28 Jun 2017 22:26:38 +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.1240.006; Wed, 28 Jun 2017 22:26:38 +0000 From: Mike Bishop To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Jo Kulik , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: QUIC WG , Dmitri Tikhonov Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K+GEgoMqpt2Pk2cfh8bhUTRCKI0Yv2AgATdKACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfOeQ Date: Wed, 28 Jun 2017 22:26:37 +0000 Message-ID: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::2c6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0126; 7:u4PSv+6c+zhYZ1pyimMFvB7NT3FL4/aEDp0VJa5Px2IJf2Sw2xtR8dGQccYgKxBJjioOOM9tCSw4ARgWBfkaoJfqUafcPVIi+vACC5mXarTj5cyF0cU2iAaFH6Gc66/oihdc3zguz4CjC2Eu9NeSx4+u3qedCJ8YYLCzHIeM8x4FY0BVtLU4rI4Snh3HnISWtqGMURnGADE2anYEPiUg4JfVYYms1ytg4osiKPOaJTiI7ve/i8sebcWDWwe8lhU08FYtT4NZS777nG1RtO5Gt7rqY8KwSWXaBpeo/oo/pIZ+B0svyX7UiMGFV0T+Aice/+ovVyDpqsN2zp6xRBo77ZfHp1m7wpqwWcekXvixYp7tc1XzniidojL21avVuxi52bBsWY/PjkYjcx6JiB1RJwqZVLzZ/IhB3te0GaiNZHFCNfNhWrToPcPZGbHTsZ+CMncCVJ/i+YcghyJ28v2V04744KlUfBbiSmV4EEWsWhkXwU85eUA09RNefm0lu4VqX0iRWA/zCwVmuOjxU8BUOy8/kn5r87sKWTYMmoFiLcQPqZS+wBQnE+uiPijzFX4V47oItxdg28Uf0OiRl+gy4jIFkh5WlsheSq4LJsfQeWyEKla5vxTDEmP7x5KaVujuW8D/3vpAroyswy63hgiAf+9HfeqMB6ZuPu9p2ZeH49RSfz3q+BHwn1SHABJpARvDhNerYxJj6P8c+3N1TmLUTUGdZ+Asiit08hwLOyjSm376+8ZUl6YtK6ga2PWIpyRXYK+WHKz+nim2k0p70je7PCtFj9IUdr0rCrY/77WBpxaMx/rbYOQXNSAro3VI10iH x-ms-office365-filtering-correlation-id: 0dd65484-60bd-4c06-423b-08d4be74be1e 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)(2017052603015)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0126; x-ms-traffictypediagnostic: MWHPR21MB0126: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(158342451672863)(133145235818549)(278428928389397)(166708455590820)(26388249023172)(236129657087228)(192374486261705)(211936372134217)(148574349560750); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(2017060910014)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0126; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0126; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39400400002)(39450400003)(39860400002)(39840400002)(377454003)(24454002)(790700001)(102836003)(3280700002)(6116002)(561944003)(53546010)(14454004)(2906002)(189998001)(3660700001)(93886004)(606006)(99286003)(236005)(54896002)(74316002)(54906002)(53936002)(55016002)(39060400002)(72206003)(2900100001)(38730400002)(6246003)(9686003)(6306002)(966005)(478600001)(8990500004)(5005710100001)(10290500003)(25786009)(7116003)(3480700004)(6436002)(7736002)(6506006)(33656002)(229853002)(4326008)(10090500001)(77096006)(7696004)(19609705001)(50986999)(86362001)(81166006)(54356999)(8676002)(5660300001)(2950100002)(76176999)(8936002)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0126; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0141BD23011EB26F882C864787DD0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 22:26:38.0282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0126 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, 28 Jun 2017 22:26:45 -0000 --_000_MWHPR21MB0141BD23011EB26F882C864787DD0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgcHJvbWlzZWQsIGEgUFIgZm9yIGFkZGluZyDigJxhc3NvY2lhdGVkIHN0cmVhbXPigJ0gaXMg YXQgaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzY3Mi4gIFRoaXMg dmVyeSBkZWxpYmVyYXRlbHkgYnVpbGRzIG9uIHRvcCBvZiBNVOKAmXMgUFIg4oCTIGl04oCZcyBh ZGRpbmcgYSBwcmltaXRpdmUgd2hpY2ggY2FuIGJlIHVzZWQgdG8gY29uc3RydWN0IHZhcmlvdXMg YWJzdHJhY3Rpb25zIGF0b3AgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcywgYnV0IHRoZSBsaWZlY3lj bGUgaXMgc3RpbGwgZnVuZGFtZW50YWxseSB1bmlkaXJlY3Rpb25hbC4NCg0KQ29weWluZyBteSBu b3RlcyBoZXJlIGZvciBsaXN0IGRpc2N1c3Npb24gcHVycG9zZXMuDQpNYWpvciBjaGFuZ2VzDQpM ZXZlcmFnaW5nIEBpZ29ybG9yZDxodHRwczovL2dpdGh1Yi5jb20vaWdvcmxvcmQ+J3MgaW5zaWdo dCB0aGF0IE9PPTAwIG9ubHkgb2NjdXJzIG9uIHRoZSBmaXJzdCBTVFJFQU0gZnJhbWUgb2YgYSBz dHJlYW0sIEkgdXNlZCB0aGF0IGFzIHRoZSB0cmlnZ2VyIGZvciBhIFN0cmVhbSBQcm9wZXJ0aWVz IGJ5dGUuIFR3byBiaXRzIG9mIHRoYXQgYnl0ZSBkZXNjcmliZSB0aGUgZGlyZWN0aW9uYWxpdHkg b2YgdGhlIHN0cmVhbToNCg0KICAqICAgVW5pZGlyZWN0aW9uYWwgKG5vIHJlc3BvbnNlIGV4cGVj dGVkKQ0KICAqICAgSW5pdGlhbCBiaWRpcmVjdGlvbmFsIChvbmUgcmVzcG9uc2UgZXhwZWN0ZWQp DQogICogICBJbml0aWFsIG11bHRpLXJlc3BvbnNlIChvbmUgb3IgbW9yZSByZXNwb25zZXMgZXhw ZWN0ZWQ7IG5lZWRzIGEgYmV0dGVyIG5hbWUpDQogICogICBSZXNwb25zZQ0KSWYgdGhlIHR5cGUg aXMgUmVzcG9uc2UsIHRoZXJlJ3MgYW4gQXNzb2NpYXRlZCBTdHJlYW0gSUQgZmllbGQsIGxlbmd0 aCBnaXZlbiBieSB0d28gbW9yZSBiaXRzIGZvbGxvd2luZyB0aGUgc2FtZSBwYXR0ZXJuIGFzIHRo ZSBTUyBiaXRzIGluIHRoZSBTVFJFQU0gZnJhbWUgSUQuDQpQZXJzb25hbCBPcGluaW9uDQpPbiB0 aGUgcGx1cyBzaWRlLCB0aGVzZSBzdHJlYW0gdHlwZXMgc2VlbSB0byBjb3ZlciB0aGUgYWJzdHJh Y3Rpb25zIEkgY2FuIGVudmlzaW9uIGZvciBtb3N0IGFwcGxpY2F0aW9ucy4gWW91IGNhbiB1bmls YXRlcmFsbHkgc2VuZCBzb21ldGhpbmcgKHVuaWRpcmVjdGlvbmFsKSwgZG8gcmVxdWVzdC9yZXNw b25zZSAoYmlkaXJlY3Rpb25hbCksIG9yIHB1Yi9zdWIgKHNpbmdsZSBzdWJzY3JpcHRpb24gc3Ry ZWFtLCBzZXJpZXMgb2YgdXBkYXRlIHN0cmVhbXMpLg0KSSBkb24ndCBjYXJlIGZvciB0aGUgZmFj dCB0aGF0IEkgc3RpbGwgbmVlZCB0aGUgc3RyZWFtIHR5cGUgaGVhZGVyIGluIEhUVFAgYWZ0ZXIg cHV0dGluZyB0aGlzIGluIHRoZSB0cmFuc3BvcnQuIFRoYXQgd2lsbCBiZSBhbWVsaW9yYXRlZCBp ZiB3ZSBnbyBiYWNrIHRvIG9uZSBzdHJlYW0gcGVyIHJlcXVlc3QsIHNpbmNlIGFsbCB1bmlkaXJl Y3Rpb25hbCBzdHJlYW1zIHdpbGwgYmUgcHVzaCBzdHJlYW1zLiAoQXMgYSBzaWRlLW5vdGUsIEkg Y29uc2lkZXJlZCB1c2luZyB0aGUgbXVsdGlwbGUtcmVzcG9uc2Ugb3B0aW9uIGluIHRoZSBIVFRQ IG1hcHBpbmcsIGJ1dCB0aGVuIEkgbmVlZCBhIHN0cmVhbSBoZWFkZXIgYWdhaW4gdG8gaW5kaWNh dGUgd2hpY2ggaXMgdGhlIHJlc3BvbnNlIGFuZCB3aGljaCB0aGUgcHVzaGVzLikNCkkgcGFydGlj dWxhcmx5IGRvbid0IGxpa2UgdGhhdCB5b3Ugbm93IGhhdmUgdG8gbG9vayBhdCB0aGUgZnJhbWUg dHlwZSBoZWFkZXIgdG8gZmluZCBvdXQgd2hldGhlciBhIGZpZWxkIGV4aXN0cyB3aGljaCB0ZWxs cyB5b3UgdGhlIGxlbmd0aCBvZiBzb21ldGhpbmcgZWxzZSBpbiB0aGUgaGVhZGVyLiBJJ2QgbGlr ZSB0byBzaW1wbGlmeSB0aGF0LiBJIHdlbnQgd2l0aCB0aGlzIG1vZGVsIG92ZXIgYSBDUkVBVEVf U1RSRUFNIGZyYW1lIGJlY2F1c2Ugb2YgQG1pa2tlbGZqPGh0dHBzOi8vZ2l0aHViLmNvbS9taWtr ZWxmaj4ncyB1c2UtY2FzZSBvZiB2ZXJ5IHNtYWxsIG1lc3NhZ2VzIC0tIHRoaXMgYWRkcyBvbmx5 IG9uZSBieXRlIHRvIHRoZSBmaXJzdCBmcmFtZSBvbiBhIHN0cmVhbSBpbiBvbmUgZGlyZWN0aW9u IGFuZCAyLTUgYnl0ZXMgdG8gdGhlIGZpcnN0IGZyYW1lIG9mIHJlc3BvbnNlIHN0cmVhbXMuIEEg c2VwYXJhdGUgZnJhbWUgdHlwZSB3b3VsZCBiZSBzb21ld2hhdCBsYXJnZXIsIGJ1dCBjb3VsZCBi ZSBjbGVhbmVyIGluIHRoYXQgcmVzcGVjdC4NCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0g R0IvQ2FtYnJpZGdlLCBVSykNClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyOCwgMjAxNyA3OjU2IEFN DQpUbzogSm8gS3VsaWsgPGpva3VsaWtAZ29vZ2xlLmNvbT47IE1pa2tlbCBGYWhuw7hlIErDuHJn ZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCkNjOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsg RG1pdHJpIFRpa2hvbm92IDxkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+DQpTdWJqZWN0OiBS RTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQpJIGFncmVlIHRoYXQgbG9va2luZyBhdCB0 aGUgbGF5ZXJzIG9mIGFic3RyYWN0aW9uIGlzIHVzZWZ1bC4gSW4gcHJpbmNpcGxlIGhhdmluZyB0 aGUgd2lyZSBwcm90b2NvbCBqdXN0IGhhdmUgY29uc3RydWN0cyBmb3IgdW5pZGlyZWN0aW9uYWwg c3RyZWFtcyBkb2VzIG5vdCBpbiBpdHNlbGYgbGltaXQgY3JlYXRpbmcgYmktZGlyZWN0aW9uYWwg Y29tbXVuaWNhdGlvbiBmbG93cywgc3VwcG9ydGVkIGF0IGVpdGhlciB0aGUgbGlicmFyeSBvciBh cHBsaWNhdGlvbiBsYXllci4NCg0KSG93ZXZlciwgdGhlcmUgbmVlZCB0byBiZSBhIHN0YW5kYXJk IHdheSBvZiBkb2luZyBiaS1kaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uIGZvciBtaWdyYXRpbmcg YXBwbGljYXRpb25zIGltcGxlbWVudGVkIHVzaW5nIGEgc29ja2V0IHN0eWxlIGFwaS4gSXQgbmVl ZHMgdG8gYmUgZWFzeSB0byBtb3ZlIGFuIGV4aXN0aW5nIGFwcGxpY2F0aW9uIGZyb20gVENQIHRv IFFVSUMuIFRoaXMgbW92ZSBtYXkgYmUgYXR0cmFjdGl2ZSBpbiBtYW55IHNpdHVhdGlvbnMgYXMg UVVJQyBnaXZlcyBpbXByb3ZlZCBzZWN1cml0eSBhbmQgbWF5IGFsbG93IGdyZWF0ZXIgdGhyb3Vn aHB1dCBkdWUgdG8gdGhlIG1vcmUgbW9kZXJuIChhbmQgY3VzdG9taXphYmxlKSBjb25nZXN0aW9u IGNvbnRyb2wgYWxnb3JpdGhtcyBjb21wYXJlZCB0byB0aGUgT1MgVENQIHN0YWNrLg0KDQpGb3Ig bWlncmF0aW5nIHN0YW5kYXJkIHNvY2tldCBhcGkgYXBwbGljYXRpb25zIEkgZG9u4oCZdCB0aGlu ayBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBsZWF2ZSB0aGUgd29yayB0byB0aGUgYXBwbGlj YXRpb24gdG8gZG8gY29ycmVsYXRpb24sIGF0IGxlYXN0IHRoZSBsaWJyYXJ5IHNob3VsZCBiZSBw cm92aWRpbmcgdGhpcyBzZXJ2aWNlIHVzaW5nIHRoZSB3aXJlIHByb3RvY29sIGFzIGFwcHJvcHJp YXRlLiBDbGVhcmx5IHdlIHdhbnQgYSBjbGllbnQgd3JpdHRlbiB3aXRoIG9uZSBsaWJyYXJ5IHRv IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgc3VjY2Vzc2Z1bGx5IHdpdGggYSBzZXJ2ZXIgd3JpdHRl biB1c2luZyBhIGRpZmZlcmVudCBsaWJyYXJ5LiBUaGlzIG5lZWRzIHNvbWUgZm9ybSBvZiBzdGFu ZGFyZGl6YXRpb24gb2YgdGhlIHNpZ25hbGxpbmcuIFRoaXMgY291bGQgZWl0aGVyIGJlIGEgYnVp bGRpbmcgYmxvY2sgb3ZlcmxheSBvbiB0b3Agb2YgUVVJQywgb3IgaW1wbGVtZW50ZWQgYXQgdGhl IHdpcmUgcHJvdG9jb2wgbGV2ZWwuDQoNCkluIHRlcm1zIG9mIHBhdHRlcm5zIEkgdGhpbmsgdGhl IGZvbGxvd2luZyBtYXkgYmUgc29tZSBvZiB0aGUgbW9zdCBjb21tb24gcGF0dGVybnMgKHdpdGgg cG90ZW50aWFsIHRvIGJlIHByb3ZpZGVkIGF0IHRoZSBsaWJyYXJ5IGFuZCBvciB3aXJlIHByb3Rv Y29sIGxldmVsKS4NCkkvTyBwYXR0ZXJuICA6IEV4YW1wbGUNCjEvMCAgIDogQW4gaW5wdXQgb25s eSBmbG93LCBwZXJoYXBzIGEgZGF0YSBsb2dnZXIgbGlrZSBzeXNsb2cgd2l0aCBubyBjb25maXJt YXRpb24vZmVlZGJhY2sNCjAvMSAgOiBhbiBvdXRwdXQgb25seSBmbG93LCBwZXJoYXBzIGEgdG9w aWMgbWVzc2FnZSBidXMgc2VydmljZSB3aXRoIG5vIGNvbmZpcm1hdGlvbi9mZWVkYmFjaw0KMS8x IDogc3RhbmRhcmQgVENQIGFwcGxpY2F0aW9ucyB3aXRoIGEgc2luZ2xlIGZsb3cgcGVyIGNvbm5l Y3Rpb24NCjEvKiA6IHNpbmdsZSBpbnB1dCwgbWFueSBvdXRwdXQsIG1vZGVsbGluZyBTVERJTi9T VERPVVQrU1RERVJSDQooMS8xKSogOiBtdWx0aXBsZXhlZCBwYWlycyBvZiBmbG93cyDigJMgc3Vw cG9ydGluZyBtdWx0aXBsZSBzb2NrZXRzIG11eGVkIG9udG8gYSBzaW5nbGUgUVVJQyBjb25uZWN0 aW9uDQoNCk9idmlvdXNseSwgYW4gYXBwbGljYXRpb24gd291bGQgYWx3YXlzIGhhdmUgdGhlIG9w dGlvbiB0byBjb21iaW5lIGFueSBzaW5nbGUgZGlyZWN0aW9uIGZsb3dzIHdpdGggYXBwbGljYXRp b24gbGV2ZWwgY29ycmVsYXRvcnMgdG8gY29uc3RydWN0IG1vcmUgY29tcGxleCBmbG93cyBpZiBk ZXNpcmVkLg0KDQpBdCB0aGUgbW9tZW50IG15IGd1dCBzYXlzIHRoZSAxLzEgdXNlLWNhc2UgaXMg Y29tbW9uIGVub3VnaCB0aGF0IHRoZSB3aXJlIHByb3RvY29sIHNob3VsZCBwcm92aWRlIGEgc3Rh bmRhcmQgbWVjaGFuaXNtIHRvIHN1cHBvcnQgaXQgYXMgYSBzdGFuZGFyZCBvdmVybGF5IHdvdWxk IHByb2JhYmx5IGVuZCB1cCBiZWluZyB0cmVhdGVkIGFzIHBhcnQgb2YgdGhlIHdpcmUgZm9ybWF0 IGFueXdheS4NCg0KUGVyaGFwcyBzdHJlYW1zIHNob3VsZCBiZSBleHBsaWNpdGx5IGNyZWF0ZWQg d2l0aCBhIENSRUFURV9TVFJFQU0gZnJhbWUgd2hpY2ggd291bGQgYmUgY2FwYWJsZSBvZiBkZWZp bmluZyBtdWx0aXBsZSByZWxhdGVkIHN0cmVhbXM/DQpUaGVyZSBpcyB0aGUgb3B0aW9uIG9mIHdo ZXRoZXIgb25seSAoMS8xKSBwYWlycyBjYW4gYmUgY3JlYXRlZCB0aGlzIHdheSwgb3IgKDEvbikg Y29tYmluYXRpb25zIGNvdWxkIGJlIHN1cHBvcnRlZCAod2l0aCBhbiBhcHBsaWNhdGlvbiBkZWZp bmVkIHdheSB0byBpZGVudGlmeSB0aGUgdXNlIG9mIGVhY2ggb2YgdGhlIG91dHB1dCBzdHJlYW1z KS4gQSBzdGVwIGZ1cnRoZXIgbWF5IGJlIHRoYXQgdGhlcmUgaXMgYSB0cmFuc3BvcnQgcGFyYW1l dGVyIHRoYXQgZGVmaW5lcyB3aGV0aGVyIHRoZSBzZXJ2ZXIgaXMgYWxsb3dlZCB0byBjcmVhdGUg YWRkaXRpb25hbCBzdHJlYW1zLCBvciBpZiBzdHJlYW0gY3JlYXRpb24gaXMgcHVyZWx5IGNsaWVu dCBkcml2ZW4gKGxpa2UgVENQKS4gSSBkb27igJl0IGtub3cgaWYgZWl0aGVyIG9mIHRoZXNlIHdv dWxkIHNpbXBsaWZ5IGhvdyB0byBoYW5kbGUgc3RyZWFtIGFjY291bnRpbmcsIGFuZCBpbiBwYXJ0 aWN1bGFyIG9ubHkgY3JlYXRpbmcgYSBmbG93IHdoZW4gYWxsIHBhcnRpZXMgaGF2ZSBzdWZmaWNp ZW50IGFsbG93YW5jZXMgbGVmdC4NCg0KVGhvbWFzDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKbyBLdWxpaw0KU2VudDogMjggSnVuZSAy MDE3IDE1OjA5DQpUbzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwu Y29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+Pg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgRG1pdHJpIFRpa2hvbm92IDxkdGlraG9ub3ZAbGl0 ZXNwZWVkdGVjaC5jb208bWFpbHRvOmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbT4+DQpTdWJq ZWN0OiBSZTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQpJJ2QgbGlrZSB0byBwb3AgYmFj ayB1cCB0byBhIGNvbW1lbnQgSWdvciBtYWRlIGxhc3Qgd2VlaywgYmVjYXVzZSBJIGZpbmQgaXQg aGVscGZ1bCBpbiB0aGlua2luZyBhYm91dCB0aGUgZGVzaWduIHNwYWNlOg0KDQpJIHRoaW5rIG9m IHRocmVlIGxheWVycyBvZiBhYnN0cmFjdGlvbjoNCg0KMS4gICAgICAgUVVJQyBXaXJlIFByb3Rv Y29sICh0aGUgdGhpbmcgZGVzY3JpYmVkIGJ5IHRoZSBRVUlDIFRyYW5zcG9ydCBSRkMpDQoyLiAg ICAgICBRVUlDIExpYnJhcnkgQVBJIChhIGxpYnJhcnkgZXhwb3Npbmcgc29tZSB1c2VmdWwgYWJz dHJhY3Rpb25zIC0tIHN1Y2ggYXMgYmxvY2tpbmcvbm9uLWJsb2NraW5nIHVuaWRpcmVjdGlvbmFs IHN0cmVhbXMgYW5kIGJpZGlyZWN0aW9uYWwg4oCcc29ja2V0c+KAnSAtLSBhbmQgaW1wbGVtZW50 aW5nIHRoZW0gdXNpbmcgUVVJQyBXaXJlIFByb3RvY29sKQ0KMy4gICAgICAgQXBwbGljYXRpb24g KHNvbWV0aGluZyB0aGF0IHVzZXMgUVVJQyBMaWJyYXJ5IEFQSXMpDQpJIHRoaW5rIHRoZXJlIGlz IHNvbWUgYXJndW1lbnQgdG8gYmUgbWFkZSB0aGF0IE1hcnRpbidzIG9yaWdpbmFsIHByb3Bvc2Fs IGRpZCBub3QgdGFrZSBpbnRvIGFjY291bnQgaG93IHdlIHdvdWxkIGFjaGlldmUgKDIpIGZvciBi aS1kaXJlY3Rpb25hbCBzdHJlYW1zLiAgKEkgZG9uJ3QgdGhpbmsgaXQgc3RyaWN0bHkgc2FpZCAi dGhvdSBzaGFsdCBub3QgZG8gKDIpIiBlaXRoZXIsIGJ1dCB0aGF0IGlzIHVwIHRvIGludGVycHJl dGF0aW9uLikNCg0KU2V2ZXJhbCBwZW9wbGUgaGF2ZSBhcmd1ZWQgdGhhdCB3ZSBkbyBub3Qgd2Fu dCBldmVyeSBhcHBsaWNhdGlvbiB0byBoYXZlIHRvIHJlLWltcGxlbWVudCBiaS1kaXJlY3Rpb25h bCBzdHJlYW1zICgzKSBmb3IgZXZlcnkgYXBwbGljYXRpb24sIGFuZCB0aGlzIGlzIG5vdCBob3cg Zy1xdWljIChvdXIgbGFyZ2VzdCBkZXBsb3ltZW50KSB3b3JrcyByaWdodCBub3cuICBUaGVzZSBh cmd1bWVudHMgbWFrZSBzZW5zZSB0byBtZSwgYnV0IFlNTVYuDQoNCkp1c3QgYmVjYXVzZSB0aGUg cGFydGljdWxhciAqbWVjaGFuaXNtKiB0aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGhhcyBzb21lIGlz c3VlcywgaG93ZXZlciwgZG9lc24ndCBzY3JlYW0gb3V0IHRvIG1lLCBhdCBsZWFzdCwgdGhhdCB3 ZSBzaG91bGQgYWJhbmRvbiB0aGlzIHBhcnRpY3VsYXIgKmRlc2lnbiBnb2FsKi4gIFRoZSBnb2Fs IGJlaW5nIGEgdHJhbnNwb3J0IHByb3RvY29sIHRoYXQgY2FuIGVsZWdhbnRseSBmaXQgd2l0aCBh IHVuaS9iaSBzdHJlYW0gbW9kZWwuICBOb3csIGlmIHdlIGNvbmNsdWRlIHRoYXQgdGhlcmUgY2Fu IG5ldmVyIGJlIGFuIGVsZWdhbnQgbW9kZWwgdGhhdCBhY2hpZXZlcyB0aGlzIGdvYWwsIHRoZW4g c28gYmUgaXQuICBCdXQgSSBhbHNvIGZlZWwgbGlrZSB3ZSBoYXZlbid0IHJlYWNoZWQgdGhhdCBw b2ludCBpbiB0aGUgZGlzY3Vzc2lvbiB5ZXQuICAoQXQgdGhlIHZlcnkgbGVhc3QsIHRoaXMgZGlz Y3Vzc2lvbiBoYXMgYmVlbiBmcnVpdGZ1bCB0byBtZSBpbiB0ZXJtcyBvZiBtYXBwaW5nIHRoZSBk ZXNpZ24gc3BhY2UgYW5kIGVsdWNpZGF0aW5nIHJlcXVpcmVtZW50cykuDQoNCk9uZSBvZiB0aGUg cmVhc29ucyBJIHN0aWxsIHRoaW5rIHRoaXMgZGVzaWduIGdvYWwgaXMgdW5kZXIgY29uc2lkZXJh dGlvbiBpcyB0aGF0IElhbiBhbmQgSWdvci9NaWtlIGhhdmUgYmVlbiB0YWxraW5nIGFib3V0IGFs dGVybmF0ZSBzb2x1dGlvbnMgd2hpY2ggaGF2ZSBhIHNpbWlsYXIgZmxhdm9yLiAgRHVyaW5nIHRo ZSByZWNlbnQgInF1aWV0Im5lc3Mgb24gdGhlIHRocmVhZCwgcGVyc29uYWxseSwgSSd2ZSBiZWVu IHdhaXRpbmcgdG8gaGVhciBtb3JlIGZyb20gdGhlbS4NCg0KT24gV2VkLCBKdW4gMjgsIDIwMTcg YXQgOTo0MSBBTSwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29t PG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiB3cm90ZToNCkluIHJlcGx5IHRvIFJhbmplZXRo DQoNCkl0IGlzIG5vdCBvbmx5IGEgbWF0dGVyIG9mIHNpbXBsaWNpdHkgZm9yIHRoZSBzYWtlIG9m IHNpbXBsaWNpdHk6DQoNCi0gQSBjb21wbGV4IHRyYW5zcG9ydCBsYXllciBtaWdodCBlbmQgdXAg YmVpbmcgcG9vcmx5IGltcGxlbWVudGVkIGxlYWRpbmcgdG8gcmVkdWNlZCBpbnRlcm9wZXJhYmls aXR5IGFuZCB1bHRpbWF0ZWx5IGFkb3B0aW9uLiBUaGlzIGNvbXBsZXhpdHkgaXMgbm90IG9ubHkg aW4gaW1wbGVtZW50YXRpb24gYnV0IGFsc28gaW4gdW5kZXJzdGFuZGluZyB0aGUgZXhhY3Qgc2Vt YW50aWNzIG9mIHN0cmVhbSBsaWZldGltZS4gRXZlbiBpZiB0aGUgc3BlYyBpcyBzdWZmaWNpZW50 bHkgY2xlYXIsIGl0IHdpbGwgc3RpbGwgYmUgb3BlbiB0byBtaXNpbnRlcnByZXRhdGlvbnMuDQoN Ci0gQmktZGlyZWN0aW9uYWwgc3RhdGUgbWF5IGhhdmUgdG8gYmUgbWFpbnRhaW5lZCBsb25nZXIg YW5kIHdpdGggbW9yZSBvdmVyaGVhZCB0aGFuIHdpdGggdW5pLWRpcmVjdGlvbmFsIHN0cmVhbXMs IGVzcGVjaWFsbHkgdW5kZXIgbG9zcywgcG90ZW50aWFsbHkgbGVhZGluZyB0byBwb29yIHBlcmZv cm1hbmNlIGFuZCBwb29yIHJlc291cmNlIHV0aWxpc2F0aW9uIGJlY2F1c2UgdGhlIHRyYW5zcG9y dCBsYXllciBoYXMgaW5zdWZmaWNpZW50IGluZm9ybWF0aW9uLg0KDQotIFRoZSBleHRyYSBjb21w bGV4aXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBtYXkgYmUgb3ZlcnN0YXRlZCAtIGl0IGlz IHNpZ25pZmljYW50bHkgc2ltcGxlciB0byBtYW5hZ2UgYSBtYXAgdGhhdCBhc3NvY2lhdGVzIHRv IHR3byBzdHJlYW1zIHRoYW4gaXQgaXMgdG8gbWFpbnRhaW4gYmktZGlyZWN0aW9uYWwgc3RhdGUg YXQgdGhlIHRyYW5zcG9ydCBsYXllci4gSXQgaXMgZXZlbiBwb3NzaWJsZSB0byBpbXBsaWNpdGx5 IGxpbmsgc3RyZWFtcyB3aXRoIHNhbWUgaWRlbnRpZmllcnMsIGUuZy4gaW4gYSBSUEMgc2NlbmFy aW8uIFRoYXQgc2FpZCwgSSBkbyBzZWUgYSBwb3RlbnRpYWwgYmVuZWZpdCBvZiBhIHdyYXBwZXIg dGhhdCBpbXBsZW1lbnRzIHRoZSBjb21tb24gYmktZGlyZWN0aW9uYWwgY2FzZS4NCg0KLSBDb21w bGV4aXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBtYXkgYmUgZHVwbGljYXRlZCwgYnV0IGlt cGxlbWVudGF0aW9uIGVycm9ycyBhcmUgYWxzbyBpc29sYXRlZCB0byB0aGF0IGFwcGxpY2F0aW9u LiBTcGVjaWZpY2FsbHkgZm9yIEhUVFAgSSB3b3VsZCBhc3N1bWUgdGhhdCBRVUlDIHRyYW5zcG9y dCBhbmQgUVVJQyBIVFRQIGltcGxlbWVudGVycyB3b3VsZCBiZSBsYXJnZSB0aGUgc2FtZSBmb3Ig YSBsb25nIHRpbWUgdG8gY29tZSwgc28gSSB3b3VsZCBub3QgZXhwZWN0IHRoZSB0cmFkZW9mZiBo ZXJlIHRvIGJlIHBhcnRpY3VsYXJseSBjb25jZXJuaW5nLg0KDQotIFVuaXggcGlwZXMgYXJlIHRy YWRpdGlvbmFsbHkgY29uc3RydWN0ZWQgYXMgYSBwYWlyIG9mIHVuaS1kaXJlY3Rpb25hbCBmaWxl IGRlc2NyaXB0b3JzIGFuZCB0aGF0IGlzIGEgcmVhc29uYWJseSBwcm92ZW4gbW9kZWwuIEPigJlz IHN0YW5kYXJkIGxpYnJhcnkgc3RkaW4sIHN0ZG91dCBhbmQgc3RkZXJyIGlzIGFuIGV4YW1wbGUg b2YgYW4gYXN5bW1ldHJpYyBtb2RlbCB3aXRoIGltcGxpY2l0IGxpbmthZ2UgYmV0d2VlbiB1bmkt ZGlyZWN0aW9uYWwgZmlsZSBkZXNjcmlwdG9ycy4NCg0KLSBUaGVyZSBhcmUgbG90cyBvZiB1c2Ug Y2FzZXMgZm9yIG5vbi1IVFRQIGxpa2UgY29ubmVjdGl2aXR5IC0gS2Fma2EgaGlnaCB2b2x1bWUg bWVzc2FnZSBxdWV1aW5nIGZvciBleGFtcGxlLiBUaGUgaW5kdXN0cnkgdHJlbmQgYXBwZWFycyB0 byBtb3ZlIHRvd2FyZHMgYXN5bmNocm9ub3VzIHByb2Nlc3NpbmcgYW5kIG1lc3NhZ2luZy4gSXQg ZGVwZW5kcyBvbiB3aGV0aGVyIHlvdSBsb29rIGF0IFFVSUMgYXMgYSBUQ1AgKyBUTFMgcmVwbGFj ZW1lbnQsIG9yIGFzIGEgSFRUUFMgLyBSRVNUIFJQQyByZXBsYWNlbWVudC4NCg0KLSBVbmktZGly ZWN0aW9uYWwgc3RyZWFtcyBtYXkgY3VycmVudGx5IGJlIHVucHJvdmVuIGluIHRoZSB3aWxkLCBi dXQgYSBwcm9wb3NhbCBpcyBuZWVkZWQgYmVmb3JlIGFuIGltcGxlbWVudGF0aW9uIGNhbiBiZSBt YWRlIGFuZCB0ZXN0ZXQuIEkgYWdyZWUgdGhhdCBpdCBpcyBlYXN5IHRvIGRlc2lnbiBpbnRvIHdy b25nIGFzc3VtcHRpb25zIHdpdGhvdXQgcmVhbCB3b3JsZCB0ZXN0aW5nLg0KDQotIFRoZXJlIHdp bGwgaG9wZWZ1bGx5IG5vdCBiZSBhIGxhcmdlIG51bWJlciBvZiBzdWNjZXNzb3JzIHRvIFFVSUMg LSBwZXJoYXBzIHNvbWUgcHVycG9zZSBzcGVjaWZpYyB2YXJpYW50cywgZS5nLiBmb3IgZW1iZWRk ZWQgdXNlLiBXaWRlc3ByZWFkIGFkYXB0YXRpb24gYW5kIGNvbXBhdGliaWxpdHkgaXMgdmVyeSBu ZWNlc3Nhcnkgc28gaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBRVUlDIGJlaW5nIHN1ZmZpY2llbnRs eSBzaW1wbGUgYW5kIGV4cHJlc3NpdmUgdG8gYWNoaWV2ZSB0aGlzIGdvYWwuIEEgcG9seW1vcmYg UVVJQyB3aWxsIG5vdCBhY2hpZXZlIHRoYXQgZ29hbC4gT24gdGhlIG90aGVyIGhhbmQsIGEgc29s aWQgUVVJQyBmb3VuZGF0aW9uIGNhbiBiZSB1c2VkIGZvciBhIGxhcmdlIG51bWJlciBvZiBhcHBs aWNhdGlvbiBwcm90b2NvbHMuDQoNCi0gRmluYWxseSwgaXQgbWF5IHR1cm4gb3V0IHRoYXQgdW5p LWRpcmVjdGlvbmFsIHN0cmVhbXMganVzdCBpcyBhIGJhZCBpZGVhIC0gSSBkb3VidCBpdCwgYnV0 IEkgZG8gYmVsaWV2ZSByZWFsIHdvcmxkIHRlc3RzIGFyZSBuZWVkZWQuDQoNCktpbmQgUmVnYXJk cywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiAyOCBKdW5lIDIwMTcgYXQgMTQu NDIuMzYsIERtaXRyaSBUaWtob25vdiAoZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29tPG1haWx0 bzpkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+KSB3cm90ZToNCk9uIFR1ZSwgSnVuIDI3LCAy MDE3IGF0IDAyOjMxOjM4UE0gLTA3MDAsIFJhbmplZXRoIEt1bWFyIERhc2luZW5pIHdyb3RlOg0K PiAyLiBXZSBhcmUgb3ZlcnBsYXlpbmcgdGhlIHNpbXBsaWNpdHkgb2YgZGVzaWduLiBFdmVuIGlm IHdlIGRlZW0gZGVwbG95bWVudA0KPiBleHBlcmllbmNlIG5vdCBhIGNvbmNlcm4sIGlmIGV2ZXJ5 IGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sIHRoYXQgbmVlZHMNCj4gc3VwcG9ydCBmb3IgYmlk aXJlY3Rpb25hbCBzdHJlYW1zIGhhcyB0byBpbXBsZW1lbnQgc29tZSBjb3JyZWxhdG9ycyBhbmQN Cj4gc3VjaCBhYm92ZSwgdGhhdCdzIGEgbmV0IG5lZ2F0aXZlIGluIHRlcm1zIG9mIGNvbXBsZXhp dHkuDQoNClRoaXMgaXMgYW4gaW1wb3J0YW50IHBvaW50OiB3ZSB3YW50IFFVSUMgYWRvcHRpb24g dG8gYmUgbWFkZSBlYXN5Lg0KQSBwcm9ncmFtIHRoYXQgc3BlYWtzIEhUVFAgdG9kYXkgc2hvdWxk IGJlIGFibGUgdG8gdXNlIGFuIGV4aXN0aW5nIFFVSUMNCmxpYnJhcnkgd2l0aG91dCBoYXZpbmcg dG8gZW11bGF0ZSBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgaW4gb3JkZXIgdG8gZml0DQppdCBpbnRv IEhUVFAgdXNhZ2UgcGF0dGVybi4gRm9yY2luZyBldmVyeSBvbmUgb2YgdGhlc2UgcHJvZ3JhbXMg dG8gZG8NCnRoaXMgaXMgY2VydGFpbmx5IGEgaHVyZGxlLg0KDQotIERtaXRyaS4NCg0K --_000_MWHPR21MB0141BD23011EB26F882C864787DD0MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5Oi1hcHBsZS1zeXN0ZW07fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNh IE5ldWUiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KaDENCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRp bmcgMSBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MjQuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQt d2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLmdt YWlsLW01NDIzNTk4MDc0NzA0Mzc5ODMybTY0MzU3MTczODg4NTI1NTcwNTdtc29saXN0cGFyYWdy YXBoLCBsaS5nbWFpbC1tNTQyMzU5ODA3NDcwNDM3OTgzMm02NDM1NzE3Mzg4ODUyNTU3MDU3bXNv bGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW01NDIzNTk4MDc0NzA0Mzc5ODMybTY0MzU3MTczODg4 NTI1NTcwNTdtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fNTQyMzU5 ODA3NDcwNDM3OTgzMm1fNjQzNTcxNzM4ODg1MjU1NzA1N21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm0xOTk1ODQ5NDQ2MzM0NjM2 MDk4YWlybWFpbG9uLCBsaS5tMTk5NTg0OTQ0NjMzNDYzNjA5OGFpcm1haWxvbiwgZGl2Lm0xOTk1 ODQ5NDQ2MzM0NjM2MDk4YWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOm1fMTk5NTg0OTQ0NjMz NDYzNjA5OGFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhlYWRpbmcxQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAxIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDEiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTYxOTk0NjEwNjsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MTQ1ODg0MzAzMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+QXMgcHJvbWlzZWQsIGEgUFIgZm9yIGFkZGluZyDigJxhc3NvY2lhdGVkIHN0cmVhbXPigJ0g aXMgYXQNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVs bC82NzIiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC82NzI8L2E+ LiZuYnNwOyBUaGlzIHZlcnkgZGVsaWJlcmF0ZWx5IGJ1aWxkcyBvbiB0b3Agb2YgTVTigJlzIFBS IOKAkyBpdOKAmXMgYWRkaW5nIGEgcHJpbWl0aXZlIHdoaWNoIGNhbiBiZSB1c2VkIHRvIGNvbnN0 cnVjdCB2YXJpb3VzIGFic3RyYWN0aW9ucyBhdG9wIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMsDQog YnV0IHRoZSBsaWZlY3ljbGUgaXMgc3RpbGwgZnVuZGFtZW50YWxseSB1bmlkaXJlY3Rpb25hbC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Q29weWluZyBteSBub3RlcyBoZXJlIGZvciBsaXN0IGRpc2N1c3Npb24g cHVycG9zZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6 cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgI0VBRUNFRiAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gNi4wcHQgMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6LjI1aW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjYuMjVwdDtib3JkZXI6bm9u ZTtwYWRkaW5nOjBpbiI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjIxLjBwdDtmb250LWZh bWlseTotYXBwbGUtc3lzdGVtO2NvbG9yOiMyNDI5MkUiPk1ham9yIGNoYW5nZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Oi1hcHBsZS1zeXN0ZW07Y29sb3I6IzI0MjkyRSI+TGV2ZXJhZ2luZw0KPGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL2lnb3Jsb3JkIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzI0MjkyRSI+ QGlnb3Jsb3JkPC9zcGFuPjwvYj48L2E+J3MgaW5zaWdodCB0aGF0IE9PPTAwIG9ubHkgb2NjdXJz IG9uIHRoZSBmaXJzdCBTVFJFQU0gZnJhbWUgb2YgYSBzdHJlYW0sIEkgdXNlZCB0aGF0IGFzIHRo ZSB0cmlnZ2VyIGZvciBhIFN0cmVhbSBQcm9wZXJ0aWVzIGJ5dGUuIFR3byBiaXRzIG9mIHRoYXQg Ynl0ZSBkZXNjcmliZSB0aGUNCiBkaXJlY3Rpb25hbGl0eSBvZiB0aGUgc3RyZWFtOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6IzI0MjkyRTttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LWFwcGxlLXN5c3RlbSI+ VW5pZGlyZWN0aW9uYWwgKG5vIHJlc3BvbnNlIGV4cGVjdGVkKTxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMjQyOTJFO21hcmdpbi10b3A6 Mi42NXB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTotYXBwbGUtc3lzdGVtIj5Jbml0aWFsIGJpZGlyZWN0aW9uYWwgKG9uZSByZXNwb25zZSBl eHBlY3RlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6IzI0MjkyRTttYXJnaW4tdG9wOjIuNjVwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LWFwcGxlLXN5c3RlbSI+SW5pdGlhbCBt dWx0aS1yZXNwb25zZSAob25lIG9yIG1vcmUgcmVzcG9uc2VzIGV4cGVjdGVkOyBuZWVkcyBhIGJl dHRlciBuYW1lKTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjojMjQyOTJFO21hcmdpbi10b3A6Mi42NXB0O21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotYXBwbGUtc3lzdGVtIj5SZXNwb25z ZTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6LWFwcGxlLXN5c3RlbTtjb2xvcjojMjQyOTJFIj5JZiB0aGUgdHlwZSBpcyBSZXNw b25zZSwgdGhlcmUncyBhbiBBc3NvY2lhdGVkIFN0cmVhbSBJRCBmaWVsZCwgbGVuZ3RoIGdpdmVu IGJ5IHR3byBtb3JlIGJpdHMgZm9sbG93aW5nIHRoZSBzYW1lIHBhdHRlcm4gYXMgdGhlIFNTIGJp dHMNCiBpbiB0aGUgU1RSRUFNIGZyYW1lIElELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3JkZXItYm90 dG9tOnNvbGlkICNFQUVDRUYgMS4wcHQ7cGFkZGluZzowaW4gMGluIDYuMHB0IDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4yNWluO21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0 OjI2LjI1cHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToyMS4wcHQ7Zm9udC1mYW1pbHk6LWFwcGxlLXN5c3RlbTtjb2xvcjojMjQyOTJFIj5QZXJz b25hbCBPcGluaW9uPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotYXBwbGUtc3lzdGVtO2NvbG9yOiMyNDI5MkUiPk9u IHRoZSBwbHVzIHNpZGUsIHRoZXNlIHN0cmVhbSB0eXBlcyBzZWVtIHRvIGNvdmVyIHRoZSBhYnN0 cmFjdGlvbnMgSSBjYW4gZW52aXNpb24gZm9yIG1vc3QgYXBwbGljYXRpb25zLiBZb3UgY2FuIHVu aWxhdGVyYWxseSBzZW5kIHNvbWV0aGluZw0KICh1bmlkaXJlY3Rpb25hbCksIGRvIHJlcXVlc3Qv cmVzcG9uc2UgKGJpZGlyZWN0aW9uYWwpLCBvciBwdWIvc3ViIChzaW5nbGUgc3Vic2NyaXB0aW9u IHN0cmVhbSwgc2VyaWVzIG9mIHVwZGF0ZSBzdHJlYW1zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi1hcHBsZS1zeXN0ZW07Y29sb3I6 IzI0MjkyRSI+SSBkb24ndCBjYXJlIGZvciB0aGUgZmFjdCB0aGF0IEkgc3RpbGwgbmVlZCB0aGUg c3RyZWFtIHR5cGUgaGVhZGVyIGluIEhUVFAgYWZ0ZXIgcHV0dGluZyB0aGlzIGluIHRoZSB0cmFu c3BvcnQuIFRoYXQgd2lsbCBiZSBhbWVsaW9yYXRlZA0KIGlmIHdlIGdvIGJhY2sgdG8gb25lIHN0 cmVhbSBwZXIgcmVxdWVzdCwgc2luY2UgYWxsIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgd2lsbCBi ZSBwdXNoIHN0cmVhbXMuIChBcyBhIHNpZGUtbm90ZSwgSSBjb25zaWRlcmVkIHVzaW5nIHRoZSBt dWx0aXBsZS1yZXNwb25zZSBvcHRpb24gaW4gdGhlIEhUVFAgbWFwcGluZywgYnV0IHRoZW4gSSBu ZWVkIGEgc3RyZWFtIGhlYWRlciBhZ2FpbiB0byBpbmRpY2F0ZSB3aGljaCBpcyB0aGUgcmVzcG9u c2UgYW5kDQogd2hpY2ggdGhlIHB1c2hlcy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 LWFwcGxlLXN5c3RlbTtjb2xvcjojMjQyOTJFIj5JIHBhcnRpY3VsYXJseSBkb24ndCBsaWtlIHRo YXQgeW91IG5vdyBoYXZlIHRvIGxvb2sgYXQgdGhlIGZyYW1lIHR5cGUgaGVhZGVyIHRvIGZpbmQg b3V0IHdoZXRoZXIgYSBmaWVsZCBleGlzdHMgd2hpY2ggdGVsbHMgeW91IHRoZSBsZW5ndGggb2Yg c29tZXRoaW5nIGVsc2UgaW4gdGhlIGhlYWRlci4NCiBJJ2QgbGlrZSB0byBzaW1wbGlmeSB0aGF0 LiBJIHdlbnQgd2l0aCB0aGlzIG1vZGVsIG92ZXIgYSBDUkVBVEVfU1RSRUFNIGZyYW1lIGJlY2F1 c2Ugb2YNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9taWtrZWxmaiI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMyNDI5MkUiPkBtaWtrZWxmajwvc3Bhbj48L2I+PC9hPidzIHVzZS1jYXNlIG9m IHZlcnkgc21hbGwgbWVzc2FnZXMgLS0gdGhpcyBhZGRzIG9ubHkgb25lIGJ5dGUgdG8gdGhlIGZp cnN0IGZyYW1lIG9uIGEgc3RyZWFtIGluIG9uZSBkaXJlY3Rpb24gYW5kIDItNSBieXRlcyB0byB0 aGUgZmlyc3QgZnJhbWUgb2YgcmVzcG9uc2Ugc3RyZWFtcy4NCiBBIHNlcGFyYXRlIGZyYW1lIHR5 cGUgd291bGQgYmUgc29tZXdoYXQgbGFyZ2VyLCBidXQgY291bGQgYmUgY2xlYW5lciBpbiB0aGF0 IHJlc3BlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlDIFtt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Td2luZGVs bHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKTxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIEp1bmUgMjgsIDIwMTcgNzo1NiBBTTxicj4NCjxiPlRvOjwvYj4gSm8gS3VsaWsg Jmx0O2pva3VsaWtAZ29vZ2xlLmNvbSZndDs7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0 O21pa2tlbGZqQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFFVSUMgV0cgJmx0O3F1aWNA aWV0Zi5vcmcmZ3Q7OyBEbWl0cmkgVGlraG9ub3YgJmx0O2R0aWtob25vdkBsaXRlc3BlZWR0ZWNo LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMg UFI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHRoYXQgbG9va2luZyBhdCB0aGUgbGF5ZXJz IG9mIGFic3RyYWN0aW9uIGlzIHVzZWZ1bC4gSW4gcHJpbmNpcGxlIGhhdmluZyB0aGUgd2lyZSBw cm90b2NvbCBqdXN0IGhhdmUgY29uc3RydWN0cyBmb3IgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBk b2VzIG5vdCBpbg0KIGl0c2VsZiBsaW1pdCBjcmVhdGluZyBiaS1kaXJlY3Rpb25hbCBjb21tdW5p Y2F0aW9uIGZsb3dzLCBzdXBwb3J0ZWQgYXQgZWl0aGVyIHRoZSBsaWJyYXJ5IG9yIGFwcGxpY2F0 aW9uIGxheWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhvd2V2 ZXIsIHRoZXJlIG5lZWQgdG8gYmUgYSBzdGFuZGFyZCB3YXkgb2YgZG9pbmcgYmktZGlyZWN0aW9u YWwgY29tbXVuaWNhdGlvbiBmb3IgbWlncmF0aW5nIGFwcGxpY2F0aW9ucyBpbXBsZW1lbnRlZCB1 c2luZyBhIHNvY2tldCBzdHlsZSBhcGkuIEl0IG5lZWRzIHRvIGJlDQogZWFzeSB0byBtb3ZlIGFu IGV4aXN0aW5nIGFwcGxpY2F0aW9uIGZyb20gVENQIHRvIFFVSUMuIFRoaXMgbW92ZSBtYXkgYmUg YXR0cmFjdGl2ZSBpbiBtYW55IHNpdHVhdGlvbnMgYXMgUVVJQyBnaXZlcyBpbXByb3ZlZCBzZWN1 cml0eSBhbmQgbWF5IGFsbG93IGdyZWF0ZXIgdGhyb3VnaHB1dCBkdWUgdG8gdGhlIG1vcmUgbW9k ZXJuIChhbmQgY3VzdG9taXphYmxlKSBjb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtcyBjb21w YXJlZCB0byB0aGUgT1MNCiBUQ1Agc3RhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Rm9yIG1pZ3JhdGluZyBzdGFuZGFyZCBzb2NrZXQgYXBpIGFwcGxpY2F0aW9u cyBJIGRvbuKAmXQgdGhpbmsgaXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gbGVhdmUgdGhlIHdv cmsgdG8gdGhlIGFwcGxpY2F0aW9uIHRvIGRvIGNvcnJlbGF0aW9uLCBhdCBsZWFzdCB0aGUgbGli cmFyeQ0KIHNob3VsZCBiZSBwcm92aWRpbmcgdGhpcyBzZXJ2aWNlIHVzaW5nIHRoZSB3aXJlIHBy b3RvY29sIGFzIGFwcHJvcHJpYXRlLiBDbGVhcmx5IHdlIHdhbnQgYSBjbGllbnQgd3JpdHRlbiB3 aXRoIG9uZSBsaWJyYXJ5IHRvIGJlIGFibGUgdG8gY29tbXVuaWNhdGUgc3VjY2Vzc2Z1bGx5IHdp dGggYSBzZXJ2ZXIgd3JpdHRlbiB1c2luZyBhIGRpZmZlcmVudCBsaWJyYXJ5LiBUaGlzIG5lZWRz IHNvbWUgZm9ybSBvZiBzdGFuZGFyZGl6YXRpb24gb2YgdGhlDQogc2lnbmFsbGluZy4gVGhpcyBj b3VsZCBlaXRoZXIgYmUgYSBidWlsZGluZyBibG9jayBvdmVybGF5IG9uIHRvcCBvZiBRVUlDLCBv ciBpbXBsZW1lbnRlZCBhdCB0aGUgd2lyZSBwcm90b2NvbCBsZXZlbC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0ZXJtcyBvZiBwYXR0ZXJucyBJIHRoaW5rIHRo ZSBmb2xsb3dpbmcgbWF5IGJlIHNvbWUgb2YgdGhlIG1vc3QgY29tbW9uIHBhdHRlcm5zICh3aXRo IHBvdGVudGlhbCB0byBiZSBwcm92aWRlZCBhdCB0aGUgbGlicmFyeSBhbmQgb3Igd2lyZSBwcm90 b2NvbCBsZXZlbCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SS9PIHBhdHRlcm4gJm5ic3A7OiBFeGFtcGxl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+MS8wJm5ic3A7Jm5ic3A7IDogQW4gaW5wdXQgb25seSBmbG93LCBw ZXJoYXBzIGEgZGF0YSBsb2dnZXIgbGlrZSBzeXNsb2cgd2l0aCBubyBjb25maXJtYXRpb24vZmVl ZGJhY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4wLzEmbmJzcDsgOiBhbiBvdXRwdXQgb25seSBmbG93LCBw ZXJoYXBzIGEgdG9waWMgbWVzc2FnZSBidXMgc2VydmljZSB3aXRoIG5vIGNvbmZpcm1hdGlvbi9m ZWVkYmFjazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEvMSA6IHN0YW5kYXJkIFRDUCBhcHBsaWNhdGlvbnMg d2l0aCBhIHNpbmdsZSBmbG93IHBlciBjb25uZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MS8qIDog c2luZ2xlIGlucHV0LCBtYW55IG91dHB1dCwgbW9kZWxsaW5nIFNURElOL1NURE9VVCYjNDM7U1RE RVJSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+KDEvMSkqIDogbXVsdGlwbGV4ZWQgcGFpcnMgb2YgZmxvd3Mg 4oCTIHN1cHBvcnRpbmcgbXVsdGlwbGUgc29ja2V0cyBtdXhlZCBvbnRvIGEgc2luZ2xlIFFVSUMg Y29ubmVjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9idmlv dXNseSwgYW4gYXBwbGljYXRpb24gd291bGQgYWx3YXlzIGhhdmUgdGhlIG9wdGlvbiB0byBjb21i aW5lIGFueSBzaW5nbGUgZGlyZWN0aW9uIGZsb3dzIHdpdGggYXBwbGljYXRpb24gbGV2ZWwgY29y cmVsYXRvcnMgdG8gY29uc3RydWN0IG1vcmUgY29tcGxleCBmbG93cw0KIGlmIGRlc2lyZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXQgdGhlIG1vbWVudCBteSBn dXQgc2F5cyB0aGUgMS8xIHVzZS1jYXNlIGlzIGNvbW1vbiBlbm91Z2ggdGhhdCB0aGUgd2lyZSBw cm90b2NvbCBzaG91bGQgcHJvdmlkZSBhIHN0YW5kYXJkIG1lY2hhbmlzbSB0byBzdXBwb3J0IGl0 IGFzIGEgc3RhbmRhcmQgb3ZlcmxheSB3b3VsZA0KIHByb2JhYmx5IGVuZCB1cCBiZWluZyB0cmVh dGVkIGFzIHBhcnQgb2YgdGhlIHdpcmUgZm9ybWF0IGFueXdheS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5QZXJoYXBzIHN0cmVhbXMgc2hvdWxkIGJlIGV4cGxpY2l0 bHkgY3JlYXRlZCB3aXRoIGEgQ1JFQVRFX1NUUkVBTSBmcmFtZSB3aGljaCB3b3VsZCBiZSBjYXBh YmxlIG9mIGRlZmluaW5nIG11bHRpcGxlIHJlbGF0ZWQgc3RyZWFtcz8NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPlRoZXJlIGlzIHRoZSBvcHRpb24gb2Ygd2hldGhlciBvbmx5ICgxLzEpIHBhaXJzIGNhbiBi ZSBjcmVhdGVkIHRoaXMgd2F5LCBvciAoMS9uKSBjb21iaW5hdGlvbnMgY291bGQgYmUgc3VwcG9y dGVkICh3aXRoIGFuIGFwcGxpY2F0aW9uIGRlZmluZWQgd2F5IHRvIGlkZW50aWZ5DQogdGhlIHVz ZSBvZiBlYWNoIG9mIHRoZSBvdXRwdXQgc3RyZWFtcykuIEEgc3RlcCBmdXJ0aGVyIG1heSBiZSB0 aGF0IHRoZXJlIGlzIGEgdHJhbnNwb3J0IHBhcmFtZXRlciB0aGF0IGRlZmluZXMgd2hldGhlciB0 aGUgc2VydmVyIGlzIGFsbG93ZWQgdG8gY3JlYXRlIGFkZGl0aW9uYWwgc3RyZWFtcywgb3IgaWYg c3RyZWFtIGNyZWF0aW9uIGlzIHB1cmVseSBjbGllbnQgZHJpdmVuIChsaWtlIFRDUCkuIEkgZG9u 4oCZdCBrbm93IGlmIGVpdGhlciBvZiB0aGVzZQ0KIHdvdWxkIHNpbXBsaWZ5IGhvdyB0byBoYW5k bGUgc3RyZWFtIGFjY291bnRpbmcsIGFuZCBpbiBwYXJ0aWN1bGFyIG9ubHkgY3JlYXRpbmcgYSBm bG93IHdoZW4gYWxsIHBhcnRpZXMgaGF2ZSBzdWZmaWNpZW50IGFsbG93YW5jZXMgbGVmdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaG9tYXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFFV SUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KbyBLdWxpazxicj4NCjxi PlNlbnQ6PC9iPiAyOCBKdW5lIDIwMTcgMTU6MDk8YnI+DQo8Yj5Ubzo8L2I+IE1pa2tlbCBGYWhu w7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPm1p a2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBRVUlDIFdHICZsdDs8YSBo cmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBEbWl0cmkg VGlraG9ub3YgJmx0OzxhIGhyZWY9Im1haWx0bzpkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20i PmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBSPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPkknZCBsaWtlIHRvIHBvcCBiYWNrIHVwIHRvIGEgY29tbWVudCBJZ29y IG1hZGUgbGFzdCB3ZWVrLCBiZWNhdXNlIEkgZmluZCBpdCBoZWxwZnVsIGluIHRoaW5raW5nIGFi b3V0IHRoZSBkZXNpZ24gc3BhY2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkkgdGhpbmsgb2YgdGhyZWUgbGF5ZXJzIG9mIGFic3RyYWN0aW9uOjxicj4NCiZu YnNwOzxicj4NCjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UVVJQyBXaXJlIFByb3RvY29sICh0aGUgdGhpbmcg ZGVzY3JpYmVkIGJ5IHRoZSBRVUlDIFRyYW5zcG9ydCBSRkMpPGJyPg0KMi48L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5RVUlDIExpYnJhcnkgQVBJIChhIGxpYnJhcnkgZXhwb3Npbmcgc29tZSB1c2VmdWwgYWJzdHJh Y3Rpb25zIC0tIHN1Y2ggYXMgYmxvY2tpbmcvbm9uLWJsb2NraW5nIHVuaWRpcmVjdGlvbmFsIHN0 cmVhbXMNCiBhbmQgYmlkaXJlY3Rpb25hbCDigJxzb2NrZXRz4oCdIC0tIGFuZCBpbXBsZW1lbnRp bmcgdGhlbSB1c2luZyBRVUlDIFdpcmUgUHJvdG9jb2wpPGJyPg0KMy48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5B cHBsaWNhdGlvbiAoc29tZXRoaW5nIHRoYXQgdXNlcyBRVUlDIExpYnJhcnkgQVBJcyk8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5J IHRoaW5rIHRoZXJlIGlzIHNvbWUgYXJndW1lbnQgdG8gYmUgbWFkZSB0aGF0IE1hcnRpbidzIG9y aWdpbmFsIHByb3Bvc2FsIGRpZCBub3QgdGFrZSBpbnRvIGFjY291bnQgaG93IHdlIHdvdWxkIGFj aGlldmUgKDIpIGZvciBiaS1kaXJlY3Rpb25hbCBzdHJlYW1zLiAmbmJzcDsoSSBkb24ndCB0aGlu ayBpdCBzdHJpY3RseSBzYWlkICZxdW90O3Rob3Ugc2hhbHQgbm90IGRvICgyKSZxdW90OyBlaXRo ZXIsDQogYnV0IHRoYXQgaXMgdXAgdG8gaW50ZXJwcmV0YXRpb24uKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+U2V2ZXJhbCBwZW9wbGUgaGF2ZSBhcmd1 ZWQgdGhhdCB3ZSBkbyBub3Qgd2FudCBldmVyeSBhcHBsaWNhdGlvbiB0byBoYXZlIHRvIHJlLWlt cGxlbWVudCBiaS1kaXJlY3Rpb25hbCBzdHJlYW1zICgzKSBmb3IgZXZlcnkgYXBwbGljYXRpb24s IGFuZCB0aGlzIGlzIG5vdCBob3cgZy1xdWljIChvdXIgbGFyZ2VzdCBkZXBsb3ltZW50KSB3b3Jr cyByaWdodCBub3cuJm5ic3A7IFRoZXNlIGFyZ3VtZW50cw0KIG1ha2Ugc2Vuc2UgdG8gbWUsIGJ1 dCBZTU1WLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ SnVzdCBiZWNhdXNlIHRoZSBwYXJ0aWN1bGFyICptZWNoYW5pc20qIHRoYXQgaXMgYmVpbmcgcHJv cG9zZWQgaGFzIHNvbWUgaXNzdWVzLCBob3dldmVyLCBkb2Vzbid0IHNjcmVhbSBvdXQgdG8gbWUs IGF0IGxlYXN0LCB0aGF0IHdlIHNob3VsZCBhYmFuZG9uIHRoaXMgcGFydGljdWxhciAqZGVzaWdu IGdvYWwqLiZuYnNwOyBUaGUgZ29hbCBiZWluZyBhIHRyYW5zcG9ydCBwcm90b2NvbCB0aGF0DQog Y2FuIGVsZWdhbnRseSBmaXQgd2l0aCBhIHVuaS9iaSBzdHJlYW0gbW9kZWwuJm5ic3A7IE5vdywg aWYgd2UgY29uY2x1ZGUgdGhhdCB0aGVyZSBjYW4gbmV2ZXIgYmUgYW4gZWxlZ2FudCBtb2RlbCB0 aGF0IGFjaGlldmVzIHRoaXMgZ29hbCwgdGhlbiBzbyBiZSBpdC4mbmJzcDsgQnV0IEkgYWxzbyBm ZWVsIGxpa2Ugd2UgaGF2ZW4ndCByZWFjaGVkIHRoYXQgcG9pbnQgaW4gdGhlIGRpc2N1c3Npb24g eWV0LiAmbmJzcDsoQXQgdGhlIHZlcnkgbGVhc3QsIHRoaXMgZGlzY3Vzc2lvbg0KIGhhcyBiZWVu IGZydWl0ZnVsIHRvIG1lIGluIHRlcm1zIG9mIG1hcHBpbmcgdGhlIGRlc2lnbiBzcGFjZSBhbmQg ZWx1Y2lkYXRpbmcgcmVxdWlyZW1lbnRzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPk9uZSBvZiB0aGUgcmVhc29ucyBJIHN0aWxsIHRoaW5rIHRoaXMg ZGVzaWduIGdvYWwgaXMgdW5kZXIgY29uc2lkZXJhdGlvbiBpcyB0aGF0IElhbiBhbmQgSWdvci9N aWtlIGhhdmUgYmVlbiB0YWxraW5nIGFib3V0IGFsdGVybmF0ZSBzb2x1dGlvbnMgd2hpY2ggaGF2 ZSBhIHNpbWlsYXIgZmxhdm9yLiZuYnNwOyBEdXJpbmcgdGhlIHJlY2VudCAmcXVvdDtxdWlldCZx dW90O25lc3Mgb24gdGhlIHRocmVhZCwNCiBwZXJzb25hbGx5LCBJJ3ZlIGJlZW4gd2FpdGluZyB0 byBoZWFyIG1vcmUgZnJvbSB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+T24gV2VkLCBKdW4gMjgsIDIwMTcgYXQgOTo0MSBBTSwgTWlra2VsIEZh aG7DuGUgSsO4cmdlbnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5JbiByZXBseSB0byZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPlJh bmplZXRoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE5OTU4NDk0NDYzMzQ2MzYwOThibG9vcF9j dXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt XzE5OTU4NDk0NDYzMzQ2MzYwOThibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SXQgaXMgbm90IG9ubHkgYSBtYXR0 ZXIgb2Ygc2ltcGxpY2l0eSBmb3IgdGhlIHNha2Ugb2Ygc2ltcGxpY2l0eTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f MTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIEEgY29tcGxleCB0cmFuc3BvcnQg bGF5ZXIgbWlnaHQgZW5kIHVwIGJlaW5nIHBvb3JseSBpbXBsZW1lbnRlZCBsZWFkaW5nIHRvIHJl ZHVjZWQgaW50ZXJvcGVyYWJpbGl0eSBhbmQgdWx0aW1hdGVseSBhZG9wdGlvbi4gVGhpcyBjb21w bGV4aXR5IGlzIG5vdCBvbmx5IGluDQogaW1wbGVtZW50YXRpb24gYnV0IGFsc28gaW4gdW5kZXJz dGFuZGluZyB0aGUgZXhhY3Qgc2VtYW50aWNzIG9mIHN0cmVhbSBsaWZldGltZS4gRXZlbiBpZiB0 aGUgc3BlYyBpcyBzdWZmaWNpZW50bHkgY2xlYXIsIGl0IHdpbGwgc3RpbGwgYmUgb3BlbiB0byBt aXNpbnRlcnByZXRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtXzE5OTU4NDk0NDYzMzQ2MzYwOThibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE5OTU4NDk0NDYzMzQ2MzYwOThibG9vcF9j dXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+LSBCaS1kaXJlY3Rpb25hbCBzdGF0ZSBtYXkgaGF2ZSB0byBiZSBtYWludGFpbmVk IGxvbmdlciBhbmQgd2l0aCBtb3JlIG92ZXJoZWFkIHRoYW4gd2l0aCB1bmktZGlyZWN0aW9uYWwg c3RyZWFtcywgZXNwZWNpYWxseSB1bmRlciBsb3NzLCBwb3RlbnRpYWxseSBsZWFkaW5nDQogdG8g cG9vciBwZXJmb3JtYW5jZSBhbmQgcG9vciByZXNvdXJjZSB1dGlsaXNhdGlvbiBiZWNhdXNlIHRo ZSB0cmFuc3BvcnQgbGF5ZXIgaGFzIGluc3VmZmljaWVudCBpbmZvcm1hdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIFRoZSBleHRyYSBjb21wbGV4 aXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBtYXkgYmUgb3ZlcnN0YXRlZCAtIGl0IGlzIHNp Z25pZmljYW50bHkgc2ltcGxlciB0byBtYW5hZ2UgYSBtYXAgdGhhdCBhc3NvY2lhdGVzIHRvIHR3 byBzdHJlYW1zIHRoYW4gaXQgaXMgdG8NCiBtYWludGFpbiBiaS1kaXJlY3Rpb25hbCBzdGF0ZSBh dCB0aGUgdHJhbnNwb3J0IGxheWVyLiBJdCBpcyBldmVuIHBvc3NpYmxlIHRvIGltcGxpY2l0bHkg bGluayBzdHJlYW1zIHdpdGggc2FtZSBpZGVudGlmaWVycywgZS5nLiBpbiBhIFJQQyBzY2VuYXJp by4gVGhhdCBzYWlkLCBJIGRvIHNlZSBhIHBvdGVudGlhbCBiZW5lZml0IG9mIGEgd3JhcHBlciB0 aGF0IGltcGxlbWVudHMgdGhlIGNvbW1vbiBiaS1kaXJlY3Rpb25hbCBjYXNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i bV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi0gQ29tcGxleGl0eSBhdCB0aGUg YXBwbGljYXRpb24gbGF5ZXIgbWF5IGJlIGR1cGxpY2F0ZWQsIGJ1dCBpbXBsZW1lbnRhdGlvbiBl cnJvcnMgYXJlIGFsc28gaXNvbGF0ZWQgdG8gdGhhdCBhcHBsaWNhdGlvbi4gU3BlY2lmaWNhbGx5 IGZvciBIVFRQIEkgd291bGQgYXNzdW1lDQogdGhhdCBRVUlDIHRyYW5zcG9ydCBhbmQgUVVJQyBI VFRQIGltcGxlbWVudGVycyB3b3VsZCBiZSBsYXJnZSB0aGUgc2FtZSBmb3IgYSBsb25nIHRpbWUg dG8gY29tZSwgc28gSSB3b3VsZCBub3QgZXhwZWN0IHRoZSB0cmFkZW9mZiBoZXJlIHRvIGJlIHBh cnRpY3VsYXJseSBjb25jZXJuaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxv b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPi0gVW5peCBwaXBlcyBhcmUgdHJhZGl0aW9uYWxseSBjb25zdHJ1Y3RlZCBh cyBhIHBhaXIgb2YgdW5pLWRpcmVjdGlvbmFsIGZpbGUgZGVzY3JpcHRvcnMgYW5kIHRoYXQgaXMg YSByZWFzb25hYmx5IHByb3ZlbiBtb2RlbC4gQ+KAmXMgc3RhbmRhcmQgbGlicmFyeSBzdGRpbiwg c3Rkb3V0DQogYW5kIHN0ZGVyciBpcyBhbiBleGFtcGxlIG9mIGFuIGFzeW1tZXRyaWMgbW9kZWwg d2l0aCBpbXBsaWNpdCBsaW5rYWdlIGJldHdlZW4gdW5pLWRpcmVjdGlvbmFsIGZpbGUgZGVzY3Jp cHRvcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE5OTU4NDk0 NDYzMzQ2MzYwOThibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtXzE5OTU4NDk0NDYzMzQ2MzYwOThibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LSBU aGVyZSBhcmUgbG90cyBvZiB1c2UgY2FzZXMgZm9yIG5vbi1IVFRQIGxpa2UgY29ubmVjdGl2aXR5 IC0gS2Fma2EgaGlnaCB2b2x1bWUgbWVzc2FnZSBxdWV1aW5nIGZvciBleGFtcGxlLiBUaGUgaW5k dXN0cnkgdHJlbmQgYXBwZWFycyB0byBtb3ZlIHRvd2FyZHMgYXN5bmNocm9ub3VzDQogcHJvY2Vz c2luZyBhbmQgbWVzc2FnaW5nLiBJdCBkZXBlbmRzIG9uIHdoZXRoZXIgeW91IGxvb2sgYXQgUVVJ QyBhcyBhIFRDUCAmIzQzOyBUTFMgcmVwbGFjZW1lbnQsIG9yIGFzIGEgSFRUUFMgLyBSRVNUIFJQ QyByZXBsYWNlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f MTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4tIFVuaS1kaXJlY3Rpb25hbCBzdHJlYW1zIG1heSBjdXJyZW50bHkgYmUgdW5wcm92ZW4g aW4gdGhlIHdpbGQsIGJ1dCBhIHByb3Bvc2FsIGlzIG5lZWRlZCBiZWZvcmUgYW4gaW1wbGVtZW50 YXRpb24gY2FuIGJlIG1hZGUgYW5kIHRlc3RldC4gSSBhZ3JlZSB0aGF0IGl0IGlzDQogZWFzeSB0 byBkZXNpZ24gaW50byB3cm9uZyBhc3N1bXB0aW9ucyB3aXRob3V0IHJlYWwgd29ybGQgdGVzdGlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMz NDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1fMTk5NTg0OTQ0NjMzNDYzNjA5OGJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIFRoZXJl IHdpbGwgaG9wZWZ1bGx5IG5vdCBiZSBhIGxhcmdlIG51bWJlciBvZiBzdWNjZXNzb3JzIHRvIFFV SUMgLSBwZXJoYXBzIHNvbWUgcHVycG9zZSBzcGVjaWZpYyB2YXJpYW50cywgZS5nLiBmb3IgZW1i ZWRkZWQgdXNlLiBXaWRlc3ByZWFkIGFkYXB0YXRpb24gYW5kDQogY29tcGF0aWJpbGl0eSBpcyB2 ZXJ5IG5lY2Vzc2FyeSBzbyBpdCBtYWtlcyBzZW5zZSB0byBoYXZlIFFVSUMgYmVpbmcgc3VmZmlj aWVudGx5IHNpbXBsZSBhbmQgZXhwcmVzc2l2ZSB0byBhY2hpZXZlIHRoaXMgZ29hbC4gQSBwb2x5 bW9yZiBRVUlDIHdpbGwgbm90IGFjaGlldmUgdGhhdCBnb2FsLiBPbiB0aGUgb3RoZXIgaGFuZCwg YSBzb2xpZCBRVUlDIGZvdW5kYXRpb24gY2FuIGJlIHVzZWQgZm9yIGEgbGFyZ2UgbnVtYmVyIG9m IGFwcGxpY2F0aW9uDQogcHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj4tIEZpbmFsbHksIGl0IG1heSB0dXJuIG91dCB0aGF0IHVuaS1kaXJlY3Rpb25h bCBzdHJlYW1zIGp1c3QgaXMgYSBiYWQgaWRlYSAtIEkgZG91YnQgaXQsIGJ1dCBJIGRvIGJlbGll dmUgcmVhbCB3b3JsZCB0ZXN0cyBhcmUgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0ibV8xOTk1ODQ5NDQ2MzM0NjM2MDk4Ymxvb3Bfc2ln bl8xNDk4NjU0MDMyMzAwODgxOTIwIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlra2VsIEZh aG7DuGUgSsO4cmdlbnNlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTE5OTU4NDk0NDYzMzQ2MzYwOThh aXJtYWlsb24iPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiAyOCBKdW5lIDIwMTcgYXQgMTQuNDIuMzYs IERtaXRyaSBUaWtob25vdiAoPGEgaHJlZj0ibWFpbHRvOmR0aWtob25vdkBsaXRlc3BlZWR0ZWNo LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbTwvYT4pIHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5P biBUdWUsIEp1biAyNywgMjAxNyBhdCAwMjozMTozOFBNIC0wNzAwLCBSYW5qZWV0aCBLdW1hciBE YXNpbmVuaSB3cm90ZToNCjxicj4NCiZndDsgMi4gV2UgYXJlIG92ZXJwbGF5aW5nIHRoZSBzaW1w bGljaXR5IG9mIGRlc2lnbi4gRXZlbiBpZiB3ZSBkZWVtIGRlcGxveW1lbnQgPGJyPg0KJmd0OyBl eHBlcmllbmNlIG5vdCBhIGNvbmNlcm4sIGlmIGV2ZXJ5IGFwcGxpY2F0aW9uIGxheWVyIHByb3Rv Y29sIHRoYXQgbmVlZHMgPGJyPg0KJmd0OyBzdXBwb3J0IGZvciBiaWRpcmVjdGlvbmFsIHN0cmVh bXMgaGFzIHRvIGltcGxlbWVudCBzb21lIGNvcnJlbGF0b3JzIGFuZCA8YnI+DQomZ3Q7IHN1Y2gg YWJvdmUsIHRoYXQncyBhIG5ldCBuZWdhdGl2ZSBpbiB0ZXJtcyBvZiBjb21wbGV4aXR5LiA8YnI+ DQo8YnI+DQpUaGlzIGlzIGFuIGltcG9ydGFudCBwb2ludDogd2Ugd2FudCBRVUlDIGFkb3B0aW9u IHRvIGJlIG1hZGUgZWFzeS4gPGJyPg0KQSBwcm9ncmFtIHRoYXQgc3BlYWtzIEhUVFAgdG9kYXkg c2hvdWxkIGJlIGFibGUgdG8gdXNlIGFuIGV4aXN0aW5nIFFVSUMgPGJyPg0KbGlicmFyeSB3aXRo b3V0IGhhdmluZyB0byBlbXVsYXRlIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBpbiBvcmRlciB0byBm aXQgPGJyPg0KaXQgaW50byBIVFRQIHVzYWdlIHBhdHRlcm4uIEZvcmNpbmcgZXZlcnkgb25lIG9m IHRoZXNlIHByb2dyYW1zIHRvIGRvIDxicj4NCnRoaXMgaXMgY2VydGFpbmx5IGEgaHVyZGxlLiA8 YnI+DQo8YnI+DQotIERtaXRyaS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB0141BD23011EB26F882C864787DD0MWHPR21MB0141namp_-- From nobody Wed Jun 28 15:43:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB0512EC2A for ; Wed, 28 Jun 2017 15:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 EINz9_VfHram for ; Wed, 28 Jun 2017 15:43:34 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::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 B4E34129413 for ; Wed, 28 Jun 2017 15:43:34 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id b81so23640506yba.2 for ; Wed, 28 Jun 2017 15:43:34 -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=kWr+roZZX6DJ4HLcawJwNc75J+deDskJ04Q4I9iUdgw=; b=Yh+4KR1pSXOk1EvjhuPe3QiTpjgtVeuHen4y7r7Zmlwc8sBBmEW+6+ctz4O5TX/C7x SNAl/0kGRB9KUG4Ago8mph8CxDuMvx5aVkMVZ9t0rUXg7IHIHoO941p61lixYRWXth7H N9bQkYK0mjs65OkfuvV/ljZKfXL1m3VevfFspGur23VsKaTrbBFjxtxlRhkr0XCJA9T5 6fq3VJza+oHCj8OlhiYPMvmzZaW0rL68R3eW96MkqmuW+xEU1/winohoQlXTW0Y3WSn4 59rWQKE+cVGpvz1QDsYV9l5W0FsHZfb7OwrLlku/m7pJEeNHMnxztCN2etEma/7c6VMh RDew== 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=kWr+roZZX6DJ4HLcawJwNc75J+deDskJ04Q4I9iUdgw=; b=qCsKT5cS87ohyN3tK3k8DOb5KUGmCx4xjntShJweSFaySNKAc31KaYRGZsvBydrpPI e7eGLNO1lhpk9LB443yGCHt7XUsCpk0MAeBIsA+qAzRWWEQlTXzJHZiPcTEN7r2oMfPB MO+2vsA93vkgcsOvED9g1x2gn5GyBE64Fz4RqF+dQpYdIsH2TSa2zl6bWx/KJySNTj/3 Zd9v3JB5JaSx5+0xTmv9nvAwWLrIXszNsrf6IrqshsS27CoQYjzgodGi3AFa7hueQeDv Md/e0QJrVzpPfVHOUSzsq7fdoanEeqRuVTQBDYYlHX9c2bH6WvC2d1ND1kCzn5L/gl3X q2Zw== X-Gm-Message-State: AKS2vOw/tqlpNFcwjRtvAV29u6awwF8KXqh/MQ4qeJmO2/yQjAoJgKoS XEjNIQ84pD62YJGRcib+WV+RJTkWnWjh X-Received: by 10.37.118.210 with SMTP id r201mr10101885ybc.15.1498689813953; Wed, 28 Jun 2017 15:43:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 28 Jun 2017 15:42:53 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 28 Jun 2017 15:42:53 -0700 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Patrick McManus Cc: Martin Thomson , Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114bd4c8fd64f005530ce9d9" 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, 28 Jun 2017 22:43:36 -0000 --001a114bd4c8fd64f005530ce9d9 Content-Type: text/plain; charset="UTF-8" My understanding was that BoringSSL had a -20 branch, as NSS does. Is that incorrect? -Ekr On Wed, Jun 28, 2017 at 2:13 PM, Patrick McManus wrote: > and now we see the reason we have a problem :) > > On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson > wrote: > >> On 28 June 2017 at 14:10, Ian Swett wrote: >> > Would only supporting 18 cause problems for anyone? >> >> >> Anyone using OpenSSL would have a real hard time. >> > > --001a114bd4c8fd64f005530ce9d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My understanding was that BoringSSL had a -20 branch, as N= SS does. Is that incorrect?

-Ekr


On Wed, Jun 28, 2017 at 2:= 13 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
and now we see the reason we= have a problem :)

On Wed, Jun 28, 2017 at = 2:12 PM, Martin Thomson <martin.thomson@gmail.com> wr= ote:
On 28 June 2017 at 14:10, Ian = Swett <ianswett= @google.com> wrote:
> Would only supporting 18 cause problems for anyone?


Anyone using OpenSSL would have a real hard time.


--001a114bd4c8fd64f005530ce9d9-- From nobody Wed Jun 28 15:50: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 97ECF12EC2A for ; Wed, 28 Jun 2017 15:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, 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 tle5WOJBV5ms for ; Wed, 28 Jun 2017 15:50:28 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 87D901298BA for ; Wed, 28 Jun 2017 15:50:28 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id h22so43108322lfk.3 for ; Wed, 28 Jun 2017 15:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n10z2un5oy4NGeIoCDJW2wj1Z49/WMiRZ9H4pZKQCXI=; b=Vw88KXj+fsTBhVfdaLZQzCbVNHFM1EwMqYY+g4CmcAePunwPblKnyfgFFjPEiPvYjb Lu8lFU7gJQoQxBLDUYQw86gRhqwx6stpQ/tVyxYUbIRg19vtuqeZ/r/nSrdZJFpKwcRq hQdooW/7ys6Lr+X31q7hYdl3DJyqDQyLlIXhT5AoG46ijJPQMZoNIubXNnlXJX0ylpsk z550CMHCnQbtwbkDP8rubC+R95xU6FQfL0QmLY+RNssf3q7/jBtJJuqCizS1JPKshNZz EcQNNEwKyyjX+CAlOcjTsJuV4c2zKfOQkXKJU9yaAFQdpj7DfUjY1ZNuhOTWfdo9ZrBt zAAQ== 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=n10z2un5oy4NGeIoCDJW2wj1Z49/WMiRZ9H4pZKQCXI=; b=FsdxCFzTLAtGNBHNb1eIEST5Mc/a0Kf94dk0W8cYu9arzxf0vndEi5vBtXt+HzaB60 HgGLcYEiB8B2A2qA1kwXGTws4gIsDtK/DtBj/LdgphyBHOe3lbhuGTmLBHYKU6OlmY03 Y5QCoYOEb54nFkELquNr2K/AWIoVIwDVrLSIGEvNaW7Urk4HjvxgGIe4lkvj5X+Er4sb KlZF2A2vdcpRRnMDbEOoRB0KozC6uDn6JsG2hvt7dtQ14q6LKMWICza1zXFL1GrDcRMb TkIcfAR9oBao7jSypISgWm6KXmxTcGOOfpd8kxfOf3gVqTuLqXMzwcnKA0AnAGbDHQzM S06Q== X-Gm-Message-State: AKS2vOy3xbe5MUJWkHJ3Nqioc/DjYmvayg4YrztjWIiBNKlIGG+TkBhU akOiM5LC5jYRSI6+1T3WIsNjM4IMJWyK X-Received: by 10.46.77.193 with SMTP id c62mr3695322ljd.72.1498690226671; Wed, 28 Jun 2017 15:50:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.44.73 with HTTP; Wed, 28 Jun 2017 15:50:05 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 28 Jun 2017 15:50:05 -0700 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Eric Rescorla Cc: Patrick McManus , Ian Swett , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 22:50:31 -0000 https://boringssl.googlesource.com/boringssl/+refs does not show a -20 branch. On Wed, Jun 28, 2017 at 3:42 PM, Eric Rescorla wrote: > My understanding was that BoringSSL had a -20 branch, as NSS does. Is that > incorrect? > > -Ekr > > > On Wed, Jun 28, 2017 at 2:13 PM, Patrick McManus > wrote: >> >> and now we see the reason we have a problem :) >> >> On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson >> wrote: >>> >>> On 28 June 2017 at 14:10, Ian Swett wrote: >>> > Would only supporting 18 cause problems for anyone? >>> >>> >>> Anyone using OpenSSL would have a real hard time. >> >> > From nobody Wed Jun 28 16:28:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65820129466 for ; Wed, 28 Jun 2017 16:28:35 -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 jBcRfUCbG-6R for ; Wed, 28 Jun 2017 16:28:33 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 84E5412EB0B for ; Wed, 28 Jun 2017 16:28:32 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id z78so1783132lff.0 for ; Wed, 28 Jun 2017 16:28: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=ShsVmRjNh3opeNN8OGFYRQx/Uv8x0SLRt0EmTM//t+E=; b=g3QGDo0zRYD6UAV6zzxWB9JFSdvBUeSpioLhIoCAiPX0MRf8LgHrQYx3bujZ1lKCJc Z/e+TCdJKlq6dq4Twv3Or9MTu6v8QDgOUtAwqBHnyYUc6ShOM1lv+BgxjgIQ4+j06ViJ lbxE4IXcNsQtjd576Za/Uh4K4jD7cKKVDAOt56KmrAAbpYzcl/aA12ULmVY4aLRKPss7 BOpN+bTPLp1oNjFv28p7mAGjCiLuvjQGeKAOLSfIdy1+8WI2JDasErLurjhYF30U4/Ff mdltJRkZsog/osetD76IXAqc/4BLmEi6SG3lyisJvXIaVSY6GQrmfjTwHzH6Q6mi+EYG oEug== 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=ShsVmRjNh3opeNN8OGFYRQx/Uv8x0SLRt0EmTM//t+E=; b=MAyqM7mofjyxjl7WV6xiHT/Sg6jZ5NB2rpBACtTnGF5ETkyifsiOK2J24iYbaxkpZJ mG6GIy+ZflryDnFWESA6gT3nLEiaQHg20rKtIuusO9udzOU006erx5Xe2tZZUKJogI20 r94XP9FCsbBGQR7c1P+bBq6vWOiLz5ubT7+kfk3uMCO69l5xr7auXcVs20bcPSuZkZwC n8/ad307DumpUBAl363inI1n3cCl27mfvfvNeyz35wr7r0y2mBQurEr+FB3x8zwo3glT 3gdYmaWW7GXrCoPh47MIUACH9NkY9JdJCxrkVPhv8YuLOxV/KDlheEyrIK5PV+/YZX1b qvKA== X-Gm-Message-State: AKS2vOyumxz8igmVIiCVRYGea1zr5M3SDnyp1un571elN2aAaSkme5hZ 8ZeTmuFUUTzmnTcafa0jj4MDAcYmiA== X-Received: by 10.25.148.81 with SMTP id w78mr4276155lfd.169.1498692510667; Wed, 28 Jun 2017 16:28:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Wed, 28 Jun 2017 16:28:28 -0700 (PDT) In-Reply-To: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> From: Martin Thomson Date: Wed, 28 Jun 2017 16:28:28 -0700 Message-ID: Subject: Re: Unidirectional streams PR To: Mike Bishop Cc: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Jo Kulik , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Dmitri Tikhonov 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, 28 Jun 2017 23:28:35 -0000 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 =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 primitiv= e 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 STRE= AM > frame of a stream, I used that as the trigger for a Stream Properties byt= e. > 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 na= me) > Response > > If the type is Response, there's an Associated Stream ID field, length gi= ven > 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 HTT= P > after putting this in the transport. That will be ameliorated if we go ba= ck > 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 hea= der > to find out whether a field exists which tells you the length of somethin= g > else in the header. I'd like to simplify that. I went with this model ove= r a > CREATE_STREAM frame because of @mikkelfj's use-case of very small message= s > -- this adds only one byte to the first frame on a stream in one directio= n > and 2-5 bytes to the first frame of response streams. A separate frame ty= pe > 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 w= ould be > appropriate to leave the work to the application to do correlation, at le= ast > 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 eit= her > 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 protoc= ol > 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 sockets= muxed onto > a single QUIC connection > > > > Obviously, an application would always have the option to combine any sin= gle > direction flows with application level correlators to construct more comp= lex > 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 th= at > 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 partie= s > 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 RF= C) > 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 Protoc= ol) > 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 i= s > 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 aband= on > 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. Bu= t 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 t= he > 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 implementati= on > errors are also isolated to that application. Specifically for HTTP I wou= ld > 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 f= ile > descriptors and that is a reasonably proven model. C=E2=80=99s standard l= ibrary > stdin, stdout and stderr is an example of an asymmetric model with implic= it > 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 agr= ee > that it is easy to design into wrong assumptions without real world testi= ng. > > > > - There will hopefully not be a large number of successors to QUIC - perh= aps > some purpose specific variants, e.g. for embedded use. Widespread adaptat= ion > 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 ca= n > be used for a large number of application protocols. > > > > - Finally, it may turn out that uni-directional streams just is a bad ide= a - > 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 deployme= nt >> 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. > > From nobody Wed Jun 28 16:45: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 4D5AC12EC80 for ; Wed, 28 Jun 2017 16:44:59 -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 yzfi5nAZ_Iyk for ; Wed, 28 Jun 2017 16:44:57 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3022F12EC1A for ; Wed, 28 Jun 2017 16:44:57 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id s9so23853031ybe.3 for ; Wed, 28 Jun 2017 16:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RMFaTKoRdAPt2KyHKenv6nbQyJtFD2TS0zlKXBwXzZQ=; b=FypVBlyuAdx5rA1w+y4O7eHJyFUlSYMhA2rToiLXYglNjw1P5b+XmYCsrz7x1V+m4N sBaVuh9vpyZ1fg4Y/2E9wZoOwU1J/8rSweRqw4jQgMx+5R9ybno2mWmCvOBGHR+UR1Yp CxIz9YR3ev/9cw+m1KBgVxnFGFkwtXTWch37VG4Yz39PMLGhCyiI1tG8I2S5jZqa5Xaj othr0TK68ML34oMbYoe+pbX/7DAXCMpOR6BhqAxPcb7HWI8F24uMJe76G5rcRGEqfWah 4mSnFbuoSL5SWbupRp5TJvay6onuYnP1Tqfb3jyTj5dVwImNRMzu79b2i4g3lXYoF/Qa D+rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RMFaTKoRdAPt2KyHKenv6nbQyJtFD2TS0zlKXBwXzZQ=; b=atoOSPg7efKQOzf2tPPUeAIxlsYauhpRzvXTfWc4poR+A6BE+jPzEBtr31/3ZO0fN/ ClBZqYn0j+ETsofbAZJvlyku5Q81XAmsBWa5Vy0eICGcv1ihYWzCVAI9df2M86VRsHtb FWdj3N34T3v649w0nWOKFEKIzMrcs3I7ZZnP5W0IVtQXp6nwlC/c/77Who6rQ0SVUwZt Oxa7O+wQ3KQJzh4x9JO1JrniAx+O3xXh7k7sB5DLIFpKcX4R5/mKw3Qz7IOWgPtjKoRI 0XoAvLRWoSL+QpXddg5AZdV9Fiz3GIb/iIJl794yRM0XoOe8KnRIL0rRz+cNSiHjotSS AWFw== X-Gm-Message-State: AKS2vOxBFpj+JfSLNQAkGBDNP9ynPzKQnddBXPT3l24FJm/ln81HyHB3 //Fts46KQnkp/ytt9ANxIxN38nJu1XeB X-Received: by 10.37.182.9 with SMTP id r9mr8605396ybj.44.1498693496281; Wed, 28 Jun 2017 16:44:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steven Valdez Date: Wed, 28 Jun 2017 23:44:45 +0000 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Nick Harper , Eric Rescorla Cc: Ian Swett , IETF QUIC WG , Martin Thomson , Patrick McManus Content-Type: multipart/alternative; boundary="f403045e86c4797ac905530dc56f" 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, 28 Jun 2017 23:44:59 -0000 --f403045e86c4797ac905530dc56f Content-Type: text/plain; charset="UTF-8" While there was some work on draft 20 during the last IETF Hackathon, the code is far from complete and still needs lots of tests and the implementation of additional parts of the draft 20 changes, which unfortunately won't happen for a while due to other issues*. In general, it sounds like many TLS implementations at the very least have a copy of the draft 18 code, from the previous IETF Hackathons (NSS, OpenSSL, BoringSSL, etc) and it also sounds like at least other parties on the TLS WG list (implementations and tools, Wireshark, Apple, etc) have draft 18 reviewed in some form. -Steven * We've had a lot of issues actually deploying TLS 1.3 in the wild, and most of our focus has been on gathering information on the ecosystem intolerance and how to avoid it, and will likely continue prioritizing that for the near future so we can give feedback to the TLS WG. On Wed, Jun 28, 2017 at 6:50 PM Nick Harper wrote: > https://boringssl.googlesource.com/boringssl/+refs does not show a -20 > branch. > > On Wed, Jun 28, 2017 at 3:42 PM, Eric Rescorla wrote: > > My understanding was that BoringSSL had a -20 branch, as NSS does. Is > that > > incorrect? > > > > -Ekr > > > > > > On Wed, Jun 28, 2017 at 2:13 PM, Patrick McManus > > wrote: > >> > >> and now we see the reason we have a problem :) > >> > >> On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson < > martin.thomson@gmail.com> > >> wrote: > >>> > >>> On 28 June 2017 at 14:10, Ian Swett wrote: > >>> > Would only supporting 18 cause problems for anyone? > >>> > >>> > >>> Anyone using OpenSSL would have a real hard time. > >> > >> > > > > --f403045e86c4797ac905530dc56f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While there was some work on draft 20 during the last IETF= Hackathon, the code is far from complete and still needs lots of tests and= the implementation of additional parts of the draft 20 changes, which unfo= rtunately won't happen for a while due to other issues*.

=
In general, it sounds like many TLS implementations at the very least = have a copy of the draft 18 code, from the previous IETF Hackathons (NSS, O= penSSL, BoringSSL, etc) and it also sounds like at least other parties on t= he TLS WG list (implementations and tools, Wireshark, Apple, etc) have draf= t 18 reviewed in some form.

-Steven

=
* We've had a lot of issues actually deploying TLS 1.3 in th= e wild, and most of our focus has been on gathering information on the ecos= ystem intolerance and how to avoid it, and will likely continue prioritizin= g that for the near future so we can give feedback to the TLS WG.

On We= d, Jun 28, 2017 at 6:50 PM Nick Harper <nharper@google.com> wrote:
https://boringssl.googlesou= rce.com/boringssl/+refs does not show a -20 branch.

On Wed, Jun 28, 2017 at 3:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> My understanding was that BoringSSL had a -20 branch, as NSS does. Is = that
> incorrect?
>
> -Ekr
>
>
> On Wed, Jun 28, 2017 at 2:13 PM, Patrick McManus <pmcmanus@mozilla.com>
> wrote:
>>
>> and now we see the reason we have a problem :)
>>
>> On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>>
>>> On 28 June 2017 at 14:10, Ian Swett <ianswett@google.com> wrote:
>>> > Would only supporting 18 cause problems for anyone?
>>>
>>>
>>> Anyone using OpenSSL would have a real hard time.
>>
>>
>

--f403045e86c4797ac905530dc56f-- From nobody Wed Jun 28 17:00: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 2BBA8126C23 for ; Wed, 28 Jun 2017 17:00:12 -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 WUHqw2HNiy1H for ; Wed, 28 Jun 2017 17:00:10 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 990F1124D85 for ; Wed, 28 Jun 2017 17:00:10 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id c73so41073647pfk.2 for ; Wed, 28 Jun 2017 17:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yyRNROt6W5RJn7cfKBBk3JJNCgeE0tS4J6sHiBmvM64=; b=ORimAFBeq/mk7jiJc/FZ+1xMjSXjVwwDQLxviAYdfLLUI/kO23dwzwz0TII4wpYn/Y fVX+pd6WUGRFDBApUpHL66Odh58U17hugVPWLhxwi3Bh32K98dJ1boQBvrH4eRvuGdhR kZh137fqXx1d9mtjPh1+UbhVG3xwJ1EOu97SSO2znwuPr4KGIAXCf/skg/n+nNQCsapE no9pGRbmWG0q4jOpJpqyunvMoxjUap1AyjcTVR47qlp/us0rJhKsMtNPx/M7lFVa3KWN JxjSVusmF21xuYemEqegFsJEJOY12zr8PG64GI9KiPUshrTH4nehZJY+60cxN55lYZhb /S3w== 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=yyRNROt6W5RJn7cfKBBk3JJNCgeE0tS4J6sHiBmvM64=; b=GepF1t+rTeMRyuNgtJRm0PcHWYS7Beujj3mp/ppPCAp3QdYVBZfbLBvnbmBHtrsSCs Wua8vJ+mwLzg4sN/UX8UeKLj2dKMm+toMJQ69nLwlwE9sj9FfZgPUjV4ONrxERgSF52N yNghp7ar07ufGpg3WBkc7uIIrY6EvPvsjU1x3LAe04yVZm/GZMSlbjG0vWgbWp6wyc3j WZsXTPadEO46bbiuc2WhUE9YDPgNqJA7EtwRS3E4VSff52Mm4z8JuNt8uFTGee5L+L5T u4Cqa3JmxRmTrk18CZm42v0sb/2pthIwm629yAdNUWyXUuFC7UPJ193usqHh1Bh6pCVC dnRA== X-Gm-Message-State: AKS2vOyH0ml5KJ4HNqG4Rq72+0WytOIDKpn143VTtkf/vSfpwX35aBGL 26iHea7c8Ujg/hpSGOPMP+qN0JaPKPdd X-Received: by 10.98.28.71 with SMTP id c68mr13557053pfc.116.1498694409914; Wed, 28 Jun 2017 17:00:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.176.133 with HTTP; Wed, 28 Jun 2017 17:00:09 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 28 Jun 2017 17:00:09 -0700 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Martin Thomson Cc: Ian Swett , IETF QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="94eb2c050446ee7ecf05530dfb1d" 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, 29 Jun 2017 00:00:12 -0000 --94eb2c050446ee7ecf05530dfb1d Content-Type: text/plain; charset="UTF-8" On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson wrote: > On 28 June 2017 at 14:10, Ian Swett wrote: > > Would only supporting 18 cause problems for anyone? > > > Anyone using OpenSSL would have a real hard time. > Is anyone planning to use OpenSSL for the interop? --94eb2c050446ee7ecf05530dfb1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 28, 2017 at 2:12 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 28 June 2017 at 14:10, Ian Swett <ianswett@google.com> wrote:
> Would only supporting 18 cause problems for anyone?


Anyone using OpenSSL would have a real hard time.

Is anyone planning to use OpenSSL for the interop?=C2=A0<= /div>

--94eb2c050446ee7ecf05530dfb1d-- From nobody Wed Jun 28 17:14:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49496129B45 for ; Wed, 28 Jun 2017 17:14:44 -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 vgXGh85jEWJR for ; Wed, 28 Jun 2017 17:14:38 -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 8D167129B19 for ; Wed, 28 Jun 2017 17:14:38 -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 v5T0CZc0006460; Thu, 29 Jun 2017 01:14:36 +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=fqyTKXbZn779gE4IDc+hx1ZQFYKogoPulfvzzQnFDzM=; b=hmX2VpCR9XtJHwAysDav6hQCxHhNWaNN3tQSU33krJfmXRwcBurTW2tm+oersuBvHblm JGSGB0bv50rlF/Y/UeKil1QlF9TOu5o46t05SjUemWUiehT589T8Rtl387A44vXrU+JZ 8/KF5x08XT7EIbYe4JoRAEw1wu5uBccIcA9NwVmreOxrC4gPdQvlEQlyHeGtpGVzMhGC 2gQvSi8fNBIPstuiwvep0+7VfWDEYE8Ro4P4Z6Ssi503UZNPbbMHo8Vy2NNG+2GaH8Z3 Vm3fykVnKWvucneI0+R34Wrn22ZCeSAs1tDsxb1fKaMSt94FcV8RYdkHweQTF7vWX+XS dg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2bcd2k47b7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2017 01:14:35 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5T0C7KD002090; Wed, 28 Jun 2017 20:14:34 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b9kduwya2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Jun 2017 20:14:34 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 17:14:33 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 20:14:32 -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, 28 Jun 2017 20:14:32 -0400 From: "Lubashev, Igor" To: Martin Thomson , Mike Bishop CC: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , QUIC WG , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Dmitri Tikhonov , Jo Kulik Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qFJcNmOfPnkGlJjRXQ/9soKI0ttCAgATMZACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSAD//8GgUA== Date: Thu, 29 Jun 2017 00:14:32 +0000 Message-ID: <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> 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.34.11] 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-06-28_15:, , 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-1706290002 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-28_15:, , 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-1706290003 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, 29 Jun 2017 00:14:44 -0000 PiB1bmxlc3Mgd2hhdCB0aGUgdHJhbnNwb3J0IHByb3ZpZGVzIGlzIGEgcGVyZmVjdCBmaXQgZm9y IGFwcGxpY2F0aW9uIHNlbWFudGljcywgeW91IGVuZCB1cCBidWlsZGluZyB0aG9zZSBzZW1hbnRp Y3MgaW50byB0aGUgYXBwbGljYXRpb24gYW55d2F5Lg0KDQpJIGFncmVlIHdpdGggdGhpcy4gV2Ug c2hvdWxkIGF2b2lkIGFkZGluZyBjb21wbGV4aXR5IGludG8gdHJhbnNwb3J0IGZvciByYXJlIHVz ZSBjYXNlcywgc2luY2UgaXQgZ29lcyBhZ2FpbnN0IEtJU1MgcHJpbmNpcGxlLg0KDQpPbiB0aGUg b3RoZXIgaGFuZCwgYWRkaW5nIHN1cHBvcnQgZm9yIGEgYnkgZmFyIHRoZSBtb3N0IGNvbW1vbiB1 c2UgY2FzZSBtYWtlcyBhIGxvdCBvZiBzZW5zZS4gIFRoaXMgaGVscHMgYXBwcyBhdm9pZCBzY3Jl d2luZyB1cCBpbXBsZW1lbnRpbmcgdGhhdCBjb21tb24gY2FzZSBhbmQgbGV0cyB1cyBvcHRpbWl6 ZSB0aGF0IGNvbW1vbiBjYXNlIGluIHRoZSBsb3dlciBsYXllci4gQmlEaSBzdHJlYW1zIGFyZSBz dWNoIGNvbW1vbiBjYXNlcy4gVW5pIHN0cmVhbXMgYXJlIGxpa2VseSB0byBiZSB0aGUgc2Vjb25k LW1vc3QtY29tbW9uIGNhc2VzIChoZW5jZSB5b3Ugb2ZmZXJlZCB0aGlzIFBSIHRvIG9wdGltaXpl IHRoZW0pLg0KDQoNClRoZSBBc3NvY2lhdGVkIFN0cmVhbXMgcHJvcG9zYWwgb2ZmZXJzIGV4dHJh IHNlbWFudGljIGZsZXhpYmlsaXR5IGF0IGEgY29zdCBvZiBzb21lIHNlbWFudGljIGNvbXBsZXhp dHkgKHNvbWVvbmUgd291bGQgbmVlZCB0byB2ZXJpZnkgdGhhdCB0aGUgYXNzb2NpYXRlZCBzdHJl YW0gbnVtYmVycyBtYWtlIHNlbnNlIC0tIGFwaT8gYXBwcz8pIGFuZCBhIGZldyBleHRyYSBieXRl cy4NCg0KSSdkIGxpa2UgdG8gd2FpdCB0byBzZWUgSWFuJ3MgcmV2aXNlZCBwcm9wb3NhbC4gIFRo ZSBpbml0aWFsIHByb3Bvc2FsIG9mZmVyZWQgdG8gZG8gb25seSBvbmUgdGhpbmcgLS0gb2ZmZXIg YSBjaG9pY2Ugb2YgdW5pL2JpLWRpcmVjdGlvbmFsIHN0cmVhbXMgLS0gYnV0IGl0IGRpZCBpdCBp biBhIHZlcnkgc2ltcGxlIHdheSwgd2hpY2ggaXMgbmljZS4NCg0KLSBJZ29yDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyOCwgMjAxNyA3OjI4 IFBNDQpUbzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpDYzog U3dpbmRlbGxzLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSykgPHRob21hcy5zd2lu ZGVsbHNAbm9raWEuY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1pa2tlbCBGYWhuw7hl IErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47IERtaXRyaSBUaWtob25vdiA8ZHRpa2hv bm92QGxpdGVzcGVlZHRlY2guY29tPjsgSm8gS3VsaWsgPGpva3VsaWtAZ29vZ2xlLmNvbT4NClN1 YmplY3Q6IFJlOiBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBSDQoNClRoZXJlIGlzIHByb2JhYmx5 IGEgc2ltcGxlciBhcHByb2FjaCBoZXJlLCB0YWtlIGEgYml0IChhcyBJYW4gZGlkKSBhbmQgc2F5 IHRoYXQgaWYgdGhhdCBiaXQgaXMgc2V0LCB0aGVuIHRoZSBzdHJlYW0gaXMgaW4gcmVzcG9uc2Ug dG8gYW5vdGhlciBhbmQgdGhlIHN0cmVhbSBJRCBvZiB0aGUgc3RyZWFtIHRvIHdoaWNoIHRoaXMg aXMgcmVzcG9uZGluZyBmb2xsb3dzIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBzdHJlYW0gSUQgb2Yg dGhlIHN0cmVhbSBpdHNlbGYuICBZb3UgY291bGQgdGhlbiBpbmNsdWRlIHRoYXQgb25seSBhdCB0 aGUgc3RhcnQgb2YgdGhlIHN0cmVhbSwgb3IgaW4gbXVsdGlwbGUgZnJhbWVzIChvciBhcyB3ZSBk ZWNpZGUpLg0KDQpUaGUgcHJvYmxlbSB3aXRoIHRoaXMsIGFzIHdpdGggc2V2ZXJhbCBvZiB0aGUg b3RoZXIgaXNzdWVzIHdlJ3JlIGRpc2N1c3NpbmcsIGlzIHRoYXQgdW5sZXNzIHdoYXQgdGhlIHRy YW5zcG9ydCBwcm92aWRlcyBpcyBhIHBlcmZlY3QgZml0IGZvciBhcHBsaWNhdGlvbiBzZW1hbnRp Y3MsIHlvdSBlbmQgdXAgYnVpbGRpbmcgdGhvc2Ugc2VtYW50aWNzIGludG8gdGhlIGFwcGxpY2F0 aW9uIGFueXdheS4gIEhUVFAgY2VydGFpbmx5IGNhbid0IHN1cnZpdmUgd2l0aG91dCBpdHMgb3du IGFzc29jaWF0aW9uIHNlbWFudGljcyBmb3IgcHVzaGVzLiAgVGhhdCBzdWdnZXN0cyB0byBtZSB0 aGF0IGhhdmluZyBiaWRpcmVjdGlvbmFsIHNlbWFudGljcyBpbiB0aGUgdHJhbnNwb3J0IGNyZWF0 ZXMgbW9yZSBkdXBsaWNhdGlvbiB0aGFuIG90aGVyd2lzZS4gIEhlbmNlIG15IHByb3Bvc2FsLg0K DQpPbiAyOCBKdW5lIDIwMTcgYXQgMTU6MjYsIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBt aWNyb3NvZnQuY29tPiB3cm90ZToNCj4gQXMgcHJvbWlzZWQsIGEgUFIgZm9yIGFkZGluZyDigJxh c3NvY2lhdGVkIHN0cmVhbXPigJ0gaXMgYXQgDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cv YmFzZS1kcmFmdHMvcHVsbC82NzIuICBUaGlzIHZlcnkgDQo+IGRlbGliZXJhdGVseSBidWlsZHMg b24gdG9wIG9mIE1U4oCZcyBQUiDigJMgaXTigJlzIGFkZGluZyBhIHByaW1pdGl2ZSB3aGljaCAN Cj4gY2FuIGJlIHVzZWQgdG8gY29uc3RydWN0IHZhcmlvdXMgYWJzdHJhY3Rpb25zIGF0b3AgdW5p ZGlyZWN0aW9uYWwgDQo+IHN0cmVhbXMsIGJ1dCB0aGUgbGlmZWN5Y2xlIGlzIHN0aWxsIGZ1bmRh bWVudGFsbHkgdW5pZGlyZWN0aW9uYWwuDQo+DQo+DQo+DQo+IENvcHlpbmcgbXkgbm90ZXMgaGVy ZSBmb3IgbGlzdCBkaXNjdXNzaW9uIHB1cnBvc2VzLg0KPg0KPiBNYWpvciBjaGFuZ2VzDQo+DQo+ IExldmVyYWdpbmcgQGlnb3Jsb3JkJ3MgaW5zaWdodCB0aGF0IE9PPTAwIG9ubHkgb2NjdXJzIG9u IHRoZSBmaXJzdCANCj4gU1RSRUFNIGZyYW1lIG9mIGEgc3RyZWFtLCBJIHVzZWQgdGhhdCBhcyB0 aGUgdHJpZ2dlciBmb3IgYSBTdHJlYW0gUHJvcGVydGllcyBieXRlLg0KPiBUd28gYml0cyBvZiB0 aGF0IGJ5dGUgZGVzY3JpYmUgdGhlIGRpcmVjdGlvbmFsaXR5IG9mIHRoZSBzdHJlYW06DQo+DQo+ IFVuaWRpcmVjdGlvbmFsIChubyByZXNwb25zZSBleHBlY3RlZCkNCj4gSW5pdGlhbCBiaWRpcmVj dGlvbmFsIChvbmUgcmVzcG9uc2UgZXhwZWN0ZWQpIEluaXRpYWwgbXVsdGktcmVzcG9uc2UgDQo+ IChvbmUgb3IgbW9yZSByZXNwb25zZXMgZXhwZWN0ZWQ7IG5lZWRzIGEgYmV0dGVyIG5hbWUpIFJl c3BvbnNlDQo+DQo+IElmIHRoZSB0eXBlIGlzIFJlc3BvbnNlLCB0aGVyZSdzIGFuIEFzc29jaWF0 ZWQgU3RyZWFtIElEIGZpZWxkLCBsZW5ndGggDQo+IGdpdmVuIGJ5IHR3byBtb3JlIGJpdHMgZm9s bG93aW5nIHRoZSBzYW1lIHBhdHRlcm4gYXMgdGhlIFNTIGJpdHMgaW4gDQo+IHRoZSBTVFJFQU0g ZnJhbWUgSUQuDQo+DQo+IFBlcnNvbmFsIE9waW5pb24NCj4NCj4gT24gdGhlIHBsdXMgc2lkZSwg dGhlc2Ugc3RyZWFtIHR5cGVzIHNlZW0gdG8gY292ZXIgdGhlIGFic3RyYWN0aW9ucyBJIA0KPiBj YW4gZW52aXNpb24gZm9yIG1vc3QgYXBwbGljYXRpb25zLiBZb3UgY2FuIHVuaWxhdGVyYWxseSBz ZW5kIA0KPiBzb21ldGhpbmcgKHVuaWRpcmVjdGlvbmFsKSwgZG8gcmVxdWVzdC9yZXNwb25zZSAo YmlkaXJlY3Rpb25hbCksIG9yIA0KPiBwdWIvc3ViIChzaW5nbGUgc3Vic2NyaXB0aW9uIHN0cmVh bSwgc2VyaWVzIG9mIHVwZGF0ZSBzdHJlYW1zKS4NCj4NCj4gSSBkb24ndCBjYXJlIGZvciB0aGUg ZmFjdCB0aGF0IEkgc3RpbGwgbmVlZCB0aGUgc3RyZWFtIHR5cGUgaGVhZGVyIGluIA0KPiBIVFRQ IGFmdGVyIHB1dHRpbmcgdGhpcyBpbiB0aGUgdHJhbnNwb3J0LiBUaGF0IHdpbGwgYmUgYW1lbGlv cmF0ZWQgaWYgDQo+IHdlIGdvIGJhY2sgdG8gb25lIHN0cmVhbSBwZXIgcmVxdWVzdCwgc2luY2Ug YWxsIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgDQo+IHdpbGwgYmUgcHVzaCBzdHJlYW1zLiAoQXMg YSBzaWRlLW5vdGUsIEkgY29uc2lkZXJlZCB1c2luZyB0aGUgDQo+IG11bHRpcGxlLXJlc3BvbnNl IG9wdGlvbiBpbiB0aGUgSFRUUCBtYXBwaW5nLCBidXQgdGhlbiBJIG5lZWQgYSBzdHJlYW0gDQo+ IGhlYWRlciBhZ2FpbiB0byBpbmRpY2F0ZSB3aGljaCBpcyB0aGUgcmVzcG9uc2UgYW5kIHdoaWNo IHRoZSBwdXNoZXMuKQ0KPg0KPiBJIHBhcnRpY3VsYXJseSBkb24ndCBsaWtlIHRoYXQgeW91IG5v dyBoYXZlIHRvIGxvb2sgYXQgdGhlIGZyYW1lIHR5cGUgDQo+IGhlYWRlciB0byBmaW5kIG91dCB3 aGV0aGVyIGEgZmllbGQgZXhpc3RzIHdoaWNoIHRlbGxzIHlvdSB0aGUgbGVuZ3RoIA0KPiBvZiBz b21ldGhpbmcgZWxzZSBpbiB0aGUgaGVhZGVyLiBJJ2QgbGlrZSB0byBzaW1wbGlmeSB0aGF0LiBJ IHdlbnQgDQo+IHdpdGggdGhpcyBtb2RlbCBvdmVyIGEgQ1JFQVRFX1NUUkVBTSBmcmFtZSBiZWNh dXNlIG9mIEBtaWtrZWxmaidzIA0KPiB1c2UtY2FzZSBvZiB2ZXJ5IHNtYWxsIG1lc3NhZ2VzDQo+ IC0tIHRoaXMgYWRkcyBvbmx5IG9uZSBieXRlIHRvIHRoZSBmaXJzdCBmcmFtZSBvbiBhIHN0cmVh bSBpbiBvbmUgDQo+IGRpcmVjdGlvbiBhbmQgMi01IGJ5dGVzIHRvIHRoZSBmaXJzdCBmcmFtZSBv ZiByZXNwb25zZSBzdHJlYW1zLiBBIA0KPiBzZXBhcmF0ZSBmcmFtZSB0eXBlIHdvdWxkIGJlIHNv bWV3aGF0IGxhcmdlciwgYnV0IGNvdWxkIGJlIGNsZWFuZXIgaW4gdGhhdCByZXNwZWN0Lg0KPg0K Pg0KPg0KPg0KPg0KPiBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgU3dpbmRlbGxzLCANCj4gVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwg VUspDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyOCwgMjAxNyA3OjU2IEFNDQo+IFRvOiBKbyBL dWxpayA8am9rdWxpa0Bnb29nbGUuY29tPjsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiANCj4g PG1pa2tlbGZqQGdtYWlsLmNvbT4NCj4gQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBEbWl0 cmkgVGlraG9ub3YgDQo+IDxkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+DQo+IFN1YmplY3Q6 IFJFOiBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBSDQo+DQo+DQo+DQo+IEkgYWdyZWUgdGhhdCBs b29raW5nIGF0IHRoZSBsYXllcnMgb2YgYWJzdHJhY3Rpb24gaXMgdXNlZnVsLiBJbiANCj4gcHJp bmNpcGxlIGhhdmluZyB0aGUgd2lyZSBwcm90b2NvbCBqdXN0IGhhdmUgY29uc3RydWN0cyBmb3Ig DQo+IHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgZG9lcyBub3QgaW4gaXRzZWxmIGxpbWl0IGNyZWF0 aW5nIA0KPiBiaS1kaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uIGZsb3dzLCBzdXBwb3J0ZWQgYXQg ZWl0aGVyIHRoZSBsaWJyYXJ5IG9yIGFwcGxpY2F0aW9uIGxheWVyLg0KPg0KPg0KPg0KPiBIb3dl dmVyLCB0aGVyZSBuZWVkIHRvIGJlIGEgc3RhbmRhcmQgd2F5IG9mIGRvaW5nIGJpLWRpcmVjdGlv bmFsIA0KPiBjb21tdW5pY2F0aW9uIGZvciBtaWdyYXRpbmcgYXBwbGljYXRpb25zIGltcGxlbWVu dGVkIHVzaW5nIGEgc29ja2V0IA0KPiBzdHlsZSBhcGkuIEl0IG5lZWRzIHRvIGJlIGVhc3kgdG8g bW92ZSBhbiBleGlzdGluZyBhcHBsaWNhdGlvbiBmcm9tIFRDUCB0byBRVUlDLg0KPiBUaGlzIG1v dmUgbWF5IGJlIGF0dHJhY3RpdmUgaW4gbWFueSBzaXR1YXRpb25zIGFzIFFVSUMgZ2l2ZXMgaW1w cm92ZWQgDQo+IHNlY3VyaXR5IGFuZCBtYXkgYWxsb3cgZ3JlYXRlciB0aHJvdWdocHV0IGR1ZSB0 byB0aGUgbW9yZSBtb2Rlcm4gKGFuZA0KPiBjdXN0b21pemFibGUpIGNvbmdlc3Rpb24gY29udHJv bCBhbGdvcml0aG1zIGNvbXBhcmVkIHRvIHRoZSBPUyBUQ1Agc3RhY2suDQo+DQo+DQo+DQo+IEZv ciBtaWdyYXRpbmcgc3RhbmRhcmQgc29ja2V0IGFwaSBhcHBsaWNhdGlvbnMgSSBkb27igJl0IHRo aW5rIGl0IHdvdWxkIA0KPiBiZSBhcHByb3ByaWF0ZSB0byBsZWF2ZSB0aGUgd29yayB0byB0aGUg YXBwbGljYXRpb24gdG8gZG8gY29ycmVsYXRpb24sIA0KPiBhdCBsZWFzdCB0aGUgbGlicmFyeSBz aG91bGQgYmUgcHJvdmlkaW5nIHRoaXMgc2VydmljZSB1c2luZyB0aGUgd2lyZSANCj4gcHJvdG9j b2wgYXMgYXBwcm9wcmlhdGUuIENsZWFybHkgd2Ugd2FudCBhIGNsaWVudCB3cml0dGVuIHdpdGgg b25lIA0KPiBsaWJyYXJ5IHRvIGJlIGFibGUgdG8gY29tbXVuaWNhdGUgc3VjY2Vzc2Z1bGx5IHdp dGggYSBzZXJ2ZXIgd3JpdHRlbiB1c2luZyBhIGRpZmZlcmVudCBsaWJyYXJ5Lg0KPiBUaGlzIG5l ZWRzIHNvbWUgZm9ybSBvZiBzdGFuZGFyZGl6YXRpb24gb2YgdGhlIHNpZ25hbGxpbmcuIFRoaXMg Y291bGQgDQo+IGVpdGhlciBiZSBhIGJ1aWxkaW5nIGJsb2NrIG92ZXJsYXkgb24gdG9wIG9mIFFV SUMsIG9yIGltcGxlbWVudGVkIGF0IA0KPiB0aGUgd2lyZSBwcm90b2NvbCBsZXZlbC4NCj4NCj4N Cj4NCj4gSW4gdGVybXMgb2YgcGF0dGVybnMgSSB0aGluayB0aGUgZm9sbG93aW5nIG1heSBiZSBz b21lIG9mIHRoZSBtb3N0IA0KPiBjb21tb24gcGF0dGVybnMgKHdpdGggcG90ZW50aWFsIHRvIGJl IHByb3ZpZGVkIGF0IHRoZSBsaWJyYXJ5IGFuZCBvciANCj4gd2lyZSBwcm90b2NvbCBsZXZlbCku DQo+DQo+IEkvTyBwYXR0ZXJuICA6IEV4YW1wbGUNCj4NCj4gMS8wICAgOiBBbiBpbnB1dCBvbmx5 IGZsb3csIHBlcmhhcHMgYSBkYXRhIGxvZ2dlciBsaWtlIHN5c2xvZyB3aXRoIG5vDQo+IGNvbmZp cm1hdGlvbi9mZWVkYmFjaw0KPg0KPiAwLzEgIDogYW4gb3V0cHV0IG9ubHkgZmxvdywgcGVyaGFw cyBhIHRvcGljIG1lc3NhZ2UgYnVzIHNlcnZpY2Ugd2l0aCANCj4gbm8gY29uZmlybWF0aW9uL2Zl ZWRiYWNrDQo+DQo+IDEvMSA6IHN0YW5kYXJkIFRDUCBhcHBsaWNhdGlvbnMgd2l0aCBhIHNpbmds ZSBmbG93IHBlciBjb25uZWN0aW9uDQo+DQo+IDEvKiA6IHNpbmdsZSBpbnB1dCwgbWFueSBvdXRw dXQsIG1vZGVsbGluZyBTVERJTi9TVERPVVQrU1RERVJSDQo+DQo+ICgxLzEpKiA6IG11bHRpcGxl eGVkIHBhaXJzIG9mIGZsb3dzIOKAkyBzdXBwb3J0aW5nIG11bHRpcGxlIHNvY2tldHMgDQo+IG11 eGVkIG9udG8gYSBzaW5nbGUgUVVJQyBjb25uZWN0aW9uDQo+DQo+DQo+DQo+IE9idmlvdXNseSwg YW4gYXBwbGljYXRpb24gd291bGQgYWx3YXlzIGhhdmUgdGhlIG9wdGlvbiB0byBjb21iaW5lIGFu eSANCj4gc2luZ2xlIGRpcmVjdGlvbiBmbG93cyB3aXRoIGFwcGxpY2F0aW9uIGxldmVsIGNvcnJl bGF0b3JzIHRvIGNvbnN0cnVjdCANCj4gbW9yZSBjb21wbGV4IGZsb3dzIGlmIGRlc2lyZWQuDQo+ DQo+DQo+DQo+IEF0IHRoZSBtb21lbnQgbXkgZ3V0IHNheXMgdGhlIDEvMSB1c2UtY2FzZSBpcyBj b21tb24gZW5vdWdoIHRoYXQgdGhlIA0KPiB3aXJlIHByb3RvY29sIHNob3VsZCBwcm92aWRlIGEg c3RhbmRhcmQgbWVjaGFuaXNtIHRvIHN1cHBvcnQgaXQgYXMgYSANCj4gc3RhbmRhcmQgb3Zlcmxh eSB3b3VsZCBwcm9iYWJseSBlbmQgdXAgYmVpbmcgdHJlYXRlZCBhcyBwYXJ0IG9mIHRoZSANCj4g d2lyZSBmb3JtYXQgYW55d2F5Lg0KPg0KPg0KPg0KPiBQZXJoYXBzIHN0cmVhbXMgc2hvdWxkIGJl IGV4cGxpY2l0bHkgY3JlYXRlZCB3aXRoIGEgQ1JFQVRFX1NUUkVBTSANCj4gZnJhbWUgd2hpY2gg d291bGQgYmUgY2FwYWJsZSBvZiBkZWZpbmluZyBtdWx0aXBsZSByZWxhdGVkIHN0cmVhbXM/DQo+ DQo+IFRoZXJlIGlzIHRoZSBvcHRpb24gb2Ygd2hldGhlciBvbmx5ICgxLzEpIHBhaXJzIGNhbiBi ZSBjcmVhdGVkIHRoaXMgDQo+IHdheSwgb3INCj4gKDEvbikgY29tYmluYXRpb25zIGNvdWxkIGJl IHN1cHBvcnRlZCAod2l0aCBhbiBhcHBsaWNhdGlvbiBkZWZpbmVkIHdheSANCj4gdG8gaWRlbnRp ZnkgdGhlIHVzZSBvZiBlYWNoIG9mIHRoZSBvdXRwdXQgc3RyZWFtcykuIEEgc3RlcCBmdXJ0aGVy IG1heSANCj4gYmUgdGhhdCB0aGVyZSBpcyBhIHRyYW5zcG9ydCBwYXJhbWV0ZXIgdGhhdCBkZWZp bmVzIHdoZXRoZXIgdGhlIHNlcnZlciANCj4gaXMgYWxsb3dlZCB0byBjcmVhdGUgYWRkaXRpb25h bCBzdHJlYW1zLCBvciBpZiBzdHJlYW0gY3JlYXRpb24gaXMgDQo+IHB1cmVseSBjbGllbnQgZHJp dmVuIChsaWtlIFRDUCkuIEkgZG9u4oCZdCBrbm93IGlmIGVpdGhlciBvZiB0aGVzZSB3b3VsZCAN Cj4gc2ltcGxpZnkgaG93IHRvIGhhbmRsZSBzdHJlYW0gYWNjb3VudGluZywgYW5kIGluIHBhcnRp Y3VsYXIgb25seSANCj4gY3JlYXRpbmcgYSBmbG93IHdoZW4gYWxsIHBhcnRpZXMgaGF2ZSBzdWZm aWNpZW50IGFsbG93YW5jZXMgbGVmdC4NCj4NCj4NCj4NCj4gVGhvbWFzDQo+DQo+DQo+DQo+IEZy b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKbyBL dWxpaw0KPiBTZW50OiAyOCBKdW5lIDIwMTcgMTU6MDkNCj4gVG86IE1pa2tlbCBGYWhuw7hlIErD uHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCj4gQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc+OyBEbWl0cmkgVGlraG9ub3YgDQo+IDxkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+DQo+ IFN1YmplY3Q6IFJlOiBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIFBSDQo+DQo+DQo+DQo+IEknZCBs aWtlIHRvIHBvcCBiYWNrIHVwIHRvIGEgY29tbWVudCBJZ29yIG1hZGUgbGFzdCB3ZWVrLCBiZWNh dXNlIEkgDQo+IGZpbmQgaXQgaGVscGZ1bCBpbiB0aGlua2luZyBhYm91dCB0aGUgZGVzaWduIHNw YWNlOg0KPg0KPg0KPg0KPiBJIHRoaW5rIG9mIHRocmVlIGxheWVycyBvZiBhYnN0cmFjdGlvbjoN Cj4NCj4gMS4gICAgICAgUVVJQyBXaXJlIFByb3RvY29sICh0aGUgdGhpbmcgZGVzY3JpYmVkIGJ5 IHRoZSBRVUlDIFRyYW5zcG9ydCBSRkMpDQo+IDIuICAgICAgIFFVSUMgTGlicmFyeSBBUEkgKGEg bGlicmFyeSBleHBvc2luZyBzb21lIHVzZWZ1bCBhYnN0cmFjdGlvbnMgLS0NCj4gc3VjaCBhcyBi bG9ja2luZy9ub24tYmxvY2tpbmcgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhbmQgYmlkaXJlY3Rp b25hbCANCj4g4oCcc29ja2V0c+KAnSAtLSBhbmQgaW1wbGVtZW50aW5nIHRoZW0gdXNpbmcgUVVJ QyBXaXJlIFByb3RvY29sKQ0KPiAzLiAgICAgICBBcHBsaWNhdGlvbiAoc29tZXRoaW5nIHRoYXQg dXNlcyBRVUlDIExpYnJhcnkgQVBJcykNCj4NCj4gSSB0aGluayB0aGVyZSBpcyBzb21lIGFyZ3Vt ZW50IHRvIGJlIG1hZGUgdGhhdCBNYXJ0aW4ncyBvcmlnaW5hbCANCj4gcHJvcG9zYWwgZGlkIG5v dCB0YWtlIGludG8gYWNjb3VudCBob3cgd2Ugd291bGQgYWNoaWV2ZSAoMikgZm9yIA0KPiBiaS1k aXJlY3Rpb25hbCBzdHJlYW1zLiAgKEkgZG9uJ3QgdGhpbmsgaXQgc3RyaWN0bHkgc2FpZCAidGhv dSBzaGFsdCANCj4gbm90IGRvICgyKSIgZWl0aGVyLCBidXQgdGhhdCBpcyB1cCB0byBpbnRlcnBy ZXRhdGlvbi4pDQo+DQo+DQo+DQo+IFNldmVyYWwgcGVvcGxlIGhhdmUgYXJndWVkIHRoYXQgd2Ug ZG8gbm90IHdhbnQgZXZlcnkgYXBwbGljYXRpb24gdG8gDQo+IGhhdmUgdG8gcmUtaW1wbGVtZW50 IGJpLWRpcmVjdGlvbmFsIHN0cmVhbXMgKDMpIGZvciBldmVyeSBhcHBsaWNhdGlvbiwgDQo+IGFu ZCB0aGlzIGlzIG5vdCBob3cgZy1xdWljIChvdXIgbGFyZ2VzdCBkZXBsb3ltZW50KSB3b3JrcyBy aWdodCBub3cuICANCj4gVGhlc2UgYXJndW1lbnRzIG1ha2Ugc2Vuc2UgdG8gbWUsIGJ1dCBZTU1W Lg0KPg0KPg0KPg0KPiBKdXN0IGJlY2F1c2UgdGhlIHBhcnRpY3VsYXIgKm1lY2hhbmlzbSogdGhh dCBpcyBiZWluZyBwcm9wb3NlZCBoYXMgDQo+IHNvbWUgaXNzdWVzLCBob3dldmVyLCBkb2Vzbid0 IHNjcmVhbSBvdXQgdG8gbWUsIGF0IGxlYXN0LCB0aGF0IHdlIA0KPiBzaG91bGQgYWJhbmRvbiB0 aGlzIHBhcnRpY3VsYXIgKmRlc2lnbiBnb2FsKi4gIFRoZSBnb2FsIGJlaW5nIGEgDQo+IHRyYW5z cG9ydCBwcm90b2NvbCB0aGF0IGNhbiBlbGVnYW50bHkgZml0IHdpdGggYSB1bmkvYmkgc3RyZWFt IG1vZGVsLiAgDQo+IE5vdywgaWYgd2UgY29uY2x1ZGUgdGhhdCB0aGVyZSBjYW4gbmV2ZXIgYmUg YW4gZWxlZ2FudCBtb2RlbCB0aGF0IA0KPiBhY2hpZXZlcyB0aGlzIGdvYWwsIHRoZW4gc28gYmUg aXQuICBCdXQgSSBhbHNvIGZlZWwgbGlrZSB3ZSBoYXZlbid0IA0KPiByZWFjaGVkIHRoYXQgcG9p bnQgaW4gdGhlIGRpc2N1c3Npb24geWV0LiAgKEF0IHRoZSB2ZXJ5IGxlYXN0LCB0aGlzIA0KPiBk aXNjdXNzaW9uIGhhcyBiZWVuIGZydWl0ZnVsIHRvIG1lIGluIHRlcm1zIG9mIG1hcHBpbmcgdGhl IGRlc2lnbiBzcGFjZSBhbmQgZWx1Y2lkYXRpbmcgcmVxdWlyZW1lbnRzKS4NCj4NCj4NCj4NCj4g T25lIG9mIHRoZSByZWFzb25zIEkgc3RpbGwgdGhpbmsgdGhpcyBkZXNpZ24gZ29hbCBpcyB1bmRl ciANCj4gY29uc2lkZXJhdGlvbiBpcyB0aGF0IElhbiBhbmQgSWdvci9NaWtlIGhhdmUgYmVlbiB0 YWxraW5nIGFib3V0IA0KPiBhbHRlcm5hdGUgc29sdXRpb25zIHdoaWNoIGhhdmUgYSBzaW1pbGFy IGZsYXZvci4gIER1cmluZyB0aGUgcmVjZW50IA0KPiAicXVpZXQibmVzcyBvbiB0aGUgdGhyZWFk LCBwZXJzb25hbGx5LCBJJ3ZlIGJlZW4gd2FpdGluZyB0byBoZWFyIG1vcmUgZnJvbSB0aGVtLg0K Pg0KPg0KPg0KPiBPbiBXZWQsIEp1biAyOCwgMjAxNyBhdCA5OjQxIEFNLCBNaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuIA0KPiA8bWlra2VsZmpAZ21haWwuY29tPiB3cm90ZToNCj4NCj4gSW4gcmVw bHkgdG8gUmFuamVldGgNCj4NCj4NCj4NCj4gSXQgaXMgbm90IG9ubHkgYSBtYXR0ZXIgb2Ygc2lt cGxpY2l0eSBmb3IgdGhlIHNha2Ugb2Ygc2ltcGxpY2l0eToNCj4NCj4NCj4NCj4gLSBBIGNvbXBs ZXggdHJhbnNwb3J0IGxheWVyIG1pZ2h0IGVuZCB1cCBiZWluZyBwb29ybHkgaW1wbGVtZW50ZWQg DQo+IGxlYWRpbmcgdG8gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5IGFuZCB1bHRpbWF0ZWx5IGFk b3B0aW9uLiBUaGlzIA0KPiBjb21wbGV4aXR5IGlzIG5vdCBvbmx5IGluIGltcGxlbWVudGF0aW9u IGJ1dCBhbHNvIGluIHVuZGVyc3RhbmRpbmcgdGhlIA0KPiBleGFjdCBzZW1hbnRpY3Mgb2Ygc3Ry ZWFtIGxpZmV0aW1lLiBFdmVuIGlmIHRoZSBzcGVjIGlzIHN1ZmZpY2llbnRseSANCj4gY2xlYXIs IGl0IHdpbGwgc3RpbGwgYmUgb3BlbiB0byBtaXNpbnRlcnByZXRhdGlvbnMuDQo+DQo+DQo+DQo+ IC0gQmktZGlyZWN0aW9uYWwgc3RhdGUgbWF5IGhhdmUgdG8gYmUgbWFpbnRhaW5lZCBsb25nZXIg YW5kIHdpdGggbW9yZSANCj4gb3ZlcmhlYWQgdGhhbiB3aXRoIHVuaS1kaXJlY3Rpb25hbCBzdHJl YW1zLCBlc3BlY2lhbGx5IHVuZGVyIGxvc3MsIA0KPiBwb3RlbnRpYWxseSBsZWFkaW5nIHRvIHBv b3IgcGVyZm9ybWFuY2UgYW5kIHBvb3IgcmVzb3VyY2UgdXRpbGlzYXRpb24gDQo+IGJlY2F1c2Ug dGhlIHRyYW5zcG9ydCBsYXllciBoYXMgaW5zdWZmaWNpZW50IGluZm9ybWF0aW9uLg0KPg0KPg0K Pg0KPiAtIFRoZSBleHRyYSBjb21wbGV4aXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBtYXkg YmUgb3ZlcnN0YXRlZCAtIGl0IA0KPiBpcyBzaWduaWZpY2FudGx5IHNpbXBsZXIgdG8gbWFuYWdl IGEgbWFwIHRoYXQgYXNzb2NpYXRlcyB0byB0d28gDQo+IHN0cmVhbXMgdGhhbiBpdCBpcyB0byBt YWludGFpbiBiaS1kaXJlY3Rpb25hbCBzdGF0ZSBhdCB0aGUgdHJhbnNwb3J0IA0KPiBsYXllci4g SXQgaXMgZXZlbiBwb3NzaWJsZSB0byBpbXBsaWNpdGx5IGxpbmsgc3RyZWFtcyB3aXRoIHNhbWUg DQo+IGlkZW50aWZpZXJzLCBlLmcuIGluIGEgUlBDIHNjZW5hcmlvLiBUaGF0IHNhaWQsIEkgZG8g c2VlIGEgcG90ZW50aWFsIA0KPiBiZW5lZml0IG9mIGEgd3JhcHBlciB0aGF0IGltcGxlbWVudHMg dGhlIGNvbW1vbiBiaS1kaXJlY3Rpb25hbCBjYXNlLg0KPg0KPg0KPg0KPiAtIENvbXBsZXhpdHkg YXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIG1heSBiZSBkdXBsaWNhdGVkLCBidXQgDQo+IGltcGxl bWVudGF0aW9uIGVycm9ycyBhcmUgYWxzbyBpc29sYXRlZCB0byB0aGF0IGFwcGxpY2F0aW9uLiAN Cj4gU3BlY2lmaWNhbGx5IGZvciBIVFRQIEkgd291bGQgYXNzdW1lIHRoYXQgUVVJQyB0cmFuc3Bv cnQgYW5kIFFVSUMgSFRUUCANCj4gaW1wbGVtZW50ZXJzIHdvdWxkIGJlIGxhcmdlIHRoZSBzYW1l IGZvciBhIGxvbmcgdGltZSB0byBjb21lLCBzbyBJIA0KPiB3b3VsZCBub3QgZXhwZWN0IHRoZSB0 cmFkZW9mZiBoZXJlIHRvIGJlIHBhcnRpY3VsYXJseSBjb25jZXJuaW5nLg0KPg0KPg0KPg0KPiAt IFVuaXggcGlwZXMgYXJlIHRyYWRpdGlvbmFsbHkgY29uc3RydWN0ZWQgYXMgYSBwYWlyIG9mIA0K PiB1bmktZGlyZWN0aW9uYWwgZmlsZSBkZXNjcmlwdG9ycyBhbmQgdGhhdCBpcyBhIHJlYXNvbmFi bHkgcHJvdmVuIA0KPiBtb2RlbC4gQ+KAmXMgc3RhbmRhcmQgbGlicmFyeSBzdGRpbiwgc3Rkb3V0 IGFuZCBzdGRlcnIgaXMgYW4gZXhhbXBsZSBvZiANCj4gYW4gYXN5bW1ldHJpYyBtb2RlbCB3aXRo IGltcGxpY2l0IGxpbmthZ2UgYmV0d2VlbiB1bmktZGlyZWN0aW9uYWwgZmlsZSBkZXNjcmlwdG9y cy4NCj4NCj4NCj4NCj4gLSBUaGVyZSBhcmUgbG90cyBvZiB1c2UgY2FzZXMgZm9yIG5vbi1IVFRQ IGxpa2UgY29ubmVjdGl2aXR5IC0gS2Fma2EgDQo+IGhpZ2ggdm9sdW1lIG1lc3NhZ2UgcXVldWlu ZyBmb3IgZXhhbXBsZS4gVGhlIGluZHVzdHJ5IHRyZW5kIGFwcGVhcnMgdG8gDQo+IG1vdmUgdG93 YXJkcyBhc3luY2hyb25vdXMgcHJvY2Vzc2luZyBhbmQgbWVzc2FnaW5nLiBJdCBkZXBlbmRzIG9u IA0KPiB3aGV0aGVyIHlvdSBsb29rIGF0IFFVSUMgYXMgYSBUQ1AgKyBUTFMgcmVwbGFjZW1lbnQs IG9yIGFzIGEgSFRUUFMgLyANCj4gUkVTVCBSUEMgcmVwbGFjZW1lbnQuDQo+DQo+DQo+DQo+IC0g VW5pLWRpcmVjdGlvbmFsIHN0cmVhbXMgbWF5IGN1cnJlbnRseSBiZSB1bnByb3ZlbiBpbiB0aGUg d2lsZCwgYnV0IGEgDQo+IHByb3Bvc2FsIGlzIG5lZWRlZCBiZWZvcmUgYW4gaW1wbGVtZW50YXRp b24gY2FuIGJlIG1hZGUgYW5kIHRlc3RldC4gSSANCj4gYWdyZWUgdGhhdCBpdCBpcyBlYXN5IHRv IGRlc2lnbiBpbnRvIHdyb25nIGFzc3VtcHRpb25zIHdpdGhvdXQgcmVhbCB3b3JsZCB0ZXN0aW5n Lg0KPg0KPg0KPg0KPiAtIFRoZXJlIHdpbGwgaG9wZWZ1bGx5IG5vdCBiZSBhIGxhcmdlIG51bWJl ciBvZiBzdWNjZXNzb3JzIHRvIFFVSUMgLSANCj4gcGVyaGFwcyBzb21lIHB1cnBvc2Ugc3BlY2lm aWMgdmFyaWFudHMsIGUuZy4gZm9yIGVtYmVkZGVkIHVzZS4gDQo+IFdpZGVzcHJlYWQgYWRhcHRh dGlvbiBhbmQgY29tcGF0aWJpbGl0eSBpcyB2ZXJ5IG5lY2Vzc2FyeSBzbyBpdCBtYWtlcyANCj4g c2Vuc2UgdG8gaGF2ZSBRVUlDIGJlaW5nIHN1ZmZpY2llbnRseSBzaW1wbGUgYW5kIGV4cHJlc3Np dmUgdG8gYWNoaWV2ZSANCj4gdGhpcyBnb2FsLiBBIHBvbHltb3JmIFFVSUMgd2lsbCBub3QgYWNo aWV2ZSB0aGF0IGdvYWwuIE9uIHRoZSBvdGhlciANCj4gaGFuZCwgYSBzb2xpZCBRVUlDIGZvdW5k YXRpb24gY2FuIGJlIHVzZWQgZm9yIGEgbGFyZ2UgbnVtYmVyIG9mIGFwcGxpY2F0aW9uIHByb3Rv Y29scy4NCj4NCj4NCj4NCj4gLSBGaW5hbGx5LCBpdCBtYXkgdHVybiBvdXQgdGhhdCB1bmktZGly ZWN0aW9uYWwgc3RyZWFtcyBqdXN0IGlzIGEgYmFkIA0KPiBpZGVhIC0gSSBkb3VidCBpdCwgYnV0 IEkgZG8gYmVsaWV2ZSByZWFsIHdvcmxkIHRlc3RzIGFyZSBuZWVkZWQuDQo+DQo+DQo+DQo+IEtp bmQgUmVnYXJkcywNCj4NCj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KPg0KPg0KPg0KPiBP biAyOCBKdW5lIDIwMTcgYXQgMTQuNDIuMzYsIERtaXRyaSBUaWtob25vdiANCj4gKGR0aWtob25v dkBsaXRlc3BlZWR0ZWNoLmNvbSkNCj4gd3JvdGU6DQo+DQo+IE9uIFR1ZSwgSnVuIDI3LCAyMDE3 IGF0IDAyOjMxOjM4UE0gLTA3MDAsIFJhbmplZXRoIEt1bWFyIERhc2luZW5pIHdyb3RlOg0KPj4g Mi4gV2UgYXJlIG92ZXJwbGF5aW5nIHRoZSBzaW1wbGljaXR5IG9mIGRlc2lnbi4gRXZlbiBpZiB3 ZSBkZWVtIA0KPj4gZGVwbG95bWVudCBleHBlcmllbmNlIG5vdCBhIGNvbmNlcm4sIGlmIGV2ZXJ5 IGFwcGxpY2F0aW9uIGxheWVyIA0KPj4gcHJvdG9jb2wgdGhhdCBuZWVkcyBzdXBwb3J0IGZvciBi aWRpcmVjdGlvbmFsIHN0cmVhbXMgaGFzIHRvIA0KPj4gaW1wbGVtZW50IHNvbWUgY29ycmVsYXRv cnMgYW5kIHN1Y2ggYWJvdmUsIHRoYXQncyBhIG5ldCBuZWdhdGl2ZSBpbiB0ZXJtcyBvZiBjb21w bGV4aXR5Lg0KPg0KPiBUaGlzIGlzIGFuIGltcG9ydGFudCBwb2ludDogd2Ugd2FudCBRVUlDIGFk b3B0aW9uIHRvIGJlIG1hZGUgZWFzeS4NCj4gQSBwcm9ncmFtIHRoYXQgc3BlYWtzIEhUVFAgdG9k YXkgc2hvdWxkIGJlIGFibGUgdG8gdXNlIGFuIGV4aXN0aW5nIA0KPiBRVUlDIGxpYnJhcnkgd2l0 aG91dCBoYXZpbmcgdG8gZW11bGF0ZSBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgaW4gb3JkZXIgDQo+ IHRvIGZpdCBpdCBpbnRvIEhUVFAgdXNhZ2UgcGF0dGVybi4gRm9yY2luZyBldmVyeSBvbmUgb2Yg dGhlc2UgcHJvZ3JhbXMgDQo+IHRvIGRvIHRoaXMgaXMgY2VydGFpbmx5IGEgaHVyZGxlLg0KPg0K PiAtIERtaXRyaS4NCj4NCj4NCg0K From nobody Wed Jun 28 17:48: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 47E20124D68 for ; Wed, 28 Jun 2017 17:48:27 -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 nvwkX7s_ZwsT for ; Wed, 28 Jun 2017 17:48:25 -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 DB8FC1200ED for ; Wed, 28 Jun 2017 17:48:25 -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 v5T0mLRF006668; Thu, 29 Jun 2017 01:48:23 +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=ZX+o53tlgTlvWLykN6J47+j+o2ekwsPSIyyqVzF/N1w=; b=djOs2Rt9izJkx8wImGqhs2MeOWeGRs+ILOel/H8qsKdngZm6QNNI9xPO5y8323dkfwkV vknWomRxKZqRuTqCfsGQwnNWLFdzfAB/miDd94JKjhQXGZ/yWJjyFaGpBvoGUfY/kx2M A798iEV6q0zhRN+r2vm7XgEhvxsANLoUM1IIK1kq0D/obps360koUzd8vOwRghVTcrQo c7C6gYW07jgs4YyTp9uNeDE7/Qje/LpNcDz3SWKi5mYy79lVSwfbnXjj4V3cwmBo7moJ 6JkBdIGmyMMmJboJ78JeDQmlqusGKBUrQqjeQDGrxPBeWjwYamIf6MLgTORbEzqyiJGA Rw== 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 2bcj9ca7fn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2017 01:48:23 +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 v5T0kgqk000319; Wed, 28 Jun 2017 20:48:20 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b9kduxj9s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Jun 2017 20:48:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 20:48:19 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 28 Jun 2017 20:48:19 -0400 From: "Salz, Rich" To: Martin Thomson , Ian Swett CC: IETF QUIC WG , Patrick McManus Subject: RE: 2 Points of First Implementation Draft we might clarify Thread-Topic: 2 Points of First Implementation Draft we might clarify Thread-Index: AQHS8FBPH6TyB59WF0Oa9Z3+06dB/aI7A6gAgAAExQCAAACXgP//+Lwg Date: Thu, 29 Jun 2017 00:48:18 +0000 Message-ID: <0a8b613fa376412a88c95631c44531a4@usma1ex-dag1mb1.msg.corp.akamai.com> References: 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.37.175] 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-06-28_15:, , 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-1706290011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-28_15:, , 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-1706290011 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, 29 Jun 2017 00:48:27 -0000 PiBPbiAyOCBKdW5lIDIwMTcgYXQgMTQ6MTAsIElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNv bT4gd3JvdGU6DQo+ID4gV291bGQgb25seSBzdXBwb3J0aW5nIDE4IGNhdXNlIHByb2JsZW1zIGZv ciBhbnlvbmU/DQo+IA0KPiANCj4gQW55b25lIHVzaW5nIE9wZW5TU0wgd291bGQgaGF2ZSBhIHJl YWwgaGFyZCB0aW1lLg0KDQpXZWxsLCBub3QgYSByZWFsIGhhcmQgdGltZS4gIE91ciBjdXJyZW50 IG1hc3RlciBpcyBhdCAyMCwgYnV0IHRoZSAtMTggdmVyc2lvbiBpcyB0YWdnZWQsIHNvIHlvdSdk IGJlIGFibGUgdG8gZG8gaXQgaWYgbmVjZXNzYXJ5Lg0KDQpJIGhvcGUgaXQncyBub3QgbmVjZXNz YXJ5OyBpZiB0aGlzIGFkZHMgcHJlc3N1cmUgdG8gZ2V0IHRoZSBibG9ja2FnZXMgdW5zdHVjay4u Lg0KDQo= From nobody Wed Jun 28 17:54: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 215B1126D85 for ; Wed, 28 Jun 2017 17:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV5HGYugzQFN for ; Wed, 28 Jun 2017 17:54:35 -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 8027D1200ED for ; Wed, 28 Jun 2017 17:54:35 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id i2so63231663qta.3 for ; Wed, 28 Jun 2017 17:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vICbCJZHfYksDwjLXVfZJAB7ZSR8vxrCBF8h8QwELso=; b=KMXBta3EPj+RJaPnisZsdiEy5JmiL2uSMfLMDnaZ2P06h5x9nrKHKuTrPN9T6Diqsy p50DaYRrHfwaZ8ET9AZrIXVBE83DrBZAyDq6cVpG4nb+lR6UP25n74UVZjHpJXSmFlgt FpLvTWhLDwkCMceyoaBnMFZFFCDYqvp4LeE1sKS4nY1E4KGEK4qkD6+n2EdQGoP0nO+r J0HocNMmXwmff16N8he2/NHepk9lnNEKZ0jFeNMwOoVI5HpbrI2gL1r2+PWrFAFPqIES t+OKHR6YriPWCUHoo8MOuQA0dZ6QOjt+iVXyqLINJx8oOzXejYdJ661StXIA1pnkggQi dnEw== 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=vICbCJZHfYksDwjLXVfZJAB7ZSR8vxrCBF8h8QwELso=; b=idVv7bz2NSAS+XrXHbmJQgUHcCuiVPzfK5STbKJJTg1E4fVE18saLt20xZh9mpO76x /IdHzYE3XwGN1Da14FN2EpRH8rvCh6zJlpPudy2AOH1YbrQiLGIstqhWwmKIqsI+to18 5Uqiytc9XbXpGLsNwk0IMD+nzuhWowtrQNrZoQ9uQhLfTQk+M2YTCjt2TxqknjREoqiS R054NTcRHy8Llqnf6QjWn68EOs4DtFGWDodyEUr4D5XapVtrtPL5maRwwd1bIbfZCUHt pPDYdfsukZay4mSxkvpB8yC+uezLdYD4/PFVKpXwVPsp/PNt2RdzIG70ty4gjYHdiXfd reBg== X-Gm-Message-State: AKS2vOxH4OaKDXgVyKs5ZlfEqKssYrja91Z3tfqfhsCCwgjhPlxd+7+i ooL83nE+yWo5KAygdfvhHQGWxn6zeY0b X-Received: by 10.237.43.134 with SMTP id e6mr16023235qtd.131.1498697674718; Wed, 28 Jun 2017 17:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.48.148 with HTTP; Wed, 28 Jun 2017 17:54:14 -0700 (PDT) In-Reply-To: References: From: Tatsuhiro Tsujikawa Date: Thu, 29 Jun 2017 09:54:14 +0900 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Jana Iyengar Cc: Martin Thomson , Ian Swett , IETF QUIC WG , Patrick McManus Content-Type: multipart/alternative; boundary="001a114ecf0087029f05530ebedf" 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, 29 Jun 2017 00:54:37 -0000 --001a114ecf0087029f05530ebedf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 29, 2017 at 9:00 AM, Jana Iyengar wrote: > On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson > wrote: > >> On 28 June 2017 at 14:10, Ian Swett wrote: >> > Would only supporting 18 cause problems for anyone? >> >> >> Anyone using OpenSSL would have a real hard time. >> > > Is anyone planning to use OpenSSL for the interop? > > =E2=80=8BI originally planed to use OpenSSL, but it turns out that it does = not have TLSv1.3 exporter yet. I can live with boringssl (-18) for the first implementation draft. Best regards, Tatsuhiro Tsujikawa=E2=80=8B --001a114ecf0087029f05530ebedf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jun 29, 2017 at 9:00 AM, Jana Iyengar = <j= ri@google.com> wrote:
On = Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 28 June 2017 at 14:10, Ian S= wett <ianswett@= google.com> wrote:
> Would only supporting 18 cause problems for anyone?


Anyone using OpenSSL would have a real hard time.

Is anyone planning to use OpenSSL for the int= erop?=C2=A0


=E2=80=8BI originally planed to use OpenSSL, but it tur= ns out that it does not have TLSv1.3 exporter yet.
I can live with boringssl (-18) for the first implementa= tion draft.

Best regards,
Tatsuhiro Tsujikawa=E2=80=8B
= =C2=A0

--001a114ecf0087029f05530ebedf-- From nobody Wed Jun 28 17:59: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 0766C126C83 for ; Wed, 28 Jun 2017 17:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMxwipgHmTWZ for ; Wed, 28 Jun 2017 17:59:08 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 97F861200ED for ; Wed, 28 Jun 2017 17:59:08 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id t127so31236462ywc.3 for ; Wed, 28 Jun 2017 17:59:08 -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=MmdMDcu2ZuEhWPIOmEzJRTk9IUWm74R4HF8mdbV5Ans=; b=fNZ0CAJlL/TFnOQ1hBrhYGKkSedwsyxHeo9W345dtaKgR4YDRwo2GTqnndbG3URYUV PQUh/k3WV+5sAsI5/4Ta1vNCw8bQRQJ40uC9uiPCTPRNdOAmCAzxeHxQzgHSRH7v8tnc fXB6VR991BHkpk9qs2oRMiYFDABeNsf/XwWfZsfEVTvRVGfa4iCa9/n0kj+dWfasT+IJ izWr0J7lqSn/AhEO2oqCu/5JzSCl+vDkQv8OvV7DJueWmWQBpSyWoMTHEnkVvJKlF+W9 FFZgq/CLvx8a9koIsHL2bKn9hesn1HMhZzTRNy4k47KKVZrroi/Cl5W0Z1+vr8RuDQ7J P96g== 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=MmdMDcu2ZuEhWPIOmEzJRTk9IUWm74R4HF8mdbV5Ans=; b=EosmOwlQHWH8+wP5JulzUuCQDYFXeTj80h00lsy+kU9MuawFt1JHdin1Nt9zD/dtGq YDQI0Nnqm4t7zIC27laDHx8uybKVsR0Hy+QcMvijUD1xXxbIhZT0WFv6K9I3Lx8Kqq0j QSJmp9tvew2bf3PQxYlKG7xskgY7fPmT+R48eoMwEkutInQCwCLf6yuCLNr8j2m7FW0p liIxnyt76euOsJ+td3ecEzSy4FdZ0pbfTM+G+yS9vvxyxTJ+WHFU1c/loM/cIGTa3XOZ IlzA7+L6unkjHCrO1TCNCGA1wAYb1S74PqQUZzNvm+HSST/nAcL2irY0A8Cjdk6LmLTL shEA== X-Gm-Message-State: AKS2vOzwSixuklBxMQlkcDDerxyouilJknJivQFdHsuW2U2pKeYAeu5T u582oyp3gIkWXVJk42Hj93G4ymKTs6te X-Received: by 10.129.109.206 with SMTP id i197mr3548673ywc.24.1498697947563; Wed, 28 Jun 2017 17:59:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 28 Jun 2017 17:58:26 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 28 Jun 2017 17:58:26 -0700 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Tatsuhiro Tsujikawa Cc: Jana Iyengar , Ian Swett , IETF QUIC WG , Martin Thomson , Patrick McManus Content-Type: multipart/alternative; boundary="001a114dd266ca5c8a05530ece6c" 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, 29 Jun 2017 00:59:10 -0000 --001a114dd266ca5c8a05530ece6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think it's disastrous to use -18, as that's what people have generally fielded. If/when people feel comfortable in their -20 branches, it would be good to change to that, however. -Ekr On Wed, Jun 28, 2017 at 5:54 PM, Tatsuhiro Tsujikawa wrote: > > > On Thu, Jun 29, 2017 at 9:00 AM, Jana Iyengar wrote: > >> On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson > > wrote: >> >>> On 28 June 2017 at 14:10, Ian Swett wrote: >>> > Would only supporting 18 cause problems for anyone? >>> >>> >>> Anyone using OpenSSL would have a real hard time. >>> >> >> Is anyone planning to use OpenSSL for the interop? >> >> > =E2=80=8BI originally planed to use OpenSSL, but it turns out that it doe= s not > have TLSv1.3 exporter yet. > I can live with boringssl (-18) for the first implementation draft. > > Best regards, > Tatsuhiro Tsujikawa=E2=80=8B > > > --001a114dd266ca5c8a05530ece6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think it's disastrous to use -18, as that&= #39;s what people have generally fielded.

If/when people= feel comfortable in their -20 branches, it would be good to change to that= , however.

-Ekr

<= /div>

On Wed= , Jun 28, 2017 at 5:54 PM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com<= /a>> wrote:


On Thu, Jun 29, 2017 at 9:00 AM, Jana Iyen= gar <jri@google.com> wrote:
<= div dir=3D"ltr">
On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
On 28 J= une 2017 at 14:10, Ian Swett <ianswett@google.com> wrote:
> Would only supporting 18 cause problems for anyone?


Anyone using OpenSSL would have a real hard time.

Is anyone planning to use OpenSSL for the int= erop?=C2=A0


=E2=80=8BI originally planed to use OpenSSL= , but it turns out that it does not have TLSv1.3 exporter yet.
I can live with boringssl (-18) for the firs= t implementation draft.

Best= regards,
Tatsuhiro Tsujikawa=E2= =80=8B
=C2=A0

--001a114dd266ca5c8a05530ece6c-- From nobody Wed Jun 28 18:01: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 8466F127333 for ; Wed, 28 Jun 2017 18:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 73mUzhYX607F for ; Wed, 28 Jun 2017 18:01:17 -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 E25F412708C for ; Wed, 28 Jun 2017 18:01:17 -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 v5T0wYhV010749; Thu, 29 Jun 2017 02:01:14 +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=r7JBk/96XnReQqQL+xQ8SiO0RR+5IgG6fzOHuejbVGo=; b=WQm05nAaN80cPhX9FSIOblWYNw66J7fAW6IIzxHjO4LLYhrJ2r2VxCd3TOJBfWv1mEm7 Dd3UbL5mOHZ9NX5PW3Nv4W/6M5n8fcOJ8GFjRnmdAoxZcB02iThI9QTbg/YDT4oJIwLB gKM/RbN9jzWPszHDd6IWsF15m99JCXn8tYhWk0HW+TsAiQCtPHxfJruMV3lAYXqLTe4+ Jf6q4fKVNC6w0fj/LeOmfrhBteVdyCfcuqmzV0j7SPm/sNm5tIj+zx0srouADCJZaqjR PvC9GpbdcPtD64Ut9p/J56LMroXulpD7NQSxGpdgzPf5fctuD1L0L/W2D498zXiIpgKy DQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bcd2k4dkh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2017 02:01:14 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5T0wBPc011673; Wed, 28 Jun 2017 21:01:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b9kdv6kqw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Jun 2017 21:01:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 21:01:03 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 28 Jun 2017 21:01:03 -0400 From: "Salz, Rich" To: Tatsuhiro Tsujikawa , Jana Iyengar CC: Ian Swett , IETF QUIC WG , "Martin Thomson" , Patrick McManus Subject: RE: 2 Points of First Implementation Draft we might clarify Thread-Topic: 2 Points of First Implementation Draft we might clarify Thread-Index: AQHS8FBPH6TyB59WF0Oa9Z3+06dB/aI7A6gAgAAExQCAAACXgIAALsGAgAAPHAD//77DIA== Date: Thu, 29 Jun 2017 01:01:02 +0000 Message-ID: <57ecca1258534ffab0c07931d5593c33@usma1ex-dag1mb1.msg.corp.akamai.com> References: 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.37.175] Content-Type: multipart/alternative; boundary="_000_57ecca1258534ffab0c07931d5593c33usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-29_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-1706290013 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-29_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-1706290014 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, 29 Jun 2017 01:01:19 -0000 --_000_57ecca1258534ffab0c07931d5593c33usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3BlblNTTCBoYXMgdGhlIGV4cG9ydGVyIG5vdywgYnV0IGl04oCZcyBpbiBtYXN0ZXIgKGRyYWZ0 IDIwKSBub3QgdGhlIGRyYWZ0IDE4IGJyYW5jaC4NCg== --_000_57ecca1258534ffab0c07931d5593c33usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9wZW5TU0wgaGFzIHRoZSBleHBvcnRlciBub3csIGJ1dCBp dOKAmXMgaW4gbWFzdGVyIChkcmFmdCAyMCkgbm90IHRoZSBkcmFmdCAxOCBicmFuY2guPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_57ecca1258534ffab0c07931d5593c33usma1exdag1mb1msgcorpak_-- From nobody Wed Jun 28 18:23: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 533F8127337 for ; Wed, 28 Jun 2017 18:23:39 -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 uYVGIsCtcNGb for ; Wed, 28 Jun 2017 18:23:35 -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 DE74B126E64 for ; Wed, 28 Jun 2017 18:23:34 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id 63so31455236ywr.0 for ; Wed, 28 Jun 2017 18:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zaZ2qLGronWFkrtSGUtnA4NBzMi4GoACB4KveAw6+VU=; b=LCN5RhYIT6WLXvtwzLfeDSkTqh/7czOsVau5Otw6DUFa/co01bY9kFVl4fQ8oZJy/D bKUsGUGklpuDrPV4dHq60/QmDeli0yUjvSoZKo6lkasKd/QPdu84Z3NJu83qG3QjP5Op SkrnX2Mj17toTLW0iXyl9O+w27pJxGhxc/gHOXHOqpJAREPxCcSh9GqohF2ud30dhmAS cIAbbT8x0av1U2zYDHOBgwtIVJ73PrmizM2/kP7ws6qowO1Gt6j+4V+Az0MyqZvYq0W9 UR1Tz5qQi7Wt/4FYKE26ua65qV5iT68gXvyGq0iyYD7NB0nShZqAkBSj95ABEEIkvpL6 0uyg== 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=zaZ2qLGronWFkrtSGUtnA4NBzMi4GoACB4KveAw6+VU=; b=rjKhMEHJU9YrpfrHOucZMLRORiOcCsLQSyVaZ3irIm3AhKWDq/PVo4BEJrEy2cDdRl JJ9CiEhWsjuuyqNUN2mRhqK2fchBBn3frKCgc8UzNO63/YbHbBEfkMGxXgveLdBlyn71 Q/R1OQf6jDvxNPV/i/JAjfq3J8UglC+BL+VuaUF6NmNnvJjO56P+sVPec+9Oy/bkkpTq gGyT/y0ahCBBtwrbP+ul4LCOt3M6L+4/mCn6qM6I5nOscnxgUXoV88hB5+3y2LHHw9DJ wQOli79egVRheHTWF6QNNtUQFGSluCfu7dxCjGborWWZskH+FoTNFkLvzAn0eo0NGtVI C1Jg== X-Gm-Message-State: AKS2vOzE8FT22NgD2k10V6mmJTkRoU3qMnvJ06OdZ0aUVo2+/oCD9YyP ovMwybisCB1U4eavCD6UyVM7Qz1pbdbx X-Received: by 10.129.146.15 with SMTP id j15mr9833836ywg.283.1498699413894; Wed, 28 Jun 2017 18:23:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.3 with HTTP; Wed, 28 Jun 2017 18:23:13 -0700 (PDT) In-Reply-To: <2240c2a68910453e97fc50d42e8a1d4f@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> From: Ian Swett Date: Wed, 28 Jun 2017 21:23:13 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: "Lubashev, Igor" Cc: Martin Thomson , Mike Bishop , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , QUIC WG , Jo Kulik , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Dmitri Tikhonov Content-Type: multipart/alternative; boundary="94eb2c094216311c7005530f268f" 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, 29 Jun 2017 01:23:39 -0000 --94eb2c094216311c7005530f268f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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 anywa= y. > > 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 tha= t > common case and lets us optimize that common case in the lower layer. BiD= i > 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) < > thomas.swindells@nokia.com>; QUIC WG ; Mikkel Fahn=C3=B8e > J=C3=B8rgensen ; Dmitri Tikhonov < > dtikhonov@litespeedtech.com>; Jo Kulik > Subject: Re: Unidirectional streams PR > > There is probably a simpler approach here, take a bit (as Ian did) and sa= y > that if that bit is set, then the stream is in response to another and th= e > 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 on= ly > 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 f= or > 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 ad= ding 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 stac= k. > > > > > > > > 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 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 socke= ts > > 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 thes= e 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 Prot= ocol) > > 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 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 exam= ple 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. > > > > > > --94eb2c094216311c7005530f268f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 tweaks= to the state diagram, which are also possible, so I'm open to suggesti= ons.

In the meantime, I've been considering other al= ternatives, 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 s= erver push) were unidirectional, as GQUIC does today.=C2=A0 Overall, I thin= k the approach I've outlined does a good job of iterating on existing d= eployment experience and adding explicit signaling for unidirectional strea= ms instead of implicit signaling at the application layer.=C2=A0 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, Lubash= ev, Igor <ilubashe@akamai.com> 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 mak= es a lot of sense.=C2=A0 This helps apps avoid screwing up implementing tha= t common case and lets us optimize that common case in the lower layer. BiD= i streams are such common cases. Uni streams are likely to be the second-mo= st-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 associa= ted 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 p= roposal offered to do only one thing -- offer a choice of uni/bi-directiona= l streams -- but it did it in a very simple way, which is nice.

- Igor


-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.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) <thom= as.swindells@nokia.com>; QUIC WG <quic@ietf.org>; Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Dmitri Tikhonov <<= a href=3D"mailto:dtikhonov@litespeedtech.com">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 responding follows immediately aft= er the stream ID of the stream itself.=C2=A0 You could then include that on= ly 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 discus= sing, is that unless what the transport provides is a perfect fit for appli= cation semantics, you end up building those semantics into the application = anyway.=C2=A0 HTTP certainly can't survive without its own association = semantics for pushes.=C2=A0 That suggests to me that having bidirectional s= emantics in the transport creates more duplication than otherwise.=C2=A0 He= nce my proposal.

On 28 June 2017 at 15:26, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> As promised, a PR for adding =E2=80=9Cassociated streams=E2=80=9D is a= t
> https://github.com/quicwg/base-drafts/pull/6= 72.=C2=A0 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 fir= st
> STREAM frame of a stream, I used that as the trigger for a Stream Prop= erties 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, le= ngth
> 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<= br> > 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<= br> > 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.)<= br> >
> I particularly don't like that you now have to look at the frame t= ype
> 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<= br> > 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-bounc= es@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
> <mikkelfj@gmail.com> > Cc: QUIC WG <quic@ietf.org>= ; Dmitri Tikhonov
> <dtikhonov@litespeed= tech.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
> 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<= br> > security and may allow greater throughput due to the more modern (and<= br> > customizable) congestion control algorithms compared to the OS TCP sta= ck.
>
>
>
> 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 u= sing a different library.
> This needs some form of standardization of the signalling. This could<= br> > 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=C2=A0 : Example
>
> 1/0=C2=A0 =C2=A0: An input only flow, perhaps a data logger like syslo= g with no
> confirmation/feedback
>
> 0/1=C2=A0 : an output only flow, perhaps a topic message bus service w= ith
> 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<= br> > 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-bounc= es@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@litespeed= tech.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=A0QUIC Wire Protocol (the thing described b= y the QUIC Transport RFC)
> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0QUIC 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.=C2=A0 =C2=A0 =C2=A0 =C2=A0Application (something that uses QUIC Lib= rary 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.=C2=A0 (I don't think it strictly said &quo= t;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<= br> > should abandon this particular *design goal*.=C2=A0 The goal being a > transport protocol that can elegantly fit with a uni/bi stream model.<= br> > 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, th= is
> 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.=C2=A0 During the rece= nt
> "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
> <mikkelfj@gmail.com> w= rote:
>
> 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<= br> > overhead than with uni-directional streams, especially under loss,
> potentially leading to poor performance and poor resource utilisation<= br> > 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<= br> > agree that it is easy to design into wrong assumptions without real wo= rld 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<= br> > 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 applic= ation protocols.
>
>
>
> - Finally, it may turn out that uni-directional streams just is a bad<= br> > 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@litespeedtec= h.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 negati= ve 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<= br> > to fit it into HTTP usage pattern. Forcing every one of these programs=
> to do this is certainly a hurdle.
>
> - Dmitri.
>
>


--94eb2c094216311c7005530f268f-- From nobody Wed Jun 28 23:12:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB8F128ACA for ; Wed, 28 Jun 2017 23:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mnot.net header.b=SXkSuILP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KcLi/GNE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHIbNdS-rfZB for ; Wed, 28 Jun 2017 23:12:53 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACEA128C82 for ; Wed, 28 Jun 2017 23:12:52 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3D4B820AA5 for ; Thu, 29 Jun 2017 02:12:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 29 Jun 2017 02:12:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= 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=DOXiMqcsSqSvXUMcr35VyeGtHVCUiPag0MEgNEjfM Jg=; b=SXkSuILPQ5K/2mlQpHN8/NfnjMwup8SnoRhBCga0hzu9NqEWCYrRhRCIR 4f+RSF2ikpX8upiwdfaYb95UoGJotcJ6YsP1QM8oWjlN5vZt5cUtj/ZihzpTqFOz v7gaU5dzu9c2qRdwjOmEwmIaNZQ8bkeVRzUFSmCS88ofHZDyXhvNFR9jk5Ua1UBT L6pKg5plyFDl5cp8x+BCA4ri1OVvsT5TJAd1+aKthJW48raEhzRKSN1jU0Al7zr1 fN+x+BchNwQPa4BQDGfTk1E4V36aKX3oQ4XejxbkwJjZmY4VH1w443GAr0kHdoko XlijlKY72XuANtRgrSZyvwD4JuSuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=DOXiMqcsSqSvXUMcr3 5VyeGtHVCUiPag0MEgNEjfMJg=; b=KcLi/GNE7g0JLktYRY+Srz9agBIFFO7Bo8 4FICVY8tzm7AmNBmI6n6JRJ88ZF2IyXhnwbvtcysqm36mlPencH6pSQ6Al4L/NOs p2qrNwqrLXRR0BVuHAkD3Cy5cyue1y1j4ehqtw1wpxkEiHIPSGa19cd+S0n8wL3l hYIxFje9qBXc7p5YfRzW0Eq0UeSXdYqpur5p0bhjC/lJ8SqCa1GP3YsESAE9lMbs +E0GfO21w7gYVh5I2qphtbN2uFZtqXjH7VYgkPx9kylxFpGPvieNBtxzgLMKpIxR 7+TXPKjyhgaUFyO2z4xs0ixXFVxtxtUGNTL57i1ZmgP5tbzXA6KQ== X-ME-Sender: X-Sasl-enc: +VkVBK1bV0NNM12W7e3apIfs3Vz8mckw+i07bE4xBe7L 1498716771 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 87E9724253 for ; Thu, 29 Jun 2017 02:12:51 -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: DRAFT Prague Agenda Message-Id: <4C1E3F53-4DE3-4737-ABDD-CCCD3E41129A@mnot.net> Date: Thu, 29 Jun 2017 16:12:48 +1000 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: Thu, 29 Jun 2017 06:12:55 -0000 .. is at: https://github.com/quicwg/wg-materials/blob/master/ietf99/agenda.md NOTE: We will be holding a joint session with the HTTP Working Group on = Wednesday, 19 July. See their agenda at: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf99/agenda.md -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jun 29 01:27:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3612EB69 for ; Thu, 29 Jun 2017 01:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_V1QxDmwibl for ; Thu, 29 Jun 2017 01:27:38 -0700 (PDT) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F67312EAF0 for ; Thu, 29 Jun 2017 01:27:38 -0700 (PDT) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v5T8Ra3B029182; Thu, 29 Jun 2017 09:27:36 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0319.002; Thu, 29 Jun 2017 09:27:35 +0100 From: Lucas Pardue To: Mark Nottingham , IETF QUIC WG Subject: RE: DRAFT Prague Agenda Thread-Topic: DRAFT Prague Agenda Thread-Index: AQHS8J7EB3800D0uC0alPDYBrMeWFaI7gcdN Date: Thu, 29 Jun 2017 08:27:35 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A37724B12@bgb01xud1012> References: <4C1E3F53-4DE3-4737-ABDD-CCCD3E41129A@mnot.net> In-Reply-To: <4C1E3F53-4DE3-4737-ABDD-CCCD3E41129A@mnot.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23164.005 x-tm-as-result: No--6.911000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" 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: Thu, 29 Jun 2017 08:27:40 -0000 Hi Mark, Is the agenda open to proposals for talks (in one session or another)? I ap= preciate its going to be pretty full with issues discussion already... Lucas ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Mark Nottingham [mnot@mnot.= net] Sent: 29 June 2017 07:12 To: IETF QUIC WG Subject: DRAFT Prague Agenda .. is at: https://github.com/quicwg/wg-materials/blob/master/ietf99/agenda.md NOTE: We will be holding a joint session with the HTTP Working Group on Wed= nesday, 19 July. See their agenda at: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf99/agenda.md -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jun 29 09:35: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 34AAA12EC49 for ; Thu, 29 Jun 2017 09:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETRTqava51zg for ; Thu, 29 Jun 2017 09:35:10 -0700 (PDT) Received: from mx36-42.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 35B2A124E15 for ; Thu, 29 Jun 2017 09:35:10 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dQcPM-0004NC-EA for quic@ietf.org; Thu, 29 Jun 2017 18:35:09 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dQcPF-0002wy-UT for quic@ietf.org; Thu, 29 Jun 2017 12:35:06 -0400 Received: (qmail 27781 invoked from network); 29 Jun 2017 16:35:00 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.244]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Jun 2017 16:35:00 -0000 To: quic@ietf.org References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> From: Christian Huitema Message-ID: <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> Date: Thu, 29 Jun 2017 09:34:58 -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="------------770AB73FAD11E52838B95C5B" Subject: Re: Unidirectional streams PR X-Originating-IP: 168.144.250.232 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.20) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJackVDEeh/s63C3hq8BP19aND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23gyy/6QOlnqqnVP+erb63jz1ArgeOpTMAnrdw QOeVZolmW+kLkdxBnHUv18zBlWQxYOEkjsX7F8KmpUaZQHV+ST61TfxIvi8LwOTvVrRIhaC2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpIuW2VxLnS94njDgTNmyTXH6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGySJ1NAlehadpd7FIhnvRSGveNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17jczFy7tELlDUkEnE2lik8C2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe91Y2lWQ2MJXd3CnOcfuxlrTMLn6MURQGfriekzS 9Ga3AA== 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, 29 Jun 2017 16:35:12 -0000 This is a multi-part message in MIME format. --------------770AB73FAD11E52838B95C5B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/28/2017 6:23 PM, Ian Swett wrote: > 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. > > 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= =2E > I understand how to handle concurrent stream limits with plain bidirectional streams or with plain unidirectional streams, but things are not so clear when we start mixing models by adding a unidirectional option to bidirectional or vice versa. In the clean models, we can count the number of streams initiated by one entity and not yet closed. But in the mixed models, what do we count, exactly? For example, let's suppose that in an unidirectional stream model, the client creates a stream that also "implies" a stream creation in the other direction. Does this implied stream count against the server limit or the client limit? Or vice versa. Suppose that in a bidirectional stream model the client creates a stream that is declared as actually unidirectional. And suppose that this stream is immediately closed -- a stream frame with both the FIN bit and the PR 656 UNI bit set. This stream counts against the client's number of concurrent streams, but it is immediately closed by both parties. Does it count as zero? --=20 Christian Huitema --------------770AB73FAD11E52838B95C5B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 6/28/2017 6:23 PM, Ian Swett wrote:

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.

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.


I understand how to handle concurrent stream limits with plain bidirectional streams or with plain unidirectional streams, but things are not so clear when we start mixing models by adding a unidirectional option to bidirectional or vice versa. In the clean models, we can count the number of streams initiated by one entity and not yet closed. But in the mixed models, what do we count, exactly?

For example, let's suppose that in an unidirectional stream model, the client creates a stream that also "implies" a stream creation in the other direction. Does this implied stream count against the server limit or the client limit?

Or vice versa. Suppose that in a bidirectional stream model the client creates a stream that is declared as actually unidirectional. And suppose that this stream is immediately closed -- a stream frame with both the FIN bit and the PR 656 UNI bit set. This stream counts against the client's number of concurrent streams, but it is immediately closed by both parties. Does it count as zero?
-- 
Christian Huitema
--------------770AB73FAD11E52838B95C5B-- From nobody Thu Jun 29 09:57:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E23B129B4B for ; Thu, 29 Jun 2017 09:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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, T_KAM_HTML_FONT_INVALID=0.01, 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 sm9wTbeiVbzD for ; Thu, 29 Jun 2017 09:57:29 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0106.outbound.protection.outlook.com [104.47.40.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5323F129B41 for ; Thu, 29 Jun 2017 09:57:29 -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=/3X5AyWTP1NBCFdyZO0akPGzuxbE9ma9uaeKhMjIL8g=; b=XRmTUsYb05u8vFtB+bKZ27Wpz4BP2ReLoUQfXAVHt9QujS2Tz5OrnJsbZdGDUZErT0IIHSp3CoCtMhiYqT0oZfC9cerdAnHmCzKP9T6+d1lN3whWCa6FSZgQrlfBNh8W+9FrSN504T4GqznAk3mKOb0dBdOWq/NvHM4XHkxnPbU= 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_128_CBC_SHA256_P256) id 15.1.1240.5; Thu, 29 Jun 2017 16:57:28 +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.1240.007; Thu, 29 Jun 2017 16:57:28 +0000 From: Mike Bishop To: huitema , "quic@ietf.org" Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K+GEgoMqpt2Pk2cfh8bhUTRCKI0Yv2AgATdKACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfOeQgAASMwCAAAzfAIAAEzGAgAD+vQCAAAS6QA== Date: Thu, 29 Jun 2017 16:57:27 +0000 Message-ID: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> In-Reply-To: <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huitema.net; dkim=none (message not signed) header.d=none;huitema.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::de] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0125; 7:OuZpO14bi6UCSCOHi1idpVN6M3iRsDhBJbofrqcSFUtV4O+8CcUBq2rEbtXwPA3m9nrn0lHbqptilhijpdFpbT2fWCo//qy6QAWfzJ1XigJAR1DOMl/Pk/n0E0UjNE1sAvJcdiuyWQPOjyXEWJ9S88XNDBft9kjcRAjCtZWHR+jShfWLVDP8mt+7XnzR2LLCxXaGY0sKxMA+qK9MPvdyA2tr80NtDPazQDf2UYBZOwxrebc2oZGZVVfyqBPuvkI+qxDeOPpfR7NAa5NBPe/DTe6VtYPLM4vkOYsiirNBnuSk7omNCW2iNv/usWVM2lRYYP0p7CyegVxrXvOp6mh1QtOw+ieEw+cVB5nzKt2iyGOngMLg3T+bWnB683sFEh6Lgx2PaB0vtIKuFDy9vCscmbK6pqY08wSox7JpaAUGq2zLa3qno1ZGx6iX2A6/XTtxWMRVAiIyf+xcFe8HyYNCu2Qb6CWJw4DvmMLe3GSueGnpcVwOePXo1eXzemR1jLXKdJpR/w3S1rAeKG2c5hD2UVUPXgByGYyMCrFfysU76VKMYH60sNxVCHQeb76LP1q1yMZz6kT62JShZbN1q+TcZxFnydJYjUMT46NpQ+c5ec24AX49n7tkkAP5SR0rcvBk6CedvUuTYhuW9mI+ZXi9K4m0kV1cIyzF6Dkop1RumKPxxVvS+oywF++IqKU83hVyLgBD7fUuKAclKKCkF22Uaydrjxb5Oq/5M5+mypf6Jc1nv40/cEzv8iJvy6w76yiTl0FDLkOZ85YxlL3l8yGp52t9k8uU83CDuwR+HHQLADwMKN4rlxuY45D0cjSp9Pbv x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: 102c5164-4f26-4fe1-ce12-08d4bf0fec94 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)(2017052603026)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0125; x-ms-traffictypediagnostic: MWHPR21MB0125: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(158342451672863)(26388249023172)(236129657087228)(189930954265078)(48057245064654)(148574349560750)(219752817060721)(21748063052155)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910016)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(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: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(377454003)(55674003)(24454002)(6506006)(7736002)(5005710100001)(10090500001)(33656002)(3480700004)(77096006)(25786009)(6436002)(478600001)(7116003)(5660300001)(8936002)(54356999)(50986999)(76176999)(86612001)(86362001)(81166006)(2950100002)(10290500003)(2501003)(229853002)(7696004)(74316002)(3280700002)(189998001)(14454004)(790700001)(6116002)(53546010)(93886004)(2900100001)(6306002)(6246003)(8676002)(236005)(9686003)(72206003)(38730400002)(3660700001)(54896002)(606006)(55016002)(53936002)(99286003)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0125; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0141DAB51088DE57504B12F087D20MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2017 16:57:27.8953 (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: Thu, 29 Jun 2017 16:57:32 -0000 --_000_MWHPR21MB0141DAB51088DE57504B12F087D20MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TW9vdCBwb2ludCDigJMgdGhlcmUgaXMgbm8gY29uY3VycmVudCBzdHJlYW0gbGltaXQgaW4gdGhl IHByb3RvY29sLiAgVGhlcmUgaXMgb25seSBhIG1heGltdW0gc3RyZWFtIElELCBhbmQgaG93IHlv dXIgaW1wbGVtZW50YXRpb24gZGVjaWRlcyB3aGF0IG1heGltdW0gc3RyZWFtIElEIHRvIGlzc3Vl IHRvIHRoZSBwZWVyIGFsbG93cyB5b3UgdG8gY2hvb3NlIGFueSByZXNvbHV0aW9uIHRvIHRoZXNl IHF1ZXN0aW9ucyB5b3UgbGlrZS4NCg0KTm93LCBpbiB0aGUgdW5pZGlyZWN0aW9uYWwgb3IgbWl4 ZWQgZGVzaWducywgeW91IGRvIGhhdmUgdGhlIGNvcm5lciBjYXNlIHdoZXJlIGEgY2xpZW50IGNh biBzZW5kIGEgcmVxdWVzdCwgYnV0IG5vdCBnaXZlIHRoZSBzZXJ2ZXIgZW5vdWdoIFN0cmVhbSBJ RHMgdG8gcmVzcG9uZC4gIChEb27igJl0IGRvIHRoYXQuKSAgTW9yZSByZWFsaXN0aWNhbGx5LCB0 aGUgc2VydmVyIGNhbiBoYXZlIGEgbGltaXRlZCBudW1iZXIgb2YgU3RyZWFtIElEcyBhbmQgc3Bl bmQgdGhlbSBvbiBwdXNoZXMgaW5zdGVhZCBvZiBhY3R1YWwgcmVzcG9uc2VzLg0KDQpGcm9tOiBR VUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFu IEh1aXRlbWENClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI5LCAyMDE3IDk6MzUgQU0NClRvOiBxdWlj QGlldGYub3JnDQpTdWJqZWN0OiBSZTogVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBQUg0KDQoNCk9u IDYvMjgvMjAxNyA2OjIzIFBNLCBJYW4gU3dldHQgd3JvdGU6DQpJIHVwZGF0ZWQgbXkgUFIoIzY1 NjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY2NTYm ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDNTBiN2M5MWE2 YmY0NDFkNjY3NGQwOGQ0YmYwY2Q0OTglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2MzQzNTA5MjEwOTU5NjU3JnNkYXRhPXpkSEhnYzFJZnpkd0VXRlFDUElr JTJCN2l1ZkNSMWp6SjllSHRxWHg5QmFrMCUzRCZyZXNlcnZlZD0wPikgdG9kYXksIHNvcnJ5IGZv ciB0aGUgZGVsYXkuICBJIGF0dGVtcHRlZCB0byBhZGRyZXNzIHRoZSBpc3N1ZXMgaWRlbnRpZmll ZCB3aXRoIHRleHQuICBTb21lIG1heSBwcmVmZXIgbW9yZSB0d2Vha3MgdG8gdGhlIHN0YXRlIGRp YWdyYW0sIHdoaWNoIGFyZSBhbHNvIHBvc3NpYmxlLCBzbyBJJ20gb3BlbiB0byBzdWdnZXN0aW9u cy4NCg0KSW4gdGhlIG1lYW50aW1lLCBJJ3ZlIGJlZW4gY29uc2lkZXJpbmcgb3RoZXIgYWx0ZXJu YXRpdmVzLCBpbmNsdWRpbmcgdmFyaWF0aW9ucyBvbiBNaWtlJ3MgZGlyZWN0aW9uIGFuZCBhIHZh cmlhdGlvbiBvZiB0aGUgIkRvIE5vdGhpbmciIG9wdGlvbiB3aGljaCBpbnZvbHZlZCB0aGUgYXBw bGljYXRpb24gc2lnbmFsaW5nIHRvIHRoZSB0cmFuc3BvcnQgdGhhdCBzdHJlYW1zIG9mIGEgY2Vy dGFpbiBzb3J0KGllOiBzZXJ2ZXIgdG8gY2xpZW50IGZvciBzZXJ2ZXIgcHVzaCkgd2VyZSB1bmlk aXJlY3Rpb25hbCwgYXMgR1FVSUMgZG9lcyB0b2RheS4gIE92ZXJhbGwsIEkgdGhpbmsgdGhlIGFw cHJvYWNoIEkndmUgb3V0bGluZWQgZG9lcyBhIGdvb2Qgam9iIG9mIGl0ZXJhdGluZyBvbiBleGlz dGluZyBkZXBsb3ltZW50IGV4cGVyaWVuY2UgYW5kIGFkZGluZyBleHBsaWNpdCBzaWduYWxpbmcg Zm9yIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgaW5zdGVhZCBvZiBpbXBsaWNpdCBzaWduYWxpbmcg YXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiAgVGhlcmUgYXJlIHByb3MgYW5kIGNvbnMgdG8gYm90 aCBleHBsaWNpdCBhbmQgaW1wbGljaXQgc2lnbmFsaW5nLCBidXQgSSB0aGluayBleHBsaWNpdCBz aWduYWxpbmcgaXMgbW9yZSBjb21wbGV0ZSBhbmQgbGVzcyBwcm9uZSB0byBhcHBsaWNhdGlvbiBl cnJvci4NCg0KDQpJIHVuZGVyc3RhbmQgaG93IHRvIGhhbmRsZSBjb25jdXJyZW50IHN0cmVhbSBs aW1pdHMgd2l0aCBwbGFpbiBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgb3Igd2l0aCBwbGFpbiB1bmlk aXJlY3Rpb25hbCBzdHJlYW1zLCBidXQgdGhpbmdzIGFyZSBub3Qgc28gY2xlYXIgd2hlbiB3ZSBz dGFydCBtaXhpbmcgbW9kZWxzIGJ5IGFkZGluZyBhIHVuaWRpcmVjdGlvbmFsIG9wdGlvbiB0byBi aWRpcmVjdGlvbmFsIG9yIHZpY2UgdmVyc2EuIEluIHRoZSBjbGVhbiBtb2RlbHMsIHdlIGNhbiBj b3VudCB0aGUgbnVtYmVyIG9mIHN0cmVhbXMgaW5pdGlhdGVkIGJ5IG9uZSBlbnRpdHkgYW5kIG5v dCB5ZXQgY2xvc2VkLiBCdXQgaW4gdGhlIG1peGVkIG1vZGVscywgd2hhdCBkbyB3ZSBjb3VudCwg ZXhhY3RseT8NCg0KRm9yIGV4YW1wbGUsIGxldCdzIHN1cHBvc2UgdGhhdCBpbiBhbiB1bmlkaXJl Y3Rpb25hbCBzdHJlYW0gbW9kZWwsIHRoZSBjbGllbnQgY3JlYXRlcyBhIHN0cmVhbSB0aGF0IGFs c28gImltcGxpZXMiIGEgc3RyZWFtIGNyZWF0aW9uIGluIHRoZSBvdGhlciBkaXJlY3Rpb24uIERv ZXMgdGhpcyBpbXBsaWVkIHN0cmVhbSBjb3VudCBhZ2FpbnN0IHRoZSBzZXJ2ZXIgbGltaXQgb3Ig dGhlIGNsaWVudCBsaW1pdD8NCg0KT3IgdmljZSB2ZXJzYS4gU3VwcG9zZSB0aGF0IGluIGEgYmlk aXJlY3Rpb25hbCBzdHJlYW0gbW9kZWwgdGhlIGNsaWVudCBjcmVhdGVzIGEgc3RyZWFtIHRoYXQg aXMgZGVjbGFyZWQgYXMgYWN0dWFsbHkgdW5pZGlyZWN0aW9uYWwuIEFuZCBzdXBwb3NlIHRoYXQg dGhpcyBzdHJlYW0gaXMgaW1tZWRpYXRlbHkgY2xvc2VkIC0tIGEgc3RyZWFtIGZyYW1lIHdpdGgg Ym90aCB0aGUgRklOIGJpdCBhbmQgdGhlIFBSIDY1NiBVTkkgYml0IHNldC4gVGhpcyBzdHJlYW0g Y291bnRzIGFnYWluc3QgdGhlIGNsaWVudCdzIG51bWJlciBvZiBjb25jdXJyZW50IHN0cmVhbXMs IGJ1dCBpdCBpcyBpbW1lZGlhdGVseSBjbG9zZWQgYnkgYm90aCBwYXJ0aWVzLiBEb2VzIGl0IGNv dW50IGFzIHplcm8/DQotLQ0KDQpDaHJpc3RpYW4gSHVpdGVtYQ0K --_000_MWHPR21MB0141DAB51088DE57504B12F087D20MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+TW9vdCBwb2ludCDigJMgdGhlcmUgaXMgbm8gY29u Y3VycmVudCBzdHJlYW0gbGltaXQgaW4gdGhlIHByb3RvY29sLiZuYnNwOyBUaGVyZSBpcyBvbmx5 IGEgbWF4aW11bSBzdHJlYW0gSUQsIGFuZCBob3cgeW91ciBpbXBsZW1lbnRhdGlvbiBkZWNpZGVz IHdoYXQgbWF4aW11bSBzdHJlYW0gSUQgdG8gaXNzdWUgdG8gdGhlIHBlZXIgYWxsb3dzIHlvdSB0 byBjaG9vc2UgYW55DQogcmVzb2x1dGlvbiB0byB0aGVzZSBxdWVzdGlvbnMgeW91IGxpa2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Ob3csIGluIHRoZSB1bmlk aXJlY3Rpb25hbCBvciBtaXhlZCBkZXNpZ25zLCB5b3UgZG8gaGF2ZSB0aGUgY29ybmVyIGNhc2Ug d2hlcmUgYSBjbGllbnQgY2FuIHNlbmQgYSByZXF1ZXN0LCBidXQgbm90IGdpdmUgdGhlIHNlcnZl ciBlbm91Z2ggU3RyZWFtIElEcyB0byByZXNwb25kLiZuYnNwOyAoRG9u4oCZdCBkbyB0aGF0Likm bmJzcDsgTW9yZSByZWFsaXN0aWNhbGx5LCB0aGUNCiBzZXJ2ZXIgY2FuIGhhdmUgYSBsaW1pdGVk IG51bWJlciBvZiBTdHJlYW0gSURzIGFuZCBzcGVuZCB0aGVtIG9uIHB1c2hlcyBpbnN0ZWFkIG9m IGFjdHVhbCByZXNwb25zZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMjksIDIwMTcgOTozNSBBTTxicj4NCjxiPlRvOjwv Yj4gcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVW5pZGlyZWN0aW9uYWwg c3RyZWFtcyBQUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPk9uIDYvMjgvMjAxNyA2OjIz IFBNLCBJYW4gU3dldHQgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdXBkYXRlZCBteSBQUig8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2cl MkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY2NTYmYW1wO2RhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlz aG9wJTQwbWljcm9zb2Z0LmNvbSU3QzUwYjdjOTFhNmJmNDQxZDY2NzRkMDhkNGJmMGNkNDk4JTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjM0MzUwOTIxMDk1 OTY1NyZhbXA7c2RhdGE9emRISGdjMUlmemR3RVdGUUNQSWslMkI3aXVmQ1IxanpKOWVIdHFYeDlC YWswJTNEJmFtcDtyZXNlcnZlZD0wIj4jNjU2PC9hPikNCiB0b2RheSwgc29ycnkgZm9yIHRoZSBk ZWxheS4mbmJzcDsgSSBhdHRlbXB0ZWQgdG8gYWRkcmVzcyB0aGUgaXNzdWVzIGlkZW50aWZpZWQg d2l0aCB0ZXh0LiZuYnNwOyBTb21lIG1heSBwcmVmZXIgbW9yZSB0d2Vha3MgdG8gdGhlIHN0YXRl IGRpYWdyYW0sIHdoaWNoIGFyZSBhbHNvIHBvc3NpYmxlLCBzbyBJJ20gb3BlbiB0byBzdWdnZXN0 aW9ucy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4g dGhlIG1lYW50aW1lLCBJJ3ZlIGJlZW4gY29uc2lkZXJpbmcgb3RoZXIgYWx0ZXJuYXRpdmVzLCBp bmNsdWRpbmcgdmFyaWF0aW9ucyBvbiBNaWtlJ3MgZGlyZWN0aW9uIGFuZCBhIHZhcmlhdGlvbiBv ZiB0aGUgJnF1b3Q7RG8gTm90aGluZyZxdW90OyBvcHRpb24gd2hpY2ggaW52b2x2ZWQgdGhlIGFw cGxpY2F0aW9uIHNpZ25hbGluZyB0byB0aGUgdHJhbnNwb3J0IHRoYXQgc3RyZWFtcyBvZiBhIGNl cnRhaW4gc29ydChpZToNCiBzZXJ2ZXIgdG8gY2xpZW50IGZvciBzZXJ2ZXIgcHVzaCkgd2VyZSB1 bmlkaXJlY3Rpb25hbCwgYXMgR1FVSUMgZG9lcyB0b2RheS4mbmJzcDsgT3ZlcmFsbCwgSSB0aGlu ayB0aGUgYXBwcm9hY2ggSSd2ZSBvdXRsaW5lZCBkb2VzIGEgZ29vZCBqb2Igb2YgaXRlcmF0aW5n IG9uIGV4aXN0aW5nIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBhbmQgYWRkaW5nIGV4cGxpY2l0IHNp Z25hbGluZyBmb3IgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBpbnN0ZWFkIG9mIGltcGxpY2l0DQog c2lnbmFsaW5nIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllci4mbmJzcDsgVGhlcmUgYXJlIHByb3Mg YW5kIGNvbnMgdG8gYm90aCBleHBsaWNpdCBhbmQgaW1wbGljaXQgc2lnbmFsaW5nLCBidXQgSSB0 aGluayBleHBsaWNpdCBzaWduYWxpbmcgaXMgbW9yZSBjb21wbGV0ZSBhbmQgbGVzcyBwcm9uZSB0 byBhcHBsaWNhdGlvbiBlcnJvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIHVuZGVyc3RhbmQgaG93IHRvIGhhbmRs ZSBjb25jdXJyZW50IHN0cmVhbSBsaW1pdHMgd2l0aCBwbGFpbiBiaWRpcmVjdGlvbmFsIHN0cmVh bXMgb3Igd2l0aCBwbGFpbiB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zLCBidXQgdGhpbmdzIGFyZSBu b3Qgc28gY2xlYXIgd2hlbiB3ZSBzdGFydCBtaXhpbmcgbW9kZWxzIGJ5IGFkZGluZyBhIHVuaWRp cmVjdGlvbmFsIG9wdGlvbiB0byBiaWRpcmVjdGlvbmFsIG9yIHZpY2UgdmVyc2EuIEluIHRoZSBj bGVhbg0KIG1vZGVscywgd2UgY2FuIGNvdW50IHRoZSBudW1iZXIgb2Ygc3RyZWFtcyBpbml0aWF0 ZWQgYnkgb25lIGVudGl0eSBhbmQgbm90IHlldCBjbG9zZWQuIEJ1dCBpbiB0aGUgbWl4ZWQgbW9k ZWxzLCB3aGF0IGRvIHdlIGNvdW50LCBleGFjdGx5Pw0KPGJyPg0KPGJyPg0KRm9yIGV4YW1wbGUs IGxldCdzIHN1cHBvc2UgdGhhdCBpbiBhbiB1bmlkaXJlY3Rpb25hbCBzdHJlYW0gbW9kZWwsIHRo ZSBjbGllbnQgY3JlYXRlcyBhIHN0cmVhbSB0aGF0IGFsc28gJnF1b3Q7aW1wbGllcyZxdW90OyBh IHN0cmVhbSBjcmVhdGlvbiBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uLiBEb2VzIHRoaXMgaW1wbGll ZCBzdHJlYW0gY291bnQgYWdhaW5zdCB0aGUgc2VydmVyIGxpbWl0IG9yIHRoZSBjbGllbnQgbGlt aXQ/PGJyPg0KPGJyPg0KT3IgdmljZSB2ZXJzYS4gU3VwcG9zZSB0aGF0IGluIGEgYmlkaXJlY3Rp b25hbCBzdHJlYW0gbW9kZWwgdGhlIGNsaWVudCBjcmVhdGVzIGEgc3RyZWFtIHRoYXQgaXMgZGVj bGFyZWQgYXMgYWN0dWFsbHkgdW5pZGlyZWN0aW9uYWwuIEFuZCBzdXBwb3NlIHRoYXQgdGhpcyBz dHJlYW0gaXMgaW1tZWRpYXRlbHkgY2xvc2VkIC0tIGEgc3RyZWFtIGZyYW1lIHdpdGggYm90aCB0 aGUgRklOIGJpdCBhbmQgdGhlIFBSIDY1NiBVTkkgYml0IHNldC4gVGhpcw0KIHN0cmVhbSBjb3Vu dHMgYWdhaW5zdCB0aGUgY2xpZW50J3MgbnVtYmVyIG9mIGNvbmN1cnJlbnQgc3RyZWFtcywgYnV0 IGl0IGlzIGltbWVkaWF0ZWx5IGNsb3NlZCBieSBib3RoIHBhcnRpZXMuIERvZXMgaXQgY291bnQg YXMgemVybz88YnI+DQotLSA8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Q2hyaXN0aWFuIEh1aXRlbWE8 bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR21MB0141DAB51088DE57504B12F087D20MWHPR21MB0141namp_-- From nobody Thu Jun 29 11:40:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BF6129B8C for ; Thu, 29 Jun 2017 11:40:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 6b5Jy1IZsbBl for ; Thu, 29 Jun 2017 11:40:43 -0700 (PDT) Received: from mx36-42.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 397FE126D05 for ; Thu, 29 Jun 2017 11:40:43 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dQeMr-0000Bv-KB for quic@ietf.org; Thu, 29 Jun 2017 20:40:42 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dQeMp-0003AO-PJ for quic@ietf.org; Thu, 29 Jun 2017 14:40:40 -0400 Received: (qmail 4691 invoked from network); 29 Jun 2017 18:40:39 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.244]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Jun 2017 18:40:38 -0000 To: Mike Bishop , "quic@ietf.org" References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> From: Christian Huitema Message-ID: <176a76c7-bdcd-9007-1f26-e436f61076f3@huitema.net> Date: Thu, 29 Jun 2017 11:40:36 -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="------------D5C5CDF3E61336D97E654782" Subject: Re: Unidirectional streams PR X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJZYP2pkjqshrWYL747BjInHND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23rX/k4pOlu0PyUcxuDqrAIJzZ8rfsXcrYidfw YfZGgWJRV0+jKPbGI0Xa9U79k5CQYOEkjsX7F8KmpUaZQHV+SejOO+5k046wqf0SEutzqoO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpOWca0Z0beD6jMx95O4U5K/6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyZhUiWISA8QsB0V05SY5wf7eNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS171oitdW4N7+pdGHGnF6r0Gy2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe91Y2lWQ2MJXd3CnOcfuxlrTMLn6MURQGfriekzS 9Ga3AA== 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, 29 Jun 2017 18:40:45 -0000 This is a multi-part message in MIME format. --------------D5C5CDF3E61336D97E654782 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/29/2017 9:57 AM, Mike Bishop wrote: > > Moot point =E2=80=93 there is no concurrent stream limit in the protoco= l.=20 > There is only a maximum stream ID, and how your implementation decides > what maximum stream ID to issue to the peer allows you to choose any > resolution to these questions you like. > OK, my bad. > Now, in the unidirectional or mixed designs, you do have the corner > case where a client can send a request, but not give the server enough > Stream IDs to respond. (Don=E2=80=99t do that.) More realistically, t= he > server can have a limited number of Stream IDs and spend them on > pushes instead of actual responses > I am looking at the "mixed" scenario, in which the client would open an unidirectional stream with an associated "stream N" in the other direction. Will we say that doing so automatically pushes the server's maximum stream ID to some value greater than N? --=20 Christian Huitema --------------D5C5CDF3E61336D97E654782 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 6/29/2017 9:57 AM, Mike Bishop wrote:

Moot point – there is no concurrent stream limit in the protocol.  There is only a maximum stream ID, and how your implementation decides what maximum stream ID to issue to the peer allows you to choose any resolution to these questions you like.

OK, my bad.

Now, in the unidirectional or mixed designs, you do have the corner case where a client can send a request, but not give the server enough Stream IDs to respond.  (Don’t do that.)  More realistically, the server can have a limited number of Stream IDs and spend them on pushes instead of actual responses


I am looking at the "mixed" scenario, in which the client would open an unidirectional stream with an associated "stream N" in the other direction. Will we say that doing so automatically pushes the server's maximum stream ID to some value greater than N?
-- 
Christian Huitema
--------------D5C5CDF3E61336D97E654782-- From nobody Thu Jun 29 12:02: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 BBE1B129ABD for ; Thu, 29 Jun 2017 12:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjmGey9sXKnc for ; Thu, 29 Jun 2017 12:02:24 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 7C839129BA0 for ; Thu, 29 Jun 2017 12:02:11 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r125so55393730vkf.1 for ; Thu, 29 Jun 2017 12:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=iSPNobEFVzO7wG2omB7i+0ZUeakOlWXjbTGp/ncYiBk=; b=bDmAFfa+nkA6FIvgF0p/2KxDm7QepYiM1qBY5IoABK6AiZr6RfydK9/Xj/tZpI0/Jc 7CiXCI38sy/YvHuNex31evR7hPRSWmgqcPd3T4ZCXlud7Dr+m7rJ0OwssnOT4FdhKRI+ C8Q8kH3VR4a4ZgZl7r7OxUGMXxmKugPF/FhRFIibbmxm/xEnpM7YkDKCkMFSaSqbWcJi WyTejiJL+o2xK69j+U2pv7WqxDl7Xt36VmqXppewHFkNqkAmQ+fUGbwgGR4bYbrrbttq DENSM3Xhb2z+ec4PPmu0Cb1gm9KS+XVSHX76l3yaFSZ/qguRXAN1ygJdMeLJOw1ANjMK 5PLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=iSPNobEFVzO7wG2omB7i+0ZUeakOlWXjbTGp/ncYiBk=; b=p6rs29oeeX7NqukUs4vONouHEJGntHpHS7GSnq7Z7VNyQIwTSQU1SZTQOxYNGFC4rA v/Cla4h34qqgR+QhQXnEB+byE2/GtAHaYRZ9EMs8qPt/IeA0X+vfAWQw2OE/wg5VNP5v t85w0JlmC7rUguUQPXdOIGgw9kKkyxjZ//Og87mIiBNl6ZRu4x5OkxhN9J2p5DVnkEQ/ o4b4O/sLGSCpBcfoortsa1u7CNWEwQBjR6LbcPPhuIUHrC4LOYtdao/b2SYcrzs4kNcP IoD0dWlR9IGdz36Fstw7Bqe17wmu6cgc9zPC4Smd4yPrH2NQE9sFfRNYNIBDi9BeOht3 SDUw== X-Gm-Message-State: AKS2vOyjq3U+0OQkmZ7KIRgnl4hphGphaeOQJlF2pm0zE6hymRuYMF+l cRMFQLGbB9cyccUiw4msAo57WeKhgo7U X-Received: by 10.31.69.82 with SMTP id s79mr10206535vka.118.1498762930359; Thu, 29 Jun 2017 12:02:10 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 29 Jun 2017 15:02:09 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <176a76c7-bdcd-9007-1f26-e436f61076f3@huitema.net> References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> <176a76c7-bdcd-9007-1f26-e436f61076f3@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 29 Jun 2017 15:02:09 -0400 Message-ID: Subject: Re: Unidirectional streams PR To: "quic@ietf.org" , Christian Huitema , Mike Bishop Content-Type: multipart/alternative; boundary="001a114db0bc11132405531df056" 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, 29 Jun 2017 19:02:26 -0000 --001a114db0bc11132405531df056 Content-Type: text/plain; charset="UTF-8" On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote: I am looking at the "mixed" scenario, in which the client would open an unidirectional stream with an associated "stream N" in the other direction. Will we say that doing so automatically pushes the server's maximum stream ID to some value greater than N? I believe the streams need to operate independently: having endpoint A open a unidirectional stream A/N that can be responded to by endpoint B necessarily requires that B has granted A a limit of at least the value A/N. If the stream A/N permits association by one or more streams B/M initiated by B, each of those streams necessarily must be at or below the limit granted by A but only once those streams are in fact opened. Endpoint A might never grant sufficient streams to enable B to respond. The identifiers B/M chosen by B are unknown to A. Note that there is a problem with enforcing how many streams that can be associated with A/N because A/N might be closed and gone. Keeping state is problematic. On the other hand it is trivial to reject associations with streams that have not yet been opened, especially if streams are opened in strict order. Implicit opening of lower valued streams will not work, and is not needed. --001a114db0bc11132405531df056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On 29 June 2017 at 20.40.50, Christian Huitema (<= a href=3D"mailto:huitema@huitema.net">huitema@huitema.net) wrote:
=

I am looking at the "mixed= " scenario, in which the client would open an unidirectional stream wi= th an associated "stream N" in the other direction. Will we say t= hat doing so automatically pushes the server's maximum stream ID to som= e value greater than N?

I belie= ve the streams need to operate independently: having endpoint A open a unid= irectional stream A/N that can be responded to by endpoint B necessarily re= quires that B has granted A a limit of at least the value A/N. If the strea= m A/N permits association by one or more streams B/M initiated by B, each o= f those streams necessarily must be at or below the limit granted by A but = only once those streams are in fact opened. Endpoint A might never grant su= fficient streams to enable B to respond. The identifiers B/M chosen by B ar= e unknown to A.

Note that there is a problem with enforcing how many = streams that can be associated with A/N because A/N might be closed and gon= e. Keeping state is problematic. On the other hand it is trivial to reject = associations with streams that have not yet been opened, especially if stre= ams are opened in strict order. Implicit opening of lower valued streams wi= ll not work, and is not needed.

--001a114db0bc11132405531df056-- From nobody Fri Jun 30 15:58:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47701129B1A for ; Fri, 30 Jun 2017 15:58:53 -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 9XyrA46n3CzF for ; Fri, 30 Jun 2017 15:58:51 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8E9129AA3 for ; Fri, 30 Jun 2017 15:58:51 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id j186so69710962pge.2 for ; Fri, 30 Jun 2017 15:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OSxZWtfFLzCHieKlk3EoMWyUsQ5jH99D68WWZDCQoaA=; b=j8p7YwabCjR3G7SZ0XWHZozq46NWcz9zCDMSEJ1Zqz9VEaoyy9KdqPCzKbcUEq1sc8 w0USMaE+q4pOjWcb7qtWO8zraboCfNsvjoX0QYx3IT9uRrdcdaABR8brHcKrU21Q50+j aUbDT895V10saVuhegZF/64lb/1UYQCvoMkCtPMhfceoeToIUNU+qoM/u1+iXHsEDJ85 PJgxs+/N2iujOeU7oZWkgUNhCdu+ZwcZ1VrdAA3SWx0+P8qlNOvwMdJnooBU8jZ1CDe7 XoUSGzqKN9ObPQjKvR6XQzQQEu5oP80c/feTR6DGx3KQR23MOH+maZ+dfoe19n6bQokq r7gg== 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=OSxZWtfFLzCHieKlk3EoMWyUsQ5jH99D68WWZDCQoaA=; b=GbkrFqfEodALWWLQK2hZzIEfnCNGHB/vdk7KEwODigBaSQEy8GKSH4BKO9fgjbCEMA VnUMBTDUS0tzMIEYHzSr9i4EcsVJuy+wsLaU5Q/J2HKoFiFZhEOoK24/f12V58edKJms v9PtfrNs3lbHKBh0bpy1qDWz3W1d4L/4JzGUk1TjId0eo4dNfl7K4ovKgfT8MQvHLcx6 US/PFgUbbV+ijlVOzoHZmf/hoG3RlKcBb+MMzb0GZKNzqXmaR1lqKAt6G3M4vj/rIGuY Y138bgIGo24yXLXff3e+OcvQUxhHGdlFFsd687ApvFcqx/tL4iKP9549DSwHDhijUWxg lTgQ== X-Gm-Message-State: AKS2vOwxNfFsHzToMZGquZF4FyMOM6EPgrYuUiUBczuSJ8wp9xshvXc9 479QfZqdke0U0FlcO3SdYMnNzFW+eg== X-Received: by 10.99.45.6 with SMTP id t6mr22992032pgt.209.1498863531251; Fri, 30 Jun 2017 15:58:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Fri, 30 Jun 2017 15:58:50 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 30 Jun 2017 15:58:50 -0700 Message-ID: Subject: Re: 2 Points of First Implementation Draft we might clarify To: Ian Swett Cc: Patrick McManus , 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: Fri, 30 Jun 2017 22:58:53 -0000 I'd prefer draft-18 since that's the version we support in picotls. If others prefer to -20, maybe I can prepare that before Prague though. 2017-06-28 14:10 GMT-07:00 Ian Swett : > I've been informed that BoringSSL doesn't yet support draft 20 and won't > until we understand how to get middleboxes to stop hating TLS 1.3 over TCP, > so from a practical perspective, it would be much easier for us to support > 18. > > Would only supporting 18 cause problems for anyone? > > On Wed, Jun 28, 2017 at 4:53 PM, Ian Swett wrote: >> >> Those both seem like good changes to me. >> >> On Wed, Jun 28, 2017 at 4:51 PM, Patrick McManus >> wrote: >>> >>> Hi All - First, its really amazing to see nascent quic implementations >>> emerging from primordial soup over the last couple of weeks. I can count at >>> least 5 that have been mentioned on email, chat, or twitter trying to do >>> real interop. Its all a giant morass of work in progress of course - but >>> this is exciting and I take it as a very good sign. >>> >>> A couple things have come up >>> >>> 1] The implementation milestone wiki should probably specific a draft >>> version of TLS 1.3. Both -18 and -20 have been in common use (depending on >>> what TLS library you are using) and this leads to a common interop failure. >>> Presumably this isn't a problem we will have with the second milestone when >>> the TLS WG will have settled on a final revision. I would argue for -20 >>> simply because its a later marker on the march of forward progress. >>> >>> 2] the text on connection_close doesn't indicate which peer does the >>> close, or really when. If we want to do un-attended endpoint testing it >>> might be a useful thing to profile. e.g. "the server sends connection close >>> on a timer 2 seconds after the handshake is complete".. or something. >>> >>> -Patrick >>> >>> >>> >> > -- Kazuho Oku From nobody Fri Jun 30 16:14: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 C54DB12EA5A for ; Fri, 30 Jun 2017 16:14:21 -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=Ly03RlFQ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=XssrXEeX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dy5D8lQvxfo for ; Fri, 30 Jun 2017 16:14:19 -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 8A777129B4C for ; Fri, 30 Jun 2017 16:14:19 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5UNDrbT014595; Fri, 30 Jun 2017 16:14:07 -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=PFrb+evWpCn3IiEm2f1OvZIHJTx5qsiHePOSrT8BTn0=; b=Ly03RlFQvFMJ9czhyihKzvum2H7WUWAaRP3EH8gU1dzVQjeZnvY7c0Hl4ZcARh32ipwq pybzX/kXQZISr79wF5Cr+lf9LAPo+eycZVqsLkimhHPR0/JmjEVDkJ0TlRsmKD4tW0hB khxy1ydM0/yJrMr8LtJjoITpiU+OJtpDgGU= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2bdvs10tpn-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Jun 2017 16:14:07 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.23) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 30 Jun 2017 16:14:05 -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=PFrb+evWpCn3IiEm2f1OvZIHJTx5qsiHePOSrT8BTn0=; b=XssrXEeXcgzToBf7KQDkZSS8+xIPGhbCPu2JN6ixYJTKGzk3kWKsyeyL27WE11Q560EygVhm3LfT5PYoSxLl/PkAZTiG8mIC5R2YzUmRPRGyRJNPoLS+bW3IlLtxmj9GaTxpiwcBA94RP7zzNkWUKAANriEd0Jzel4NvOIjgtM4= 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.1199.15; Fri, 30 Jun 2017 23:14:03 +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.015; Fri, 30 Jun 2017 23:14:02 +0000 From: Subodh Iyengar To: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , "quic@ietf.org" , Christian Huitema , Mike Bishop Subject: Re: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qYA+OJNlgCk66zUVoUQGXHqI0Yv6AgATdKACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSACAAAzfAIAAEzGAgAD+vQCAAAZIgIAAHNIAgAAGBYCAAcjsJA== Date: Fri, 30 Jun 2017 23:14:02 +0000 Message-ID: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> <176a76c7-bdcd-9007-1f26-e436f61076f3@huitema.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [2620:10d:c090:180::1:8fdd] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1453; 20:aDvvTAGH3mQzpQqxwd2uOc72QjgnuX1mv6QT9/QOqGWMqZ6VxGZZkd+EX9alN93VsDDIewlg9rKwK3R6WQV/FGEyf3YzqOEigXC65MNOeBtTZIOAIxk07YfxWJVqvBGcLy2xKC/NYXdSUm847qqCMEg0fyOhAQ8dXeeWSi5SBX0= x-ms-office365-filtering-correlation-id: 2bcedc5b-b8bf-4730-3915-08d4c00db243 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:MWHPR15MB1453; x-ms-traffictypediagnostic: MWHPR15MB1453: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(133145235818549)(278428928389397)(236129657087228)(148574349560750)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(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: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39840400002)(24454002)(377454003)(81166006)(8936002)(25786009)(8676002)(1511001)(2900100001)(39060400002)(2561002)(50986999)(53546010)(54356999)(76176999)(3480700004)(38730400002)(102836003)(7736002)(2501003)(6116002)(2421001)(19627405001)(478600001)(2950100002)(33656002)(6436002)(77096006)(189998001)(53936002)(6246003)(14454004)(561944003)(8666007)(93886004)(229853002)(2906002)(236005)(5660300001)(99286003)(6506006)(74316002)(54896002)(3660700001)(6486002)(3280700002)(7116003)(6512007)(86362001)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1453; 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_DM5PR15MB14494D50B82F681CE0027483B6D30DM5PR15MB1449namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 23:14:02.2534 (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-06-30_15:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 23:14:22 -0000 --_000_DM5PR15MB14494D50B82F681CE0027483B6D30DM5PR15MB1449namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've read through both approaches and commented on both PR with concrete is= sues. I would like to voice some high level thoughts as well. I believe the purpose of the unidirectional streams exercise is two-fold: m= aybe reduce complexity of transport, enable applications to have easier map= pings. I have implemented the stream state machine specified in the current draft = and I have to stress this very much that no matter what state diagram we sp= ecify in the draft, the implementation of the state machine will not match = 1:1, there are always hidden states. One such concrete example is when you = reset a stream you might want to discard any incoming data vs if you're in = half closed you would want to process and buffer it. This creates a new hid= den state which is not captured in the state machine. To me personally, the initial draw for pure unidirectionality (@Martin's pr= oposal) was to reduce the number of states in the transport to make the tra= nsport easier to implement and not so much the easier mappings of applicati= ons. We're chartered to work on HTTP/2 first and that's my primary interest= as well. It seems though that in HTTP/2 the vast majority of transactions = are actually bidirectional, and it only needs unidirectional support for pu= shes. I think unidirectional streams doesn't add new functionality to HTTP/= 2. However after looking at the proposals and the feedback, as a transport imp= lementor I'm rethinking my initial draw towards purely unidirectional strea= ms such that I might as well take up the burden to implement bi-directional= ity once so that the apps can be simpler. That being said we need some concept of unidirectionality in the transport = to support the push use case for HTTP/2. It is kind of awkward right now th= at we need to send a FIN from the client to close a push stream. I'm not in favor of #656 because it adds more complexity to the state machi= ne, however I'm more of a fan of @Ian's do nothing + app dictates a manual = transition, since that allows us to keep the same state machine flow and le= t the app get undirectionality by explicitly having the app transition the = stream state machine as needed. There are some cool things in @Martin's pro= posal that I would actually like to see back in the HTTP mapping with bidi = streams like stream headers for pushed streams, however I'd rather prefer t= he do nothing + manually transition states with application coordination. Subodh ________________________________ From: QUIC on behalf of Mikkel Fahn=F8e J=F8rgensen= Sent: Thursday, June 29, 2017 12:02:09 PM To: quic@ietf.org; Christian Huitema; Mike Bishop Subject: Re: Unidirectional streams PR On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote: I am looking at the "mixed" scenario, in which the client would open an uni= directional stream with an associated "stream N" in the other direction. Wi= ll we say that doing so automatically pushes the server's maximum stream ID= to some value greater than N? I believe the streams need to operate independently: having endpoint A open= a unidirectional stream A/N that can be responded to by endpoint B necessa= rily requires that B has granted A a limit of at least the value A/N. If th= e stream A/N permits association by one or more streams B/M initiated by B,= each of those streams necessarily must be at or below the limit granted by= A but only once those streams are in fact opened. Endpoint A might never g= rant sufficient streams to enable B to respond. The identifiers B/M chosen = by B are unknown to A. Note that there is a problem with enforcing how many streams that can be as= sociated with A/N because A/N might be closed and gone. Keeping state is pr= oblematic. On the other hand it is trivial to reject associations with stre= ams that have not yet been opened, especially if streams are opened in stri= ct order. Implicit opening of lower valued streams will not work, and is no= t needed. --_000_DM5PR15MB14494D50B82F681CE0027483B6D30DM5PR15MB1449namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've read through both approaches and commented on both PR with concrete is= sues. I would like to voice some high level thoughts as well. 

I believe the purpose of the unidirectional streams exercise= is two-fold: maybe reduce complexity of transport, enable applic= ations to have easier mappings.

I have implemented the stream state machine specified in the current draft and I have to stress this very much that = no matter what state diagram we specify in the draft, the implementation of= the state machine will not match 1:1, there are always hidden states.= One such concrete example is when you reset a stream you might want to discard any incoming data vs if you're in = half closed you would want to process and buffer it. This creates= a new hidden state which is not captured in the state machine.

To me personally, the initial draw for pure unidirectionality (@Martin's proposal) was to reduce the number of states in the transport to make= the transport easier to implement and not so much the easier mappings of applications. We're chartered to work o= n HTTP/2 first and that's my primary interest as well. It seems though that in HTTP/2 the vast majority of transactions are actually bidirectional, and it=  only needs unidirectional support fo= r pushes. I think unidirectional streams doesn't add new functionality= to HTTP/2. 

However after looking at the proposals and the feedback, as a tra= nsport implementor I'm rethinking my initial draw towards purely unidi= rectional streams such that I might as well take up the burden to implement= bi-directionality once so that the apps can be simpler.

That being said we need some concept of unidirectionality in the trans= port to support the push use case for HTTP/2. It is kind of awkward right n= ow that we need to send a FIN from the client to close a push stream.

I'm not in favor of #656 because it adds more complexity to the state machi= ne, however I'm more of a fan of @Ian's do nothing + app dictates a man= ual transition, since that allows us to keep the same state machine flow an= d let the app get undirectionality by explicitly having the app transition the stream state machine as needed.&n= bsp;There are some cool things in @Martin'= s proposal that I would actually like to see back in the HTTP mapping with = bidi streams like stream headers for pushed streams, however I'd rather prefer the do nothing + manually transitio= n states with application coordination.

Subodh
From: QUIC <quic-bounces= @ietf.org> on behalf of Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.c= om>
Sent: Thursday, June 29, 2017 12:02:09 PM
To: quic@ietf.org; Christian Huitema; Mike Bishop
Subject: Re: Unidirectional streams PR
 
On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote:

I am looking at the "mixed" scenario, in which the client woul= d open an unidirectional stream with an associated "stream N" in = the other direction. Will we say that doing so automatically pushes the ser= ver's maximum stream ID to some value greater than N?

I believe the streams need to operate independently: having endpoint A o= pen a unidirectional stream A/N that can be responded to by endpoint B nece= ssarily requires that B has granted A a limit of at least the value A/N. If= the stream A/N permits association by one or more streams B/M initiated by B, each of those streams necessari= ly must be at or below the limit granted by A but only once those streams a= re in fact opened. Endpoint A might never grant sufficient streams to enabl= e B to respond. The identifiers B/M chosen by B are unknown to A.

Note that there is a problem with enforcing how many streams that can be= associated with A/N because A/N might be closed and gone. Keeping state is= problematic. On the other hand it is trivial to reject associations with s= treams that have not yet been opened, especially if streams are opened in strict order. Implicit opening of lowe= r valued streams will not work, and is not needed.

--_000_DM5PR15MB14494D50B82F681CE0027483B6D30DM5PR15MB1449namp_-- From nobody Fri Jun 30 16:55: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 B397A12EADA for ; Fri, 30 Jun 2017 16:54: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, 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 6MoFvGNuU8v4 for ; Fri, 30 Jun 2017 16:54:56 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A42512EA76 for ; Fri, 30 Jun 2017 16:54:56 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5UNqRFm032741; Sat, 1 Jul 2017 00:54:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=C1QZt51qCsDXfZ/7aJXIVR8On+j9QOXsacV8mkZKSI8=; b=pNWGT43L93z+tc8+tbB19632XhDURhz4zCSRx/W32lmqfagHIU83jqYVCOH/5oqJikzy Xer+I2gyPKSZBsnIrj/c4m8fuMW6RYJs3yLTM3PbbEHDVpWMc2tcYPnfZ8Om350wbVqq WWZainXldoNVRcxQGwVQxZgRvnIWPj1gmVdHA+TStscgfAJ3QtnGfncBY1WYDImJc9JP Cpa5XV+WkvTaARUO9XWC6lhXRoD2JS+y9VlAgzByFBgjfv8xaGZzMGpc9IL43psIH7XJ WTmyoc1Q2ot2XG+cgKdhRsa9Hha94ArHgWfuMzs9KIHtlW89qxzi7FOKl37TMX/OPguw xQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2bdrgrae0n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 01 Jul 2017 00:54:46 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5UNon3E000436; Fri, 30 Jun 2017 19:54:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b9kdv60nw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 30 Jun 2017 19:54:45 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 30 Jun 2017 19:54:43 -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; Fri, 30 Jun 2017 19:54:43 -0400 From: "Lubashev, Igor" To: "quic@ietf.org" , "huitema@huitema.net" , "mikkelfj@gmail.com" , "subodh@fb.com" , "Michael.Bishop@microsoft.com" Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qFJcNmOfPnkGlJjRXQ/9soKI0ttCAgATMZACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSAD//8GgUIAAXnCAgAD+vQCAAAZIgIAAHNIAgAAGBoCAAdi0AP//yFAx Date: Fri, 30 Jun 2017 23:54:43 +0000 Message-ID: <07d8c169e6a8405e9303d35b4e1f02e1@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> <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> <176a76c7-bdcd-9007-1f26-e436f61076f3@huitema.net>, , 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_07d8c169e6a8405e9303d35b4e1f02e1usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_16:, , 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-1706300367 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_16:, , 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-1706300367 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, 30 Jun 2017 23:54:59 -0000 --_000_07d8c169e6a8405e9303d35b4e1f02e1usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am worried about silent (app-directed) stream closing. This it a layering= violation, since it introduces transport-layer semantics (stream state tra= nsition) that are not signaled on the wire. Such silent stream closing would make it hard (impossible?) to write a gene= ric QUIC proxy, for example. A generic proxy must be able to know when a st= ream is closed, so it can release resources. In fact, the proxy would provi= de a better experience, if it could also know stream priorities and other p= ossible stream attributes explicitly. (The proxy may be a good idea, if you have limited devices attached to you= r low latency/high quality network, which is connected to the rest of the N= et over high latency/low quality links. You=92d deploy such a proxy, so it = can maintain deep buffers, needed for communication over high latency/low q= uality links.) As for Ian's Uni-bit proposal, the state machine is no more complicated tha= n in the original spec. (You would probably want to add a Uni bit to RST_ST= REAM frame to keep stream directionality unambiguous at all times.) - Igor -----Original Message----- From: Subodh Iyengar [subodh@fb.com] Received: Friday, 30 Jun 2017, 7:14PM To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; quic@ietf.org [quic@i= etf.org]; Christian Huitema [huitema@huitema.net]; Mike Bishop [Michael.Bis= hop@microsoft.com] Subject: Re: Unidirectional streams PR I've read through both approaches and commented on both PR with concrete is= sues. I would like to voice some high level thoughts as well. I believe the purpose of the unidirectional streams exercise is two-fold: m= aybe reduce complexity of transport, enable applications to have easier map= pings. I have implemented the stream state machine specified in the current draft = and I have to stress this very much that no matter what state diagram we sp= ecify in the draft, the implementation of the state machine will not match = 1:1, there are always hidden states. One such concrete example is when you = reset a stream you might want to discard any incoming data vs if you're in = half closed you would want to process and buffer it. This creates a new hid= den state which is not captured in the state machine. To me personally, the initial draw for pure unidirectionality (@Martin's pr= oposal) was to reduce the number of states in the transport to make the tra= nsport easier to implement and not so much the easier mappings of applicati= ons. We're chartered to work on HTTP/2 first and that's my primary interest= as well. It seems though that in HTTP/2 the vast majority of transactions = are actually bidirectional, and it only needs unidirectional support for pu= shes. I think unidirectional streams doesn't add new functionality to HTTP/= 2. However after looking at the proposals and the feedback, as a transport imp= lementor I'm rethinking my initial draw towards purely unidirectional strea= ms such that I might as well take up the burden to implement bi-directional= ity once so that the apps can be simpler. That being said we need some concept of unidirectionality in the transport = to support the push use case for HTTP/2. It is kind of awkward right now th= at we need to send a FIN from the client to close a push stream. I'm not in favor of #656 because it adds more complexity to the state machi= ne, however I'm more of a fan of @Ian's do nothing + app dictates a manual = transition, since that allows us to keep the same state machine flow and le= t the app get undirectionality by explicitly having the app transition the = stream state machine as needed. There are some cool things in @Martin's pro= posal that I would actually like to see back in the HTTP mapping with bidi = streams like stream headers for pushed streams, however I'd rather prefer t= he do nothing + manually transition states with application coordination. Subodh ________________________________ From: QUIC on behalf of Mikkel Fahn=F8e J=F8rgensen= Sent: Thursday, June 29, 2017 12:02:09 PM To: quic@ietf.org; Christian Huitema; Mike Bishop Subject: Re: Unidirectional streams PR On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote: I am looking at the "mixed" scenario, in which the client would open an uni= directional stream with an associated "stream N" in the other direction. Wi= ll we say that doing so automatically pushes the server's maximum stream ID= to some value greater than N? I believe the streams need to operate independently: having endpoint A open= a unidirectional stream A/N that can be responded to by endpoint B necessa= rily requires that B has granted A a limit of at least the value A/N. If th= e stream A/N permits association by one or more streams B/M initiated by B,= each of those streams necessarily must be at or below the limit granted by= A but only once those streams are in fact opened. Endpoint A might never g= rant sufficient streams to enable B to respond. The identifiers B/M chosen = by B are unknown to A. Note that there is a problem with enforcing how many streams that can be as= sociated with A/N because A/N might be closed and gone. Keeping state is pr= oblematic. On the other hand it is trivial to reject associations with stre= ams that have not yet been opened, especially if streams are opened in stri= ct order. Implicit opening of lower valued streams will not work, and is no= t needed. --_000_07d8c169e6a8405e9303d35b4e1f02e1usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am worried about silent (app-directed) stream closing. T= his it a layering violation, since it introduces transport-layer semantics = (stream state transition) that are not signaled on the wire.

Such silent stream closing would make it hard (impossible?) to write a gene= ric QUIC proxy, for example. A generic proxy must be able to know when a st= ream is closed, so it can release resources. In fact, the proxy would provi= de a better experience, if it could also know stream priorities and other possible stream attributes explicitl= y.

 (The proxy may be a good idea, if you have limited devices attached t= o your low latency/high quality network, which is connected to the rest of = the Net over high latency/low quality links. You=92d deploy such a proxy, s= o it can maintain deep buffers, needed for communication over high latency/low quality links.)


As for Ian's Uni-bit proposal, the state machine is no more complicated tha= n in the original spec. (You would probably want to add a Uni bit to RST_ST= REAM frame to keep stream directionality unambiguous at all times.)

- Igor



-----Original Message-----
From: Subodh Iyengar [subodh@fb.com]
Received: Friday, 30 Jun 2017, 7:14PM
To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; quic@ietf.org = [quic@ietf.org]; Christian Huitema [huitema@huitema.net]; Mike Bishop [Mich= ael.Bishop@microsoft.com]
Subject: Re: Unidirectional streams PR
I've read through both approaches and commented on both PR with concrete is= sues. I would like to voice some high level thoughts as well. 

I believe the purpose of the unidirectional streams exercise= is two-fold: maybe reduce complexity of transport, enable applic= ations to have easier mappings.

I have implemented the stream state machine specified in the current draft and I have to stress this very much that no matter what = state diagram we specify in the draft, the implementation of the state mach= ine will not match 1:1, there are always hidden states. One such concr= ete example is when you reset a stream you might want to discard any incoming data vs if you're in half closed y= ou would want to process and buffer it. This creates a new hidden= state which is not captured in the state machine.

To me personally, the initial draw for pure unidirectionality (@Martin's proposal) was to reduce the number of states in the transport to make the= transport easier to implement a= nd not so much the easier mappings of applications. We're chartered to work o= n HTTP/2 first and that's my primary interest as well. It seems though that in HTTP/2 the vast majority of transactions are actually bidirectional, and it=  only needs unidirectional support for = pushes. I think unidirectional streams doesn't add new functionality t= o HTTP/2. 

However after looking at the proposals and the feedback, as a tra= nsport implementor I'm rethinking my initial draw towards purely unidi= rectional streams such that I might as well take up the burden to implement= bi-directionality once so that the apps can be simpler.

That being said we need some concept of unidirectionality in the trans= port to support the push use case for HTTP/2. It is kind of awkward right n= ow that we need to send a FIN from the client to close a push stream.

I'm not in favor of #656 because it adds more complexity to the state machi= ne, however I'm more of a fan of @Ian's do nothing + app dictates a man= ual transition, since that allows us to keep the same state machine flow an= d let the app get undirectionality by explicitly having the app transition the stream state machine as needed.&n= bsp;There are some cool things in @Martin's = proposal that I would actually like to see back in the HTTP mapping with bi= di streams like stream headers for pushed streams, however I'd rather prefer the do nothing + manually transitio= n states with application coordination.

Subodh
From: QUIC <quic-bounces= @ietf.org> on behalf of Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.c= om>
Sent: Thursday, June 29, 2017 12:02:09 PM
To: quic@ietf.org; Christian Huitema; Mike Bishop
Subject: Re: Unidirectional streams PR
 
On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote:

I am looking at the "mixed" scenario, in which the client woul= d open an unidirectional stream with an associated "stream N" in = the other direction. Will we say that doing so automatically pushes the ser= ver's maximum stream ID to some value greater than N?

I believe the streams need to operate independently: having endpoint A o= pen a unidirectional stream A/N that can be responded to by endpoint B nece= ssarily requires that B has granted A a limit of at least the value A/N. If= the stream A/N permits association by one or more streams B/M initiated by B, each of those streams necessari= ly must be at or below the limit granted by A but only once those streams a= re in fact opened. Endpoint A might never grant sufficient streams to enabl= e B to respond. The identifiers B/M chosen by B are unknown to A.

Note that there is a problem with enforcing how many streams that can be= associated with A/N because A/N might be closed and gone. Keeping state is= problematic. On the other hand it is trivial to reject associations with s= treams that have not yet been opened, especially if streams are opened in strict order. Implicit opening of lowe= r valued streams will not work, and is not needed.

--_000_07d8c169e6a8405e9303d35b4e1f02e1usma1exdag1mb5msgcorpak_-- From nobody Fri Jun 30 17:08:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62AC127698 for ; Fri, 30 Jun 2017 17:08:43 -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=p1C2SKCc; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=k1XgC2Q0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoWJt8VvzX3f for ; Fri, 30 Jun 2017 17:08:41 -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 6A4601205D3 for ; Fri, 30 Jun 2017 17:08:41 -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 v6108LEn007216; Fri, 30 Jun 2017 17:08:31 -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=01U/qasK56ynYVZwmGHj+g6a4DF4c4lKEV7T4rCQEUY=; b=p1C2SKCct0EVaNZ5YhJshha+sjTTTED+pi6C0eHhJgR+TjS9KaMGIR1TFS3cqBm1sGdk ek5fEsprluWS6EbZkGmj5KihEGjFV7t/qWDvOm0kX2DAa6WsRkoE7dpRbEXgX1HBwgiP PYXO93yYhJuAR/IFRSDwmMP9SvwL6g5Tk6U= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2bdx0a0nmw-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Jun 2017 17:08:31 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 30 Jun 2017 20:08:29 -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=01U/qasK56ynYVZwmGHj+g6a4DF4c4lKEV7T4rCQEUY=; b=k1XgC2Q0bfVone1sPe9tCJSoDVUHKYi9vhv2LT0Fasj+wVWQWkWxbmqADdkCOFdPGNCr1O1MyPgOV4M92hkjXHYs6CfksmiNcc7KJvTsOp9J7elhJbjsH45/hXoXHrRcwIoEY4QlG82tjcVyBgMwrBxO8e1r3zfXsbb/tC989fw= 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.1199.15; Sat, 1 Jul 2017 00:08:27 +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.015; Sat, 1 Jul 2017 00:08:27 +0000 From: Subodh Iyengar To: "Lubashev, Igor" , "quic@ietf.org" , "huitema@huitema.net" , "mikkelfj@gmail.com" , "Michael.Bishop@microsoft.com" Subject: Re: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qYA+OJNlgCk66zUVoUQGXHqI0Yv6AgATdKACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSACAAAzfAIAAEzGAgAD+vQCAAAZIgIAAHNIAgAAGBYCAAcjsJIAAGyeAgAAB0nY= Date: Sat, 1 Jul 2017 00:08:27 +0000 Message-ID: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> <176a76c7-bdcd-9007-1f26-e436f61076f3@huitema.net>, , , <07d8c169e6a8405e9303d35b4e1f02e1@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <07d8c169e6a8405e9303d35b4e1f02e1@usma1ex-dag1mb5.msg.corp.akamai.com> 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:1c0:6f01:173c:6089:a88:dd25:dbe0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 20:18oCtWHSM/FyI6fomf/IpIo2f1dZgbmkhAYr7Ba3kvkZIKoQ6CsTDAzHmYJo1DKgXt6SwD8LavRpOGDRHfA2O7qrQQQPeVQK3Ma4tkEHyhu466AB4wwBNT97ghy0PcDnRxLw/OQxlYE4zLKsHLHQLmhW0dmpFsS5uy97mfgeliQ= x-ms-office365-filtering-correlation-id: d8fe5aae-ad57-4e5c-55a1-08d4c0154c9a 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-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(133145235818549)(278428928389397)(236129657087228)(67672495146484)(48057245064654)(148574349560750)(247924648384137); 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)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(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: 0355F3A3AE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39400400002)(39410400002)(39450400003)(13464003)(24454002)(377454003)(7116003)(76176999)(5660300001)(50986999)(99286003)(102836003)(55016002)(54896002)(54356999)(229853002)(236005)(2950100002)(189998001)(9686003)(6506006)(1511001)(6116002)(561944003)(77096006)(7696004)(6436002)(8666007)(7736002)(81166006)(8676002)(3480700004)(8936002)(2421001)(93886004)(2501003)(86362001)(5890100001)(2561002)(53546010)(478600001)(25786009)(38730400002)(2900100001)(6246003)(39060400002)(74316002)(45080400002)(53936002)(2201001)(3280700002)(3660700001)(19627405001)(33656002)(14454004)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; 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_MWHPR15MB1455819E649AFAF2748A836EB6D00MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2017 00:08:27.6861 (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-06-30_16:, , 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: Sat, 01 Jul 2017 00:08:44 -0000 --_000_MWHPR15MB1455819E649AFAF2748A836EB6D00MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > I am worried about silent (app-directed) stream closing. This it a layeri= ng violation, since it introduces transport-layer semantics (stream state t= ransition) that are not signaled on the wire. Why is it a layer violation, apps change state of the transport all the tim= e :) The way it would happen is that the transport would expose an API like= closeWithoutFin() and close() which basically decide whether or not a stre= am is unidirectional. app directed closing doesn't prevent a generic quic proxy from sending a FI= N if it wants. The FIN will be completely consistent with the state machine= . I see app directed closing as more of an optimization to not sending some= extra bytes when not needed. > As for Ian's Uni-bit proposal, the state machine is no more complicated t= han in the original spec. (You would probably want to add a Uni bit to RST_= STREAM frame to keep stream directionality unambiguous at all times.) See my comments on the PR. I suggested the same RST uni bit as well as ther= e is another state transition that is missing as well, so I think it's defi= nitely a change. Plus it makes it such that we cannot open lower streams wh= ich I think is undesirable. Subodh ________________________________ From: Lubashev, Igor Sent: Friday, June 30, 2017 4:54:43 PM To: quic@ietf.org; huitema@huitema.net; mikkelfj@gmail.com; Subodh Iyengar;= Michael.Bishop@microsoft.com Subject: RE: Unidirectional streams PR I am worried about silent (app-directed) stream closing. This it a layering= violation, since it introduces transport-layer semantics (stream state tra= nsition) that are not signaled on the wire. Such silent stream closing would make it hard (impossible?) to write a gene= ric QUIC proxy, for example. A generic proxy must be able to know when a st= ream is closed, so it can release resources. In fact, the proxy would provi= de a better experience, if it could also know stream priorities and other p= ossible stream attributes explicitly. (The proxy may be a good idea, if you have limited devices attached to you= r low latency/high quality network, which is connected to the rest of the N= et over high latency/low quality links. You=92d deploy such a proxy, so it = can maintain deep buffers, needed for communication over high latency/low q= uality links.) As for Ian's Uni-bit proposal, the state machine is no more complicated tha= n in the original spec. (You would probably want to add a Uni bit to RST_ST= REAM frame to keep stream directionality unambiguous at all times.) - Igor -----Original Message----- From: Subodh Iyengar [subodh@fb.com] Received: Friday, 30 Jun 2017, 7:14PM To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; quic@ietf.org [quic@i= etf.org]; Christian Huitema [huitema@huitema.net]; Mike Bishop [Michael.Bis= hop@microsoft.com] Subject: Re: Unidirectional streams PR I've read through both approaches and commented on both PR with concrete is= sues. I would like to voice some high level thoughts as well. I believe the purpose of the unidirectional streams exercise is two-fold: m= aybe reduce complexity of transport, enable applications to have easier map= pings. I have implemented the stream state machine specified in the current draft = and I have to stress this very much that no matter what state diagram we sp= ecify in the draft, the implementation of the state machine will not match = 1:1, there are always hidden states. One such concrete example is when you = reset a stream you might want to discard any incoming data vs if you're in = half closed you would want to process and buffer it. This creates a new hid= den state which is not captured in the state machine. To me personally, the initial draw for pure unidirectionality (@Martin's pr= oposal) was to reduce the number of states in the transport to make the tra= nsport easier to implement and not so much the easier mappings of applicati= ons. We're chartered to work on HTTP/2 first and that's my primary interest= as well. It seems though that in HTTP/2 the vast majority of transactions = are actually bidirectional, and it only needs unidirectional support for pu= shes. I think unidirectional streams doesn't add new functionality to HTTP/= 2. However after looking at the proposals and the feedback, as a transport imp= lementor I'm rethinking my initial draw towards purely unidirectional strea= ms such that I might as well take up the burden to implement bi-directional= ity once so that the apps can be simpler. That being said we need some concept of unidirectionality in the transport = to support the push use case for HTTP/2. It is kind of awkward right now th= at we need to send a FIN from the client to close a push stream. I'm not in favor of #656 because it adds more complexity to the state machi= ne, however I'm more of a fan of @Ian's do nothing + app dictates a manual = transition, since that allows us to keep the same state machine flow and le= t the app get undirectionality by explicitly having the app transition the = stream state machine as needed. There are some cool things in @Martin's pro= posal that I would actually like to see back in the HTTP mapping with bidi = streams like stream headers for pushed streams, however I'd rather prefer t= he do nothing + manually transition states with application coordination. Subodh ________________________________ From: QUIC on behalf of Mikkel Fahn=F8e J=F8rgensen= Sent: Thursday, June 29, 2017 12:02:09 PM To: quic@ietf.org; Christian Huitema; Mike Bishop Subject: Re: Unidirectional streams PR On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote: I am looking at the "mixed" scenario, in which the client would open an uni= directional stream with an associated "stream N" in the other direction. Wi= ll we say that doing so automatically pushes the server's maximum stream ID= to some value greater than N? I believe the streams need to operate independently: having endpoint A open= a unidirectional stream A/N that can be responded to by endpoint B necessa= rily requires that B has granted A a limit of at least the value A/N. If th= e stream A/N permits association by one or more streams B/M initiated by B,= each of those streams necessarily must be at or below the limit granted by= A but only once those streams are in fact opened. Endpoint A might never g= rant sufficient streams to enable B to respond. The identifiers B/M chosen = by B are unknown to A. Note that there is a problem with enforcing how many streams that can be as= sociated with A/N because A/N might be closed and gone. Keeping state is pr= oblematic. On the other hand it is trivial to reject associations with stre= ams that have not yet been opened, especially if streams are opened in stri= ct order. Implicit opening of lower valued streams will not work, and is no= t needed. --_000_MWHPR15MB1455819E649AFAF2748A836EB6D00MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> I am worried about silent (ap= p-directed) stream closing. This it a layering violation, since it introduc= es transport-layer semantics (stream state transition) that are not signaled on the wire.

Why is it a layer violation, apps change state of the transport all the tim= e :) The way it would happen is that the transport would exp= ose an API like closeWithoutFin() and close() which basically decide whethe= r or not a stream is unidirectional. 


app directed closing doesn't prevent a generic quic proxy from sending a= FIN if it wants. The FIN will be completely consistent with the state mach= ine. I see app directed closing as more of an optimization to not sending s= ome extra bytes when not needed.

> As for Ian's Uni-bit proposal, the state machine is no more com= plicated than in the original spec. (You would probably want to add a Uni bit to RST_STREAM frame to keep stream directio= nality unambiguous at all times.)

See my comments on the PR. I suggested the same RST uni bit as well as ther= e is another state transition that is missing as well, so I think it's defi= nitely a change. Plus it makes it such that we cannot open lower streams wh= ich I think is undesirable.


Subodh

From: Lubashev, Igor <il= ubashe@akamai.com>
Sent: Friday, June 30, 2017 4:54:43 PM
To: quic@ietf.org; huitema@huitema.net; mikkelfj@gmail.com; Subodh I= yengar; Michael.Bishop@microsoft.com
Subject: RE: Unidirectional streams PR
 
I am worried about silent (app-directed) stream closi= ng. This it a layering violation, since it introduces transport-layer seman= tics (stream state transition) that are not signaled on the wire.

Such silent stream closing would make it hard (impossible?) to write a gene= ric QUIC proxy, for example. A generic proxy must be able to know when a st= ream is closed, so it can release resources. In fact, the proxy would provi= de a better experience, if it could also know stream priorities and other possible stream attributes explicitl= y.

 (The proxy may be a good idea, if you have limited devices attached t= o your low latency/high quality network, which is connected to the rest of = the Net over high latency/low quality links. You=92d deploy such a proxy, s= o it can maintain deep buffers, needed for communication over high latency/low quality links.)


As for Ian's Uni-bit proposal, the state machine is no more complicated tha= n in the original spec. (You would probably want to add a Uni bit to RST_ST= REAM frame to keep stream directionality unambiguous at all times.)

- Igor



-----Original Message-----
From: Subodh Iyengar [subodh@fb.com]
Received: Friday, 30 Jun 2017, 7:14PM
To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; quic@ietf.org = [quic@ietf.org]; Christian Huitema [huitema@huitema.net]; Mike Bishop [Mich= ael.Bishop@microsoft.com]
Subject: Re: Unidirectional streams PR
I've read through both approaches and commented on both PR with concrete is= sues. I would like to voice some high level thoughts as well. 

I believe the purpose of the unidirectional streams exercise= is two-fold: maybe reduce complexity of transport, enable applic= ations to have easier mappings.

I have implemented the stream state machine specified in the current draft and I have to stress this very much that no matter what = state diagram we specify in the draft, the implementation of the state mach= ine will not match 1:1, there are always hidden states. One such concr= ete example is when you reset a stream you might want to discard any incoming data vs if you're in half closed y= ou would want to process and buffer it. This creates a new hidden= state which is not captured in the state machine.

To me personally, the initial draw for pure unidirectionality (@Martin's proposal) was to reduce the number of states in the transport to make the= transport easier to implement a= nd not so much the easier mappings of applications. We're chartered to work o= n HTTP/2 first and that's my primary interest as well. It seems though that in HTTP/2 the vast majority of transactions are actually bidirectional, and it=  only needs unidirectional support for = pushes. I think unidirectional streams doesn't add new functionality t= o HTTP/2. 

However after looking at the proposals and the feedback, as a tra= nsport implementor I'm rethinking my initial draw towards purely unidi= rectional streams such that I might as well take up the burden to implement= bi-directionality once so that the apps can be simpler.

That being said we need some concept of unidirectionality in the trans= port to support the push use case for HTTP/2. It is kind of awkward right n= ow that we need to send a FIN from the client to close a push stream.

I'm not in favor of #656 because it adds more complexity to the state machi= ne, however I'm more of a fan of @Ian's do nothing + app dictates a man= ual transition, since that allows us to keep the same state machine flow an= d let the app get undirectionality by explicitly having the app transition the stream state machine as needed.&n= bsp;There are some cool things in @Martin's = proposal that I would actually like to see back in the HTTP mapping with bi= di streams like stream headers for pushed streams, however I'd rather prefer the do nothing + manually transitio= n states with application coordination.

Subodh
From: QUIC <quic-bounces= @ietf.org> on behalf of Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.c= om>
Sent: Thursday, June 29, 2017 12:02:09 PM
To: quic@ietf.org; Christian Huitema; Mike Bishop
Subject: Re: Unidirectional streams PR
 
On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote:

I am looking at the "mixed" scenario, in which the client woul= d open an unidirectional stream with an associated "stream N" in = the other direction. Will we say that doing so automatically pushes the ser= ver's maximum stream ID to some value greater than N?

I believe the streams need to operate independently: having endpoint A o= pen a unidirectional stream A/N that can be responded to by endpoint B nece= ssarily requires that B has granted A a limit of at least the value A/N. If= the stream A/N permits association by one or more streams B/M initiated by B, each of those streams necessari= ly must be at or below the limit granted by A but only once those streams a= re in fact opened. Endpoint A might never grant sufficient streams to enabl= e B to respond. The identifiers B/M chosen by B are unknown to A.

Note that there is a problem with enforcing how many streams that can be= associated with A/N because A/N might be closed and gone. Keeping state is= problematic. On the other hand it is trivial to reject associations with s= treams that have not yet been opened, especially if streams are opened in strict order. Implicit opening of lowe= r valued streams will not work, and is not needed.

--_000_MWHPR15MB1455819E649AFAF2748A836EB6D00MWHPR15MB1455namp_-- From nobody Fri Jun 30 17:40:07 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 BFB8C12EB0E for ; Fri, 30 Jun 2017 17:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1nhuD7bZOfpn for ; Fri, 30 Jun 2017 17:40:03 -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 1481E12EA5A for ; Fri, 30 Jun 2017 17:40:03 -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 v610WF01029341; Sat, 1 Jul 2017 01:39:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=kPreFS1ABVHiPMaIp1g9NhXvwq5vOmitgRM/TqFMnp4=; b=aWUgn8bJ5wjOQ1tSz2ysPTd4EpU77Xh1Q1j7+gffcY1l++Rm1AMFS8pDG23EJBDnDM7x LIuIMzZ5fYRjcZSOPlCIiqEOzJDwR9KGjZPFpCtJnPwjxTAQe0c0zg2JnJQUaTjoEluH Zlx7OdT9l0LzW1Jq9M/lnImBcjuVvPMa2WGBTdq//eEIh48vk9VhUuJMw2gxrlKhPET/ lhVau+xWjCzecXPVWuy4AEg0N7C0F0W3HKIrL094IwVi/6X4+J4RRkhrsnrM34ISNbt6 IFAyWjcQVJ6pheG8aEzahKj5b7w2RYtQyG7mcSGSgMKrEkT6DFxMDDvZnnbRDFQxb7eR SQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bdcefvwue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 01 Jul 2017 01:39:53 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v610a4Mh007778; Fri, 30 Jun 2017 20:39:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b9kdvdd3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 30 Jun 2017 20:39:51 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 30 Jun 2017 17:39:50 -0700 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; Fri, 30 Jun 2017 20:39:50 -0400 From: "Lubashev, Igor" To: "quic@ietf.org" , "mikkelfj@gmail.com" , "huitema@huitema.net" , "subodh@fb.com" , "Michael.Bishop@microsoft.com" Subject: RE: Unidirectional streams PR Thread-Topic: Unidirectional streams PR Thread-Index: AQHS7K8qFJcNmOfPnkGlJjRXQ/9soKI0ttCAgATMZACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSAD//8GgUIAAXnCAgAD+vQCAAAZIgIAAHNIAgAAGBoCAAdi0AP//yFAxgABG5YD//8W33w== Date: Sat, 1 Jul 2017 00:39:50 +0000 Message-ID: References: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <20170628124221.GA15608@ubuntu-dmitri> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> <176a76c7-bdcd-9007-1f26-e436f61076f3@huitema.net>, , , <07d8c169e6a8405e9303d35b4e1f02e1@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_e3d857f1a64148bd8c960052441d3caausma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_16:, , 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-1707010007 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707010007 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 00:40:06 -0000 --_000_e3d857f1a64148bd8c960052441d3caausma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Why is it a layer violation, apps change state of the transport all the t= ime The key is the lack of explicit on-the-wire signaling of stream state trans= ition. Without such a signal, a generic proxy that is not aware of your app= lication internals is not able to know when to send the FIN (and get rid of= its state). It has to keep the stream half-closed, ready for an endpoint t= o start sending data over that stream at any moment, till the end of the co= nnection. > PR Thanks. I will take a look. (Three places for discussions: the list, issues= , PRs...) -----Original Message----- From: Subodh Iyengar [subodh@fb.com] Received: Friday, 30 Jun 2017, 8:08PM To: Lubashev, Igor [ilubashe@akamai.com]; quic@ietf.org [quic@ietf.org]; hu= itema@huitema.net [huitema@huitema.net]; mikkelfj@gmail.com [mikkelfj@gmail= .com]; Michael.Bishop@microsoft.com [Michael.Bishop@microsoft.com] Subject: Re: Unidirectional streams PR > I am worried about silent (app-directed) stream closing. This it a layeri= ng violation, since it introduces transport-layer semantics (stream state t= ransition) that are not signaled on the wire. Why is it a layer violation, apps change state of the transport all the tim= e :) The way it would happen is that the transport would expose an API like= closeWithoutFin() and close() which basically decide whether or not a stre= am is unidirectional. app directed closing doesn't prevent a generic quic proxy from sending a FI= N if it wants. The FIN will be completely consistent with the state machine= . I see app directed closing as more of an optimization to not sending some= extra bytes when not needed. > As for Ian's Uni-bit proposal, the state machine is no more complicated t= han in the original spec. (You would probably want to add a Uni bit to RST_= STREAM frame to keep stream directionality unambiguous at all times.) See my comments on the PR. I suggested the same RST uni bit as well as ther= e is another state transition that is missing as well, so I think it's defi= nitely a change. Plus it makes it such that we cannot open lower streams wh= ich I think is undesirable. Subodh ________________________________ From: Lubashev, Igor Sent: Friday, June 30, 2017 4:54:43 PM To: quic@ietf.org; huitema@huitema.net; mikkelfj@gmail.com; Subodh Iyengar;= Michael.Bishop@microsoft.com Subject: RE: Unidirectional streams PR I am worried about silent (app-directed) stream closing. This it a layering= violation, since it introduces transport-layer semantics (stream state tra= nsition) that are not signaled on the wire. Such silent stream closing would make it hard (impossible?) to write a gene= ric QUIC proxy, for example. A generic proxy must be able to know when a st= ream is closed, so it can release resources. In fact, the proxy would provi= de a better experience, if it could also know stream priorities and other p= ossible stream attributes explicitly. (The proxy may be a good idea, if you have limited devices attached to you= r low latency/high quality network, which is connected to the rest of the N= et over high latency/low quality links. You=92d deploy such a proxy, so it = can maintain deep buffers, needed for communication over high latency/low q= uality links.) As for Ian's Uni-bit proposal, the state machine is no more complicated tha= n in the original spec. (You would probably want to add a Uni bit to RST_ST= REAM frame to keep stream directionality unambiguous at all times.) - Igor -----Original Message----- From: Subodh Iyengar [subodh@fb.com] Received: Friday, 30 Jun 2017, 7:14PM To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; quic@ietf.org [quic@i= etf.org]; Christian Huitema [huitema@huitema.net]; Mike Bishop [Michael.Bis= hop@microsoft.com] Subject: Re: Unidirectional streams PR I've read through both approaches and commented on both PR with concrete is= sues. I would like to voice some high level thoughts as well. I believe the purpose of the unidirectional streams exercise is two-fold: m= aybe reduce complexity of transport, enable applications to have easier map= pings. I have implemented the stream state machine specified in the current draft = and I have to stress this very much that no matter what state diagram we sp= ecify in the draft, the implementation of the state machine will not match = 1:1, there are always hidden states. One such concrete example is when you = reset a stream you might want to discard any incoming data vs if you're in = half closed you would want to process and buffer it. This creates a new hid= den state which is not captured in the state machine. To me personally, the initial draw for pure unidirectionality (@Martin's pr= oposal) was to reduce the number of states in the transport to make the tra= nsport easier to implement and not so much the easier mappings of applicati= ons. We're chartered to work on HTTP/2 first and that's my primary interest= as well. It seems though that in HTTP/2 the vast majority of transactions = are actually bidirectional, and it only needs unidirectional support for pu= shes. I think unidirectional streams doesn't add new functionality to HTTP/= 2. However after looking at the proposals and the feedback, as a transport imp= lementor I'm rethinking my initial draw towards purely unidirectional strea= ms such that I might as well take up the burden to implement bi-directional= ity once so that the apps can be simpler. That being said we need some concept of unidirectionality in the transport = to support the push use case for HTTP/2. It is kind of awkward right now th= at we need to send a FIN from the client to close a push stream. I'm not in favor of #656 because it adds more complexity to the state machi= ne, however I'm more of a fan of @Ian's do nothing + app dictates a manual = transition, since that allows us to keep the same state machine flow and le= t the app get undirectionality by explicitly having the app transition the = stream state machine as needed. There are some cool things in @Martin's pro= posal that I would actually like to see back in the HTTP mapping with bidi = streams like stream headers for pushed streams, however I'd rather prefer t= he do nothing + manually transition states with application coordination. Subodh ________________________________ From: QUIC on behalf of Mikkel Fahn=F8e J=F8rgensen= Sent: Thursday, June 29, 2017 12:02:09 PM To: quic@ietf.org; Christian Huitema; Mike Bishop Subject: Re: Unidirectional streams PR On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote: I am looking at the "mixed" scenario, in which the client would open an uni= directional stream with an associated "stream N" in the other direction. Wi= ll we say that doing so automatically pushes the server's maximum stream ID= to some value greater than N? I believe the streams need to operate independently: having endpoint A open= a unidirectional stream A/N that can be responded to by endpoint B necessa= rily requires that B has granted A a limit of at least the value A/N. If th= e stream A/N permits association by one or more streams B/M initiated by B,= each of those streams necessarily must be at or below the limit granted by= A but only once those streams are in fact opened. Endpoint A might never g= rant sufficient streams to enable B to respond. The identifiers B/M chosen = by B are unknown to A. Note that there is a problem with enforcing how many streams that can be as= sociated with A/N because A/N might be closed and gone. Keeping state is pr= oblematic. On the other hand it is trivial to reject associations with stre= ams that have not yet been opened, especially if streams are opened in stri= ct order. Implicit opening of lower valued streams will not work, and is no= t needed. --_000_e3d857f1a64148bd8c960052441d3caausma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Why is it a layer violation, apps change state of the= transport all the time

The key is the lack of explicit on-the-wire signaling of stream state trans= ition. Without such a signal, a generic proxy that is not aware of your app= lication internals is not able to know when to send the FIN (and get rid of= its state). It has to keep the stream half-closed, ready for an endpoint to start sending data over that = stream at any moment, till the end of the connection.

> PR

Thanks. I will take a look. (Three places for discussions: the list, issues= , PRs...)

-----Original Message-----
From: Subodh Iyengar [subodh@fb.com]
Received: Friday, 30 Jun 2017, 8:08PM
To: Lubashev, Igor [ilubashe@akamai.com]; quic@ietf.org [quic@ietf.o= rg]; huitema@huitema.net [huitema@huitema.net]; mikkelfj@gmail.com [mikkelf= j@gmail.com]; Michael.Bishop@microsoft.com [Michael.Bishop@microsoft.com] Subject: Re: Unidirectional streams PR

> I am worried about silent (app-direct= ed) stream closing. This it a layering violation, since it introduces trans= port-layer semantics (stream state transition) that are not signaled on the wire.

Why is it a layer violation, apps change state of the transport all the tim= e :) The way it would happen is that the transport would exp= ose an API like closeWithoutFin() and close() which basically decide whethe= r or not a stream is unidirectional. 


app directed closing doesn't prevent a generic quic proxy from sending a= FIN if it wants. The FIN will be completely consistent with the state mach= ine. I see app directed closing as more of an optimization to not sending s= ome extra bytes when not needed.

> As for Ian's Uni-bit proposal, the state machine is no more complicated t= han in the original spec. (You would probably want to add a Uni bit to RST_STREAM frame to keep stream directionality un= ambiguous at all times.)

See my comments on the PR. I suggested the same RST uni bit as well as ther= e is another state transition that is missing as well, so I think it's defi= nitely a change. Plus it makes it such that we cannot open lower streams wh= ich I think is undesirable.


Subod= h

From: Lubashev, Igor <il= ubashe@akamai.com>
Sent: Friday, June 30, 2017 4:54:43 PM
To: quic@ietf.org; huitema@huitema.net; mikkelfj@gmail.com; Subodh I= yengar; Michael.Bishop@microsoft.com
Subject: RE: Unidirectional streams PR
 
I am worried about silent (app-directed) stream closi= ng. This it a layering violation, since it introduces transport-layer seman= tics (stream state transition) that are not signaled on the wire.

Such silent stream closing would make it hard (impossible?) to write a gene= ric QUIC proxy, for example. A generic proxy must be able to know when a st= ream is closed, so it can release resources. In fact, the proxy would provi= de a better experience, if it could also know stream priorities and other possible stream attributes explicitl= y.

 (The proxy may be a good idea, if you have limited devices attached t= o your low latency/high quality network, which is connected to the rest of = the Net over high latency/low quality links. You=92d deploy such a proxy, s= o it can maintain deep buffers, needed for communication over high latency/low quality links.)


As for Ian's Uni-bit proposal, the state machine is no more complicated tha= n in the original spec. (You would probably want to add a Uni bit to RST_ST= REAM frame to keep stream directionality unambiguous at all times.)

- Igor



-----Original Message-----
From: Subodh Iyengar [subodh@fb.com]
Received: Friday, 30 Jun 2017, 7:14PM
To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; quic@ietf.org = [quic@ietf.org]; Christian Huitema [huitema@huitema.net]; Mike Bishop [Mich= ael.Bishop@microsoft.com]
Subject: Re: Unidirectional streams PR
I've read through both approaches and commented on both PR with concrete is= sues. I would like to voice some high level thoughts as well. 

I believe the purpose of the unidirectional streams exercise= is two-fold: maybe reduce complexity of transport, enable applic= ations to have easier mappings.

I have implemented the stream state machine specified in the current draft and I have to stress this very much that no matter what = state diagram we specify in the draft, the implementation of the state mach= ine will not match 1:1, there are always hidden states. One such concr= ete example is when you reset a stream you might want to discard any incoming data vs if you're in half closed y= ou would want to process and buffer it. This creates a new hidden= state which is not captured in the state machine.

To me personally, the initial draw for pure unidirectionality (@Martin's proposal) was to reduce the number of states in the transport to make the= transport easier to implement a= nd not so much the easier mappings of applications. We're chartered to work o= n HTTP/2 first and that's my primary interest as well. It seems though that in HTTP/2 the vast majority of transactions are actually bidirectional, and it=  only needs unidirectional support for = pushes. I think unidirectional streams doesn't add new functionality t= o HTTP/2. 

However after looking at the proposals and the feedback, as a tra= nsport implementor I'm rethinking my initial draw towards purely unidi= rectional streams such that I might as well take up the burden to implement= bi-directionality once so that the apps can be simpler.

That being said we need some concept of unidirectionality in the trans= port to support the push use case for HTTP/2. It is kind of awkward right n= ow that we need to send a FIN from the client to close a push stream.

I'm not in favor of #656 because it adds more complexity to the state machi= ne, however I'm more of a fan of @Ian's do nothing + app dictates a man= ual transition, since that allows us to keep the same state machine flow an= d let the app get undirectionality by explicitly having the app transition the stream state machine as needed.&n= bsp;There are some cool things in @Martin's = proposal that I would actually like to see back in the HTTP mapping with bi= di streams like stream headers for pushed streams, however I'd rather prefer the do nothing + manually transitio= n states with application coordination.

Subodh
From: QUIC <quic-bounces= @ietf.org> on behalf of Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.c= om>
Sent: Thursday, June 29, 2017 12:02:09 PM
To: quic@ietf.org; Christian Huitema; Mike Bishop
Subject: Re: Unidirectional streams PR
 
On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net) wrote:

I am looking at the "mixed" scenario, in which the client woul= d open an unidirectional stream with an associated "stream N" in = the other direction. Will we say that doing so automatically pushes the ser= ver's maximum stream ID to some value greater than N?

I believe the streams need to operate independently: having endpoint A o= pen a unidirectional stream A/N that can be responded to by endpoint B nece= ssarily requires that B has granted A a limit of at least the value A/N. If= the stream A/N permits association by one or more streams B/M initiated by B, each of those streams necessari= ly must be at or below the limit granted by A but only once those streams a= re in fact opened. Endpoint A might never grant sufficient streams to enabl= e B to respond. The identifiers B/M chosen by B are unknown to A.

Note that there is a problem with enforcing how many streams that can be= associated with A/N because A/N might be closed and gone. Keeping state is= problematic. On the other hand it is trivial to reject associations with s= treams that have not yet been opened, especially if streams are opened in strict order. Implicit opening of lowe= r valued streams will not work, and is not needed.

--_000_e3d857f1a64148bd8c960052441d3caausma1exdag1mb5msgcorpak_--